Post-quantum Hybrid Key Exchange in IKEv2 with FrodoKEM

Changes made in version draft-ietf-ipsecme-kem-auth-ikev2-00:

A new co-author is added.
Clarifications are added that FrodoKEM can be used either as an additional key exchange method, or as the only key exchange method for IKE SA (provided there is no transport issues).
References are re-arranged and updated.
Github address of this document added: .
Editorial changes throughout the document: Shorten Introduction, aligned Security Discussions with , ....

Changes made in version draft-wang-ipsecme-kem-auth-ikev2-03:

This specification has switched 4 variants of eFrodoKEM (ephemeral mode) to those of FrodoKEM (standard mode). The reasons are given in .
Other Sections are updated correspondingly.

Three main changes have been made in version draft-wang-ipsecme-kem-auth-ikev2-02, as a response to comments received since July of 2025.

Reduced code points from 6 in v01 to 4 now (revised Sections 3.3 and 6).
Explained why variants for both AES and SHAKE are necessary (revised Section 3.2).
Added KEi and KEr payloads for using FrodoKEM in IKEv2 (added new Sections 4.3).

Two main changes have been made in version draft-wang-ipsecme-kem-auth-ikev2-01, as a response to comments received at 122 meeting:

Restructured the draft.
Reduced the point codes from 12 to 6 (eFrodoKEM).

Cryptographically-relevant quantum computers (CRQCs) pose a threat to data protected using traditional security algorithms. In particular, the so-called harvest-now-and-decrypt-later (HNDL) attack is considered an imminent threat. To mitigate this threat, the concept of hybrid key encapsulation mechanisms (KEMs) has been proposed to achieve secure key exchange if at least one of the KEMs is still secure . “Multiple key exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) specifies a framework to perform hybrid key encapsulation in IKEv2 by allowing multiple key exchanges for deriving shared secret keys during a Security Association (SA) setup. This framework employs the IKE_INTERMEDIATE exchange, which is a new IKEv2 exchange introduced in “Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)” , so that multiple key exchanges can be run to establish an IKE SA. RFC 9370 also introduces IKE_FOLLOWUP_KE, a new IKEv2 exchange for realizing the same purpose when the IKE SA is being rekeyed or additional Child SAs are created. just specifies the framework of hybrid KEMs and has to be instantiated for concrete KEMs by separate documents. describes how the framework can be run with ML-KEM , previously called Kyber, which has been standardized by NIST in August 2024. However, for some applications (e.g. financial services) demanding high security level, additional PQ KEMs may be desired for use with . Currently, ISO is standardizing three PQ KEM algorithms (EDNOTE: we may want to change the wording since the ISO standard will be finished eventually): Kyber, FrodoKEM, and Classic McEliece. Note that FrodoKEM is an unstructured lattice based KEM, whose security is more conservative compared to ML-KEM based on structured lattices. This specification is a profile of the Multiple Key Exchanges in IKEv2 specification and registers new algorithm identifiers for FrodoKEM key exchanges in IKEv2. While this document focuses on using FrodoKEM as an additional key exchange in a hybrid KEM scenario, in some scenarios it is possible to also use FrodoKEM as a quantum-resistant-only key exchange. Since its encapsulation key and ciphertext sizes make UDP packet size larger than typical network MTUs, using FrodoKEM in the IKE_SA_INIT will most probably lead to IP fragmentation of these messages. However, when reliable transport is used for IKE (e.g. , ) or IP fragmentation is not an issue in a given network, implementations MAY use FrodoKEM in the IKE_SA_INIT exchange. EDITOR NOTE: This document is being developed at .

Requirements Language 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.

KEMs and FrodoKEM

KEMs Key encapsulation mechanism (KEM) is a kind of key exchange, which allows one entity to encapsulate a secret key under a (long-term or ephemeral) public key of another entity. By following the definiton given in , a KEM consists of three algorithms:

KeyGen(k) -> (pk, sk): A probabilistic key generation algorithm, which generates a public encapsulation key pk and a secret decapsulation key sk, when a security parameter k is given.
Encaps(pk) -> (ct, ss): A probabilistic encapsulation algorithm, which takes as input a public encapsulation key pk and outputs a ciphertext ct and a shared secret ss.
Decaps(sk, ct) -> ss: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret ss.

