Composite ML-DSA Authentication in the IKEv2

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) , multiple key exchanges in the IKEv2 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)" 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 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)" specifies how NIST PQ digital algorithms ML-DSA and SLH-DSA can be used in the IKEv2 by indicating the supported signature algorithms via exchanging the Notify SIGNATURE_HASH_ALGORITHMS, defined in . Similarly, "IKEv2 Support of ML-DSA", 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 . On the other hand, "Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2)" 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 . Motivated by the fact that no concrete composite signature authentication has been proposed, this draft specifies how the authentication in the IKEv2 is completed by using composite ML-DSA singature algorithms, defined . Namely, those algorithms include all the following compsite signatures of ML-DSA , the newly post-quantum digital singature standard released by NIST, and one of the following traditional singature algorithms, SA-PKCS#1v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448. In function, composite ML-DSA authenticatio is achieved by asking to add a new value (TBD) in the "IKEv2 Authentication Method" registry , mantained by IANA. After that, two peers MUST send the SUPPORTED_AUTH_METHODS Notify, defined in , to negotiate the specific composite ML-DSA algoithms. Finally, using the the specific composite ML-DSA algoithms selected, not necessarily the same algoithm in bidirections, the peers SHALL sign and verify the IKE data to be authenticated, according the specfication in . The whole procedure is just the same as using one of the current signature algorithm for the IKEv2 authenticaitno. Therefore, a compsote algorithm achieves "protocol backwards-compatibility" by simply replacing one existing algorithm without requiring any modification at the protocol level, ranther than at the cryptography level, as further explained in Section 2, Composite Design Philosophy, in .

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 when, and only when, they appear in all capitals, as shown here.

Composite ML-DSA Signatures By following the definiton given in , a signature scheme consists of the following three algorithms:

KeyGen(k) -> (pk, sk): A probabilistic key generation algorithm, which generates a public verifying key pk and a private signing key sk, when a security parameter k is given..
Sign(sk, m) -> s: A deterministic or probabilistic signature generation algorithm, which takes as input a private signing key sk and a message m, and outputs a signature s.
Verify(pk, s, m) -> b: A deterministic verification algorithm, which takes as input a public verifying key pk, 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).

Composite signature follows the same syntax as the above for normal signature algorithm, with the signing key sk and the verifying key pk consisted of two compsonent keys. The detailed structures of composite signature and its keys follow the specification given in . For simplicy, all these structures for composit signature can be treated as the concatenation of those of two component signature algorithm. ML-DSA , Module-Lattice-Based Digital Signature Standard, was released in August of 2024 by NIST. The algorithm has three sets of parameters for three NIST security levels. Namely, ML-DSA-44 for Level 2, ML-DSA-65 for Level 3, and ML-DSA-87 for Level 5. Moreover, ML-DSA is specified in pure and pre-hashed signing modes, referred to as "ML-DSA" and "HashML-DSA" respectively. Following the specifications in , this draft also uses "Composite-ML-DSA" and "HashComposite-ML-DSA" to refer the composite signature obtained by using "ML-DSA" and "HashML-DSA" respectivley. In total, specifies 27 composite ML-DSA algorithms: Namely, 13 for "Composite-ML-DSA" with OIDs from <CompSig>.21 to <CompSig>.43, listed in Section 7.1 in , and 14 for "HashComposite-ML-DSA" with OIDs from <CompSig>.40 to <CompSig>.53, listed in Section 7.2 in . Here, "<CompSig>" is equal to "2.16.840.1.114027.80.8.1". For the purpose of this document, the following uderstanding shall be enough. Namely, to generate a ML-DSA composite signature, the given message M MUST be first processed as following, according to ML-DSA is used as pure or pre-hashed mode.

For the pure mode "ML-DSA": M'=Domain||len(ctx)||ctx||M.
For the pre-hashed mode "HashML-DSA": M'=Domain||len(ctx)||ctx||HashOID||PH(M).

Here, according to the specification given in ,

Domain: It is the domain separator, which is defiend as the OID of the this specific composite siganture algorithm, eg., <CompSig>.28 for pure mode MLDSA65-ECDSA-P384, or <CompSig>.51 for pre-hashed mode HashMLDSA87-ECDSA-P384-SHA512. >.
ctx: The context string, which defaults to the empty string.
len(ctx): The length of ctx.
PH(M): The hash value of applying pre-hash PH to message M, where PH is the assocated hash algorithm with this specific composite siganture algorithm, e.g., SHA512 for the compsite siganture HashMLDSA87-ECDSA-P384-SHA512.
HashOID: The OID of the pre-hash PH assocated with this specific composite siganture algorithm, e.g., the OID of SHA512 for the compsite siganture algorithm HashMLDSA87-ECDSA-P384-SHA512.

