| Internet-Draft | Hybrid KEM in the IKEv2 | March 2025 |
| Wang, et al. | Expires 4 September 2025 | [Page] |
Multiple key exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC9370] specifies a framework that supports multiple key encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2) by allowing up to 7 layers of additional KEMs to derive the final shared secret keys for IPsec protocols. The primary goal is to mitigate the “harvest now and decrypt later” threat posed by cryptanalytically-relevant quantum computers. For this purpose, usually one or more post-quantum KEMs are performed in addition to the traditional (EC)DH key exchange. This draft specifies how the post-quantum KEM FrodoKEM is instantiated in IKEv2 as an additional key exchange mechanism.¶
[EDNOTE: IANA KE code points for FrodoKEM may need to be assigned, as the code points for ML-KEM has been considered in [I-D.KR24]. ]¶
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 https://datatracker.ietf.org/drafts/current/.¶
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 4 September 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Cryptographically-relevant quantum computers (CRQC) pose a threat to cryptographically protected data. 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) [RFC9370] specifies a framework to perform hybrid key encapsulation in the IKEv2 by allowing multiple key exchanges to take place for deriving shared secret keys during a Security Association (SA) setup. Essentially, this specification employs the IKE_INTERMEDIATE exchange, which is a new IKEv2 message introduced in “Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)” [RFC9242], so that multiple key exchanges can be run to establish an IKE SA via exchanging additional PQ public keys and ciphertexts between a client and a server. 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.¶
However, [RFC9370] just specifies the framework of hybrid KEMs and has to be been instantiated for concrete KEMs by separate documents. [I-D.KR24] describes how the framework given by [RFC9370] can be run with the ML-KEM [FIPS203], previously called Kyber, which has been standardized by NIST in August 2024. However, on the one hand, [RFC9370] allows up to 7 layers of additional KEMs to derive final shared secret keys for the IKEv2. On the other hand, for some applications (e.g. financial services) demanding high security level, additional PQ KEMs may be desired for use with [RFC9370]. 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 [FrodoKEM] is unstructured lattice based KEM, whose security is more conservative compared to ML-KEM, which is based on structured lattice. Therefore, this draft is motivated to describe concretely how the frame of hybrid KEMs for the IKEv2 specified in RFC 9370 can be instantiated with FrodoKEM. FrodoKEM should be used together with a traditional key exchange mechanism such as ECDH and in addition, may be used with further KEMs, e.g. ML-KEM.¶
Here are a few reasons for explaining why such diversity of KEMs is important for the IKEv2 (and also other security protocols).¶
However, the performance of FrodoKEM is not as good as ML-KEM. In particular, the sizes of pulic key and ciphtertext of FrodoKEM are roughly 10 times larger than those of ML-KEM. Consequently, this will almost unavoidably trigger IKE fragmentation.¶
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.¶
Key encapsulation mechanism(KEM) is a kind of key exchange, which allows one entity to encapsulate a secret key under a (longterm or ephemeral) public key of another entity. By following the definiton given in [I-D.KR24], a KEM consists of three algorithms:¶
ML-KEM and FrodoKEM are two well-known post-quantum KEMs from lattice. More specifically, ML-KEM [FIPS203], orignially called Kyber, has been published as the only one KEM scheme by NIST in August of 2024. It is a Module-Lattice based Key-Encapsulation Mechanism, so called ML-KEM. ML-KEM is also specified as an Internet Draft in IETF [I-D.Kyber24].¶
FrodoKEM [FrodoKEM] is one of three KEMS in the process of ISO standardization, which is based on unstructured lattice problem. However, the perfomace of FrodoKEM is not as good as ML-KEM. Specifically, as shown in Table 1, the sizes of pulic key and ciphtertext of FrodoKEM are roughly 10 times larger than those of ML-KEM. Consequently, this will almost unavoidably trigger IKE fragmentation [RFC7383] [RFC9242].¶
+===============+============+============+============+===============+ | Algorithms | secret key | public key | ciphterext | shared secret | | | sk | pk | ct | ss | +===============+============+============+============+===============+ | ML-KEM-512 | 800 | 1,632 | 768 | 32 | +---------------+------------+------------+------------+---------------+ | ML-KEM-768 | 1,184 | 2,400 | 1,088 | 32 | +---------------+------------+------------+------------+---------------+ | ML-KEM-1024 | 1,568 | 3,168 | 1,568 | 32 | +---------------+------------+------------+------------+---------------+ | FrodoKEM-640 | 19,888 | 9,616 | 9,752 | 16 | +---------------+------------+------------+------------+---------------+ | FrodoKEM-976 | 31,296 | 15,632 | 15,792 | 24 | +---------------+------------+------------+------------+---------------+ | FrodoKEM-1344 | 43,088 | 21,520 | 21,696 | 32 | +---------------+------------+------------+---------------+------------+ Table 1: Size (in bytes) of keys and ciphertexts of ML-KEM and FrodoKEM¶
Following general exmaples given in Appendix A of [RFC9370], 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 TBD36 (ml-kem-768), TBD37 (ml-kem-1024) [I-D.KR24] or NONE; the second set is TBD43 (eFrodoKEM-976-<AES>), TBD45 (eFrodoKEM-976-<SHAKE>) or NONE; and the third set is TBD49 (eFrodoKEM-1344-<SHAKE>) or NONE (refer to Section 6). As all of the three additional key exchanes are optional, the responder can choose NONE for some or all of the additional exchanges if the proposed key exchange methods are not supported or for whatever reasons the responder decides not to perform the additional key exchange.¶
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = TBD36)
Transform ADDKE1 (ID = TBD37)
Transform ADDKE1 (ID = NONE)
Transform ADDKE2 (ID = TBD43)
Transform ADDKE2 (ID = TBD45)
Transform ADDKE2 (ID = NONE)
Transform ADDKE3 (ID = TBD49)
Transform ADDKE3 (ID = NONE)
<--- HDR(IKE_SA_INIT), SAr1(.. ADDKE*...),
KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = TBD36)
Transform ADDKE2 (ID = TBD43)
Transform ADDKE3 (ID = NONE)
HDR(IKE_INTERMEDIATE), SK {KEi(1)(TBD36)} -->
<--- HDR(IKE_INTERMEDIATE), SK {KEr(1)(TBD36)}
HDR(IKE_INTERMEDIATE), SK {KEi(2)(TBD43)} -->
<--- HDR(IKE_INTERMEDIATE), SK {KEr(2)(TBD43)}
HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } --->
<--- HDR(IKE_AUTH), SK{IDr, AUTH, SAr2,TSi, TSr}
Fig. 1 Hybrid KEMs of ECDH, TBD36 (ml-kem-768), and TBD43 (eFrodoKEM-976-<AES>)
¶
In the above example, the responder chooses to run two additional key exchanges. Namely, it selects TBD36 (ml-kem-768), TBD43 (eFrodoKEM-976-<AES>), and NONE, respectively for the first, second, and third additional key exchanges. According to the IKEv2 specification [RFC7296], a set of keying materials can 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 TBD36 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 TBD36 shared secret. Next, an IKE_INTERMEDIATE exchange for TBD43 payload will be performed so that the SKEYSEED will be updated again.¶
After the completion of both IKE_INTERMEDIATE exchanges for TBD36 and TBD43, the initiator and the responder will continue the IKE_AUTH exchange phase.¶
More details and and further examples will be provided later¶
Basically, security considerations from [RFC7383], [RFC9242] and [RFC9370] apply to hybrid KEM exchange of ECDH, ML-KEM, and FrodoKEM described in this draft.¶
In additon, due to the fragmentation of public key and cipthertext of IKE message when FrodoKEM is hybrided, the performance of IKEv2 may be affected and the chance of re-transmision of IKE packet could become higher in some networking secnarios.¶
Further security analysis will be updated later.¶
In total, FrodoKEM has 12 variants. Namely, 3 security levels for NIST Levels 1, 3, and 5; the pseudorandom generate (PRG) using AES128 or SHAKE 128; and the KEM public key can be a long-term key (standard mode) or a short-term key (ephemeral mode). This document is planning to request 12 values for registration in the "Transform Type 4 - Key Exchange Method Transform IDs" registry [IANA-IKEv2], maintained by IANA. Namely, they are: "FrodoKEM-640-<AES>", , "eFrodoKEM-640-<AES>", "FrodoKEM-640-<SHAKE>", "eFrodoKEM-640-<SHAKE>", "FrodoKEM-976-<AES>", "eFrodoKEM-976-<AES>", "FrodoKEM-976-<SHAKE>", "eFrodoKEM-976-<SHAKE>", "FrodoKEM-1344-<AES>", "eFrodoKEM-1344-<AES>", "FrodoKEM-1344-<SHAKE>", and "eFrodoKEM-1344-<SHAKE>".. Table 2 below gives the list of 12 IANA values for the 12 versions of FrodoKEM. The Recipient Tests field should point to this document as well.¶
+========+===============+========+===============+============+ | Number | Name | Status | Recipient | Reference | | | | | Tests | | +=========+==============+========+===============+============+ | TBD38 | FrodoKEM-640 | | [TBD, this | [TBD, this | | | -<AES> | | draft] | draft] | +---------+--------------+--------+---------------+------------+ | TBD39 |eFrodoKEM-640 | | [TBD, this | [TBD, this | | |-<AES> | | draft] | draft] | +---------+--------------+--------+---------------+------------+ | TBD40 | FrodoKEM-640 | | [TBD, this | [TBD, this | | | -<SHAKE> | | draft] | draft] | +---------+--------------+--------+---------------+------------+ | TBD41 |eFrodoKEM-640 | | [TBD, this | [TBD, this | | |-<SHAKE> | | draft] | draft] | +---------+--------------+--------+---------------+------------+ | TBD42 | FrodoKEM-976 | | [TBD, this | [TBD, this | | | -<AES> | | draft] | draft] | +---------+--------------+--------+---------------+------------+ | TBD43 |eFrodoKEM-976 | | [TBD, this | [TBD, this | | |-<AES> | | draft] | draft] | +---------+--------------+--------+---------------+------------+ | TBD44 | FrodoKEM-976 | | [TBD, this | [TBD, this | | | -<SHAKE> | | draft] | draft] | +---------+--------------+--------+---------------+------------+ | TBD45 |eFrodoKEM-976 | | [TBD, this | [TBD, this | | |-<SHAKE> | | draft] | draft] | +---------+--------------+--------+---------------+------------+ | TBD46 | FrodoKEM-1344| | [TBD, this | [TBD, this | | | -<AES> | | draft] | draft] | +---------+--------------+--------+---------------+------------+ | TBD47 |eFrodoKEM-1344| | [TBD, this | [TBD, this | | |-<AES> | | draft] | draft] | +---------+--------------+--------+---------------+------------+ | TBD48 | FrodoKEM-1344| | [TBD, this | [TBD, this | | | -<SHAKE> | | draft] | draft] | +---------+------------- +--------+---------------+------------+ | TBD49 |eFrodoKEM-1344| | [TBD, this | [TBD, this | | |-<SHAKE> | | draft] | draft] | +---------+--------------+--------+---------------+------------+ Table 2: Updates to the IANA "Transform Type 4 - Key Exchange"¶
To be added later.¶