]> Amazon Web Services

kpanos@amazon.com

Security IPSECME Internet-Draft NIST recently standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft specifies how to use ML-KEM as an additional key exchange in IKEv2 along with traditional key exchanges. This Post-Quantum Traditional Hybrid Key Encapsulation Mechanism approach allows for negotiating IKE and Child SA keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM.

Introduction A Cryptanalytically-relevant Quantum Computer (CRQC), if it became a reality, could threaten today's public key establishment algorithms. Someone storing encrypted communications that use (Elliptic Curve) Diffie-Hellman ((EC)DH) to establish keys could decrypt these communications in the future after a CRQC became available to them. Such communications include Internet Key Exchange Protocol Version 2 (IKEv2). To address this concern, the Mixing Preshared Keys in IKEv2 specification introduced Post-quantum Preshared Keys as a temporary option for stirring a pre-shared key of adequate entropy in the derived Child SA encryption keys in order to provide quantum-resistance. This specification can be used in conjunction with PPK as defined in . Since then, NIST has been working on a public project for standardizing quantum-resistant algorithms which include key encapsulation and signatures. At the end of Round 3, they picked Kyber as the first Key Encapsulation Mechanism (KEM) for standardization . Kyber was then standardized as Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM) in 2024 . As post-quantum public keys and ciphertexts may make UDP packet sizes larger than common network Maximum Transport Units (MTU), the Intermediate Exchange in IKEv2 document defined how to do additional large message exchanges by using new IKE_INTERMEDIATE messages. IKE_INTERMEDIATE messages can only be used after IKE_SA_INIT. The Multiple Key Exchanges in IKEv2 specification defined how to do up to seven additional key exchanges by using IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages and by deriving new SKEYSEED and KEYMAT key materials. These messages can be fragmented at the IKEv2 layer before causing IP fragmentation . If a post-quantum KEM does not fit inside IKE_SA_INIT without causing IP fragmentation, then it should be used after IKE_SA_INIT in an IKE_INTERMEDIATE or IKE_FOLLOWUP_KE message as an additional key establishment algorithm. This document describes how ML-KEM can be used as a quantum-resistant KEM in IKEv2 in an IKE_SA_INIT key exchange, or in one additional IKE_INTERMEDIATE or IKE_FOLLOWUP_KE key exchange after an initial IKE_SA_INIT or CREATE_CHILD_SA respectively. This approach of combining a quantum-resistant with a traditional algorithm, is commonly called Post-Quantum Traditional (PQ/T) Hybrid key exchange and combines the security of a well-established algorithm with relatively new quantum-resistant algorithms. The result is a new Child SA key or an IKE or Child SA rekey with keying material which is safe against a CRQC. Another use of a PQ/T Hybrid key exchange in IKEv2 is for someone that wants to exchange keys using the high security parameter of ML-KEM. As these may not fit in common network packet payload sizes, they will need to be sent in a IKE_FOLLOWUP_KE or CREATE_CHILD_SA key exchange which can be fragmented. This specification is a profile of the Multiple Key Exchanges in IKEv2 specification and registers new algorithm identifiers for ML-KEM key exchanges in IKEv2.

KEMs In the context of the NIST Post-Quantum Cryptography Standardization Project , key exchange algorithms are formulated as KEMs, which consist of three steps:

• 'KeyGen() -> (pk, sk)': A probabilistic key generation algorithm, which generates a public / encapsulation key 'pk' and a private / decapsulation key 'sk'. The resulting pk is sent to the responder in the KEi payload.
• 'Encaps(pk) -> (ct, ss)': A probabilistic encapsulation algorithm, which takes as input a public key 'pk' (from the KEi) and outputs a ciphertext 'ct' and shared secret 'ss'. The 'ct' is sent back to intiator in the KEr payload.
• 'Decaps(sk, ct) -> ss': A decapsulation algorithm, which takes as input a secret key 'sk' and ciphertext 'ct' (from the KEr) and outputs a shared secret 'ss', or in some rare cases a distinguished error value.

ML-KEM ML-KEM is a standardized lattice-based key encapsulation mechanism . It uses Module Learning with Errors as its underlying primitive which is a structured lattices variant that offers good performance and relatively small and balanced key and ciphertext sizes. ML-KEM was standardized with three parameters, ML-KEM-512, ML-KEM-768, and ML-KEM-1024. These were mapped by NIST to the three security levels defined in the NIST PQC Project, Level 1, 3, and 5. These levels correspond to the hardness of breaking AES-128, AES-192 and AES-256 respectively. ML-KEM-512, ML-KEM-768 and ML-KEM-1024 key exchanges will not have material performance impact on IKEv2/IPsec tunnels which usually stay up for long periods of time and transfer sizable amounts of data. Since the ML-KEM-768 and ML-KEM-1024 public key and ciphertext sizes can exceed the typical network MTU, these key exchanges could require two or three network IP packets from both the initiator and the responder.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

