| Internet-Draft | Multi-Authentication in IKEv2 | March 2026 |
| Wang & Pan | Expires 3 September 2026 | [Page] |
Motivated to mitigate security threats again quantum computers, this draft specifies a general authentication mechanism in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296], called Multi-Authentication. Namely, two peers can negotiate two or more authentication methods to authenticate each other. The authentication methods selected do not necessarily belong to the same category. This mechanism is achieved by adding a new value (17) (TBD) in the "IKEv2 Authentication Method" registry [IANA-IKEv2], maintained by IANA. To run Multiple Authentication, two peers send the SUPPORTED_AUTH_METHODS Notify, defined in [RFC9593], to negotiate two or more authentication methods for authenticaion in IKEv2.¶
[EDNOTE: Code points for Multi-Authentication may need to be assigned in the "IKEv2 Authentication Method" registry [IANA-IKEv2], 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 3 September 2026.¶
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.¶
Cryptographically-relevant quantum computers (CRQC) pose a threat to data securely protected by current standards. 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], multiple key exchanges in the IKEv2 [RFC9370] were introduced to achieve post-quantum (PQ) security. To enable post-quantum security for the authentication in 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 authentication in IKEv2, as further discribed by the following drafts.¶
"Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC" [I-D.RSF25] specifies how NIST PQ digital algorithms ML-DSA [FIPS204] and SLH-DSA [FIPS205] can be used in 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 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.HMW25] specifies how to run general hybrid PQ/T digital algorithms in IKEv2 via introducing some extensions in the SUPPORTED_AUTH_METHODS Notify.¶
For all of those Internet standard drafts, the correponding public certificates and signatures for the involved siganture algorithms are exchanged via the INTERMEDIATE Exchange, defined in [RFC9242].¶
However, except authentication by composite signatures is specified in [I-D.HMW25] where the corresponding certificates can be a composite certificate or dual certificates, all others are single method authentication. As discussed in [I-D.DPH25] and [I-D.WBS25], hybrid is a more conservative approach to the migration from traditional algrotihms to post-quantum (PQ) algorithms. Moreover, there a number of different authentication methods now, including Shared Key Message Integrity Code (2), Generic Secure Password Authentication Method (12), several specific signature algorithms (3, 9, 10, 11), general Digital Signature (14), and newly proposed KEM based authentication (16, TBD) [I-D.WS25].¶
Motivated by the fact that there is a need of hybrid authentication, this draft specifies a general authentication mechanism in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296], called Multi-Authentication. Namely, two peers can negotiate two or more authentication methods to authenticate each other. The authentication methods selected do not necessarily belong to the same category. For example, two peers may select a traditional signature and a PQ signature (like ML-DSA [FIPS204]), or MAC based authentication and a PQ signature.¶
This mechanism is achieved by adding a new value (17, TBD) in the "IKEv2 Authentication Method" registry [IANA-IKEv2], maintained by IANA. To run Multi-Authentication, two peers send the SUPPORTED_AUTH_METHODS Notify, defined in [RFC9593], to negotiate two or more authentication methods for authenticaion in IKEv2. Finally, using the authentication methods selected, not necessarily the same algoithm in two directions, the peers SHALL authenticate the IKE data to each other, according to the specfication in [RFC7296].¶
Actually, it is noticed that [RFC4739] specifies a mechanism called Multiple Authentication Exchange to run two or more authenticaiton in IKEv2. This mechanism is realized via two types of notification. Firstly, two peers run MULTIPLE_AUTH_SUPPORTED notification in the IKE_SA_INIT response (responder) and the first IKE_AUTH request (initiator) to indicate that they are willing to run a second authentication. After that, they exchange ANOTHER_AUTH_FOLLOWS notification in any IKE_AUTH message to complete the second authentication. However, [RFC4739] is not supported for post-quantum security at all.¶
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.¶
Here are the main challenging reasons for why a general PQ secure solution is hard for the authentication in the IKEv2:¶
The basic idea proposed in this document is to mimic the addtional key exchange (ADDKE) proposed in [RFC9370]. Namely, when one peer A (the sender) sends SUPPORTED_AUTH_METHODS Notify payload to announce what the authentication methods it supports, this payload also tansfers the info which methods it expects the other peer B SHALL select for authentication. This is done by assigning different authentication methods into a few authentication sets, and the other peer B MUST select one of the methods in each authentication set. More importantly, the feedback from the othe peer B (the replier) is intentionally constructed as the followings to transfer the replier's authentication policy to the sender A.¶
For example, if A sends ten methods (a1, a2, ..., a10) via 3 authentication sets, say (a2, a1, a3), (a4, a8, a9), and (a5, a6, a10, a7), according to A's preference. Then, if B sends back (a1, a4, a7), this implicitly means that both A and B SHALL use a1, a4, and a7 to authenticate itself to the other peer. Or, if B sends back two authentication sets, (a1, a4, a7) and (a2, a7), it means that B SHALL use a1, a4, and a7 to authenticate itself to A, and A SHOULD use a2 and a7 to authenticate itself to B. Finally, in another case, if B sends back 4 sets, (a1, a4, a7), () (empty set), (a1, a3, a8), and (a11, a12), it means that B SHALL use a1, a4, and a7 to authenticate itself to A, and that B is asking A selects 2 methods from set 3 and 4 so that A SHALL authenticate itself to B, though by now B is not sure if A does support either a11 or a12.¶
If one execution of the above procedures cannot achieve the authentication policy for either of the two peers, they MAY abort the procedure or restart by any of the two peers as the sender to initate this authentication method negotiation.¶
For flexibility, authentication methods in sets are not supposed to exclusively belonging to only one set, though this may be true in most cases. The reason is that selecting the same method from two different sets does not make much sense for enhacing security, unless this method is NULL Authentication (13) for adding flexibility.¶
By following [RFC9593], two communicating peers send each other the Notify Message Type SUPPORTED_AUTH_METHODS to negotiate which authentication method(s) will be used to authenticate one of them to the other. Bascially, each of the authentication methods proposed 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 Multiple Authentication, this document adds the value 17 (TBD) for "Multi-Authentication" in the "IKEv2 Authentication Method" registry (Section 6).¶
After the initiator starts the IKE_SA_INIT exchange as usual, the responder sents the notify SUPPORTED_AUTH_METHODS with value of 17 (TBD) to indicate that the responder wants to run Multiple Authentication with respect to several Authentication sets of authentication methods, which the responder supports. Each of these Authentication set will be listed in the SUPPORTED_AUTH_METHODS Notify Payload (Section 4.2), ordered by the responder's preference.¶
After the initiator receives SUPPORTED_AUTH_METHODS via several Authentication sets from the reponder, it will try to prepare the best anwser, i.e, one set, or two sets, or three sets, according to this specification given the above.¶
Table 1 below shows how two peers use the SUPPORTED_AUTH_METHODS notification to run Multiple Authentication for the above example, where the responder's intial authentication sets are (a2, a1, a3), (a4, a8, a9), and (a5, a6, a10, a7), while the initiator sends back two authentication sets (a1, a4, a7) and (a2, a7) as its feedback. In the protocol below, 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 Multiple 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(SUPPORTED_AUTH_METHODS(17((a2a1a3),(a4a8a9),(a5a6a10a7))))..
... (IKE_INTERMEDIATE for ADDKE) ...
HDR(IKE_AUTH), SK{IDi, [CERT,] [CERTRQ,]
[IDr,] AUTH, SAi2, TSi, TSr,
N(SUPPORTED_AUTH_METHODS(17(TBD)(a1a4a7),(a2a7)))} --->
... (IKE_INTERMEDIATE for [CERT,]) ...
<--- HDR(IKE_AUTH), SK{IDr, [CERT,] AUTH, SAr2, TSi, TSr}
... (IKE_INTERMEDIATE for [CERT,]) ...
Fig. 1 An Example of Multi-Authentication between Two Peers
¶
If the resulting SUPPORTED_AUTH_METHODS notification with list of authentication 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 each other the SUPPORTED_AUTH_METHODS notification with list of authentication 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 MUST be set to 0 (meaning there is no SPI field), and the Notify Message Type MUST be 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 Multi-Authentication 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 (M) of Authentication Groups of authentication methods are listed, as desribed below.¶
Once two authentication sets have been negotiated, the corresponding authentication methods will be use to the IKE data for completing authentication, according to [RFC7296]. In the above example for Fig. 2, a1, a4, and a7 will be used to run multiple authentication from B to A, and a2 and a7 will be used to multi-authentication from A to B. Once all those authentication methods are correctly verified by one side, then this directional authentication is successful.¶
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) | Multi-Auth | #Auth Groups | #Auth Meth 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Auth Meth 1.1 | Cert Link 1.1 | AlgID Len 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AlgorithmIdentifier 1.1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Meth 1.2 | Cert Link 1.2 | AlgID Len 1.2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ AlgorithmIdentifier 1.2 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Meth 1.N | Cert Link 1.N | AlgID Len 1.N | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ AlgorithmIdentifier 1.N ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #Auth Meth 2 | Reserved | Auth Meth 2.1 | Cert Link 2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AlgID Len 2.1 | |
+-+-+-+-+-+-+-+-+ |
~ AlgorithmIdentifier 2.1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #Auth Meth M | Reserved | Auth Meth M.1 | Cert Link M.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AlgID Len M.1 | |
+-+-+-+-+-+-+-+-+ |
~ AlgorithmIdentifier M.1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.3 Payload Format for Multi-Authentication Announcement
¶
[EDNOTE: More examples may be provided later.]¶
Multi-authentication is a combination of multiple component authentication methods. So, its seucrity relies on the security of the security of each component. By requiring multi-authentication is successful if and only if each component authentication is successful, multi-authentication is secure at least one of the component authentication method, with regarding to either traditional or traditional and quantum attacks.¶
At the time of writing, there are no other security issues which may need to be considered.¶
This document adds 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 |
+==========+===================================+============+
| 17 (TBD) | Composite ML-DSA Authentication | This draft |
+----------+-----------------------------------+------------+
¶
To be added later.¶