]> Amazon Web Services

kpanos@amazon.com

Amazon Web Services

gcr@amazon.com

Security IPSECME Internet-Draft [EDNOTE: The intention of this draft is to get IANA KE codepoints for ML-KEM. It could be a standards track draft given that ML-KEM will see a lot of adoption, an AD sponsored draft, or even an individual stable draft which gets codepoints from Expert Review. The approach is to be decided by the IPSECME WG. ] 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 additionall key exchange mechanism in IKEv2 along with traditional (Elliptic Curve) Diffie-Hellman. This hybrid approach allows for negotiating IKE and Child SA keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM as it is relatively new.

Introduction A Cryptanalytically-relevant Quantum Computer (CRQC), if it became a reality, could threaten public key encryption algorithms used today for key exhange. Someone storing encrypted communications which use (Elliptic Curve) Diffie-Hellman ((EC)DH) to negotiate keys could decrypt these communications in the future after a CRQC was available. This could include Internet Key Exchange Protocol Version 2 (IKEv2)/IPsec tunnels which negotiate IKE and Child SA keys by using ECDH key exchange in their IKE_SA_INIT messages. To address this concern, 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. Since then, defined how to do additional large message exchanges by using a new IKE_INTERMEDIATE message. As post-quantum keys are usualy larger than common network Maximum Transport Units (MTU), IKE_INTERMEDIATE messages can be fragmented which could allow for the peers to do post-quantum key exchanges without IP fragmentation. defined how to do up to seven additional key exchanges by using IKE_INTERMEDIATE messages and derive new SKEYSEED and KEYMAT key materials. This allows for new post-quantum key exchanges to be used in the derived IKE and Child SA keys and provide quantum resistance. NIST has been working on a public project for standardizing quantum-safe algorithms which include key ensapsulation 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 . ML-KEM was standardized in 2024 . [ EDNOTE: Reference normatively the ratified version if it is ever ratified. Otherwise keep a normative reference of . And remove the reference to . ] This document describes how ML-KEM can be used as the quantum-safe KEM in IKEv2 by using one additional IKE_INTERMEDIATE key exchange after the classical (EC)DH exchange in IKE_SA_INIT. This approach is commonly called post-quantum hybrid key exchange and combines the security of well-established (EC)DH with relatively new quantum-safe algorithms which could theoretically have uknown issues. The result is a new Child SA key or an IKE or Child SA rekey with keying material which is safe against a CRQC. This specification is a profile of 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 key 'pk' and a secret key 'sk'.
• 'Encaps(pk) -> (ct, ss)': A probabilistic encapsulation algorithm, which takes as input a public key 'pk' and outputs a ciphertext 'ct' and shared secret 'ss'.
• 'Decaps(sk, ct) -> ss': A decapsulation algorithm, which takes as input a secret key 'sk' and ciphertext 'ct' and outputs a shared secret 'ss', or in some cases a distinguished error value.

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.

ML-KEM ML-KEM is a recently standardized lattice-based key encapsulation mechanism . [ EDNOTE: Reference normatively the ratified version if it is ever ratified. Otherwise keep a normative reference of . ] ML-KEM is using 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. This specification introduces ML-KEM-768 and ML-KEM-1024 to IKEv2 key exchanges as conservative security level parameters which will not have material performance impact on IKEv2/IPsec tunnels which usually stay up for long periods of time. Since the ML-KEM-768 and ML-KEM-1024 public key and ciphertext sizes can exceed the typical network MTU, these key exchanges will usually 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 messages ML-KEM key exchanges can be negotiated in IKE_INTERMEDIATE messages as defined in . Section 2.2.2 of specifies that KEi(0), KEr(0) are regular (EC)DH key exchange messages in the first IKE_SA_INIT exchange which end up generating a first 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 . KEi(1) and KEr(1) are the subsequent key exchange messages which carry the ML-KEM public key of a keypair (sk, pk) generated by the initiators with ML-KEM KeyGen() and the 256-bit ML-KEM shared secret ss encapsulated by the responder to a ciphertext ct by using Encaps(pk) respectively. The public key and the ciphertext are encoded as raw bytes in little-endian encoding. [ EDNOTE: Confirm this makes sense. ] Then the initiator decapsulates the 256-bit ML-KEM shared secret ss from the ciphertext ct by using its private key sk in Decaps(sk, ct). Both peers have now reached a common ss at the end of this KE(1) key 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 . Afterwards the peers continue to the IKE_AUTH exchange phase as defined in Section 3.3.2 of . ML-KEM can be used in a post-quantum hybrid exchange to create or rekey a Child SA or rekey the IKE SA. The IKE or Child SA can be rekeyed by stirring the new shared secret in SKEYSEED and KEYMAT as specified in Section 2.2.4 of . IKE_INTERMEDIATE messages carrying ML-KEM public keys and ciphertexts, can be fragmented as per since the ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts can exceed typical network MTUs. Although, this document focuses on using ML-KEM as the second key exchange in a post-quantum hybrid key exchange scenario, ML-KEM-768 Key Exchange Method identifier TBD35 MAY be used in IKE_SA_INIT as a quantum-safe-only key exchange because the payloads can fit in typical network MTUs. [EDNOTE: Confirm it fits the MTU with captures.] ML-KEM-1024 Key Exchange Method identifier TBD36 SHOULD only be used in IKE_INTERMEDIATE exchanges. It SHOULD NOT be used in IKE_SA_INIT because they could often be introducing IP fragmentation which is not possible in IKE_SA_INIT exchanges.