The security of FrodoKEM is based on a well-studied hard problem in unstructured lattices, called the learning with errors (LWE) problem. The algorithm details of FrodoKEM are specified in and . FrodoKEM has 12 variants. It offers 3 NIST security levels 1, 3, and 5; its pseudorandom generator (PRG) is AES128 or SHAKE 128; and its KEM public key can be a long-term (standard mode) or a short-term ones (ephemeral mode). In this document, FrodoKEM, rather than eFrodoKEM, is specified for key exchange in IKEv2, based on the following three reasons. First of all, the performance difference between standard mode and ephemeral mode is negligible. Secondly, FrodoKEM (standard mode) has no restriction on the reuse of a public key (Section 8 in ). Finally, ephemeral public keys are expected for the key exchange in IKEv2, but it is not required in that they never repeat. In fact, Section 2.12 in describes the reason and several reasonable strategies for reuse of public keys (in the setting of Diffie-Hellman exponentials) in IKEv2, together with conditions and security implication. FrodoKEM has both AES and SHAKE variants to offer optimized performance across different hardware platforms. AES variants are highly suitable for devices with hardware acceleration for AES (like AES-NI on Intel processors). SHAKE variants provide competitive or better performance on platforms lacking AES hardware acceleration (such as many embedded systems and general-purpose CPUs). To cover both scenarios, this specification include both variants. According to the current standardization progress in ISO, FrodoKEM will be standardized for the eight variants for NIST security levels 3 and 5. Namely, they are (e)FrodoKEM-976 and (e)FrodoKEM-1344, but not (e)FrodoKEM-640 for security level 1. To align with ISO, this document specifies the use of FrodoKEM varaints for security levels 3 and 5 only, not variants for security level 1. Based on the above, this document specifies only four variants of FrodoKEM (standard mode) for IKEv2 key exchange. Namely, FrodoKEM-976-<AES> and FrodoKEM-976-<SHAKE> for security level 3, and FrodoKEM-1344-<AES> and FrodoKEM-1344-<SHAKE> for security level 5.

ML-KEM and FrodoKEM are two well-known post-quantum KEMs based on structured and unstructured lattices. The performance of FrodoKEM is not as good as ML-KEM. As shown in , the sizes of public encapsulation key and ciphtertext of FrodoKEM (Table A.5 in ) are roughly 13 times larger than those of ML-KEM (Table 3 in ). Consequently, this will almost unavoidably trigger IKE fragmentation , when FrodoKEM is used in IKEv2 as additional key exchange .

Algorithms	decapsulation key sk	encapsulation key pk	ciphterext ct	shared secret ss
ML-KEM-768	2,400	1,184	1,088	32
ML-KEM-1024	3,168	1,568	1,568	32
FrodoKEM-976	31,296	15,632	15,792	24
FrodoKEM-1344	43,088	21,520	21,696	32

Different from ML-KEM , there is no input validation for FrodoKEM public keys or ciphertexts . Therefore, the recipient tests are not required for using FrodoKEM in IKEv2.

As specified in , to run PQ KEMs in IEKv2, the initiator and the responder run traditional key exchange first and then PQ KEMs. This is because the size of PQ KEM public key or the ciphertext is normally large, such that the first exchange in IKEv2 cannot accommodate them (together with other necessary information) without exceeding MTU (Maximum Transmission Unit), which is generally set as 1500 bytes. Namely, in the first IKE_SA_INIT exchanges, the initiator sends KEi(0) payload to the responder, and the responder sends KEr(0) payload to the initiator for completing traditional ephemeral DH or ephemeral ECDH key exhange. Once these procedures are done successfully, the two entities will share the same raw key SK(0). And from SK(0), a series of keying materials are derived, which are called as SKEYSEED(0), SK_d(0), SK_a[i/r](0), SK_e[i/r](0), and SK_p[i/r](0) (refers Section 2.2.2 in ). To run FrodoKEM (or any PQ KEM) as an additional key exchange in IKEv2, both the initiator and the responder MUST declare their support of both the ADDKE Transform Types and the IKE_INTERMEDIATE exchange in the IKE_SA_INIT exchanges between them. At the same time, the initiator SHALL present its intended FrodoKEM variants via one or more ADDKE Transform Types, which are expressed in one or more Proposals. Then, the responder MAY select a variant of FrodoKEM (or more PQ KEMs) from the initiator's Proposals, and then sends the corresponding ADDKE Transform ID (or IDs) to the initiator. Once the initiator receives one ADDKE Transform ID, which denotes FrodoKEM (or any PQ KEM), it will run KeyGen(k) to generate an ephemeral public and private FrodoKEM key pairs (pk, sk) or select one of its existing public keys pk, and sends the value of public key pk to the responder via KEi(1) payload. Correspondingly, once retrieving the public key pk from KEi(1) payload, the responder will run Encaps(pk) to obtain a pair (ct1, ss1). Here, ss1 is the raw key to be shared, and ct1 is the ciphertext encapsulated ss1. Then, the responder will send ct1 via KEr(1) payload that contains ct1 to the initiator. After that, the initiator can retrieve ct1 from KEr(1) payload and then decapsulate ct1 to obtain the shared secret ss1. Here, both KEi(1) and KEr(1) payloads SHALL be sent via the IKE_INTERMEDIATE exchanges between the two entities. Also, note that during these procedures, KEi(1) and KEr(1) payloads SHALL be protected via using keys SK_a[i/r](0) and SK_e[i/r](0). Once ss1 is successfully shared, the two entities will set SK(1)=ss1, and then stir SK(1) with SK_d(0) to derive SKEYSEED(1). And then, from SKEYSEED(1), a series of SK_d(1), SK_a[i/r](1), SK_e[i/r](1), and SK_p[i/r](1) will be derived. If there are more ADDKE exchanges for PQ KEMs, these procedures will continue until the final ADDKE finishes. Then, the final updated key values, SKEYSEED(n), SK_d(n), SK_a[i/r](n), SK_e[i/r](n), and SK_p[i/r](n), SHALL be used to protect the following IKEv2 exchanges, including the IKEv2 authentication messages. The structure of KEi(1) and KEr(1) payloads and their lengths for FrodoKEMs listed in will be given in . Following general examples in Appendix A of , here is an example to show that the initiator proposes to use additional key exchanges for establishing an IKE SA. Here, the initiator proposes three sets of additional key exchanges. Namely, the first set is TBD38 (FrodoKEM-976-<AES>), TBD39 (FrodoKEM-976-<SHAKE>) or NONE (refers ); the second set is 36 (ml-kem-768), 37 (ml-kem-1024) or NONE; and the third set is TBD41 (FrodoKEM-1344-<SHAKE>) or NONE (refers ). As all of the three additional key exchanges are optional, the responder can choose NONE for some or all of the additional exchanges if the proposed key exchange methods are not supported by the responder, or for whatever reasons the responder decides not to perform the additional key exchange.

KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), N(INTERMEDIATE_EXCHANGE_SUPPORTED) Proposal #1 Transform ENCR (ID = ENCR_AES_GCM_16, 256-bit key) Transform PRF (ID = PRF_HMAC_SHA2_512) Transform KE (ID = Curve25519) Transform ADDKE1 (ID = TBD38) Transform ADDKE1 (ID = TBD39) Transform ADDKE1 (ID = NONE) Transform ADDKE2 (ID = ml-kem-768) Transform ADDKE2 (ID = ml-kem-1024) Transform ADDKE2 (ID = NONE) Transform ADDKE3 (ID = TBD41) Transform ADDKE3 (ID = NONE) <--- HDR(IKE_SA_INIT), SAr1(...ADDKE*...), KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), N(INTERMEDIATE_EXCHANGE_SUPPORTED) Proposal #1 Transform ENCR (ID = ENCR_AES_GCM_16, 256-bit key) Transform PRF (ID = PRF_HMAC_SHA2_512) Transform KE (ID = Curve25519) Transform ADDKE1 (ID = TBD38) Transform ADDKE2 (ID = ml-kem-768) Transform ADDKE3 (ID = NONE) HDR(IKE_INTERMEDIATE), SK {KEi(1)(TBD38)} --> <--- HDR(IKE_INTERMEDIATE), SK {KEr(1)(TBD38)} HDR(IKE_INTERMEDIATE), SK {KEi(2)(ml-kem-768)} --> <--- HDR(IKE_INTERMEDIATE), SK {KEr(2)(ml-kem-768)} HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } ---> <--- HDR(IKE_AUTH), SK{IDr, AUTH, SAr2,TSi, TSr} ]]> In the above example, the responder chooses to run two additional key exchanges. Namely, it selects TBD38 (FrodoKEM-976-<AES>), 36 (ml-kem-768), and NONE, respectively for the first, second, and third additional key exchanges. According to the IKEv2 specification , a set of keying materials will be derived, in particular SK_d, SK_a[i/r], and SK_e[i/r], when the IKE_SA_INIT exchange has been completed by the initiator and the responder with a successful execution of ECDH based on the curve 25519. After that, both peers will perform an IKE_INTERMEDIATE exchange, carrying TBD38 payload, which is protected with SK_e[i/r] and SK_a[i/r] keys. After the completion of this IKE_INTERMEDIATE exchange, the SKEYSEED is updated using SK(1), which is the TBD38 shared secret. Next, an IKE_INTERMEDIATE exchange for 36 payload will be performed so that the SKEYSEED will be updated again. After the completion of both IKE_INTERMEDIATE exchanges for TBD38 and 36, the initiator and the responder will continue the IKE_AUTH exchange phase. Note that similar to the above example running FrodoKEM in IKE_INTERMEDIATE with ECDH as a traditional key exchange, FrodoKEM can also be executed in IKE_INTERMEDIATE as an additional (PQ) KEM with a Post-quantum Preshared Keys (PPK) as a traditional key exchange. In this case, the traditional exchange part with PPK SHOULD be implemented as specified by or .

