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