Key Exchange Payload HDR, the IKE header, of the IKE_INTERMEDIATE messages carrying the ML-KEM key exchange has a Next Payload value of 34 (Key Exchange), Exchange Type of 43 (IKE_INTERMEDIATE) and Message ID of 1 assuming this is the first additional key exchange (ADDKE1). The IKE_INTERMEDIATE payload which is protected with SK_e[i/r] and SK_a[i/r] keys from the IKE_SA_INIT ML-KEM key exchange is shown below as defined in Section 3.4 of :

• Payload Length: The ML-KEM-768 public key is 1184 bytes, so the Payload Length field included in the payload of the IKE_INTERMEDIATE message from the initiator is 1192. The ML-KEM-768 ciphertext is 1088 bytes, so the Payload Length of IKE_INTERMEDIATE message from the responder is 1096. The ML-KEM-1024 public key is 1568 bytes, so the Payload Length field included in the payload of the IKE_INTERMEDIATE from the initiator is 1576. The ML-KEM-1024 ciphertext is 1568 bytes, so the Payload Length of IKE_INTERMEDIATE from the responder is 1576.
• The Key Exchange Method Num identifier is TBD35 for ML-KEM-768 or TBD36 for ML-KEM-1024.
• The Key Exchange Data is the 1184 or 1568 octets of the ML-KEM-768 or ML-KEM-1024 public key respectively for the IKE_INTERMEDIATE message from the initiator. The response from the responder is 1088 or 1568 octets as the size of the ML-KEM-768 or ML-KEM-1024 ciphertexts respectively.

Recipient Tests Receiving and handling of malformed ML-KEM public key or ciphertext MUST follow the input validation described in . [ EDNOTE: Reference normatively the ratified version if it is ever ratified. Otherwise keep a normative reference of . ] In particular, entities receiving the ML-KEM public key to encapsulate to MUST perform the type and modulus checks in Sections 6.1 of and reject the ML-KEM public key, if malformed. Entities receiving an ML-KEM ciphertext for decapsulation MUST perform the ciphertext and decapsulation key type checks in Section 6.2 of and reject the ciphertext or key, if malformed. [ EDNOTE: Reference normatively the ratified version if it is ever ratified. Otherwise keep a normative reference of . ] These checks could be performed separately before performing the encapsulation or decapsulation steps or be part of them. 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. [ EDNOTE: Confirm implicit rejection is still used after is ratified or change this paragraph. ]

Security Considerations All security considerations from and apply to the ML-KEM exchanges described in this specification.

IANA Considerations IANA is requested to assign two values for the names "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	mlkem-768		[TBD, this draft, ],	[TBD, this draft]
TBD36	mlkem-1024		[TBD, this draft, ],	[TBD, this draft]
37-1023	Unassigned

References Normative References 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. This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs. This document updates RFC 7296 by renaming a Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. 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. This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. Informative References National Institute of Standards and Technology (NIST) 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 memo specifies a preliminary version ("draft00", "v3.02") of Kyber, an IND-CCA2 secure Key Encapsulation Method. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://bwesterb.github.io/draft-schwabe-cfrg-kyber/draft-cfrg- schwabe-kyber.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/. Source for this draft and an issue tracker can be found at https://github.com/bwesterb/draft-schwabe-cfrg-kyber. 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.

Acknowledgments The authors would like to thank Valery Smyslov for his valuable contributions to the document.