FrodoKEM can also be used for creating additional Child SAs and rekeying the IKE SA or Child SAs. FrodoKEM may be used as the only key exchange in CREATE_CHILD_SA exchange or as an additional key exchange method. In the latter case, the IKE_FOLLOWUP_KE exchange as defined in is used. IKE_FOLLOWUP_KE is an additional exchange for the purpose of using multiple key exchanges with the CREATE_CHILD_SA Exchange. If the use of additional key exchange methods is negotiated in the CREATE_CHILD_SA exchange, these are performed subsequently in a series of IKE_FOLLOWUP_KE exchanges. After all key exchanges are completed, SKEYSEED or KEYMAT are computed as specified in Section 2.2.4 of .

For completeness, the KE (Key Exchange) payload is given below and all fields inside keep the same meaning as specified in Section 3.4 of the IKEv2 standard . This also means that the initiator SHALL prepare KEi(0) and KEi(1) payloads according to . Namely, the Key Exchange Data will be filled with KEi(0) or KEi(1). This applies for the responder to prepare KEr(0) and KEr(1) as well.

lists the lengths in octets for the KE payload with four variants of FrodoKEM specified in this document.

KE Method No.	KEM	Payload Length (for pk/ct)	Data Size in octets (KEi/KEr)
TBD38	FrodoKEM-976-<AES>	15,640/15,800	15,632/15,792
TBD39	FrodoKEM-976-<SHAKE>	15,640/15,800	15,632/15,792
TBD40	FrodoKEM-1344-<AES>	21,528/21,704	21,520/21,696
TBD41	FrodoKEM-1344-<SHAKE>	21,528/21,704	21,520/21,696

Basically, security considerations from , and apply to key exchange of ECDH, FrodoKEM, and their hybrid described in this specification. The security discussions in Section 10 of apply here as well. First of all, FrodoKEM is designed to be a post-quantum KEM with IND-CCA2 security. Namely, it has indistinguishability under adaptive chosen ciphertext attacks, which means that shared secret values should be indistinguishable from random strings even an active attacker is given the ability to access arbitrary ciphertexts decapsulated. Next, generating a new ciphertext for each FrodoKEM key exchange is REQUIRED by this specification. However, it is OPTIONAL for generating a new ephemeral key pair for each FrodoKEM key exchange, as IKEv2 does not require that the public keys never repeat. Note that when the same FrodoKEM public key is resued to encapsulate multiple shared secrets, forward security may not be guaranteed, as the compromise of the corresponding private decapsulation key may lead to the compromise of shared secrets exchanged in previous sessions using the same encapsulation key. Section 2.12 in gives the reasons for reuse of a public key and discusses the corresponding security implications. Thirdly, the independency is REQUIRED among the randomness for generating FrodoKEM encapsulation key and for generating ciphertexts, and other random seeds used in IKEv2 negotiation. For example, the responder MUST NOT reuse the same randomness to generate multiple FrodoKEM ciphertexts, and the initiator also MUST NOT use the same seed to generate the FrodoKEM and (EC)DH keypairs in a PQ/T Hybrid key exchange. Finally, downgrade attacks on the authentication part of IKEv2 has been identified and repaired in "Prevention Downgrade Attacks on the Internet Key Exchange Protocol Version 2 (IKEv2)" . Due to a flaw without authenticating the whole message received from the other peer, these attacks may allow an active attacker to mislead the two peers to finally negotiating a weak KEM for key exchange. These attacks apply to the IKEv2 and all its extensions, including . So, this specification MUST be implemented with the updated authentication mechanism given by .

As specified in , this draft is to asking 4 values for registration in the "Transform Type 4 - Key Exchange Method Transform IDs" registry , maintained by IANA. Namely, they are: "FrodoKEM-976-<AES>", "FrodoKEM-976-<SHAKE>", "FrodoKEM-1344-<AES>", and "FrodoKEM-1344-<SHAKE>". below gives the list of 4 IANA values for the 4 versions of FrodoKEM (standard mode).

Number	Name	Recipient Tests	Reference
TBD38	FrodoKEM-976-<AES>	[TBD, this draft, Section 5.1]	[TBD, this draft]
TBD39	FrodoKEM-976-<SHAKE>	[TBD, this draft, Section 5.1]	[TBD, this draft]
TBD40	FrodoKEM-1344-<AES>	[TBD, this draft, Section 5.1]	[TBD, this draft]
TBD41	FrodoKEM-1344-<SHAKE>	[TBD, this draft, Section 5.1]	[TBD, this draft]

The authors would like to thank the following experts for their valuable comments: Scott Fluhrer, Christopher Patton, Kev Kitchen, Panos Kampanakis, Paul Wouters, Thom Wiggers, Michael Richardson, John Mattsson, Marc Penninga, Tirumal Reddy, and Jun Hu.