ML-KEM in IKEv2

ML-KEM in IKE_INTERMEDIATE or CREATE_CHILD_SA messages ML-KEM key exchanges can be negotiated in IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages as defined in the Multiple Key Exchanges in IKEv2 specification . We summarize them here for completeness. Section 2.2.2 of specifies that KEi(0), KEr(0) are regular key exchange messages in the first IKE_SA_INIT exchange which end up generating a set of keying material, SK_d, SK_a[i/r], and SK_e[i/r]. The peers then perform an IKE_INTERMEDIATE exchange, carrying new Key Exchange payloads. These are protected with the SK_e[i/r] and SK_a[i/r] keys which were derived from the IKE_SA_INIT as per Section 3.3.1 of the Intermediate Exchange in IKEv2 document . The initiator generates an ML-KEM keypair (sk, pk) using KeyGen(), and sends the public key (pk) to the responder inside a KEi(1) payload. The responder will encapsulate a shared secret ss using Encaps(pk) and the resulting ciphertext (ct) is sent to initiator using the KEr(1). After the initiator receives KEr(1), it will decapsulate it using Decaps(sk, ct). Both Encaps and Decaps return the shared secret (ss) and both peers have a common shared secret SK(1) at the end of this KE(1) exchange. The ML-KEM shared secret is stirred into new keying material SK_d, SK_a[i/r], and SK_e[i/r] as defined in Section 2.2.2 of the Multiple Key Exchanges in IKEv2 document . Afterwards the peers continue to the IKE_AUTH exchange phase as defined in Section 3.3.2 of the Intermediate Exchange in IKEv2 specification . ML-KEM can also be used to create or rekey a Child SA or rekey the IKE SA by using a IKE_FOLLOWUP_KE message after a CREATE_CHILD_SA message. After the ML-KEM additional key exchange KE(1) has taken place using and IKE_FOLLOWUP_KE exchange, the IKE or Child SA are rekeyed by stirring the new ML-KEM shared secret SK(1) in SKEYSEED and KEYMAT as specified in Section 2.2.4 of . ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts may make UDP packet sizes larger typical network MTUs (1500 bytes). Thus, IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages carrying ML-KEM public keys and ciphertexts may be IKEv2 fragmented as per the IKEv2 Message Fragmentation specification . Although, this document focuses on using ML-KEM as the second key exchange in a PQ/T Hybrid KEM scenario, ML-KEM-512 and ML-KEM-768 Key Exchange Method identifiers TBD35 and TBD36 respectively MAY be used in IKE_SA_INIT as a quantum-resistant-only key exchange. The encapsulation key and ciphertext sizes for these ML-KEM parameters may not push the UDP packet to size larger than typical network MTUs of 1500 bytes. ML-KEM-1024 Key Exchange Method identifier TBD37 SHOULD NOT be used in IKE_SA_INIT messages which could exceed typical network MTUs and cannot be IKEv2 fragmented.

Key Exchange Payload The KE payload is shown below and the fields inside it has meaning as defined in Section 3.4 of the IKEv2 standard : The Key Exchange Data from the initiator to the responder contains the public key (pk) from the KeyGen() operation encoded as a raw byte array (i.e., output of ByteEncode) as defined in Section 7.1 of Module-Lattice-Based KEM standard . The Key Exchange Data from the responder to the initiator contains the ciphertext (ct) from the Encaps operation encoded as a raw byte array. shows the Payload Length, Key Exchange Method Num identifier and the Key Exchange Data Size in octets for Key Exchange Payloads from the initiator and the responder for the ML-KEM variants specified in this document. Key Exchange Payload Fields

KEM	Payload Length (initiator / responder)	Key Exchange Method Num	Data Size in Octets (initiator / responder)
ML-KEM-512	808 / 776	TBD35	800 / 768
ML-KEM-768	1192 / 1096	TBD36	1184 / 1088
ML-KEM-1024	1576 / 1576	TBD37	1568 / 1568

Recipient Tests Receiving and handling of malformed ML-KEM public keys or ciphertexts SHOULD follow the input validation described in the Module-Lattice-Based KEM standard . Responders SHOULD perform the checks specified in section 7.2 of the Module-Lattice-Based KEM standard before the Encaps(pk) operation. If the checks fail, the responder SHOULD send a Notify payload of type INVALID_SYNTAX as a response to the request from initiator. Initiators SHOULD perform the Ciphertext type check specified in section 7.3 of the Module-Lattice-Based KEM standard before the Decaps(sk, ct) operation. If the check fails, the initiator MUST reject the ciphertext and MUST fail the exchange. In this case, the initiator MAY send a Notify payload of type INVALID_SYNTAX to the responder as a separate INFORMATIONAL exchange, usually with no other payloads. This is an exception for the general rule of not starting new exchanges based on errors in responses. Note that during decapsulation, ML-KEM uses implicit rejection which leads the decapsulating entity to implicitly reject the decapsulated shared secret by setting it to a hash of the ciphertext together with a random value stored in the ML-KEM secret when the re-encrypted shared secret does not match the original one.

