KEM-based Authentication for IKEv2 with Post-quantum Security
draft-wang-ipsecme-kem-auth-ikev2-05
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 | 2026-11-15 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| On agenda | ipsecme at IETF-127 | ||
| 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-05
IP Security Maintenance and Extensions G. Wang, Ed.
Internet-Draft Huawei Int. Pte Ltd
Intended status: Standards Track V. Smyslov, Ed.
Expires: 19 May 2027 ELVIS-PLUS
15 November 2026
KEM-based Authentication for IKEv2 with Post-quantum Security
draft-wang-ipsecme-kem-auth-ikev2-05
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 19 May 2027.
Copyright Notice
Copyright (c) 2026 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 19 May 2027 [Page 1]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notes of Change . . . . . . . . . . . . . . . . . . . . . 2
1.2. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . 8
6.1. Exchanges for KEM-based Authentication . . . . . . . . . 8
6.1.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . 8
6.1.2. IKE_INTERMEDIATE Exchanges . . . . . . . . . . . . . 10
6.1.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 15
6.2. Data Formats . . . . . . . . . . . . . . . . . . . . . . 16
6.2.1. Authentication Payload for KEM-based
Authentication . . . . . . . . . . . . . . . . . . . 16
6.2.2. Authentication Announcement for KEM Authentication . 17
6.2.3. Encrypted Certificate Payload . . . . . . . . . . . . 17
7. Interaction with Other IKEv2 Extensions . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Security Objectives and Assumptions . . . . . . . . . . . 19
8.2. Authentication and Authorization . . . . . . . . . . . . 20
8.3. Transcript Binding and Downgrade Resistance . . . . . . . 20
8.4. Key Separation and Decapsulation Oracles . . . . . . . . 21
8.5. Forward Secrecy and Post-Quantum Protection . . . . . . . 21
8.6. Identity Protection . . . . . . . . . . . . . . . . . . . 22
8.7. Invalid Inputs, Failure Handling, and Side Channels . . . 23
8.8. Resource Exhaustion and Retransmission . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Relationship to PQuAKE . . . . . . . . . . . . . . . 29
A.1. Shared Design . . . . . . . . . . . . . . . . . . . . . . 29
A.2. Conceptual Correspondence . . . . . . . . . . . . . . . . 29
A.3. Differences Relevant to Security . . . . . . . . . . . . 30
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
1.1. Notes of Change
Version 05: Section 8 was fully updated, with togther a number of
editorial changes.
Wang & Smyslov Expires 19 May 2027 [Page 2]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
Version 04: Leave only one exchange sequence.
* Making the alternative sequence 2 as the main and the only
sequence of exchanges to achieve the minimum number of
IKE_INTERMEDIATE exchanges and aligns PQuAKE
[I-D.uri-cfrg-pquake].
* Removed alternative sequences to Appendix?
Version 03: Add identity protection against active attackers.
* Initiator’s identity protection against active attacker is added.
* New payload Encrypted Certificate (ECERT).
* New Certificate Encoding X.509 bundle.
* New notifications: AUTHKEM_CT, AUTHKEM_SSCONF, AUTHKEM_DATA.
* Notification AUTHKEM_DATA in version 02 is deleted.
Version 02: Completely rewritten to accommodate ideas expressed in
PQuAKE protocol.
Version 01: Two changes have been made, as a response to comments
received at 122 meeting.
* More details about how each side run KEM-based authentication in
Section 6.1.
* Added section about KEM authentication with preshared public key.
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.
Wang & Smyslov Expires 19 May 2027 [Page 3]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
"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 a 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, explicitly or implicitly. This idea was
previously 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 reduces implementation code size, as the code for
PQ signature may not be needed, 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.
3. Key Encapsulation Mechanism and Digital Signature
A key encapsulation mechanism (KEM) is a set of algorithms that
enables key exchange to be performed, 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.
Wang & Smyslov Expires 19 May 2027 [Page 4]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
* 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
inputs a secret decapsulation key sk and a 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 acceptance (b=1) or
rejection (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 Level 5, while
ML-DSA-44 for Level 2, ML-DSA-65 for Level 3, and ML-DSA-87 for Level
5.
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.
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. 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,
Wang & Smyslov Expires 19 May 2027 [Page 5]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
* 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
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 over 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 1% or more.
About the computation overhead comparison, [HAZ24] present
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.
Wang & Smyslov Expires 19 May 2027 [Page 6]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
+=============+===============+===============+===============+
| | SKeyGen Time/ | Sign Time/ | Verify Time/ |
| | KeyGen Time | Encap Time | Decap 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 a performance difference of ML-KEM and ML-DSA on
the same platform with optimal implementations, 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.
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 may
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.
Wang & Smyslov Expires 19 May 2027 [Page 7]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
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,
certified by 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 can 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.
More details about the KEM-based authentication are provided in
[I-D.uri-cfrg-pquake] and the corresonding paper.
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.
* Using group Postquantum Preshared Key (PPK) [RFC9867] can
contribute to the identity hiding, thus it is RECOMMENDED to use.
* The ability to authenticate the full protocol transcript
[I-D.ietf-ipsecme-ikev2-downgrade-prevention] protects peers
against downgrade attacks and SHOULD be used.
6.1. Exchanges for KEM-based Authentication
6.1.1. 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> by IANA) 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.
Wang & Smyslov Expires 19 May 2027 [Page 8]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
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> by IANA). The format of announcement is defined in
Section 6.2.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 [RFC9867] 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)
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 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.
Wang & Smyslov Expires 19 May 2027 [Page 9]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
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. 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. IKE_INTERMEDIATE Exchanges for Purposes Other than KEM-based
Authentication
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].
If the use of PPKs as defined in [RFC9867] is negotiated, then the
IKE_INTERMEDIATE exchange negotiating the PPK to use is performed as
defined in Section 3.1 of [RFC9867].
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 [RFC9867].
If both additional key exchange(s) and the use of PPKs as defined in
[RFC9867] are negotiated, then the last additional key exchange MAY
alternatively be combined with negotiating the PPK in a single
Wang & Smyslov Expires 19 May 2027 [Page 10]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
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 [RFC9867].
Note, that while [RFC9867] 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.
6.1.2.2. IKE_INTERMEDIATE Exchanges for KEM-based Authentication
KEM-based authentication requires two exchanges, but the first of
them is usually combined with the last IKE_INTERMEDIATE exchange
performed for other purposes (see Figure 2, Figure 3, and Figure 4),
so that only one additional IKE_INTERMEDIATE exchange takes place in
this case. If no IKE_INTERMEDIATE exchanges preceed, then two such
exchanges are needed for KEM-based authentication.
In the first exchange (which is combined with the preceeding
IKE_INTERMEDIATE exchange, if any) the responder sends its KEM
certificate to the initiator. The initiator can optionally include
Certificate Request payloads in the request message to help the
responder to select the right KEM certificate. The Certificate
Request payload can also be used to indicate which format(s) of
certificate are acceptable for the sender of this payload. This is
done by setting the Cert Encoding field to appropriate value. For
KEM-based authentication this field MUST be either "X.509 bundle"
(new certificate encoding defined in this document, it value is <TBA5
by IANA>) or "Hash and URL of X.509 bundle" (value 13). If both
encodings are acceptable, then two Certificate Request payloads MUST
Wang & Smyslov Expires 19 May 2027 [Page 11]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
be included (with possibly different list of CAs) each with its own
value in the Cert Encoding field. Since the Certificate Request
payload is optional, its absence leaves the choice of the certificate
and its encoding on the certificate sender's discretion. Note that
these rules are also applicable to the Certificate Request payload
sent by the responder in the IKE_SA_INIT exchange (see
Section 6.1.1).
The initiator can also indicate which KEMs it is willing to use for
authentication by including the SUPPORTED_AUTH_METHODS notification
[RFC9593] in the request. In this case the notification SHOULD NOT
contain announcements with the Auth Method other than the "KEM
Authentication" (<TBA1> by IANA). The format of announcement is
defined in Section 6.2.2.
The responder provides its KEM certificate in the response. Besides
the KEM certificate, additional intermediate certificates and CRLs
can be provided. All these certificates and CRLs are packed into the
CertificateBundle ASN.1 structure defined in Section 3.6 of
[RFC7296]. The KEM certificate MUST be the only KEM certificate in
the bundle.
The certificate bundle can either be sent directly in the response or
be provided by a reference using Hash and URL syntax. In both cases
this content (either bundle or hash and URL) is sent in a new payload
"Encrypted Certificate" (with type <TBA0 by IANA>), denoted as ECERT
below. The content is encrypted using key derived from the SK_d for
the next exchange (see Section 6.2.3 for details).
| Note that while the next exchange is not started yet, the
| responder can already calculate the session keys for it and can
| uses these "future" keys (purposed for the next exchange) to
| encrypt the content of the Encrypted Certificate payload, that
| itself will be protected with the "current" session keys in the
| Encrypted payload.
If the certificate bundle is sent inband, then the Cert Encoding
field in the Encrypted Certificate payload is set to a new value
"X.509 bundle", otherwise it is set to "Hash and URL of X.509
bundle". If certificate bundle is provided by reference, then a host
can avoid downloading the peer's certificates if it cached them from
a previous connection.
Exactly one Encrypted Certificate payload MUST be present in the
response.
Wang & Smyslov Expires 19 May 2027 [Page 12]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
Since this exchange can be combined with the preceeding
IKE_INTERMEDIATE exchange, we use notation "..." to indicate payloads
for the purposes other than KEM-based authentication. In case of no
preceeding IKE_INTERMEDIATE exchanges, no payloads for other purposes
are present in this exchange.
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_INTERMEDIATE), SK {... [CERTREQ+,]
[N(SUPPORTED_AUTH_METHODS)]} --->
<--- HDR(IKE_INTERMEDIATE), SK {... ECERT}
Figure 5: Obtaining Responder's KEM Certificate
Whether this exchange updates the current session keys or not depends
on the purpose of the preceeding exchange. In particular, in case of
Figure 2, Figure 3, and Figure 4), the keys are updated as the result
of those exchanges. If this exchange is not combined with other
IKE_INTERMEDIATE exchanges, then it does not update the current
session keys.
The initiator verifies the responder'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 responder authentication
based on the initiator's local policy. The exact verification steps
are out of scope of this document, but generally should follow those
defined in [RFC5280].
Then the initiator starts the next IKE_INTERMEDIATE exchange. In the
request message it sends the ciphertext CT_i, produced as a result of
encapsulation of a random value SS_i using the KEM public key from
the responder's certificate. CT_i is sent in a new status type
notification AUTHKEM_CT (with type <TBA3> by IANA). The Protocol ID
and SPI Size fields are set to 0 (meaning no SPI is present). The
notification data contains the ciphertext CT_i.
In the same request the initiator also sends its KEM certificate.
Besides the KEM certificate, additional intermediate signing
certificates and CRLs can be sent. All these certificates and CRLs
are packed into the CertificateBundle ASN.1 structure defined in
Section 3.6 of [RFC7296]. The KEM certificate MUST be the only KEM
certificate in the bundle. The bundle can either be present in the
message or be provided by reference In both cases this content
(either bundle or hash and URL) is sent in the "Encrypted
Certificate" payload. The content is encrypted using key derived
from SS_i. The details of the Certificate payload encryption are
provided in Section 6.2.3.
Wang & Smyslov Expires 19 May 2027 [Page 13]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
The encryption provides protection of initiator's identity against
active attackers, since only a responder with the private key
corresponding to the responder's certificate is able to decrypt the
initiator's KEM certificate.
| Note that if the bundle is provided by reference and an
| attacker can monitor the responder's network activity, then
| this identity protection might not work.
If the certificate bundle is sent inband, then the Cert Encoding
field in the Encrypted Certificate payload is set to a "X.509
bundle", otherwise it is set to "Hash and URL of X.509 bundle". If
certificate bundle is provided by reference, then a host can avoid
downloading the peer's certificates if it cached them from a previous
connection.
Exactly one Encrypted Certificate payload MUST be present in the
message.
The responder decrypts the initiator's certificate, verifies it to
make sure that it is valid, properly signed by a certificate chain
leaded to a trusted CA, and that it is acceptable for initiator
authentication based on the responder's local policy. The exact
verification steps are out of scope of this document, but generally
should follow those defined in [RFC5280].
The initiator's certificate and the responder's one, sent in the
previous exchange, MAY contain public keys for different KEMs,
provided that peers support these KEMs, - there is no requirement
that the KEMs must be the same.
The responder then sends a response message containing the ciphertext
CT_r, produced as a result of encapsulation of a random value SS_r
using the KEM public keys from the initiator's certificate. CT_r is
sent in the AUTHKEM_CT notification in the same manner as SS_i.
The responder also includes a new status type notification
AUTHKEM_SSCONF (with type <TBA3> by IANA). The Protocol ID and SPI
Size fields are set to 0 (meaning no SPI is present). The
notification data contains an SSCONF value computed as:
SSCONF = prf(SK_pr, SS_r)
where prf is the negotiated PRF for this SA and SK_pr is from the
current session keys (see Section 3.3.1 of [RFC9242]).
Wang & Smyslov Expires 19 May 2027 [Page 14]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_INTERMEDIATE), SK {N(AUTHKEM_CT), ECERT} --->
<--- HDR(IKE_INTERMEDIATE), SK {N(AUTHKEM_CT),
N(AUTHKEM_SSCONF)}
Figure 6: Obtaining Initiator's KEM Certificate and Exchange of
Encrypted Random Values
Upon receiving the response message, the initiator decapsulates the
received ciphertext CT_r and obtains the SS_r key. Then the
initiator computes re-computes the SSCONF value using the obtained
SS_r and verifies that the value matches the content of the
AUTHKEM_SSCONF notification data. This ensures that there are no
mis-configurations and the received SS_r value is indeed the same
that was encapsulated.
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. 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.2.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
The AUTH payloads are composed as defined in Section 6.2.1.
Wang & Smyslov Expires 19 May 2027 [Page 15]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
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
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. Data Formats
6.2.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> by IANA). 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 keys SK_pi and SK_pr used for these calculations are from the
latest generation of the SK* keys that is computed from SKEYSEED'
(see Section 6.1.2.2).
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.ietf-ipsecme-ikev2-downgrade-prevention], then the
InitiatorSignedOctets and the ResponderSignedOctets are additionally
modified as defined in [I-D.ietf-ipsecme-ikev2-downgrade-prevention].
Wang & Smyslov Expires 19 May 2027 [Page 16]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
6.2.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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: 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" <TBA1 by IANA>.
* Cert Link - Links this announcement with a 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 [RFC9935]).
6.2.3. Encrypted Certificate Payload
The Encrypted Certificate payload, denoted ECERT in this document,
provides a means to transport certificates or other authentication-
related information in encrypted form. The payload type for the
Encrypted Certificate payload is <TBA0 by IANA>. This payload is
semantically equivalent to the Certificate payload (defined in
Section 3.6 of [RFC7296], but it provides a means to encrypt the
certificate information. For this purpose the format of the
Encrypted Certificate payload mirrors the format of the Encrypted
payload (defined in Section 3.14 of [RFC7296]) with the difference,
Wang & Smyslov Expires 19 May 2027 [Page 17]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
that it contains not the encrypted IKE payloads, but the encrypted
Cert Encoding and Certificate Data as defined in Section 3.6 of
[RFC7296].
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Initialization Vector ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Encrypted Cert Encoding and Certificate Data ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Encrypted Certificate Payload Format
Initialization Vector, Padding, Pad Length and Integrity Checksum
Data are defined in Section 3.14 of [RFC7296].
This document restricts the possible values of Cert Encoding in the
ECERT payload to either "X.509 bundle" (<TBA5 by IANA>) or "Hash and
URL of X.509 bundle" (13). Future specifications may define
additional encodings allowed for use in this payload.
The cryptographic processing of the Encrypted Certificate payload is
identical to that described in Section 3.14 of [RFC7296] (as well as
any document updating such processing for particular algorithms or
modes, such as [RFC5282]).
The payload is encrypted and authenticated using the same encryption
and integrity algorithms as were negotiated for IKE SA. The
encryption key EC_e and the authentication key EC_a for protecting
the Encrypted Certificate payload play the same role as SK_ei/SK_er
and SK_ai/SK_ar keys for the Encrypted payload. They are calculated
as follows:
EC_a | EC_e = prf+ ( K, Ni | Nr )
Wang & Smyslov Expires 19 May 2027 [Page 18]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
where Ni and Nr are the nonces from the IKE_SA_INIT exchange,
stripped of any headers, and K is a key used to protect the
certificate data in a particular step of the protocol. Depending on
the place where the Encrypted Certificate is sent in the protocol,
the value of K will be different. In particular:
* For ECERT sent by the responder (as per Figure 5) the SK_d value
for the next IKE_INTERMEDIATE is used as the K, which resulted to
the following calculation:
EC_a | EC_e = prf+ ( SK_d(next), Ni | Nr )
* For ECERT sent by the initiator (as per Figure 6) the SS_i value
is used as the K, which resulted to the following calculation:
EC_a | EC_e = prf+ ( SS_i, Ni | Nr )
| Note that if AEAD transform is negotiated, then the EC_a key
| will not be used and thus will be empty. This is the same as
| for SK_ai/SK_ar keys for the Encrypted payload.
7. Interaction with Other IKEv2 Extensions
Note: Initial thoughts, need expanding.
KEM can be replaced as a composite KEM, as defined in Lamps WG. The
composition job is done at crypto-engineering level, so using a
composite KEM for KEM based authentication does not require to change
any thing at the protocol layer of IKEv2.
Extension is straightforward using reliable transport.
8. Security Considerations
8.1. Security Objectives and Assumptions
The security considerations of IKEv2 and the extensions used with KEM
based mechanism continue to apply. In particular, encryption of an
exchange before completion of authentication does not, by itself,
establish the identity of the communicating peer. Implementations
MUST distinguish protection under provisional session keys from
successful peer authentication. See [RFC7296] and [RFC9242].
The intended security properties are mutual authentication,
confidentiality of established session keys, binding of
authentication to the current exchange, and protection against replay
and modification. Identity protection and forward secrecy require
additional conditions described below.
Wang & Smyslov Expires 19 May 2027 [Page 19]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
These properties depend on secure KEMs, a cryptographically strong
pseudorandom function, secure encryption and integrity algorithms,
adequate randomness, correct credential validation, and correct
implementation of the complete protocol state machine. Selection of
a post-quantum KEM alone does not establish post-quantum security for
the complete protocol.
8.2. Authentication and Authorization
KEM-based authentication establishes possession of a private
decapsulation key through confirmation of secrets encapsulated to the
corresponding public key. A valid certificate establishes a binding
between a public key and an identity; receipt of that certificate
does not establish that the current peer possesses its private key.
An implementation MUST NOT declare authentication successful solely
because a certificate validates, a ciphertext decapsulates, or an
encrypted payload passes its integrity check. Authentication
requires successful verification of the peer's final AUTH payload
using the keys and authenticated octets prescribed for the current
exchange.
Certificate validation and local authorization policy MUST establish
that the credential is acceptable for the claimed IKE identity and
requested access. An implementation MUST NOT infer authorization
merely from membership in a trusted certification hierarchy. In
particular, differences between a certificate's identity information
and an Identification payload require an explicit policy decision.
A group preshared key establishes, at most, membership in the group
of entities possessing that key. It MUST NOT replace individual peer
authentication where individual accountability or authorization is
required.
8.3. Transcript Binding and Downgrade Resistance
Authentication MUST bind the peer's identity and role to the current
protocol instance. Implementations MUST preserve the prescribed
ordering of exchanges, key updates, and transcript processing. A
message accepted in one role, session, or key generation MUST NOT be
accepted as evidence of authentication in another.
The intermediate-exchange authentication rules are security-critical:
they connect exchanges protected before authentication to the
eventual AUTH verification. Implementations MUST apply those rules
consistently, including when an exchange combines several extensions.
See [RFC9242], Section 3.3.2.
Wang & Smyslov Expires 19 May 2027 [Page 20]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
Deployments requiring KEM authentication, post-quantum key
establishment, or preshared-key protection MUST enforce those
requirements through local policy. Failure to negotiate a required
mechanism MUST terminate establishment rather than trigger an
automatic retry with weaker requirements.
Full-transcript authentication
[I-D.ietf-ipsecme-ikev2-downgrade-prevention] [RFC9370] SHOULD be
used. Implementations MUST NOT treat an unauthenticated capability
announcement, error, or timeout as authorization to weaken security
policy.
8.4. Key Separation and Decapsulation Oracles
Long-term authentication keys MUST be separated from ephemeral key-
establishment keys. A long-term authentication private key MUST NOT
also be exposed through a service that returns raw decapsulation
results or otherwise enables an attacker to obtain the secret needed
to authenticate in this protocol.
Certificates and key-management policy SHOULD restrict authentication
KEM keys to their intended use. Where an applicable certificate
profile provides usage restrictions, implementations MUST enforce
them.
Raw KEM shared secrets MUST NOT be transmitted as authentication
evidence or recorded in ordinary diagnostic logs. Key confirmation
MUST use the protocol-defined cryptographic computations and session
context.
Keys for certificate protection, final authentication, IKE
protection, and application traffic require separation by purpose
and, where applicable, direction. A protocol revision introducing
additional derivations MUST specify unambiguous inputs and domain
separation; implementations MUST NOT invent incompatible derivation
rules locally.
8.5. Forward Secrecy and Post-Quantum Protection
Forward secrecy concerns compromise of long-term credentials after
completion of an otherwise uncompromised session. It does not
protect a session whose ephemeral secrets or traffic keys were
exposed during execution.
Post-quantum forward secrecy requires a suitable ephemeral post-
quantum contribution, or a suitable hybrid construction containing
such a contribution, that remains secure against the adversary under
consideration. Long-term KEM authentication secrets alone do not
Wang & Smyslov Expires 19 May 2027 [Page 21]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
provide this property: an adversary retaining ciphertexts AUTHKEM_CTs
may recover their shared secrets after obtaining the corresponding
long-term KEM private keys.
The selected key schedule must preserve the protection provided by
the ephemeral contribution. Implementations MUST erase obsolete
ephemeral private keys, encapsulation randomness, intermediate shared
secrets, and superseded key material when they are no longer
required.
When multiple key exchanges are used, their negotiation, combination,
and key updates MUST follow the applicable specification. Security
of the resulting composition must not be inferred simply from the
presence of several algorithms (See [RFC9370]).
A claim of post-quantum authentication also depends on the
credential-validation path. A quantum-vulnerable certification
signature can undermine authentication against an attacker capable of
forging that signature, even when the certified public key belongs to
a post-quantum KEM.
8.6. Identity Protection
Identity protection must be evaluated separately for passive
observers, active attackers, authorized peers, and holders of any
group preshared key.
For the initiator, as shown in Figure 6, confidentiality of
credentials encrypted using a secret encapsulated to the responder
depends on validating the responder's credential and checking that it
represents an acceptable intended peer before releasing the
initiator's credentials. Accepting an arbitrary trusted credential
can disclose identity information to an unintended but credentialed
responder.
An unauthenticated active initiator can establish its own ephemeral
exchange with a responder. Consequently, as shown in Figure 5,
ephemeral encryption alone does not prevent that initiator from
obtaining responder identity information. A group preshared key can
restrict this exposure to parties possessing that key, provided its
contribution protects the credentials before they are disclosed. The
placement of preshared-key mixing therefore matters; RFC 9867
provides protection earlier in IKE establishment than the mechanism
it extends.
Wang & Smyslov Expires 19 May 2027 [Page 22]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
Neither credential encryption nor a group preshared key hides
identities from an authorized peer or a compromised group member.
Group-key compromise expands the population able to probe protected
identities and requires an appropriate revocation and replacement
policy.
Certificate retrieval, revocation checking, message sizes, timing,
addresses, and stable identifiers can reveal information
independently of credential encryption. Privacy-sensitive
deployments SHOULD prefer in-band credential delivery and SHOULD
assess the observable behavior of external retrieval and validation
services. Session-key forward secrecy does not automatically imply
forward secrecy of identity information. Recorded encrypted
credentials may become readable after later compromise of the secrets
used specifically to protect them.
8.7. Invalid Inputs, Failure Handling, and Side Channels
Implementations MUST validate payload lengths, algorithm identifiers,
encodings, certificate structures, and algorithm-specific public-key
and ciphertext requirements before using them. Validation MUST
include bounds on allocation, certificate-chain processing, and
nested structures.
For KEMs providing implicit rejection, implementations MUST preserve
that behavior. They MUST NOT expose whether a correctly sized
ciphertext produced an ordinary shared secret or an implicit-
rejection secret through explicit notifications, logging interfaces
accessible to the attacker, or avoidable timing differences.
Cryptographic comparisons MUST use appropriate constant-time
operations. Private-key operations and subsequent failure processing
SHOULD avoid secret-dependent observable behavior.
Malformed framing may require immediate rejection. Failures
involving credential identity, authorization, or decapsulation
require additional care because distinguishable responses can
disclose identity or private-key information. Implementations SHOULD
minimize such distinctions without reporting successful
authentication or allowing unauthorized access.
Failure handling MUST release provisional state and prevent
application use of keys from an unsuccessful exchange.
Wang & Smyslov Expires 19 May 2027 [Page 23]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
8.8. Resource Exhaustion and Retransmission
Certificate processing, KEM operations, external retrieval, and
fragment reassembly create opportunities for denial of service before
peer authentication completes.
Implementations SHOULD apply bounded concurrency, timeouts, rate
limits, and limits on message size, certificate-chain depth,
retrieval activity, and reassembly storage. Appropriate IKEv2 cookie
mechanisms SHOULD be used where applicable.
Retransmission MUST preserve the original exchange semantics. In
particular, an implementation MUST NOT accidentally repeat a key
update, change an encapsulated secret within the same retransmitted
exchange, or reuse an encryption nonce with different plaintext under
the same key.
URLs received from an unauthenticated peer MUST NOT permit
unrestricted access to local files, internal services, or unbounded
remote resources.
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 payload type in the "IKEv2 Payload Types" registry:
+=======+=======================+==========+
| Value | Next Payload Type | Notation |
+=======+=======================+==========+
| TBA0 | Encrypted Certificate | ECERT |
+-------+-----------------------+----------+
Table 3
2. Define a new authentication method in the "IKEv2 Authentication
Method" registry:
+=======+=============================+
| Value | IKEv2 Authentication Method |
+=======+=============================+
| TBA1 | KEM Authentication |
+-------+-----------------------------+
Table 4
Wang & Smyslov Expires 19 May 2027 [Page 24]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
3. Define three new status type notifications in the "IKEv2 Notify
Message Status Types" registry:
+=======+============================+
| Value | Notify Message Status Type |
+=======+============================+
| TBA2 | USE_AUTHKEM |
+-------+----------------------------+
| TBA3 | AUTHKEM_CT |
+-------+----------------------------+
| TBA4 | AUTHKEM_SSCONF |
+-------+----------------------------+
Table 5
4. Define a new certificate encoding in the "IKEv2 Certificate
Encodings" registry:
+=======+======================+
| Value | Certificate Encoding |
+=======+======================+
| TBA5 | X.509 bundle |
+-------+----------------------+
Table 6
10. References
10.1. Normative References
[IANA-IKEv2]
"Internet Key Exchange Version 2 (IKEv2) Parameters",
<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 19 May 2027 [Page 25]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
[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-
08, 30 October 2026,
<https://datatracker.ietf.org/doc/html/draft-celi-wiggers-
tls-authkem-08>.
[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-
Wang & Smyslov Expires 19 May 2027 [Page 26]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
auth-05, 26 June 2026,
<https://datatracker.ietf.org/doc/html/draft-hu-ipsecme-
pqt-hybrid-auth-05>.
[I-D.ietf-ipsecme-ikev2-downgrade-prevention]
Smyslov, V. and C. Patton, "Downgrade Prevention for the
Internet Key Exchange Protocol Version 2 (IKEv2)", Work in
Progress, Internet-Draft, draft-ietf-ipsecme-ikev2-
downgrade-prevention-08, 1 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
ikev2-downgrade-prevention-08>.
[I-D.ietf-ipsecme-ikev2-mlkem]
Kampanakis, P., "Post-quantum Key Exchange with ML-KEM in
the Internet Key Exchange Protocol Version 2 (IKEv2)",
Work in Progress, Internet-Draft, draft-ietf-ipsecme-
ikev2-mlkem-09, 5 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
ikev2-mlkem-09>.
[I-D.ietf-ipsecme-ikev2-pqc-auth]
Reddy.K, 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-12, 20 August 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
ikev2-pqc-auth-12>.
[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>.
[I-D.uri-cfrg-pquake]
Blumenthal, U., Luo, B., O'Melia, S., Torres, G., and D.
A. Wilson, "PQuAKE - Post-Quantum Authenticated Key
Exchange", Work in Progress, Internet-Draft, draft-uri-
cfrg-pquake-01, 16 October 2026,
<https://datatracker.ietf.org/doc/html/draft-uri-cfrg-
pquake-01>.
Wang & Smyslov Expires 19 May 2027 [Page 27]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
[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-06, 30 October 2026,
<https://datatracker.ietf.org/doc/html/draft-wiggers-tls-
authkem-psk-06>.
[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>.
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282,
DOI 10.17487/RFC5282, August 2008,
<https://www.rfc-editor.org/info/rfc5282>.
[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>.
[RFC9867] Smyslov, V., "Mixing Preshared Keys in the
IKE_INTERMEDIATE and CREATE_CHILD_SA Exchanges of the
Internet Key Exchange Protocol Version 2 (IKEv2) for Post-
Quantum Security", RFC 9867, DOI 10.17487/RFC9867,
November 2025, <https://www.rfc-editor.org/info/rfc9867>.
[RFC9935] Turner, S., Kampanakis, P., Massimo, J., and B. E.
Westerbaan, "Internet X.509 Public Key Infrastructure -
Algorithm Identifiers for the Module-Lattice-Based Key-
Encapsulation Mechanism (ML-KEM)", RFC 9935,
DOI 10.17487/RFC9935, March 2026,
<https://www.rfc-editor.org/info/rfc9935>.
Wang & Smyslov Expires 19 May 2027 [Page 28]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
[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.
Appendix A. Relationship to PQuAKE
A.1. Shared Design
PQuAKE achieves authenticated key establishment with four conceptual
stages:
* Establish provisional confidentiality and exchange protected
credentials.
* Encapsulate fresh secrets to the peers' long-term authentication
public keys.
* Combine the ephemeral and authentication contributions to derive
session keys.
* Confirm possession of the resulting keys.
This construction avoids requiring each endpoint to generate an
online digital signature over the handshake. Certificate signatures
may still be required to validate the long-term public keys.
The mechanism in this document adopts the same general approach
within IKEv2. Verion-04 of this draft explicitly identifies
alignment with PQuAKE [I-D.uri-cfrg-pquake] as a design objective.
Its IKE-specific processing remains authoritative for
interoperability (see Section 6 of the draft).
A.2. Conceptual Correspondence
+==============================+===============================+
| PQuAKE [I-D.uri-cfrg-pquake] | Corresponding IKEv2 Mechanism |
| Component | Specified in This Draft |
+==============================+===============================+
| Ephemeral shared secret | Initial and any additional |
| | key exchanges |
+------------------------------+-------------------------------+
Wang & Smyslov Expires 19 May 2027 [Page 29]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
| Optional identity-hiding | PPK contribution before |
| preshared secret | credential disclosure |
+------------------------------+-------------------------------+
| Protected certificate | ECERT payloads |
| exchange | |
+------------------------------+-------------------------------+
| Encapsulation to long-term | AUTHKEM_CT notifications |
| peer keys | |
+------------------------------+-------------------------------+
| Combination of | Post-encapsulation IKE key |
| authentication secrets | update |
+------------------------------+-------------------------------+
| Directional key confirmation | Final IKE_AUTH AUTH payloads |
+------------------------------+-------------------------------+
| Binding of exchanged | IKEv2 authenticated octets |
| messages | and intermediate-exchange |
| | transcript processing |
+------------------------------+-------------------------------+
Table 7: Conceptual Correspondence
This correspondence identifies functional roles. It does not
necessarily imply identical encodings, derivation functions, or
security proofs.
A.3. Differences Relevant to Security
PQuAKE defines a protocol-specific transcript and derives separate
confirmation and session keys. An IKEv2 integration must instead be
evaluated using the actual IKEv2 key hierarchy, authenticated octets,
extension interactions, and acceptance conditions.
Revision -04 also introduces asymmetric credential protection: the
initiator's ECERT protection depends on a secret encapsulated to the
responder. Its AUTHKEM_SSCONF check precedes final authentication
and MUST NOT be treated as a replacement for AUTH verification. See
Section 6.1.2.2 for detail.
These differences affect what each participant knows at each stage.
In particular, analysis must distinguish knowledge of a provisional
encryption key, possession of a certified private key, agreement on
an identity, and successful authorization.
Acknowledgements
Thom Wiggers shared an idea to provide identity protection of one of
the peers against active attackers.
Wang & Smyslov Expires 19 May 2027 [Page 30]
Internet-Draft KEM-based Authentication for IKEv2 November 2026
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 (editor)
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd)
124460
Russian Federation
Email: svan@elvis.ru
Wang & Smyslov Expires 19 May 2027 [Page 31]