IP Security Maintenance and Extensions (ipsecme) Internet Drafts

      
 Group Key Management using IKEv2
 
 draft-ietf-ipsecme-g-ikev2-11.txt
 Date: 26/02/2024
 Authors: Valery Smyslov, Brian Weis
 Working Group: IP Security Maintenance and Extensions (ipsecme)
 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. This documents also updates RFC 7296 by renaming a transform type 5 from "Extended Sequence Numbers (ESN)" to the "Replay Protection (RP)" and by renaming IKEv2 authentication method 0 from "Reserved" to "NONE".
 Announcing Supported Authentication Methods in IKEv2
 
 draft-ietf-ipsecme-ikev2-auth-announce-10.txt
 Date: 18/04/2024
 Authors: Valery Smyslov
 Working Group: IP Security Maintenance and Extensions (ipsecme)
 This specification defines a mechanism that allows the Internet Key Exchange version 2 (IKEv2) implementations to indicate the list of supported authentication methods to their peers while establishing IKEv2 Security Association (SA). This mechanism improves interoperability when IKEv2 partners are configured with multiple credentials of different type to authenticate each other.
 IKEv2 support for per-resource Child SAs
 
 draft-ietf-ipsecme-multi-sa-performance-06.txt
 Date: 19/03/2024
 Authors: Antony Antony, Tobias Brunner, Steffen Klassert, Paul Wouters
 Working Group: IP Security Maintenance and Extensions (ipsecme)
 This document defines two Notify Message Type Payloads for the Internet Key Exchange Protocol Version 2 (IKEv2) to support the negotiation of multiple Child SAs with the same Traffic Selectors used on different resources, such as CPUs, to increase bandwidth of IPsec traffic between peers. The SA_RESOURCE_INFO notification is used to convey information that the negotiated Child SA and subsequent new Child SAs with the same Traffic Selectors are a logical group of Child SAs where most or all of the Child SAs are bound to a specific resource, such as a specific CPU. The TS_MAX_QUEUE notify conveys that the peer is unwilling to create more additional Child SAs for this particular negotiated Traffic Selector combination. Using multiple Child SAs with the same Traffic Selectors has the benefit that each resource holding the Child SA has its own Sequence Number Counter, ensuring that CPUs don't have to synchronize their cryptographic state or disable their packet replay protection.
 IKEv2 Optional SA&TS Payloads in Child Exchange
 
 draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-02.txt
 Date: 12/01/2024
 Authors: Sandeep Kampati, Wei Pan, Paul Wouters, Bharath Meduri, Meiling Chen
 Working Group: IP Security Maintenance and Extensions (ipsecme)
 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 Header Compression Profile
 
 draft-ietf-ipsecme-diet-esp-00.txt
 Date: 18/03/2024
 Authors: Daniel Migault, Tobias Guggemos, Carsten Bormann, David Schinazi
 Working Group: IP Security Maintenance and Extensions (ipsecme)
 ESP Header Compression Profile (EHCP) defines a profile to compress communications protected with IPsec/ESP.
 Internet Key Exchange version 2 (IKEv2) extension for the ESP Header Compression (EHC)
 
 draft-ietf-ipsecme-ikev2-diet-esp-extension-00.txt
 Date: 18/03/2024
 Authors: Daniel Migault, Tobias Guggemos, David Schinazi
 Working Group: IP Security Maintenance and Extensions (ipsecme)
 This document describes an IKEv2 extension of for the ESP Header Compression (EHC) to agree on a specific ESP Header Compression (EHC) Context.
 Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security
 
 draft-ietf-ipsecme-ikev2-qr-alt-00.txt
 Date: 16/04/2024
 Authors: Valery Smyslov
 Working Group: IP Security Maintenance and Extensions (ipsecme)
 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 it later, when (and if) cryptographically relevant quantum computers are available. The protection is achieved by means of Post-quantum Preshared Key (PPK) which is mixed into the session keys calculation. However, this protection doesn't cover an initial IKEv2 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. Besides, RFC8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 Security Association (SA) is created. If a fresh PPK is available before the IKE SA is 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 also defines a way to use PPKs in active IKEv2 SA for creating additional IPsec SAs and for rekeys operations.

data-group-menu-data-url="/group/groupmenu.json">

IP Security Maintenance and Extensions (ipsecme)

WG Name IP Security Maintenance and Extensions
Acronym ipsecme
Area Security Area (sec)
State Active
Charter charter-ietf-ipsecme-13 Approved
Status update Show Changed 2024-03-19
Document dependencies
Additional resources Issue tracker, Wiki, Zulip stream
Personnel Chairs Tero Kivinen, Yoav Nir
Area Director Deb Cooley
Mailing list Address ipsec@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/ipsec
Archive https://mailarchive.ietf.org/arch/browse/ipsec/
Chat Room address https://zulip.ietf.org/#narrow/stream/ipsecme

Charter for Working Group

The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec
security architecture (RFC 4301). IPsec is widely deployed in VPN
gateways, VPN remote access clients, and as a substrate for
host-to-host, host-to-network, and network-to-network security.

