]>
Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC
Nokia
Bangalore
Karnataka
India
kondtir@gmail.com
ELVISPLUS
Russian Federation
svan@elvis.ru
Cisco Systems
sfluhrer@cisco.com
Security
ipsecme
PQC
IKEv2
Digital Signature
MLDSA
SLHDSA
Signaturebased authentication methods are utilized in IKEv2 . The current version of the Internet Key Exchange Version 2 (IKEv2) protocol supports traditional digital signatures.
This document outlines how postquantum digital signatures, specifically ModuleLatticeBased Digital Signatures (MLDSA) and Stateless HashBased Digital Signatures (SLHDSA), can be employed as authentication methods within the IKEv2 protocol. It introduces MLDSA and SLHDSA capability to IKEv2 without necessitating any alterations to existing IKE operations.
About This Document
Status information for this document may be found at .
Discussion of this document takes place on the
ipsecme Working Group mailing list (),
which is archived at .
Subscribe at .
Introduction
The Internet Key Exchange, or IKEv2 , is a key agreement and security negotiation protocol; it is used for key establishment in IPsec. In the initial set of exchanges, both parties independently select and use their preferred authentication method, which may even differ between the initiator and the responder. In IKEv2, it occurs in the exchange called IKE_AUTH. One option for the authentication method is digital signatures using public key cryptography. Currently, traditional digital signatures are defined for use within IKE_AUTH: RSA signatures, Digital Signature Algorithm (DSA) Digital Signature Standard (DSS) and ECDSA.
The presence of a Cryptographically Relevant Quantum Computer (CRQC) would render stateoftheart traditional publickey algorithms obsolete and insecure. This is because the assumptions about the intractability of the mathematical problems these algorithms rely on, which offer confident levels of security today, no longer apply in the presence of a CRQC. Consequently, there is a requirement to update protocols and infrastructure to use postquantum algorithms. Postquantum algorithms are publickey algorithms designed to be secure against CRQCs as well as classical computers. The traditional cryptographic primitives that need to be replaced by PQC algorithms are discussed in .
ModuleLatticeBased Digital Signatures (MLDSA) and Stateless HashBased Digital Signatures (SLHDSA) are quantumresistant digital signature schemes standardized by the US National Institute of Standards and Technology (NIST) PQC project. This document specifies the use of the MLDSA and SLHDSA algorithms in IKEv2.
Conventions and Definitions
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.
This document uses terms defined in . For the purposes of this document, it is helpful to be able to divide cryptographic algorithms
into two classes:
"Asymmetric Traditional Cryptographic Algorithm": An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms or elliptic curve discrete logarithms, elliptic curve discrete logarithms, or related mathematical problems.
"PostQuantum Algorithm": An asymmetric cryptographic algorithm that is believed to be secure against attacks using quantum computers as well as classical computers. Postquantum algorithms can also be called quantumresistant or quantumsafe algorithms. Examples of quantumresistant digital signature schemes include MLDSA and SLHDSA.
Specifying MLDSA within IKEv2
MLDSA is a digital signature algorithm (part of the CRYSTALS suite) based on the hardness lattice problems over module lattices (i.e., the Module Learning with Errors problem (MLWE)). The design of the algorithm is based on the "FiatShamir with Aborts" framework introduced by Lyubashevsky, that leverages rejection sampling to render lattice based FS schemes compact and secure. MLDSA uses uniform distribution over small integers for computing coefficients in error vectors, which makes the scheme easier to implement.
MLDSA is instantiated with 3 parameter sets for the security categories 2, 3 and 5. Security properties of MLDSA are discussed in Section 9 of . This document specifies the use of the MLDSA algorithm in IKEv2 at three security levels: MLDSA44, MLDSA65, and MLDSA87.
MLDSA offers both deterministic and randomized signing. By default MLDSA signatures are nondeterministic, the private random seed rho' is pseudorandomly derived from the signer’s private key, the message, and a 256bit string, rnd  where rnd should be generated by an approved Random Bit Generator (RBG). In the deterministic version, rnd is instead a 256bit constant string. In the context of signaturebased authentication in IKEv2, the composition of the data used for generating a digital signature is unique for each IKEv2 session. This uniqueness arises because the data used for signature creation includes sessionspecific information such as nonces, cryptographic parameters, and identifiers. Therefore, if MLDSA is used as an authentication method within the IKEv2 protocol, the deterministic version of MLDSA can be utilized.
IKEv2 can use arbitrary signature algorithms as described in . The "Digital Signature" authentication method, as defined in , supersedes previously defined signature authentication methods. In this case, the three security levels of MLDSA are identified via AlgorithmIdentifier ASN.1 objects, as specified in . defines the SIGNATURE_HASH_ALGORITHMS notification where each side of the IKE negotiation lists its supported hash algorithms. However, in the case of MLDSA, it internally incorporates the necessary hash operation as part of its signing algorithm. MLDSA directly takes the original message, applies a hash function to it internally, and then uses the resulting hash value for the signature generation process. The data signed to prove the identity of the initiator and responder (as discussed in Section 2.15 of ) typically fits within the memory constraints of the devices involved in the IKEv2 exchange. The data consists of nonces, SPIs, and the initial exchange messages, which are manageable in size. In order to signal within IKE that no prehashing needs to be done with MLDSA, the "Identity" (5) value defined in MUST be set in the SIGNATURE_HASH_ALGORITHMS notification to indicate that prehashing is not required.
Specifying SLHDSA within IKEv2
SLHDSA utilizes the concept of stateless hashbased signatures. In contrast to stateful signature algorithms, SLHDSA eliminates the need for maintaining state information during the signing process. SLHDSA is designed to sign up to 2^64 messages and it offers three security levels. The parameters for each of the security levels were chosen to provide 128 bits of security, 192 bits of security, and 256 bits of security. This document specifies the use of the SLHDSA algorithm in IKEv2 at three security levels.
It includes the small (S) or fast (F) versions of the algorithm and allows for the use of either SHA256 or SHAKE256 as the hash function. The small version prioritizes smaller signature sizes, making them suitable for resourceconstrained environments IoT devices. Conversely, the fast version prioritizes speed over signature size, minimizing the time required to generate and verify signatures.
On the other hand, MLDSA outperforms SLHDSA in both signature generation and validation time, as well as signature size. SLHDSA, in contrast, offers smaller key sizes but larger signature sizes.
The following combinations are defined in SLHDSA :

