IP Security Maintenance and Extensions G. Wang, Ed.
Internet-Draft Huawei Int. Pte Ltd
Intended status: Standards Track 3 March 2025
Expires: 4 September 2025
KEM based Authentication for the IKEv2 with Post-quantum Security
draft-wang-ipsecme-kem-auth-ikev2-00
Abstract
This draft specifies a new authentication mechanism, called KEM based
authentication, for the Internet Key Exchange Protocol Version 2
(IKEv2) [RFC7296]. This is motivated by the fact that ML-KEM is much
more efficient that ML-DSA, which are the post-quantum algoirhtms for
mitigating the pontential security threats again quantum computers.
The KEM based authenticationth for the IKV2 is achieved via
introduing a new value of the IKEv2 Authentication Method registry
mantained by IANA. For using the new authentication method, two
peers MUST send the SUPPORTED_AUTH_METHODS Notify, defined by
[RFC9593]，to negotiate the supported KEM algorithms. After that, the
correponding KEM certificates and cipthertext are exchanged via the
INTERMEDIATE Exchange. Finally，the IKE messages are authenticated
via the shared secret encapsulated between the two peers. This
documents also specifies the instantiation with ML-KEM for this new
general authenticaiton method for the IKEv2.
[EDNOTE: Code points for KEM-based authentication may need to be
assigned in the IKEv2 Authenticaion Method registry, maintained by
IANA]
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 4 September 2025.
Wang Expires 4 September 2025 [Page 1]
Internet-Draft KEM based Authentication for the IKEv2 March 2025
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Key Encapsulation Mechanism and Digital Signature . . . . . . 4
4. Comparison of ML-KEM and ML-DSA . . . . . . . . . . . . . . . 5
5. Protocl Details for KEM based Authentication . . . . . . . . 7
5.1. Exchanges for KEM based Authentication . . . . . . . . . 7
5.2. Payload Format for KEM based Authentication . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . 11
10. Informative References . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. 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 again the Internet Key Exchange
Protocol Version 2 (IKEv2) [RFC7296], multiple key exchanges in the
IKEv2 [RFC9370] was introduced to achieve post-quantum (PQ) security
for the exchange. To offering post-quantum security for the
authentication in the IKEv2, "Announcing Supported Authentication
Methods in the Internet Key Exchange Protocol Version 2 (IKEv2)"
[RFC9593] specifies a new Notify type, called the
SUPPORTED_AUTH_METHODS, which allows two peers to indicate the list
of supported authentication methods while establishing IKEv2 SA. One
purpose of [RFC9593] is to support post-quantum signature algorithms
for authenticaion in the IKEv2, as further discribed by the following
drafts.
Wang Expires 4 September 2025 [Page 2]
Internet-Draft KEM based Authentication for the IKEv2 March 2025
"Signature Authentication in the Internet Key Exchange Version 2
(IKEv2)" [I-D.RSF25] specifies how NIST PQ digital algorithms ML-DSA
[FIPS204] and SLH-DSA [FIPS205] can be used in the IKEv2 by
indicating the supported signature algorithms via exchanging the
Notify SIGNATURE_HASH_ALGORITHMS, defined in [RFC7427]. Similarly,
"IKEv2 Support of ML-DSA", [I-D.Flu25] specifies how ML-DSA can be
run in the IKEv2, by indicating the supported signature algorithms
via exchanging the SUPPORTED_AUTH_METHODS Notify, defined in
[RFC9593]. On the other hand, "Post-Quantum Traditional (PQ/T)
Hybrid PKI Authentication in the Internet Key Exchange Version 2
(IKEv2)" [I-D.HM25] specifies how to run general hybrid PQ/T digital
algorithms in the IKEv2 via introducing some extensions in the
SUPPORTED_AUTH_METHODS Notify.
For all of those Internet standard drafts, it is the same that the
correponding KEM certificates and singatures for the involved
siganture algorithms are exchanged via the INTERMEDIATE Exchange,
defined in [RFC9242].
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.WCS] 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 a KEM, and confirms that the communicating entity
is indeed B if the entity can successfully returns the correct k to
A. The seminal 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.WCS], KEM
based authentication also benefits to reduce implementation code
size, as the code for PQ singature may not need, and KEM based
authentication can re-use the KEM code for ephemeral key
establishment.
This draft specifies how to realise KEM based authentication for the
Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296]. This is
achieved by defining a new authenication method, called KEM based
Authentication. Namely, this means to add a new value of the "IKEv2
Authenticaion Method" registry [IANA-IKEv2], mantained by IANA. To
run this new authenticaiton method, two peers MUST send the
SUPPORTED_AUTH_METHODS Notify, defined by [RFC9593]，in the
IKE_SA_INIT Exchange, to negotiate the supported KEM algorithms.
After that, the correponding KEM certificates and cipthertext are
exchanged via the INTERMEDIATE Exchange [RFC9593]. This documents
also specified the instantiation with ML-KEM for this new general
authenticaiton method for the IKEv2.
Wang Expires 4 September 2025 [Page 3]
Internet-Draft KEM based Authentication for the IKEv2 March 2025
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
Key encapsulation mechanism(KEM) is a kind of key exchange, which
allows one entity to encapsulate a secret key under a (longterm or
ephemeral) public key of another entity. By following the definiton
given in [I-D.KR24], a KEM consists of three algorithms:
* KeyGen(k) -> (pk, sk): A probabilistic key generation algorithm,
which generates a public encapsulation key pk and a secret
decapsulation key sk, when a security parameter k is given.
* Encaps(pk) -> (ct, ss): A probabilistic encapsulation algorithm,
which takes as input a public encapsulation key pk and outputs a
ciphertext ct and shared secret ss.
* Decaps(sk, ct) -> ss: A decapsulation algorithm, which takes as
input a secret decapsulation key sk and ciphertext ct and outputs
a shared secret ss.
By following the definiton given in [I-D.BHCD], 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).
Wang Expires 4 September 2025 [Page 4]
Internet-Draft KEM based Authentication for the IKEv2 March 2025
In August of 2024, NIST released ML-KEM [FIPS203] and ML-DSA
[FIPS204], which are both module-lattice based post-quantum
algorithms. Both algorithms have three parameters for 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.
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, encapsulaion, signing, decasulation, 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 conluded:
* 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/ | singature/ |
| | decapaaulation key | encapsulation key | ciphertext |
+=============+====================+===================+=============+
| 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,
Wang Expires 4 September 2025 [Page 5]
Internet-Draft KEM based Authentication for the IKEv2 March 2025
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%.
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 PQC 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 verion Kyber, also ML-DSA
and its informal verion Dilithium, the followin Table 2 is obtained.
+=============+==================+===============+===============+
| | KeyGen speed/ | Encap speed/ | Decap speed/ |
| | SKeyGen speed | Sign speed | Verify speed |
+=============+==================+===============+===============+
| 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 copmtuational comparison shown in Table 1
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 speed of ML-KEM.
* The signature verifying time of ML-DSA is over 3 times of the
decapsulation speed of ML-KEM.
Wang Expires 4 September 2025 [Page 6]
Internet-Draft KEM based Authentication for the IKEv2 March 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 computaional time of ML-DSA is about 5 times of
that of ML-KEM.
5. Protocl Details for KEM based Authentication
By following [RFC9593], two communicating peers send ech other the
Notify Message Type SUPPORTED_AUTH_METHODS to negotiate which
authentication method will be used to authenticate them to each
other. Bascially, the authentication method can be any one
registered in the "IKEv2 Authentication Method" registry under
"Internet Key Exchange Version 2 (IKEv2) Parameters" [IANA-IKEv2],
maintained by IANA. To run KEM based Authentication, the draft is
supposed to apply the value of 16 (TBD) for "KEM based
Authentication" in the "IKEv2 Authentication Method" registry
(Section 7).
5.1. Exchanges for KEM based Authentication
After the initiator starts the IKE_SA_INIT exchange as usual, the
responder sents the notify SUPPORTED_AUTH_METHODS with value of 16
(TBD) to indicate that the responder wants to run KEM based
Authentication with respect to some specific KEM algorithms, which
the responder supports. These KEMs will be listed in the
SUPPORTED_AUTH_METHODS Notify Payload (Section 5.2), ordered by the
responder's preference, among other possible authentication methods.
After the initiator receives SUPPORTED_AUTH_METHODS from the
resonder, it will select the KEM, with highest preference of the
responder, from the list of KEMs sent by the responder which the
initator supports as well, to authenticate itself to the initiator.
Table 1 below gives an example to show how two peers use the
SUPPORTED_AUTH_METHODS notification to run KEM based authentication.
In the protocol, the IKE_INTERMEDIATE exchange may be used to
faciliate the hybrid key exchange in the IKEv2 as specified in
[RFC9370], and to transfer PQ certifates between the responder and
the intitator for completing KEM based authentication.
Wang Expires 4 September 2025 [Page 7]
Internet-Draft KEM based Authentication for the IKEv2 March 2025
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. ADDKE*..), --->
KEi, Ni, N(INTERMEDIATE_EXCHANGE_SUPPORTED), ..
<--- HDR(IKE_SA_INIT), SAr1(.. ADDKE*..), [CERTRQ,]
KEr, Nr, N(INTERMEDIATE_EXCHANGE_SUPPORTED), ..
N(ISUPPORTED_AUTH_METHODS(..16(TBD)..)),..
... (IKE_INTERMEDIATE for ADDKE) ...
HDR(IKE_AUTH), SK{IDi, [CERT,] [CERTRQ,]
[IDr,] AUTH, SAi2, TSi, TSr,
N(ISUPPORTED_AUTH_METHODS(..16(TBD)..))} --->
... (IKE_INTERMEDIATE for [CERT,]) ...
<--- HDR(IKE_AUTH), SK{IDr, [CERT,] AUTH, SAr2, TSi, TSr}
... (IKE_INTERMEDIATE for [CERT,]) ...
Fig. 1 An Example of Running KEM based Authentication between Two Peers
If the resulting SUPPORTED_AUTH_METHODS notification with list of
autehnticiton methods is too long such that IP fragmentation
[RFC7383] of the IKE_SA_INIT response may happen, the responder MAY
choose to send empty SUPPORTED_AUTH_METHODS notification in the
IKE_SA_INIT exchange response. Then, the responder and the intiatior
can send ech other the SUPPORTED_AUTH_METHODS notification with list
of authentictatin methods they support by using the IKE_INTERMEDIATE
exchange, as desribed in Section 3.1 of [RFC9593].
[EDNOTE: More examples may be provided later.]
5.2. Payload Format for KEM based Authentication
For easy reference, the SUPPORTED_AUTH_METHODS Notify payload format
is shown in the following, as specified in Section 3.2 of [RFC9593].
Correspondigly, here, Protocol ID field MUST be set to 0, the SPI
Size MUS be set to 0 (meaning there is no SPI field), and the Notify
Message Type MUST set to 16443.
Wang Expires 4 September 2025 [Page 8]
Internet-Draft KEM based Authentication for the IKEv2 March 2025
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ List of Supported Auth Methods Announcements ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.2 SUPPORTED_AUTH_METHODS Notify Payload Format
Payload Format for KEM based Authentication Announcement is defined
in Fig. 3, which is treated as part of the Supported Auth Methods
Announcements shown in Fig. 2. Namely, for this part, a number (N)
of KEM based authentication methods are listed, as desribed below.
* Length: Length of the whole blob of one announcement in octets;
must be greater than 5.
* Auth Method: Announced authentication method, which is supposed to
16 (TBD), standing for "KEM based authentication" for the IKEv2.
* Cert Link: Links this announcement with a particular CA, which
issued the KEM certificate for the KEM algorithm identified in
AlgorithmIdentifiers below; see Section 3.2.2 of [RFC9593] for
detail.
* Alg Len 1: Length of the KEM algorithm idenfied in
AlgorithmIdentifiers below, in octets.
* Alg Len 2: Length of the keyed MAC algorithm idenfied in
AlgorithmIdentifiers below, in octets..
* AlgorithmIdentifiers: The concatenation of two variable-length
ASN.1 objects that are encoded using Distinguished Encoding Rules
(DER) [X.690] and identify one specific KEM aglorithm and one
keyed MAC algorithm. Those two ASN.1 objects are combined here
temporary for this instance of KEM-based authenticaion.
For example, if the concatenation of ML-KEM-768 and SHAKE128 (denoted
as ML-KEM-768+SHAKE128 for simplicity), this means that ML-KEM-768
will be used to encapsulate and decapsulate the shared secret ss in
KEM-based authenticaion, while SHAKE128 with key ss will be used to
calculate the IKE authentication code for the IKE data to be
authenticated, according to [RFC7296].
Wang Expires 4 September 2025 [Page 9]
Internet-Draft KEM based Authentication for the IKEv2 March 2025
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 (>5) | Auth Method | Cert Link 1 | Alg 1 Len 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alg 1 Len 2 | |
+-+-+-+-+-+-+-+-+ +
~ AlgorithmIdentifiers 1 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Link 2 | Alg 2 Len 1 | Alg 2 Len 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ AlgorithmIdentifiers 2 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Link N | Alg N Len 1 | Alg N Len 2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ AlgorithmIdentifiers N ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.3 Payload Format for KEM based Authentication Announcement
[EDNOTE: Moreover, the ss obtained from KEM based Authentication can
be twisted with the some key derived from the IKEv2 KE part, as does
in [I-D.WCS]. Comments and suggestions are welcome]
Alternatively, fixed algorithm combination for KEM based
authentication, say ML-KEM-768_SHA128, MAY be defined by adding a new
value in the "IKEv2 Authenticaion Method" registry [IANA-IKEv2].
Similar to the above definition for AlgorithmIdentifiers, ML-KEM-
768_SHA128 means that ML-KEM-768 will be used to encapsulate and
decapsulate the shared secret ss in KEM-based authenticaion, while
SHA128 with key ss will be used to calculate the IKE authentication
code for the IKE data to be authenticated, according to [RFC7296].
Compared to AlgorithmIdentifiers, such a fixed algorithm combination
can easily be recognized and used, but it sits on the same level as
KEM based authentication, the general scheme specified the above.
Anyway, this happens for general "Digital Signature" (14) and a
specific digital scheme, e.g., "ECDSA with SHA-256 on the P-256
curve" (16) [IANA-IKEv2]. Noce this happens, such KEM based
Authentication Announcements with different Auth Method MUST be
merged to the Authentication Announcements described in Fig. 3.
[EDNOTE: Comments and suggestions are welcome for fixed algorithm
combination]
Wang Expires 4 September 2025 [Page 10]
Internet-Draft KEM based Authentication for the IKEv2 March 2025
[EDNOTE: More examples may be provided later.]
6. Security Considerations
To be done later.
7. IANA Considerations
This document is supposed to define a new type in the "IKEv2
Authentication Method" registry under "Internet Key Exchange Version
2 (IKEv2) Parameters" [IANA-IKEv2], maintained by IANA: .
+==========+=============================+============+
| Value | IKEv2 Authentication Method | Reference |
+==========+=============================+============+
| 16 (TBD) | KEM based Authentication | This draft |
+-------+--------------------------------+------------+
8. Acknowledgments
To be added later.
9. Normative References
[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>.
[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>.
[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in
the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
DOI 10.17487/RFC7427, January 2015,
<https://www.rfc-editor.org/info/rfc7427>.
[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 Expires 4 September 2025 [Page 11]
Internet-Draft KEM based Authentication for the IKEv2 March 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>.
[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>.
[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>.
[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.
[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>.
10. Informative References
Wang Expires 4 September 2025 [Page 12]
Internet-Draft KEM based Authentication for the IKEv2 March 2025
[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>.
[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.
[I-D.RSF25]
Reddy, T., Smyslov, V., and S. Fluhrer, "Signature
Authentication in the Internet Key Exchange Version 2
(IKEv2) using PQC", Work in Progress, Internet-Draft, v04,
February 2025, <https://datatracker.ietf.org/doc/draft-
reddy-ipsecme-ikev2-pqc-auth/>.
[I-D.Flu25]
Fluhrer, S., "IKEv2 Support of ML-DSA", Work in Progress,
Internet-Draft, v00, January 2025,
<https://datatracker.ietf.org/doc/draft-sfluhrer-ipsecme-
ikev2-mldsa/>.
[I-D.HM25] Morioka, Y., "Post-Quantum Traditional (PQ/T) Hybrid PKI
Authentication in the Internet Key Exchange Version 2
(IKEv2)", Work in Progress, Internet-Draft, v01, November
2024, <https://datatracker.ietf.org/doc/draft-hu-ipsecme-
pqt-hybrid-auth/>.
[I-D.WCS] Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N.
Sullivan, "KEM-based Authentication for TLS 1.3", Work in
Progress, Individual Draft, v04, October 2024,
<https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-
authkem/>.
[I-D.BHCD] Bindel, B., Hale, B., Connolly, D., and F. Driscoll,
"Hybrid signature spectrums", Work in Progress, Internet
Draft, v06, January 2025,
<https://datatracker.ietf.org/doc/draft-ietf-pquip-hybrid-
signature-spectrums/>.
Wang Expires 4 September 2025 [Page 13]
Internet-Draft KEM based Authentication for the IKEv2 March 2025
[I-D.KR24] Kampanakis, K. and G. Ravago, "Post-quantum Hybrid Key
Exchange with ML-KEM in the Internet Key Exchange Protocol
Version 2 (IKEv2)", Work in Progress, Internet-Draft,,
November 2024, <https://datatracker.ietf.org/doc/draft-
kampanakis-ml-kem-ikev2/>.
Author's Address
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
Wang Expires 4 September 2025 [Page 14]