The IPsec Maintenance and Extensions Working Group continues the work
of the earlier IPsec Working Group which was concluded in 2005. Its
purpose is to maintain the IPsec standard and to facilitate discussion
of clarifications, improvements, and extensions to IPsec, mostly to
ESP and IKEv2. The working group also serves as a focus point for
other IETF Working Groups who use IPsec in their own protocols.

The current work items include:

IKEv1 using shared secret authentication was partially resistant to
quantum computers. IKEv2 removed this feature to make the protocol
more usable. The working group will add a mode to IKEv2 or otherwise
modify the shared-secret mode of IKEv2 to have similar or better quantum
resistant properties to those of IKEv1.

Currently, widely used counter mode based ciphers send both the ESP
sequence number and IV in the form of a counter, as they are very
commonly the same. There has been interest to work on a document that
will compress the packet and derive IV from the sequence number
instead of sending it in separate field. The working group will
specify how this compression can be negotiated in the IKEv2, and
specify how the encryption algorithm and ESP format is used in this
case.

The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based
protocol for negotiating group keys for both multicast and unicast
uses. The Working Group will develop an IKEv2-based alternative that
will include cryptographic updates. A possible starting point is
draft-yeung-g-ikev2.

Postquantum Cryptography brings new key exchange methods. Most of
these methods that are known to date have much larger public keys than
conventional Diffie-Hellman public keys. Directly using these methods in
IKEv2 might lead to a number of problems due to the increased size of
initial IKEv2 messages. The working group will analyze the possible
problems and develop a solution, that will make adding Postquantum key
exchange methods more easy. The solution will allow post quantum key
exchange to be performed in parallel with (or instead of) the existing
Diffie-Hellman key exchange.

A growing number of use cases for constrained networks - but not
limited to those networks - have shown interest in reducing ESP (resp. IKEv2)
overhead by compressing ESP (resp IKEv2) fields. The WG will define
extensions of ESP and IKEv2 to enable ESP header compression.

Possible starting points are draft-mglt-ipsecme-diet-esp,
draft-mglt-ipsecme-ikev2-diet-esp-extension,
draft-smyslov-ipsecme-ikev2-compression and
draft-smyslov-ipsecme-ikev2-compact.

RFC7427 allows peers to indicate hash algorithms they support, thus
eliminating ambiguity in selecting a hash function for digital
signature authentication. However, advances in cryptography lead to a
situation when some signature algorithms have several signature
formats. A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS; however
it is envisioned that the same situation may repeat in future with
other signature algorithms. Currently IKE peers have no explicit way
to indicate to each other which signature format(s) they support. That
leads to interoperability problems. The WG will investigate the
situation and come up with a solution that allows peers to deal with
the problem in an interoperable way.

RFC7296 defines a generic notification code that is related to a
failure to handle an internal address failure. That code does not
explicitly allow an initiator to determine why a given address family
is not assigned, nor whether it should try using another address
family. The Working Group will specify a set of more specific
notification codes that will provide sufficient information to the
IKEv2 initiator about the encountered failure. A possible starting
pointing is draft-boucadair-ipsecme-ipv6-ipv4-codes.

Some systems support security labels (aka security context) as one of
the selectors of the SPD. This label needs to be part of the IKE
negotiation for the IPsec SA. Non-standard implementations exist for
IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now
using private space IPSEC Security Association Attribute 32001). The
work is to standarize this for IKEv2, in a way that will be backwards
compatible with old implementations, meaning it must not require any
changes to implementations not supporting this.

RFC8229, published in 2017, specifies how to encapsulate
IKEv2 and ESP traffic in TCP. Implementation experience has
revealed that not all situations are covered in RFC8229, and that may
lead to interoperability problems or to suboptimal performance. The WG
will provide a document to give implementors more guidance about how to use
reliable stream transport in IKEv2 and clarify some issues that have been
discovered. A possible starting point is draft-smyslov-ipsecme-tcp-guidelines.

The demand for Traffic Flow Confidentiality has been increasing in the user
community, but the current method defined in RFC4303 (adding null
padding to each ESP payload) is very inefficient in its use of network
resources. The working group will develop an alternative TFC solution that
uses network resources more efficiently.

Milestones

Date Milestone Associated documents
Jul 2022 G-DOI for IKEv2 to IESG draft-ietf-ipsecme-g-ikev2
Jun 2021 Signature algorithm negotiation for IKEv2 to IESG
Jun 2021 The ESP on contrained network to IESG

Done milestones

Date Milestone Associated documents
Done The security labels support for IKEv2 to IESG draft-ietf-ipsecme-labeled-ipsec
Done TCP-encapsulation guidelines document to IESG draft-ietf-ipsecme-rfc8229bis
Done Postquantum cryptography document for IKEv2 to IESG draft-ietf-ipsecme-ikev2-intermediate
draft-ietf-ipsecme-ikev2-multiple-ke
Done Traffic Flow Confidentiality document to IESG draft-hopps-ipsecme-iptfs
Done The internal address failure indication in IKEv2 to IESG draft-ietf-ipsecme-ipv6-ipv4-codes