After that, the processed message M' is sent to ML-DSA signing algorithm to sign, i.e. s1=ML-DSA(mldsaSK, M', ctx=Domain) and also to the traditional digital signature algorithm to sign, e.g, s2=Trad.Sign( tradSK, M'). Then, those two component signatures SHALL be concatenated together as the composite signature s, i.e., s=s1||s2. Note that the domain separator Domain used here is to achieve the weak non-separability (WNS), defined in . Finally, to verify a composite signature s=s1||s2, s SHALL be parsed as s1 and s2. Then, message M SHALL be processed just as above to output M', according to if ML-DSA used here is pure mode or pre-hashed mode. Finally, (s, M) is a valid compsite signature and message pair if and only if both (s1, M') is valid singature for ML-DSA and (s2, M') is valid for the traditional signature algorithm used here.

By following , 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" , maintained by IANA. To run Composite ML-DSA Authentication, this document is supposed to apply the value of 15 (TBD) for "Composite ML-DSA Authentication" in the "IKEv2 Authentication Method" registry ().

After the initiator starts the IKE_SA_INIT exchange as usual, the responder sents the notify SUPPORTED_AUTH_METHODS with value of 15 (TBD) to indicate that the responder wants to run Composite ML-DSA Authentication with respect to some specific Composite ML-DSA algorithms, which the responder supports. These compsite algoithms will be listed in the SUPPORTED_AUTH_METHODS Notify Payload (), 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 Composite ML-DSA algorithm, with highest preference of the responder, from the list of all Composite ML-DSA algorithms 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 Composite ML-DSA authentication. In the protocol, the IKE_INTERMEDIATE exchange may be used to faciliate the hybrid key exchange in the IKEv2 as specified in , and to transfer PQ certifates between the responder and the intitator for completing Composite ML-DSA authentication. KEi, Ni, N(INTERMEDIATE_EXCHANGE_SUPPORTED), .. <--- HDR(IKE_SA_INIT), SAr1(.. ADDKE*..), [CERTRQ,] KEr, Nr, N(INTERMEDIATE_EXCHANGE_SUPPORTED), .. N(ISUPPORTED_AUTH_METHODS(..15(TBD)..)),.. ... (IKE_INTERMEDIATE for ADDKE) ... HDR(IKE_AUTH), SK{IDi, [CERT,] [CERTRQ,] [IDr,] AUTH, SAi2, TSi, TSr, N(ISUPPORTED_AUTH_METHODS(..15(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 Composite ML-DSA Authentication between Two Peers ]]> If the resulting SUPPORTED_AUTH_METHODS notification with list of autehnticiton methods is too long such that IP fragmentation 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 . [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 . 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. Payload Format for Composite ML-DSA 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 Composite ML-DSA 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 15 (TBD), standing for "Composite ML-DSA authentication" for the IKEv2.
Cert Link: Links this announcement with a particular CA, which issued the Composite ML-DSA certificate for the Composite ML-DSA algorithm identified in AlgorithmIdentifiers below; see Section 3.2.2 of for detail.
Alg Len 1: Length of the Composite ML-DSA algorithm idenfied in AlgorithmIdentifiers below, in octets.
AlgorithmIdentifier: One variable-length ASN.1 objects that are encoded using Distinguished Encoding Rules (DER) and identify one specific Composite ML-DSA algorithm.

By the above definition, AlgorithmIdentifier is just <CompSig>.i , where i specifies which specific Composite ML-DSA algorithm was announced here. For example, if AlgorithmIdentifier is <CompSig>.28, this means that pure mode MLDSA65-ECDSA-P384 is selected. Namely, pure mode MLDSA65ML and ECDSA-P384 will be used to compositely sign the IKE data to be authenticated, according to . 5) | Auth Method | Cert Link 1 | Alg Len 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ AlgorithmIdentifier 1 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert Link 2 | Alg Len 2 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ AlgorithmIdentifier 2 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert Link N | Alg Len N | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ AlgorithmIdentifier N ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig.3 Payload Format for Composite ML-DSA Authentication Announcement ]]> In this document, fixed composite ML-DSA algorithms defined in are registered as a set of authentication methods in the "IKEv2 Authentication Method" registry , mantained by IANA. This approach is parallel to what the general "Digital Signature" (14) is regisered in the same registry. It is also possible to choose register some specific composite ML-DSA algorithms ((popular ones, for example) at the same level as "Digital Signature" (14). However, if too many such algorithms registered there, this will make the limited codes in the "IKEv2 Authentication Method" registry (only 256 possibilities) even scarce. [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" , maintained by IANA: .

To be added later.