KEM-based Authentication for IKEv2 with Post-quantum Security
draft-wang-ipsecme-kem-auth-ikev2-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Guilin WANG , Valery Smyslov | ||
| Last updated | 2025-10-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-ipsecme-kem-auth-ikev2-02
IP Security Maintenance and Extensions G. Wang, Ed.
Internet-Draft Huawei Int. Pte Ltd
Intended status: Standards Track V. Smyslov
Expires: 21 April 2026 ELVIS-PLUS
18 October 2025
KEM-based Authentication for IKEv2 with Post-quantum Security
draft-wang-ipsecme-kem-auth-ikev2-02
Abstract
This draft specifies a new authentication mechanism, called KEM (Key
Encapsulation Mechanism) -based authentication, for the Internet Key
Exchange Protocol Version 2 (IKEv2). This is motivated by the fact
that some post-quantum KEMs (like ML-KEM) are more efficient than
post-quantum signature algorithms (like ML-DSA).
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."
This Internet-Draft will expire on 21 April 2026.
Copyright Notice
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.
Wang & Smyslov Expires 21 April 2026 [Page 1]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notes of Change . . . . . . . . . . . . . . . . . . . . . 2
1.2. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Key Encapsulation Mechanism and Digital Signature . . . . . . 4
4. Comparison of ML-KEM and ML-DSA . . . . . . . . . . . . . . . 5
5. Protocol Overview for KEM-based Authentication . . . . . . . 7
6. Protocol Details for KEM-based Authentication . . . . . . . . 7
6.1. Exchanges for KEM-based Authentication . . . . . . . . . 8
6.1.1. The IKE_SA_INIT Exchange . . . . . . . . . . . . . . 8
6.1.2. The IKE_INTERMEDIATE Exchanges . . . . . . . . . . . 9
6.1.3. The IKE_AUTH Exchange . . . . . . . . . . . . . . . . 13
6.2. Alternative Sequences of Exchanges . . . . . . . . . . . 14
6.2.1. Alternative 1: Send Certificates Encrypted Only with
the IKE_SA_INIT Keys . . . . . . . . . . . . . . . . 14
6.2.2. Alternative 2: Change the Order of Certificates and Use
Double Encryption . . . . . . . . . . . . . . . . . . 15
6.3. Data Formats . . . . . . . . . . . . . . . . . . . . . . 16
6.3.1. Authentication Payload for KEM-based
Authentication . . . . . . . . . . . . . . . . . . . 16
6.3.2. Authentication Announcement for KEM Authentication . 16
7. Interaction with Other IKEv2 Extensions . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
1.1. Notes of Change
Version -02 was completely rewritten to accommodate ideas expressed
in PQuAKE protocol.
Two changes have been made in version -01, as a response to comments
received at 122 meeting:
* More details about how each side does for running KEM
authentication in Section 6.1.
* Added section about KEM authentication with preshared public key.
Wang & Smyslov Expires 21 April 2026 [Page 2]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
1.2. Introduction
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 against the Internet Key Exchange
Protocol Version 2 (IKEv2) [RFC7296], an extension allowing multiple
key exchanges in IKEv2 [RFC9370] was introduced to achieve post-
quantum (PQ) security for the key exchange.
"Signature Authentication in the Internet Key Exchange Version 2
(IKEv2) using PQC" [I-D.ietf-ipsecme-ikev2-pqc-auth] specifies how
NIST PQ digital algorithms ML-DSA [FIPS204] and SLH-DSA [FIPS205] can
be used in IKEv2. On the other hand, "Post-Quantum Traditional (PQ/
T) Hybrid PKI Authentication in the Internet Key Exchange Version 2
(IKEv2)" [I-D.hu-ipsecme-pqt-hybrid-auth] specifies how to run
general hybrid PQ/T digital algorithms in IKEv2.
Motivated by the fact that ML-KEM [FIPS203] is much more efficient
than ML-DSA [FIPS204], "KEM-based Authentication for TLS 1.3"
[I-D.celi-wiggers-tls-authkem] [I-D.wiggers-tls-authkem-psk]
specifies how KEM can be used to achieve post-quantum secure
authentication for the TLS 1.3 protocol. The basic idea is as
follows: when one entity A receives the certified long term public
key of another entity B, A can authenticate B by encapsulating a
secret key k using B's KEM public key, and confirming that the
communicating entity is indeed B if the entity can successfully
return the correct k to A. The similar idea for TLS is presented in
[SSW20], followed by a number of research papers then. Besides
saving communication overhead and computational time, as pointed out
in [I-D.celi-wiggers-tls-authkem], KEM-based authentication also
benefits to reduce implementation code size, as the code for PQ
signature may not need, and KEM-based authentication can re-use the
KEM code for ephemeral key establishment.
This draft specifies how to use KEM-based authentication for the
Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296].
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.
Wang & Smyslov Expires 21 April 2026 [Page 3]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
3. Key Encapsulation Mechanism and Digital Signature
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 definition
given in [I-D.ietf-ipsecme-ikev2-mlkem], 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.
By following the definition given in
[I-D.ietf-pquip-hybrid-signature-spectrums], a signature scheme
consists of the following three algorithms:
* SKeyGen(k) -> (spk, ssk): A probabilistic key generation
algorithm, which generates a public verifying key spk and a
private signing key ssk, when a security parameter k is given..
* Sign(ssk, m) -> s: A deterministic or probabilistic signature
generation algorithm, which takes as input a private signing key
ssk and a message m, and outputs a signature s.
* Verify(spk, s, m) -> b: A deterministic verification algorithm,
which takes as input a public verifying key spk, a signature s and
a message m, and outputs a bit b indicating accept (b=1) or reject
(b=0) of the signature-message pair (s, m).
In August of 2024, NIST released ML-KEM [FIPS203] and ML-DSA
[FIPS204], which are both module-lattice-based post-quantum
algorithms. Each of both algorithms has three sets of parameters
corresponding to three NIST security levels. Namely, ML-KEM-512 for
Level 1, ML-KEM-768 for Level 3, and ML-KEM-1024 for for Level 5,
while ML-DSA-44 for Level 2, ML-DSA-65 for Level 3, and ML-DSA-87 for
Level 5.
Wang & Smyslov Expires 21 April 2026 [Page 4]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
4. Comparison of ML-KEM and ML-DSA
This section compares ML-KEM and ML-DSA, with respect to the sizes of
key, ciphertext and signature, and also the computational overhead of
key generation, encapsulation, signing, decapsulation, and verifying.
First of all, to compare the communication overhead when using ML-DSA
and ML-KEM, data from Table 2 in [FIPS204] and Table 3 in [FIPS204]
are used to generate the following Table 1. The results show the
comparison of keys and signature over ciphertext between ML-DSA and
ML-KEM. Namely, for all corresponding security levels, the following
statements can be concluded:
* The private key size of ML-DSA is about 1.5 times of the
decapsulation key size of ML-KEM,
* The public size of ML-DSA is about 1.6 times of that of ML-KEM,
and
* The signature size of ML-DSA is about 3 times of the ciphertext
size of ML-KEM.
+=============+===================+===================+=============+
| | Private Key/ | Public Key/ | Signature/ |
| | Decapsulation Key | Encapsulation | Ciphertext |
| | | Key | |
+=============+===================+===================+=============+
| ML-DSA-44/ | 2,650/1,632 | 1,312/800 | 2,420/768 |
| ML-KEM-512 | =157% | =164% | =315% |
+-------------+-------------------+-------------------+-------------+
| ML-DSA-65/ | 4,032/2,400 | 1,952/1,184 | 3,309/1,088 |
| ML-KEM-768 | =168% | =165% | =304% |
+-------------+-------------------+-------------------+-------------+
| ML-DSA-87/ | 4,896/3,168 | 2,592/1,568 | 4,627/1,568 |
| ML-KEM-1024 | =155% | =165% | =295% |
+-------------+-------------------+-------------------+-------------+
Table 1: Communication Overhead Comparison of ML-DSA and ML-KEM
Specifically, for the three security levels, when ML-KEM is used to
replace ML-DSA for authentication, the saved communication overhead,
namely public key+signature for ML-DSA and encapsulation
key+ciphertext for ML-KEM, is 2,164, 2,989, and 4,083 bytes,
respectively. Those savings are helpful to improve the performance
of IKEv2. In fact, as shown in the experiment in simulated
environment, the average time delay for IKEv2 can increase a few
times due to large size of PQ public key, ciphertext and signature,
especially when the IP packet loss rate reaches about 1%.
Wang & Smyslov Expires 21 April 2026 [Page 5]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
Next, the computation overhead comparison will be given now. In
[HAZ24], the authors present their implementation results of
Dilithium and Kyber, via various optimization techniques for Keccak
and the two PQ algorithms. Concretely, Table 6 in [HAZ24] shows the
performance comparison of Dilithium and Kyber on ARMv7 Cortex-M4
processor, presented by clock cycles. By ignoring the small
difference between ML-KEM and its informal version Kyber, also ML-DSA
and its informal version Dilithium, the following Table 2 is
obtained.
+=============+==============+===============+===============+
| | KeyGen Time/ | Encap Time/ | Decap Time/ |
| | SKeyGen Time | Sign Time | Verify Time |
+=============+==============+===============+===============+
| ML-DSA-44/ | 1,357k/369k | 3,487k/448k | 1,350k/409k |
| ML-KEM-512 | =368% | =778% | =330% |
+-------------+--------------+---------------+---------------+
| ML-DSA-65/ | 2,394k/604k | 5,574k/732k | 2,302k/674k |
| ML-KEM-768 | =396% | =761% | =342% |
+-------------+--------------+---------------+---------------+
| ML-DSA-87/ | 4,069k/962k | 7,730k/1,119k | 3,998k/1,043k |
| ML-KEM-1024 | =423% | =691% | =383% |
+-------------+--------------+---------------+---------------+
Table 2: Computational Overhead Comparison of ML-DSA and
ML-KEM
By assuming that the computational comparison shown in Table 2
reasonably presents the performance difference of ML-KEM and ML-DSA
at the same platform with similar implementation techniques, for all
three corresponding security levels, the following statements can be
derived:
* The private key generation time of ML-DSA is about 4 times of that
of ML-KEM.
* The signature signing time of ML-DSA is about 7 times of the
encapsulation time of ML-KEM.
* The signature verifying time of ML-DSA is over 3 times of the
decapsulation time of ML-KEM.
Wang & Smyslov Expires 21 April 2026 [Page 6]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
In the scenario of KEM-based authentication, both the private keys
for ML-DSA and ML-KEM will be long term keys, so the private key
generation time can be ignored, as it is just one time overhead.
Therefore, by combining signature signing and verifying together, and
also combining encapsulation and decapsulation together, we can
simply say that the computational time of ML-DSA is about 5 times of
that of ML-KEM.
5. Protocol Overview for KEM-based Authentication
With a KEM-based authentication in IKEv2 peers first perform an
ephemeral key exchange that allows them to derive session keys for
protecting subsequent exchanges. This ephemeral key exchange may
take place entirely in the IKE_SA_INIT exchange or be accompanied by
a series of subsequent IKE_INTERMEDIATE exchanges [RFC9370], in which
case it would be a hybrid key exchange.
To run KEM-based Authentication in IKEv2, the two peers first
exchange their long-term KEM certificates, and then exchange random
values encapsulated with each other's long-term KEM public key from
the corresponding KEM certificate. Here, both long-term KEM
certificates and the KEM ciphertexts encapsulating the random values
are sent via the IKE_INTERMEDIATE exchanges. After decapsulating
these random values the two peers cam demonstrate their knowledge of
the random values sent by the other side in the subsequent IKE_AUTH
exchange, thus confirming that they do possess the corresponding KEM
private keys linked to their long-term KEM certificates.
Mode details about the KEM-based authentication are provided in
<citations for PQuAKE and other papers needed>.
6. Protocol Details for KEM-based Authentication
The KEM-based authentication in IKEv2 relies on the IKE_INTERMEDIATE
exchange [RFC9242] that MUST be supported. In addition, the
following extensions can contribute to the security and the
robustness of the protocol.
* IKE fragmentation [RFC7383] SHOULD be negotiated in case peers use
UDP as a transport for IKE, since KEM public key and KEM
ciphertext can be of significant size.
* Multiple key exchanges [RFC9370] has to be utilized if a hybrid
key exchange combining traditional and post-quantum key exchange
methods is required.
Wang & Smyslov Expires 21 April 2026 [Page 7]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
* Using group Postquantum Preshared Key (PPK)
[I-D.ietf-ipsecme-ikev2-qr-alt] can contribute to the identity
hiding, thus it is RECOMMENDED to use.
* The ability to authenticate the full protocol transcript
[I-D.smyslov-ipsecme-ikev2-downgrade-prevention] protects peers
against downgrade attacks and SHOULD be used.
6.1. Exchanges for KEM-based Authentication
6.1.1. The IKE_SA_INIT Exchange
The initiator wishing to use the KEM-based authentication indicates
this to the responder by including a new status type notification
USE_AUTHKEM (with type <TBA2>) into the IKE_SA_INIT request message.
This notification has the Protocol ID and SPI Size both set to 0
(meaning no SPI is present), and its notification data is empty. To
be able to use the KEM-based authentication the initiator MUST also
include the INTERMEDIATE_EXCHANGE_SUPPORTED notification.
If the responder receives the IKE_SA_INIT request containing the
USE_AUTHKEM notification and it supports and is configured to use the
KEM-based authentication, then it sends this notification back in the
response. The responder can optionally include the Certificate
Request payload (as defined in [RFC7296]) to help the initiator to
select the right KEM certificate. The responder can also indicate
which KEMs it is willing to use for authentication by including the
SUPPORTED_AUTH_METHODS notification [RFC9593] in the response. In
this case the notification SHOULD NOT contain announcements with the
Auth Method other than a newly defined "KEM-based Authentication"
(<TBA1>). The format of announcement is defined in Section 6.3.2.
Peers can also negotiate other IKEv2 extensions during IKE_SA_INIT.
Some of them are listed in Section 6. In particular, the figures
below show the optional use of PPK [I-D.ietf-ipsecme-ikev2-qr-alt]
during KEM-based authentication.
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1, KEi, Ni, --->
N(INTERMEDIATE_EXCHANGE_SUPPORTED),
[N(USE_PPK_INT),]
N(USE_AUTHKEM)
<--- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ,]
N(INTERMEDIATE_EXCHANGE_SUPPORTED),
[N(SUPPORTED_AUTH_METHODS),]
[N(USE_PPK_INT),]
N(USE_AUTHKEM)
Wang & Smyslov Expires 21 April 2026 [Page 8]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
Figure 1: The IKE_SA_INIT Exchange
Peers MUST ignore the USE_AUTHKEM notification in the message if it
is not accompanied by the INTERMEDIATE_EXCHANGE_SUPPORTED
notification.
If using the KEM-based authentication is mandatory for the responder
and the initiator did not propose it or failed to make a valid
proposal, then the responder MUST send the NO_PROPOSAL_CHOSEN
notification indicating that the proposed parameters are
unacceptable. Otherwise the responder can continue establishing IKE
SA using other authentication method.
If using the KEM-based authentication is mandatory for the initiator
and it failed to negotiate it with the responder, then the initiator
MUST cancel establishing IKE SA. Otherwise the initiator can
continue using other authentication method.
After the IKE_SA_INIT exchange completes, peers calculate the session
keys as defined in Section 2.14 of [RFC7296] and use these keys to
protect the next exchange.
6.1.2. The IKE_INTERMEDIATE Exchanges
Once the KEM-based authentication is negotiated in IKE_SA_INIT, a
series of the IKE_INTERMEDIATE exchanges takes place. These
exchanges can be classified as those for the purpose of the KEM-based
authentication and those for other purposes. The exchanges for the
KEM base authentication MUST follow all other IKE_INTERMEDIATE
exchanges, so that they take place right before the IKE_AUTH
exchange.
6.1.2.1. The IKE_INTERMEDIATE Exchanges for Other Purposes
First, if multiple key exchanges were negotiated, then one or more
IKE_INTERMEDIATE exchanges are performed, right after the IKE_SA_INIT
exchange, as defined in [RFC9370].
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_INTERMEDIATE), SK {KEi(n)} --->
<--- HDR(IKE_INTERMEDIATE), SK {KEr(n)}
Figure 2: Additional Key Exchange(s)
Each of these exchanges updates the session keys as defined in
Section 2.2.2 of [RFC9370].
Wang & Smyslov Expires 21 April 2026 [Page 9]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
If the use of PPKs as defined in [I-D.ietf-ipsecme-ikev2-qr-alt] is
negotiated, then the IKE_INTERMEDIATE exchange negotiating the PPK to
use is performed then as defined in Section 3.1 of
[I-D.ietf-ipsecme-ikev2-qr-alt].
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_INTERMEDIATE), SK {PPK_IDENTITY_KEY)} --->
<--- HDR(IKE_INTERMEDIATE), SK {N(PPK_IDENTITY)}
Figure 3: PPK Negotiation
After this exchange the session keys are updated as defined in
Section 3.1.1 of [I-D.ietf-ipsecme-ikev2-qr-alt].
If both additional key exchange(s) and the use of PPKs as defined in
[I-D.ietf-ipsecme-ikev2-qr-alt] are negotiated, then the last
additional key exchange MAY alternatively be combined with
negotiation the PPK in a single IKE_INTERMEDIATE exchange as shown in
Figure 3. Note, that in many cases only one additional key exchange
will be negotiated (as a part of PQ/T hybrid key exchange), thus in
this case the last additional key exchange will also be the only one.
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_INTERMEDIATE), SK {KEi(m),
(PPK_IDENTITY_KEY)} --->
<--- HDR(IKE_INTERMEDIATE), SK {KEr(m),
N(PPK_IDENTITY)}
Figure 4: Last Additional Key Exchange Combined with PPK Negotiation
If this combined IKE_INTERMEDIATE exchange takes place, then upon its
completion session keys are updated twice - fist as defined in
Section 2.2.2 of [RFC9370] and then, provided the peers negotiate the
PPK to use, as defined in Section 3.1.1 of
[I-D.ietf-ipsecme-ikev2-qr-alt].
Note, that while [I-D.ietf-ipsecme-ikev2-qr-alt] generally requires
that the PPK negotiation is performed in the last IKE_INTERMEDIATE
exchange right before the IKE_AUTH exchange, it also allows this
requirement to be overridden by other specification. This document
specifically overrides this requirement by allowing the
IKE_INTERMEDIATE exchanges concerned with the KEM-based
authentication to take place between the negotiation of PPK and the
IKE_AUTH exchange.
Wang & Smyslov Expires 21 April 2026 [Page 10]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
6.1.2.2. The IKE_INTERMEDIATE Exchanges for the KEM-based
Authentication
The next IKE_INTERMEDIATE exchanges perform the necessary actions for
the KEM-based authentication.
First, the peers exchange their KEM certificates. The initiator can
optionally include the Certificate Request payload to help the
responder to select the right KEM certificate. The initiator can
also indicate which KEMs it is willing to use for authentication by
including the SUPPORTED_AUTH_METHODS notification [RFC9593] in the
response. In this case the notification SHOULD NOT contain
announcements with the Auth Method other than the "KEM
Authentication" (<TBA1>). The format of announcement is defined in
Section 6.3.2.
The initiator's certificate and the responder's one MAY contain
public keys for different KEMs, provided that peers support these
KEMs, - there is no requirement that they are for the same KEM.
Since KEM certificates can have significant size, peers MAY use hash-
and-URL certificate lookup (by using "Hash and URL of X.509
certificate" or "Hash and URL of X.509 bundle" certificate encoding).
In this case the CERT payload would contain the URL and the hash of
the certificate(s) as defined in Section 3.6 of [RFC7296]. The
advantage of this approach is that a host can avoid downloading the
peer's certificates if it cached this certificate from a previous
connection. The hash of a certificate provided in the Certificate
payload is used to find the certificate in a cache in this case.
Besides the KEM certificate, additional intermediate signing
certificates can be sent. The KEM certificate MUST be the first and
the only KEM certificate in the message.
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_INTERMEDIATE), SK {[CERTREQ,]
[N(SUPPORTED_AUTH_METHODS),] CERT} --->
<--- HDR(IKE_INTERMEDIATE), SK {CERT}
Figure 5: Exchange of KEM Certificates
This exchange does not update the current session keys.
Wang & Smyslov Expires 21 April 2026 [Page 11]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
Once peers exchange their KEM certificates they verify each other's
certificate to make sure that it is valid, properly signed by a
certificate chain leaded to a trusted CA, and that it is acceptable
for peer authentication based on the local policy. The exact
verification steps are out of scope of this document, but generally
should follow those defined in [RFC5280].
The next IKE_INTERMEDIATE exchange is used to exchange the
ciphertexts CT_i and CT_r obtained as a result of encapsulation of
random values SS_i and SS_r using the long-term KEM public keys. The
KEM public keys are extracted from the KEM certificates received in
the previous exchange.
The peers send each other a new status type notification AUTHKEM_DATA
(with type <TBA3>). The Protocol ID and SPI Size fields are set to 0
(meaning no SPI is present). The Notification Data is a
concatenation of two values CT and SSCONF prepared by each peer,
where CT_i and SSCONF_i are prepared by the initiator, while CT_r and
SSCONF_r are prepared by the responder. These values are computed as
follows ("x" is either "i" or "r"):
* CT_x is a ciphertext obtained as a result of encapsulation of a
random value SS_x with a the long-term public key from the peer's
certificate.
* SSCONF_x is computed as prf(SK_px, SS_x), where prf is the
negotiated PRF for this SA.
As a result, the data in the AUTHKEM_DATA notification sent by the
initiator is CT_i | SSCONF_i and the data in this notification sent
by the responder is CT_r | SSCONF_r.
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_INTERMEDIATE), SK {N(AUTHKEM_DATA)} --->
<--- HDR(IKE_INTERMEDIATE), SK {N(AUTHKEM_DATA)}
Figure 6: Exchange of Encrypted Random Values
Upon receiving the message each side performs the following steps:
1. Splits the content of the AUTHKEM_DATA notification into CT and
SSCONF parts based on the known sizes of the ciphertext of the
used KEM algorithm and the output size of the negotiated PRF.
2. Decrypts CT using the receiver's own private key corresponding to
its own KEM certificate, which was sent in the previous exchange
to the peer, and gets the SS value encapsulated by the peer.
Wang & Smyslov Expires 21 April 2026 [Page 12]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
3. Computes peer's SSCONF value and checks whether it matches the
received SSCONF value.
If the computed and the received SSCONF values match, then the host
can be sure that it received exactly the same SS value as was sent by
its peer. To complete authentication the host needs to prove this
fact to its peer, and to make sure that the peer also received
exactly the same SS value as it sent.
Upon completion of this exchange the session keys are updated. A new
value of SKEYSEED is computed as:
SKEYSEED' = prf(SK_d, SS_i | SS_r)
Then all the session keys (SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi,
and SK_pr) are computed as defined in Section 2.14 of [RFC7296].
These session keys are then used for protecting all subsequent
exchanges starting from the IKE_AUTH exchange.
6.1.3. The IKE_AUTH Exchange
The IKE_AUTH exchange immediately follows the IKE_INTERMEDIATE
exchange where peers sent each other encrypted SS values. The
IKE_AUTH exchange is basically unchanged from that defined in
[RFC7296]. The Auth Method field in the AUTH payloads MUST be "KEM
Authentication". The format of the AUTH payload is computed as
defined in Section 6.3.1.
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_AUTH), SK{IDi, [IDr,]
AUTH, SAi2, TSi, TSr} --->
<--- HDR(IKE_AUTH), SK{IDr,
AUTH, SAr2, TSi, TSr}
Figure 7: The IKE_AUTH Exchange
6.1.3.1. Identities in the IKE_AUTH Exchange
With KEM based authentication peers have to exchange their KEM
certificates before actual authentication of each other.
Certificates usually contain some identity information, that the CA
asserts the included public key is bound to. This makes peers aware
of each other's identity before the IKE_AUTH exchange starts.
However, IKEv2 doesn't rely on the identities from certificates when
performing authentication. Instead, Identification payloads (IDi and
IDr) are mandatory in the IKE_AUTH exchange and exactly they are
Wang & Smyslov Expires 21 April 2026 [Page 13]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
included into the AUTH payload calculation. The content of the IDi
and IDr payload may differ from the identification information in the
corresponding certificate, as stated in Section 3.5 of [RFC7296].
6.2. Alternative Sequences of Exchanges
This section is to be removed eventually. It provides ideas for
alternative design of the protocol.
The presented sequence of exchanges requires two additional exchanges
(namely IKE_INTERMEDIATE exchanges) for KEM-based authentication
compared to signature-based authentication. It is possible to only
have one additional IKE_INTERMEDIATE exchange, but this either
results in some degradation of security properties or leads to
additional protocol complexity. Note, that the amount of data
exchanged over the wire would not changed, the different items would
just be combined in one message. This, it turn, would increase size
of these messages that might not be desirable from reliable delivery
point of view.
6.2.1. Alternative 1: Send Certificates Encrypted Only with the
IKE_SA_INIT Keys
It is possible to exchange certificates before all additional key
exchanges (and optional negotiation of the PPK) are completed. In
this case the certificates would only be protected with session keys
computed after the IKE_SA_INIT exchange (in case of hybrid key
exchange that would be traditional key exchange).
In this case, the exchange shown in Figure 5 is not needed, since the
certificates would be exchanged in the previous exchange. For
example, the exchange shown in Figure 4 would look like:
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_INTERMEDIATE), SK {KEi(m),
(PPK_IDENTITY_KEY), [CERTREQ,]
[N(SUPPORTED_AUTH_METHODS),] CERT} --->
<--- HDR(IKE_INTERMEDIATE), SK {KEr(m),
(PPK_IDENTITY), CERT}
Figure 8: Last Additional Key Exchange Combined with PPK
Negotiation and Exchange of Certificates
This design would decrease the level of identity hiding, since the
session keys used to protect the certificates in case of hybrid key
exchange could be cracked by an attacker using quantum computer.
Wang & Smyslov Expires 21 April 2026 [Page 14]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
On the other hand, KEM-based authentication is generally more
succeptible to learning the identities of the peers by an attacker,
because the peers have to exchange their certificates before
authenticating each other, which makes it possible for the attacker
in the middle to learn them.
6.2.2. Alternative 2: Change the Order of Certificates and Use Double
Encryption
It is possible to get almost the same protection as in the original
design but still eliminating one IKE_INTERMEDIATE exchange by
complicating the protocol.
In this case the exchange shown in Figure 5 is also not needed. The
responder sends its certificate first in the previous
IKE_INTERMEDIATE exchange. Note, that this exchange contains the
last additional key exchange and optionally the PPK negotiation, thus
its messages are not yet protected with the session keys that would
result in this exchange - the new key are calculated only once the
exchange completes. However, the responder can calculate the updated
keys before it sends the response message. The idea is that the
responder calculates new session keys and use these "future" keys
(for the next exchange) to protect its certificate in the encrypted
payload, that itself is protected with the "current" session keys.
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_INTERMEDIATE), SK {KEi(m),
(PPK_IDENTITY_KEY), [CERTREQ,]
[N(SUPPORTED_AUTH_METHODS),]} --->
<--- HDR(IKE_INTERMEDIATE), SK {KEr(m),
(PPK_IDENTITY), N(ENCYPTED_CERT)(cert)}
Figure 9: Last Additional Key Exchange Combined with PPK
Negotiation and Responder's Certificate
Then the initiator sends its certificate in the exchange shown in
Figure 6.
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_INTERMEDIATE), SK {CERT, N(AUTHKEM_DATA)} --->
<--- HDR(IKE_INTERMEDIATE), SK {N(AUTHKEM_DATA)}
Figure 10: Initiator's Certificate and Exchange of Encrypted
Random Values
Wang & Smyslov Expires 21 April 2026 [Page 15]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
This sequence of exchanges allows certificates to be protected at the
same level as in the original sequence of exchanges (in particular,
both certificates can be protected with group PPK). The drawback is
the added complexity for implementations, since it could break the
traditional state transitions logic of IKE.
6.3. Data Formats
6.3.1. Authentication Payload for KEM-based Authentication
The format of the Authentication payload is defined in Section 3.8 of
[RFC7296]. In case of KEM-based authentication the Auth Method is
set to "KEM Authentication" (<TBA1>). The Authentication Data is
computed as:
For the initiator:
AUTH = prf( prf(SK_pi, "Key Pad for IKEv2"),
<InitiatorSignedOctets>)
For the responder:
AUTH = prf( prf(SK_pr, "Key Pad for IKEv2"),
<ResponderSignedOctets>)
The content of the InitiatorSignedOctets and the
ResponderSignedOctets is defined in Section 3.3.2 of [RFC9242]. If
full transcript authentication is employed as specified in
[I-D.smyslov-ipsecme-ikev2-downgrade-prevention], then the
InitiatorSignedOctets and the ResponderSignedOctets are additionally
modified as defined in
[I-D.smyslov-ipsecme-ikev2-downgrade-prevention].
6.3.2. Authentication Announcement for KEM Authentication
The format of the announcement for the "KEM Authentication" is the
same as for "Digital Signature" as shown in Section 3.2.3 of
[RFC9593]. For convenience the format is also shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (>3) | Auth Method | Cert Link | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ AlgorithmIdentifier ASN.1 object ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wang & Smyslov Expires 21 April 2026 [Page 16]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
Figure 11: Supported Authentication Method
* Length - Length of the announcement in octets, must be greater
than 3.
* Auth Method - Announced authentication method, in this case it is
"KEM Authentication".
* Cert Link - Links this announcement with particular CA; see
Section 3.2.2 of [RFC9593] for details.
* AlgorithmIdentifier ASN.1 object - the AlgorithmIdentifier of PKIX
(see Section 4.1.1.2 of [RFC5280]), encoded using distinguished
encoding rules (DER) [X.690].
For "KEM Authentication" announcement the AlgorithmIdentifier MUST
contain identifier of a KEM algorithm (and not, for example, of a
signature algorithm). Identifiers for KEM algorithms are specified
in the corresponding documents for these algorithms (e.g., for ML-KEM
see [I-D.ietf-lamps-kyber-certificates]).
7. Interaction with Other IKEv2 Extensions
To be added.
8. Security Considerations
To be done later. 1) It may be not a good idea by directly showing
the decapsulated secret ss as the means of authentication here. The
reason is that the entity being authenticated may employ the owner of
the KEM public/private key pair as an oracle to decapsualte the
secret via running a different session, normally within a separate
protocol or scenario where directly showing such a secret is
harmless. 2) It may be preferable or MUST limit the use of such a
KEM certificate only for KEM authentication.
9. IANA Considerations
IANA is requested to make the following changes in the IKEv2
registries "Internet Key Exchange Version 2 (IKEv2) Parameters"
[IANA-IKEv2]:
1. Define a new authentication method "KEM Authentication" in the
"IKEv2 Authentication Method" registry:
Wang & Smyslov Expires 21 April 2026 [Page 17]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
+=======+=============================+
| Value | IKEv2 Authentication Method |
+=======+=============================+
| TBA1 | KEM Authentication |
+-------+-----------------------------+
Table 3
2. Define two new status type notifications in the "IKEv2 Notify
Message Status Types" registry:
+=======+============================+
| Value | Notify Message Status Type |
+=======+============================+
| TBA2 | USE_AUTHKEM |
+-------+----------------------------+
| TBA3 | AUTHKEM_DATA |
+-------+----------------------------+
Table 4
10. References
10.1. Normative References
[IANA-IKEv2]
"Internet Key Exchange Version 2 (IKEv2) Parameters", the
Internet Assigned Numbers Authority (IANA). ,
<https://www.iana.org/assignments/ikev2-parameters/
ikev2-parameters.xhtml>.
[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>.
[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>.
[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>.
Wang & Smyslov Expires 21 April 2026 [Page 18]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
[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>.
10.2. Informative References
[FIPS203] National Institute of Standards and Technology, "FIPS 203:
Module-Lattice-Based Key-Encapsulation Mechanism
Standard", Federal Information Processing Standards
Publication , August 2024,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.203.pdf>.
[FIPS204] National Institute of Standards and Technology, "FIPS 204:
Module-Lattice-Based Digital Signature Standard", Federal
Information Processing Standards Publication , August
2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.204.pdf>.
[FIPS205] National Institute of Standards and Technology, "FIPS 205:
Stateless Hash-Based Digital Signature Standard", Federal
Information Processing Standards Publication , August
2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.204.pdf>.
[HAZ24] Huang, J., Adomnicai, A., Zhang, J., Dai, W., Liu, Y.,
Cheung, R. C. C., Koc, C. K., and D. Chen, "Revisiting
Keccak and Dilithium Implementations on ARMv7-M", IACR
Transactions on Cryptographic Hardware and Embedded
Systems. ISSN 2569-2925, Vol. 2024, No. 2, pp. 1–24.,
March 2024,
<https://tches.iacr.org/index.php/TCHES/article/
view/11419>.
[I-D.celi-wiggers-tls-authkem]
Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N.
Sullivan, "KEM-based Authentication for TLS 1.3", Work in
Progress, Internet-Draft, draft-celi-wiggers-tls-authkem-
05, 22 April 2025, <https://datatracker.ietf.org/doc/html/
draft-celi-wiggers-tls-authkem-05>.
Wang & Smyslov Expires 21 April 2026 [Page 19]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
[I-D.hu-ipsecme-pqt-hybrid-auth]
Hu, J., Morioka, Y., and G. WANG, "Post-Quantum
Traditional (PQ/T) Hybrid PKI Authentication in the
Internet Key Exchange Version 2 (IKEv2)", Work in
Progress, Internet-Draft, draft-hu-ipsecme-pqt-hybrid-
auth-02, 1 May 2025,
<https://datatracker.ietf.org/doc/html/draft-hu-ipsecme-
pqt-hybrid-auth-02>.
[I-D.ietf-ipsecme-ikev2-mlkem]
Kampanakis, P., "Post-quantum Hybrid Key Exchange with ML-
KEM in the Internet Key Exchange Protocol Version 2
(IKEv2)", Work in Progress, Internet-Draft, draft-ietf-
ipsecme-ikev2-mlkem-03, 29 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
ikev2-mlkem-03>.
[I-D.ietf-ipsecme-ikev2-pqc-auth]
Reddy, T., Smyslov, V., and S. Fluhrer, "Signature
Authentication in the Internet Key Exchange Version 2
(IKEv2) using PQC", Work in Progress, Internet-Draft,
draft-ietf-ipsecme-ikev2-pqc-auth-05, 16 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
ikev2-pqc-auth-05>.
[I-D.ietf-ipsecme-ikev2-qr-alt]
Smyslov, V., "Mixing Preshared Keys in the
IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of
IKEv2 for Post-quantum Security", Work in Progress,
Internet-Draft, draft-ietf-ipsecme-ikev2-qr-alt-10, 23 May
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
ipsecme-ikev2-qr-alt-10>.
[I-D.ietf-lamps-kyber-certificates]
Turner, S., Kampanakis, P., Massimo, J., and B.
Westerbaan, "Internet X.509 Public Key Infrastructure -
Algorithm Identifiers for the Module-Lattice-Based Key-
Encapsulation Mechanism (ML-KEM)", Work in Progress,
Internet-Draft, draft-ietf-lamps-kyber-certificates-11, 22
July 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-lamps-kyber-certificates-11>.
[I-D.ietf-pquip-hybrid-signature-spectrums]
Bindel, N., Hale, B., Connolly, D., and F. D, "Hybrid
signature spectrums", Work in Progress, Internet-Draft,
draft-ietf-pquip-hybrid-signature-spectrums-07, 20 June
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
pquip-hybrid-signature-spectrums-07>.
Wang & Smyslov Expires 21 April 2026 [Page 20]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
[I-D.smyslov-ipsecme-ikev2-downgrade-prevention]
Smyslov, V. and C. Patton, "Prevention Downgrade Attacks
on the Internet Key Exchange Protocol Version 2 (IKEv2)",
Work in Progress, Internet-Draft, draft-smyslov-ipsecme-
ikev2-downgrade-prevention-02, 28 August 2025,
<https://datatracker.ietf.org/doc/html/draft-smyslov-
ipsecme-ikev2-downgrade-prevention-02>.
[I-D.wiggers-tls-authkem-psk]
Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N.
Sullivan, "KEM-based pre-shared-key handshakes for TLS
1.3", Work in Progress, Internet-Draft, draft-wiggers-tls-
authkem-psk-03, 22 April 2025,
<https://datatracker.ietf.org/doc/html/draft-wiggers-tls-
authkem-psk-03>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[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>.
[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>.
[RFC9593] Smyslov, V., "Announcing Supported Authentication Methods
in the Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 9593, DOI 10.17487/RFC9593, July 2024,
<https://www.rfc-editor.org/info/rfc9593>.
[SSW20] Schwabe, P., Stebila, D., and T. Wiggers, "Post-quantum
TLS without handshake signatures", In the Proceedings of
ACM CCS 2020, pages 1461–1480. ACM
Press. doi:10.1145/3372297.3423350., November 2020.
[X.690] ITU-T, "Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2021 (E), ITU-T Recommendation
X.690, February 2021.
Wang & Smyslov Expires 21 April 2026 [Page 21]
Internet-Draft KEM-based Authentication for IKEv2 October 2025
Acknowledgements
To be added later.
Contributors
Uri Blumenthal and Brandon Luo contributed a lot to the design of
this protocol as authors of PQuAKE protocol.
Authors' Addresses
Guilin Wang (editor)
Huawei Int. Pte Ltd
9 North Buona Vista Drive, #13-01
The Metropolis Tower 1
SINGAPORE 138588
Singapore
Email: Wang.Guilin@huawei.com
Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd)
124460
Russian Federation
Email: svan@elvis.ru
Wang & Smyslov Expires 21 April 2026 [Page 22]