SLHDSA128SSHA2

SLHDSA128FSHA2

SLHDSA192SSHA2

SLHDSA192FSHA2

SLHDSA256SSHA2

SLHDSA256FSHA2

SLHDSA128SSHAKE

SLHDSA128FSHAKE

SLHDSA192SSHAKE

SLHDSA192FSHAKE

SLHDSA256SSHAKE

SLHDSA256FSHAKE
SLHDSA does not introduce a new hardness assumption beyond those inherent to the underlying hash functions. It builds upon established foundations in cryptography, making it a reliable and robust digital signature scheme for a postquantum world. While attacks on latticebased schemes like MLDSA can compromise their security, SLHDSA will remain unaffected by these attacks due to its distinct mathematical foundations. This ensures the continued security of systems and protocols that utilize SLHDSA for digital signatures.
SLHDSA offers both deterministic and randomized signing, depending on whether opt_rand is set to a fixed value or a random value. If opt_rand is set to a public seed (an element in the public key), then signing will be deterministic — signing the same message twice will result in the same signature. In the context of signaturebased authentication in IKEv2, the composition of the data used for generating a digital signature is unique for each IKEv2 session. This uniqueness arises because the data used for signature creation includes sessionspecific information such as nonces, cryptographic parameters, and identifiers. Therefore, if SLHDSA is used as an authentication method within the IKEv2 protocol, the deterministic version of SLHDSA can be utilized.
IKEv2 can use arbitrary signature algorithms as described in . The "Digital Signature" authentication method, as defined in , supersedes previously defined signature authentication methods. In this case, the different combinations of SLHDSA are identified via AlgorithmIdentifier ASN.1 objects, as specified in . The final version of SLHDSA is expected to define two signature modes: pure mode and predigest mode. This document only specifies the use of predigest mode for signaturebased authentication in IKEv2. In case of predigest mode, SLHDSA internally performs randomized message compression using a keyed hash function that can process arbitrary length messages. The data signed to prove the identity of the initiator and responder (as discussed in Section 2.15 of ) typically fits within the memory constraints of the devices involved in the IKEv2 exchange. The data consists of nonces, SPIs, and the initial exchange messages, which are manageable in size. In order to signal within IKE that no prehashing needs to be done with SLHDSA, the "Identity" (5) value defined in MUST be set in the SIGNATURE_HASH_ALGORITHMS notification to indicate that prehashing is not required.
Mechanisms for Signaling Supported Key Pair Types
The following mechanisms can be used by peers to signal the types of public/private key pairs they possess:

One method to ascertain that the key pair type the initiator wants the responder
to use is through a Certificate Request payload sent by the
initiator. For example, the initiator could indicate in the
Certificate Request payload that it trusts a certificate authority
certificate signed by an MLDSA or SLHDSA key. This indication implies
that the initiator can process MLDSA or SLHDSA signatures, which means
that the responder can use MLDSA or SLHDSA keys when authenticating.

