| Internet-Draft | KEM based Authentication for the IKEv2 | March 2025 |
| Wang | Expires 4 September 2025 | [Page] |
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]¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 September 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Cryptographically-relevant quantum computers (CRQC) pose a threat to cryptographically protected data. In particular, the so-called harvest-now-and-decrypt-later (HNDL) attack is considered an imminent threat. To mitigate this threat 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.¶
"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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Key encapsulation mechanism(KEM) is a kind of key exchange, which allows one entity to encapsulate a secret key under a (longterm or ephemeral) public key of another entity. By following the definiton given in [I-D.KR24], a KEM consists of three algorithms:¶
By following the definiton given in [I-D.BHCD], a signature scheme consists of the following three algorithms:¶
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.¶
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:¶
+=============+====================+===================+=============+ | | 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, 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:¶
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.¶
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).¶
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.¶
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.]¶
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.¶
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.¶
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].¶
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]¶
[EDNOTE: More examples may be provided later.]¶
To be done later.¶
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 |
+-------+--------------------------------+------------+
¶
To be added later.¶