Internet Engineering Task Force G. Wang, Ed.
Internet-Draft Huawei Internatinoal Pte Ltd
Intended status: Informational 22 April 2024
Expires: 24 October 2024
Post-quantum Hybrid Key Exchange in the IKEv2 with ECDH, ML-KEM, and
FrodoKE
draft-wang-hybrid-kem-ikev2-frodo-00
Abstract
RFC 9370 specifies a framework that supports mulitple key
encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol
Version 2 (IKEv2) by allowing up to 7 layers of additiona KEMs
employed with the oringal ECDH to derive the final shared secret keys
for IPsec protocols. The primitive goal is to mitigate the security
threat against quantum computers when additional post-quantum (PQ)
KEMs are hybrided with the orinigal ECDH key exchange. This draft
describes concretely how two specific QP KEMs, namely, ML-KEM and
FrodoKEM, can be instantiated in the IKEv2 as the additional KEMs
with the main ECDH to achieve hybrid key agreement.
[EDNOTE: IANA KE code points for FrodoKEM may need to be assigned,
when considering the code points for ML-KEM has been considered in
[I-D.D24]. ]
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the rfc-interest mailing list
(rfc-interest@rfc-editor.org), which has its home page at
https://www.rfc-editor.org/mailman/listinfo/rfc-interest.
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 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."
Wang Expires 24 October 2024 [Page 1]
Internet-Draft Hybrid KEM in the IKEv2 April 2024
This Internet-Draft will expire on 24 October 2024.
Copyright Notice
Copyright (c) 2024 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. ML-KEM and FrodoKEM . . . . . . . . . . . . . . . . . . . . . 4
4. Examples of Running Hybrid KEMS with FrodoKEMs . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
To mitigate the security threats on key exchanges again quantum
computers, especialy the harvest-now-and-decrypt-later (HNDL) attack,
the approach of hybrid key encapsulation mechanisms (KEMs) has been
proposed to achieve secure key exchange if at least one of KEMs is
still secure. In particular, hybrid KEMs is supposed to be used in
the scenarios where one or multiple traditional KEMs are used
together with one or multiple post-quantum KEMs [I-D.D24]. The
Internet Key Exchange Protocol Version 2 (IKEv2), which sepecifies
the key exchange procedures of IPSec, has to be updated for quantum
resistant security. For this purpose, RFC 9370 [RFC9370] describes a
framework to hybrid mulitple key encapsulation mechanisms (KEMs),
which extends the IKEv2 by allowing multiple key exchanges to take
place for deriving shared secret keys during a Security Association
(SA) setup. Essentially, this speficiation employs the
IKE_INTERMEDIATE exchange, which is a new IKE message introduced in
[RFC9242] so that multiple key exchanges can be run to establish an
IKE SA via exchanging additional PQ public keys and ciphertexts
Wang Expires 24 October 2024 [Page 2]
Internet-Draft Hybrid KEM in the IKEv2 April 2024
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 is creating additional Child SAs.
However, RFC 9370 just specifies the framework of hybrid KEMS but it
has not been instantiated for concrete multiple KEMS. [I-D.KR24]
desribes how the framework given by RFC 9370 can be run with the
post-quantum (PQ) ML-KEM, also called Kyber, whose formal
specification is expected to be published by NIST in 2024. However,
on one hand, FRC 9350 allows up to 7 layers of additiona KEMs
employed with the oringal ECDH 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 completing the hybrid KEMs for the IKEv2. Currently, ML-
KEM is the only PQ KEM in the NIST standardization process, while ISO
is now standardizing three PQ KEM aglorithms: Kyber, FrodoKEM, and
classic McElliece. Note that Frodo [Frodo] 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 proposed in RFC 9370 can be run via hybriding the ogirinal ECDH
and two PQ KEMs, i.e, ML-KEM and FrodoKEM.
The following gives several reasons why diversity of KEMs is
important for the IKEv2 (and also other security protocols).
* The availability of various PQC algorithms is beneficial to
applications as different PQC algorithms could be selected
according to practical performance requirements and security
concerns.
* Generally speaking, post-quantum algorithms are still not fully
mature yet. Some algorithms may turn out to be insecure after a
number of years’ study. An example is SIKE, which had been in the
NIST standardization progres for several years until it was
totally broken in Aug. of 2022.
* Cryptographic agility shall play a crucial role in the PQ
migration [OPM23]. To facilitate cryptographic agility, not only
should the systems and protocols be engineered agile but also
there should be a good size of standardized PQC algorithms
available, which may be based on different hard problems.
However, the perfomace of Frodo is not as good as ML-KEM. In
particular, the sizes of pulic key and ciphtertext of FrodoKEM are
roughtly 10 times larger than those of ML-KEM. Consequtently, this
will almost unavoidably triger the issue of IKE fragmentation.
Wang Expires 24 October 2024 [Page 3]
Internet-Draft Hybrid KEM in the IKEv2 April 2024
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. ML-KEM and FrodoKEM
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:
* 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 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.
ML-KEM and FrodoKEM are two well-known post-quantum KEMs from
lattice. More specifically, ML-KEM [ML-KEM23], orignially called
Kyber, has been selected as the only one KEM scheme in its first
patch of PQ standardizatio by NIST. It is a Module-Lattice-Based
Key-Encapsulation Mechanism, so called ML-KEM, which will be
published as FIPS 203 standard (ML-KEM) by NIST. ML-KEM is also
specified as an Internet Draft in IETF [I-D.Kyber24].
FrodoKEM [Frodo] is one of three KEMS in the process of ISO
stardandization, which is based on unstructured lattice problem.
However, the perfomace of Frodo is not as good as ML-KEM.
Specifically, as showen in Table 1, the sizes of pulic key and
ciphtertext of FrodoKEM are roughtly 10 times larger than those of
ML-KEM. Consequtently, this will almost unavoidably triger the issue
of IKE fragmentation [RFC7383] [RFC9242].
Wang Expires 24 October 2024 [Page 4]
Internet-Draft Hybrid KEM in the IKEv2 April 2024
+===============+============+============+============+===============+
| 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
4. Examples of Running Hybrid KEMS with FrodoKEMs
Following general exmaples given in Appendix A of [RFC9370], here is
an exmpale to show that the initiator proposes the use of additional
key exchanges to establish 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.
Wang Expires 24 October 2024 [Page 5]
Internet-Draft Hybrid KEM in the IKEv2 April 2024
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 specific 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 [RFC7296],
a set of keying materials can be derived, in particular SK_d, SK_a[i/
r], and SK_e[i/r]. After that, both peers will perform an
IKE_INTERMEDIATE exchange, carrying TBD36 payload, which is protected
Wang Expires 24 October 2024 [Page 6]
Internet-Draft Hybrid KEM in the IKEv2 April 2024
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, the
initiator and the responder continue to the IKE_AUTH exchange phase.
Further examples and details will be provided later
5. Security Considerations
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.
6. IANA Considerations
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 can be used as a long-term key
(standard mode) or a short-term key (ephemeral mode). So, by
following the new values has been requested for "ml-kem-768" and "ml-
kem-768" by [I-D.KR24], it is planning to request IANA 12 values for
the names in the IKEv2 "Transform Type 4 - Key Exchange Method
Transform IDs", which are: "FrodoKEM-640-<AES>", , "eFrodoKEM-
640-lt;AES>", "FrodoKEM-640-<SHAKE>", "eFrodoKEM-640-<SHAKE>",
"FrodoKEM-976-lt;AES>", "eFrodoKEM-976-lt;AES>", "FrodoKEM-
976-<SHAKE>", "eFrodoKEM-976-<SHAKE>", "FrodoKEM-1344-lt;AES>",
"eFrodoKEM-1344-lt;AES>", "FrodoKEM-1344-<SHAKE>", and "eFrodoKEM-
1344-<SHAKE>".. The 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.
Wang Expires 24 October 2024 [Page 7]
Internet-Draft Hybrid KEM in the IKEv2 April 2024
+========+===============+========+===============+============+
| 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
7. Acknowledgments
To be added later.
8. Normative References
Wang Expires 24 October 2024 [Page 8]
Internet-Draft Hybrid KEM in the IKEv2 April 2024
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC7296] 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, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383,
DOI 10.17487/RFC7383, November 2014,
<https://www.rfc-editor.org/info/rfc7383>.
[RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key
Exchange Protocol Version 2 (IKEv2)", RFC 9242,
DOI 10.17487/RFC9242, May 2022,
<https://www.rfc-editor.org/info/rfc9242>.
[RFC9370] 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, May
2023, <https://www.rfc-editor.org/info/rfc9370>.
9. Informative References
[I-D.D24] F. Driscoll, F., "Terminology for Post-Quantum Traditional
Hybrid Schemes", Work in Progress, Internet-Draft,,
February 2024, <https://datatracker.ietf.org/doc/draft-
ietf-pquip-pqt-hybrid-terminology/>.
[I-D.KR24] Kampanakis, K. and G. Ravago, "Post-quantum Hybrid Key
Exchange with ML-KEM in the Internet Key Exchange Protocol
Version 2 (IKEv2)", Work in Progress, Internet-Draft,,
February 2024, <https://datatracker.ietf.org/doc/draft-
kampanakis-ml-kem-ikev2/>.
[I-D.Kyber24]
Schwabe, P. and B. Westerbaan, "Kyber Post-Quantum KEM",
Work in Progress, Internet-Draft,, January 2024,
<https://datatracker.ietf.org/doc/draft-cfrg-schwabe-
kyber/>.
Wang Expires 24 October 2024 [Page 9]
Internet-Draft Hybrid KEM in the IKEv2 April 2024
[OPM23] Ott, D., Paterson, K., and D. Moreau, "Where Is the
Research on Cryptographic Transition and Agility?",
Communications of the ACM, 66(4): 29-32, January 2023.
[Frodo] Alkim, E., Bos, J. W., Ducas, L., Longa, P., Mironov, I.,
Naehrig, N., Nikolaenko, V., Peikert, C., Raghunathan, A.,
and D. Stebila, "FrodoKEM: Learning With Errors Key
Encapsulation", Preliminary Standardization Proposal
submitted to ISO , March 2023,
<https://frodokem.org/files/FrodoKEM-standard_proposal-
20230314.pdf>.
[ML-KEM23] National Institute of Standards and Technology, "FIPS
203(Initial Draft): Module-Lattice-Based Key-Encapsulation
Mechanism Standard", FIPS Standard (Draft) , August 2023,
<https://csrc.nist.gov/pubs/fips/203/ipd>.
Author's Address
Guilin Wang (editor)
Huawei Internatinoal Pte Ltd
9 North Buona Vista Drive, #13-01
The Metropolis Tower 1
SINGAPORE 138588
Singapore
Email: wang.guilin@huawei.com
Wang Expires 24 October 2024 [Page 10]