Another method is to leverage that
allows peers to announce their supported authentication methods. It improves
interoperability when IKEv2 partners are configured with multiple
credentials of different type to authenticate each other. The responder includes
a SUPPORTED_AUTH_METHODS notification in the IKE_SA_INIT response message
containing the PQC digital signature scheme(s) it supports. The initiator includes
the SUPPORTED_AUTH_METHODS notification in either the IKE_AUTH request message or
in the IKE_INTERMEDIATE request. This notification lists the PQC digital signature
scheme(s) supported by the initiator, ordered by preference.
Security Considerations
MLDSA and SLHDSA are modeled under existentially unforgeable digital signatures with respect to an adaptive chosen message attack (EUFCMA).
MLDSA44, MLDSA65, and MLDSA87 are designed to offer security comparable with the SHA256/SHA3256, AES192, and AES256 respectively. Similarly, SLHDSA128{S,F}{SHA2,SHAKE}, SLHDSA192{S,F}{SHA2,SHAKE}, and SLHDSA256{S,F}{SHA2,SHAKE} are designed to offer security comparable with the AES128, AES192, and AES256 respectively.
The Security Considerations section of and applies to this specification as well.
References
Normative References
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms.
Using the EdwardsCurve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2)
This document describes the use of the Edwardscurve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2).
Informative References
FIPS 204 (Initial Public Draft): ModuleLatticeBased Digital Signature Standard
FIPS 205 (Initial Public Draft): Stateless HashBased Digital Signature Standard
NIST, Secure Hash Standard (SHS), FIPS PUB 1804, August 2015
NIST, SHA3 Standard: PermutationBased Hash and ExtendableOutput Functions, FIPS PUB 202, August 2015.
V. Lyubashevsky, “FiatShamir With Aborts: Applications to Lattice and FactoringBased Signatures“, ASIACRYPT 2009
Internet Key Exchange Protocol Version 2 (IKEv2)
This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard.
PostQuantum Cryptography for Engineers
Nokia
Nokia
Nokia
DigiCert
The presence of a Cryptographically Relevant Quantum Computer (CRQC)
would render stateoftheart, traditional publickey algorithms
deployed today obsolete, since the assumptions about the
intractability of the mathematical problems for these algorithms that
offer confident levels of security today no longer apply in the
presence of a CRQC. This means there is a requirement to update
protocols and infrastructure to use postquantum algorithms, which
are publickey algorithms designed to be secure against CRQCs as well
as classical computers. These new publickey algorithms behave
similarly to previous public key algorithms, however the intractable
mathematical problems have been carefully chosen so they are hard for
CRQCs as well as classical computers. This document explains why
engineers need to be aware of and understand postquantum
cryptography. It emphasizes the potential impact of CRQCs on current
cryptographic systems and the need to transition to postquantum
algorithms to ensure longterm security. The most important thing to
understand is that this transition is not like previous transitions
from DES to AES or from SHA1 to SHA2. While dropin replacement
may be possible in some cases, others will require protocol redesign
to accommodate significant differences in behavior between the new
postquantum algorithms and the classical algorithms that they are
replacing.
Terminology for PostQuantum Traditional Hybrid Schemes
UK National Cyber Security Centre
UK National Cyber Security Centre
One aspect of the transition to postquantum algorithms in
cryptographic protocols is the development of hybrid schemes that
incorporate both postquantum and traditional asymmetric algorithms.
This document defines terminology for such schemes. It is intended
to be used as a reference and, hopefully, to ensure consistency and
clarity across different protocols, standards, and organisations.
Internet X.509 Public Key Infrastructure: Algorithm Identifiers for MLDSA
AWS
AWS
sn3rd
Cloudflare
Digital signatures are used within X.509 certificates, Certificate
Revocation Lists (CRLs), and to sign messages. This document
describes the conventions for using the ModuleLatticeBased Digital
Signatures (MLDSA) in Internet X.509 certificates and certificate
revocation lists. The conventions for the associated signatures,
subject public keys, and private key are also described.
Announcing Supported Authentication Methods in IKEv2
ELVISPLUS
This specification defines a mechanism that allows the Internet Key
Exchange version 2 (IKEv2) implementations to indicate the list of
supported authentication methods to their peers while establishing
IKEv2 Security Association (SA). This mechanism improves
interoperability when IKEv2 partners are configured with multiple
credentials of different type to authenticate each other.
Use of the SLHDSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
Vigil Security, LLC
Cisco Systems
Amazon Web Services
Cloudflare
SLHDSA is a stateless hashbased signature scheme. This document
specifies the conventions for using the SLHDSA signature algorithm
with the Cryptographic Message Syntax (CMS). In addition, the
algorithm identifier and public key syntax are provided.