Internet-Draft ML-KEM IKEv2 March 2024
Kampanakis & Ravago Expires 30 September 2024 [Page]
Intended Status:
Standards Track
P. Kampanakis
Amazon Web Services
G. Ravago
Amazon Web Services

Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)


[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 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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 30 September 2024.

Table of Contents

1. Introduction

A Cryptanalytically-relevant Quantum Computer (CRQC), if it became a reality, could threaten public key encryption algorithms used today for key exchange. 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. Such communications include Internet Key Exchange Protocol Version 2 (IKEv2).

To address this concern, [RFC8784] 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, [RFC9242] defined how to do additional large message exchanges by using new IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages. As post-quantum publc keys and ciphertexts may make a UDP packet sizes 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. [RFC9370] defined how to do up to seven additional key exchanges by using IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages and deriving 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 [NIST-PQ] 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 [I-D.draft-cfrg-schwabe-kyber-04]. Kyber was then standardized as Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM) in [FIPS203-ipd]. ML-KEM was standardized in 2024 [FIPS203]. [ EDNOTE: Reference normatively the ratified version [I-D.draft-cfrg-schwabe-kyber-04] if it is ever ratified. Otherwise keep a normative reference of [FIPS203]. And remove the reference to [FIPS203-ipd]. ]

This document describes how ML-KEM can be used as the quantum-resistant KEM in IKEv2 by using one additional IKE_INTERMEDIATE or IKE_FOLLOWUP_KE key exchange after an initial key exchange in IKE_SA_INIT or CREATE_CHILD_SA respectively. This approach of combining a quantum-resistant with a classical algorithm, is commonly called Post-Quantum Traditional (PQ/T) Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology-02] key exchange and combines the security of a well-established algorithm with relatively new quantum-resistant algorithms which could theoretically have unknown 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 [RFC9370] and registers new algorithm identifiers for ML-KEM key exchanges in IKEv2.

1.1. KEMs

In the context of the NIST Post-Quantum Cryptography Standardization Project [NIST-PQ], 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'.

  • '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.

1.2. ML-KEM

ML-KEM is a standardized lattice-based key encapsulation mechanism [FIPS203]. [ EDNOTE: Reference normatively the ratified version [I-D.draft-cfrg-schwabe-kyber-04] if it is ever ratified. Otherwise keep a normative reference of [FIPS203]. ]

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-512, 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 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.

1.3. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. ML-KEM in IKEv2


ML-KEM key exchanges can be negotiated in IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages as defined in [RFC9370]. We summarize them here for completeness.

Section 2.2.2 of [RFC9370] 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 [RFC9242]. 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 initiator with ML-KEM KeyGen() and the 256-bit ML-KEM shared secret SK(1) encapsulated by the responder to a ciphertext ct by using Encaps(pk) respectively. The initiator then decapsulates the 256-bit ML-KEM shared secret SK(1) from the ciphertext ct by using its private key sk in Decaps(sk, ct). Both peers have now reached a common SK(1) 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 [RFC9370]. Afterwards the peers continue to the IKE_AUTH exchange phase as defined in Section 3.3.2 of [RFC9242].

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 [RFC9370].

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 [RFC7383].

Although, this document focuses on using ML-KEM as the second key exchange in a PQ/T Hybrid KEM [I-D.ietf-pquip-pqt-hybrid-terminology-02] 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. [EDNOTE: Confirmed with sample captures where the total UDP size does not exceed 1400. ] 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.

2.2. 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). For IKE_FOLLOWUP_KE messages carrying the ML-KEM key exchange, the Exchange Type would be 44 (IKE_FOLLOWUP_KE).

The IKE_INTERMEDIATE or IKE_FOLLOWUP_KE payload is shown below as defined in Section 3.4 of [RFC7296]:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Next Payload  |C|  RESERVED   |         Payload Length        |
|   Key Exchange Method Num    |           RESERVED             |
|                                                               |
~                       Key Exchange Data                       ~
|                                                               |

Table 1 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 specific in this document. [EDNOTE: Confirm fields with packet captures. ] The public key and the ciphertext in the Key Exchange Data are encoded as raw bytes in little-endian encoding. [ EDNOTE: Confirm this makes sense. ]

Table 1: 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

2.3. Recipient Tests

Receiving and handling of malformed ML-KEM public key or ciphertext MUST follow the input validation described in [FIPS203]. [ EDNOTE: Reference normatively the ratified version [I-D.draft-cfrg-schwabe-kyber-04] if it is ever ratified. Otherwise keep a normative reference of [FIPS203]. ] In particular, entities receiving the ML-KEM public key to encapsulate to MUST perform the type and modulus checks in Sections 6.1 of [FIPS203] 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 [FIPS203] and reject the ciphertext or key, if malformed. [ EDNOTE: Reference normatively the ratified version [I-D.draft-cfrg-schwabe-kyber-04] if it is ever ratified. Otherwise keep a normative reference of [FIPS203]. ] 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 [FIPS203] is ratified or change this paragraph. ]

3. Security Considerations

All security considerations from [RFC9242] and [RFC9370] apply to the ML-KEM exchanges described in this specification.

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.

Although ML-KEM is IND-CCA2 secure, reusing the same ML-KEM keypair does not offer perfect forward secrecy. As is the case with (EC)DH, the initiator ought to generate a new ML-KEM keypair with every ML-KEM key exchange.

4. 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:

Table 2: 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, Section 2.3], [TBD, this draft]
TBD36 ml-kem-768 [TBD, this draft, Section 2.3], [TBD, this draft]
TBD37 ml-kem-1024 [TBD, this draft, Section 2.3], [TBD, this draft]
38-1023 Unassigned

5. References

5.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Smyslov, V., "Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9242, DOI 10.17487/RFC9242, , <>.
Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, , <>.

5.2. Informative References

National Institute of Standards and Technology (NIST), "Module-Lattice-based Key-Encapsulation Mechanism Standard", NIST Federal Information Processing Standards, , <>.
Schwabe, P. and B. Westerbaan, "Kyber Post-Quantum KEM", Work in Progress, Internet-Draft, draft-cfrg-schwabe-kyber-04, , <>.
D, F., "Terminology for Post-Quantum Traditional Hybrid Schemes", Work in Progress, Internet-Draft, draft-ietf-pquip-pqt-hybrid-terminology-02, , <>.
National Institute of Standards and Technology (NIST), "Post-Quantum Cryptography", .
Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, , <>.
Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, "Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security", RFC 8784, DOI 10.17487/RFC8784, , <>.


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

Authors' Addresses

Panos Kampanakis
Amazon Web Services
Gerardo Ravago
Amazon Web Services