Security Considerations All security considerations from and apply to the ML-KEM exchanges described in this specification. The main security property for KEMs standardized by NIST is indistinguishability under adaptive chosen ciphertext attacks (IND-CCA2), which means that shared secret values should be indistinguishable from random strings even given the ability to have arbitrary ciphertexts decapsulated. IND-CCA2 corresponds to security against an active attacker, and the public key / secret key pair can be treated as a long-term key or reused. A weaker security notion is indistinguishability under chosen plaintext attacks (IND-CPA), which means that the shared secret values should be indistinguishable from random strings given a copy of the public key. IND-CPA roughly corresponds to security against a passive attacker, and sometimes corresponds to one-time key exchange. As with (EC)DH keys today, generating an ephemeral key exchange keypair for ECDH and ML-KEM is still REQUIRED per connection by this specification (IND-CPA security). The ML-KEM public key generated by the initiator and the ciphertext generated by the responder use randomness (usually a seed) which MUST be independent of any other random seed used in the IKEv2 negotiation. For example, at the initiator, the ML-KEM and (EC)DH keypairs used in a PQ/T Hybrid key exchange should not be generated from the same seed. SKEYSEED and KEYMAT in this specification are generated from PQ/T Hybrid key exchanges by using shared secrets, nonces, and SPIs with a pseudorandom function as defined in . As discussed in , such PQ/T Hybrid key derivations are IND-CPA, but not proven to be IND-CCA2 secure although the keys could be reused if the nonces are never reused. IKEv2 is susceptible to downgrades where a man-in-the-middle could force an initiator and responder to perform a key exchange using algorithms of the attacker's choice although both parties support other algorithms as well . The reason for this issue is that IKEv2 does not authenticate messages exchanged by both parties. Instead, it authentication messages in one direction. A long-term solution for this issue in IKEv2 is proposed in . In the context of this specification, an adversary could force the two parties to use classical key exchange although they both support quantum-resistant ML-KEM and would prefer it if they were aware that their peer supports it. IKE_INTERMEDIATE messages do not introduce a new downgrade risk which did not exist previously. Note that this risk would require the adversary to be able control the whole flow between the paries and sinkhole, delay or drop legitimate messages as necessary. For post-quantum deployments where the responder is upgraded to support ML-KEM before any initiator, the initiator could enforce a hard requirement for using ML-KEM in the IKE_SA_INIT or the IKE_INTERMEDIATE before encrypting any data in any Child SA or fail the negotiation. This is the most straightforward protection against downgrades in cases where the responder is upgraded before any initiator. Otherwise, supports Childless IKE SAs which can be followed by a Child SA after a FOLLOWUP_KE exhange with ML-KEM. Establishing a Childless IKE SA or a Child SA which does not encrypt any data and establishing a Child SA or rekeying the existing one with a FOLLOWUP_KE exhange with ML-KEM ensures that the initiator or responder can enforce a policy which requires ML-KEM for peers expected to support ML-KEM after learning their identity in IKE_AUTH. Although this approach would prevent downgrades where an adversary can force peers that support ML-KEM to use classical key exchanges, it assumes the initiator or responder know the identities of their peers that support ML-KEM. It also has the disadvantage that an adversary with a quantum computer that can decrypt the initial IKE SA has access to all the information exchanged over it, such as identities of the peers, configuration parameters, and all negotiated SA information (including traffic selectors), with the exception of the cryptographic keys used by the IPsec SAs which are established after the ML-KEM key exchange.

IANA Considerations IANA is requested to assign three values for the names "mlkem-512", "mlkem-768", and "mlkem-1024" in the IKEv2 "Transform Type 4 - Key Exchange Method Transform IDs" and has listed this document as the reference. The Recipient Tests field should also point to this document: Updates to the IANA "Transform Type 4 - Key Exchange Method Transform IDs" table

Number	Name	Status	Recipient Tests	Reference
TBD35	ml-kem-512		[TBD, this draft, ],	[TBD, this draft]
TBD36	ml-kem-768		[TBD, this draft, ],	[TBD, this draft]
TBD37	ml-kem-1024		[TBD, this draft, ],	[TBD, this draft]
38-1023	Unassigned

References Normative References National Institute of Standards and Technology (NIST) This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment. The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References UK National Cyber Security Centre UK National Cyber Security Centre Naval Postgraduate School National Institute of Standards and Technology (NIST) The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys. MPI-SP & Radboud University Cloudflare This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through. ELVIS-PLUS

Acknowledgments The authors would like to thank Valery Smyslov, Graham Bartlett, Scott Fluhrer, Ben S, Leonie Bruckert, and Gerardo Ravago for their valuable feedback.