| |
|
| |
| | Group Key Management using IKEv2 |
| |
|
This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components are required for a GCKS (Group Controller/Key Server) to provide authorized Group Members (GMs) with IPsec group security associations. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. |
| | Optimized Rekeys in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges used for rekeying of the IKE or Child SA by replacing the SA and TS payloads with a Notify Message payload. Reducing size and complexity of IKEv2 exchanges is especially useful for low power consumption battery powered devices. |
| | ESP Echo Protocol |
| |
|
This document defines an ESP echo function which can be used to detect whether a given network path supports ESP packets. |
| | ESP Header Compression with Diet-ESP |
| |
| | draft-ietf-ipsecme-diet-esp-06.txt |
| | Date: |
16/03/2025 |
| | Authors: |
Daniel Migault, Maryam Hatami, Sandra Cespedes, J. Atwood, Daiying Liu, Tobias Guggemos, Carsten Bormann, David Schinazi |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document specifies Diet-ESP, a compression mechanism for control information in IPsec/ESP communications. The compression is expressed through the Static Context Header Compression architecture. |
| | Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP) |
| |
| | draft-ietf-ipsecme-ikev2-diet-esp-extension-05.txt |
| | Date: |
16/03/2025 |
| | Authors: |
Daniel Migault, Maryam Hatami, Daiying Liu, Stere Preda, J. Atwood, Sandra Cespedes, Tobias Guggemos, David Schinazi |
| | Working Group: |
IP Security Maintenance and Extensions (ipsecme) |
|
This document describes an IKEv2 extension for Header Compression to agree on Attributes for Rule Generation. This extension defines the necessary registries for the ESP Header Compression Profile (EHCP) Diet-ESP. |
| | Mixing Preshared Keys in the IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security |
| |
|
An Internet Key Exchange protocol version 2 (IKEv2) extension defined in RFC8784 allows IPsec traffic to be protected against someone storing VPN communications today and decrypting them later, when (and if) cryptographically relevant quantum computers are available. The protection is achieved by means of a Post-quantum Preshared Key (PPK) which is mixed into the session keys calculation. However, this protection does not cover an initial IKEv2 Security Association (SA), which might be unacceptable in some scenarios. This specification defines an alternative way to get protection against quantum computers, which is similar to the solution defined in RFC8784, but protects the initial IKEv2 SA too. RFC8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 SA is created. If a fresh PPK is available before the IKE SA expired, then the only way to use it is to delete the current IKE SA and create a new one from scratch, which is inefficient. This specification defines a way to use PPKs in active IKEv2 SAs for creating additional IPsec SAs and rekey operations. |
| | Renaming Extended Sequence Number (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
This document clarifies and extends the meaning of transform type 5 in IKEv2. It updates RFC 7296 by renaming the transform type 5 from "Extended Sequence Numbers (ESN)" to "Sequence Numbers (SN)". It also renames two currently defined values for this transform type: value 0 from "No Extended Sequence Numbers" to "32-bit Sequential Numbers" and value 1 from "Extended Sequence Numbers" to "Partially Transmitted 64-bit Sequential Numbers". |
| | Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using ML-DSA and SLH-DSA |
| |
|
Signature-based authentication methods are utilized in IKEv2 [RFC7296]. The current version of the Internet Key Exchange Version 2 (IKEv2) protocol supports traditional digital signatures. This document outlines how post-quantum digital signatures, specifically Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH-DSA), can be employed as authentication methods within the IKEv2 protocol. It adds ML-DSA and SLH-DSA capabilities to IKEv2 while preserving existing IKEv2 operations. |
| | IKEv2 negotiation for Bound End-to-End Tunnel (BEET) mode ESP |
| |
|
This document specifies a new Notify Message Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2), to negotiate IPsec ESP Bound End-to-End Tunnel (BEET) mode. BEET mode combines the benefits of tunnel mode with reduced overhead, making it suitable for applications requiring minimalistic end-to-end tunnels, mobility support, and multi-address multi-homing capabilities. The introduction of the USE_BEET_MODE Notify Message enables the negotiation and establishment of BEET mode security associations. |
| | Encrypted ESP Echo Protocol |
| |
|
This document defines the Encrypted ESP Echo Function, a mechanism designed to assess the reachability of IP Security (IPsec) network paths using Encapsulating Security Payload (ESP) packets. The primary objective is to reliably and efficiently detect the status of end-to-end paths by exchanging only encrypted ESP packets between IPsec peers. The Encrypted Echo message can either use existing congestion control payloads from RFC9347 or a new message format defined here, with an option to specify a preferred return path when there is more than one pair of IPsec SAs between the same set of IPsec peers. A peer MAY announce the support using a new IKEv2 Status Notifcation ENCRYPTED_PING_SUPPORTED. |