Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (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 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.¶

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-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 could require two or three network IP packets from both the initiator and the responder. [ EDNOTE: Consider adding ML-KEM-512 which would fit in one packet. ]¶

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.1. 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 [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 public key and the ciphertext are encoded as raw bytes in little-endian encoding. [ EDNOTE: Confirm this makes sense. ] 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 can exceed typical network MTUs (1500 bytes). Thus, IKE_INTERMEDIATE messages carrying ML-KEM public keys and ciphertexts may be IKEv2 fragmented as per [RFC7383]. IKE_FOLLOWUP_KE messages carrying ML-KEM public keys and ciphertexts cannot be IKEv2 fragmented. Thus, ML-KEM-1024 Key Exchange Method identifier TBD37 SHOULD only be used in IKE_INTERMEDIATE exchanges. It SHOULD NOT be used in IKE_FOLLOWUP_KE messages until there is a separate document which defines how such exchanges are split in several messages. [EDNOTE: Confirm ML-KEM-768 fits the MTU with captures, otherwise recommend against ML-KE-768 in IKE_FOLLOWUP_KE as well.] [ EDNOTE: Consider adding ML-KEM-512 which would fit in one packet. ]¶

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-768 Key Exchange Method identifier TBD36 MAY be used in IKE_SA_INIT as a quantum-resistant-only key exchange because the encapsulation key is 1184 bytes, which assuming an additional 250 bytes of IKE header data, can fit in typical network MTUs of 1500 bytes. [EDNOTE: Confirm it fits the MTU with captures.] 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. [ EDNOTE: Consider adding ML-KEM-512 which would fit in one packet. ]¶

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                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• Payload Length: The ML-KEM-768 public key is 1184 bytes, so the Payload Length field from the initiator would be 1192. The ML-KEM-768 ciphertext is 1088 bytes, so the Payload Length from the responder would be 1096. The ML-KEM-1024 public key is 1568 bytes, so the Payload Length field from the initiator would be 1576. The ML-KEM-1024 ciphertext is 1568 bytes, so the Payload Length from the responder would be 1576. [ EDNOTE: Consider adding ML-KEM-512 which would fit in one packet. ]¶

• The Key Exchange Method Num identifier is TBD36 for ML-KEM-768 or TBD37 for ML-KEM-1024. [ EDNOTE: Consider adding ML-KEM-512 which would fit in one packet. ]¶

• The Key Exchange Data is the 1184 or 1568 octets of the ML-KEM-768 or ML-KEM-1024 public key respectively for the 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. [ EDNOTE: Consider adding ML-KEM-512 which would fit in one packet. ]¶

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. ]¶