]> Nokia

Bangalore Karnataka India kondtir@gmail.com

ELVIS-PLUS

Russian Federation svan@elvis.ru

Cisco Systems

sfluhrer@cisco.com

Security ipsecme PQC IKEv2 Digital Signature ML-DSA SLH-DSA Signature-based authentication methods are utilized in the Internet Key Exchange Version 2 (IKEv2). The current version of the IKEv2 protocol, specified in RFC 7296, supports traditional digital signatures. This document specifies a generic mechanism for integrating post-quantum cryptographic (PQC) digital signature algorithms into the IKEv2 protocol. The approach allows for seamless inclusion of any PQC signature scheme within the existing authentication framework of IKEv2. Additionally, it outlines how Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH-DSA), can be employed as authentication methods within the IKEv2 protocol, as they have been standardized by US NIST. 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 IKE_AUTH exchange, the initiator and responder independently select and use their preferred authentication method, which may differ between peers. The most common authentication method is digital signatures using asymmetric cryptography. Currently, traditional digital signatures are defined for use within IKE_AUTH: RSA signatures, Elliptic Curve Digital Signature Algorithm (ECDSA) , and Edwards-curve Digital Signature Algorithm (EdDSA) . The existence of a Cryptographically Relevant Quantum Computer (CRQC) would render traditional asymmetric 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 existence of a CRQC. Consequently, there is a requirement to update protocols and infrastructure to use post-quantum algorithms. Post-quantum algorithms are asymmetric algorithms designed to be secure against CRQCs as well as classical computers. The traditional cryptographic primitives that need to be replaced by post-quantum cryptographic (PQC) algorithms are discussed in PQC for Engineers . This document defines a general approach to incorporating PQC digital signature algorithms into IKEv2 while maintaining interoperability and backward compatibility, as it does not change the IKEv2 protocol but adds negotiable PQC signature algorithms. Additionally, it outlines how Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH-DSA) can be employed as authentication methods within IKEv2, as they have been standardized by the US National Institute of Standards and Technology (NIST) PQC project.

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. 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, elliptic curve discrete logarithms, or related mathematical problems. "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that is believed to be secure against attacks using quantum computers as well as classical computers. Post-quantum algorithms can also be called quantum-resistant or quantum-safe algorithms. Examples of quantum-resistant digital signature schemes include ML-DSA and SLH-DSA.

General Framework for PQC Authentication in IKEv2 IKEv2 authentication commonly relies on digital signatures to verify the identity of communicating peers. The mechanism described in this document enables the use of any PQC digital signature algorithm without modifying core IKEv2 operations.

Specifying PQC Signature Algorithms

• IKEv2 can use arbitrary signature algorithms as described in Signature Authentication in IKEv2 , where the "Digital Signature" authentication method supersedes previously defined signature authentication methods. Any PQC digital signature algorithm can be incorporated using the "Digital Signature" authentication method, as defined in .
• Distinguished Encoding Rules (DER) encoded AlgorithmIdentifier ASN.1 objects will be used to uniquely identify the PQC signature algorithm scheme and the parameter set associated with it. The AlgorithmIdentifier ASN.1 object is placed in the Authentication Data field of the Authentication payload (see Figure 2 of for details).

Signature Generation and Verification PQC signatures may be generated in either deterministic or hedged modes. The terms deterministic and hedged used in this document are in accordance with ML-DSA and SLH-DSA , which define the ML-DSA and SLH-DSA algorithms, respectively. Future PQC signature algorithms may adopt different nomenclature, but will be expected to follow the same principles. In the deterministic mode, the signature is derived entirely from the message and the signer’s private key, without introducing fresh randomness at signing time. While this eliminates reliance on an external random number generator, it increases susceptibility to side-channel attacks, particularly fault injection attacks. The hedged mode provides some resistance against this risk by including precomputed randomness in the signer's private key and incorporating fresh randomness generated at signing time. This foils some side channel attack approaches, while adding no additional strength against others. If protection against side-channel attacks is required, ML-DSA implementations that implement side-channel resistance should be used. In the context of signature-based authentication in IKEv2, the data used for generating a digital signature is unique for each session, as it includes session-specific information such as nonces. PQC signature algorithms can leverage the hedged variant within IKEv2 to enhance security against side-channel attacks. The choice between deterministic and hedged signing modes does not impact interoperability because the verification process remains the same for both variants. If the PQC signature algorithm uses a 'context' input parameter, it MUST be set to an empty string. Certain digital signature algorithms support two modes: "pure" mode and "pre-hash" mode. For example, ML-DSA and SLH-DSA support both modes. In pure mode, the content is signed directly along with some domain separation information. In contrast, pre-hash mode involves signing a digest of the message. This document specifies the use of pure mode for signature-based authentication in IKEv2, where the message is signed directly along with domain separation information. The data used for authentication in IKEv2, as described in Section 2.15 of IKEv2 , consists of elements such as nonces, SPIs, and initial exchange messages (messages preceding IKE_AUTH), which are typically within device memory constraints.

Handling PQC Signatures in IKEv2 As specified in Signature Authentication in IKEv2 , both the initiator and responder MUST send the SIGNATURE_HASH_ALGORITHMS notify payload in the IKE_SA_INIT exchange to indicate the set of hash algorithms they support for signature generation and verification. The SIGNATURE_HASH_ALGORITHMS notify payload contains a list of 2-octet hash algorithm identifiers, defined in the IANA "IKEv2 Hash Algorithms" registry . For PQC signature algorithms that inherently operate directly on the raw message without hashing, such as ML-DSA and SLH-DSA, only the 'Identity' hash function is applicable. The 'Identity' hash function (value 5) is defined in Section 2 of "Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2)" and indicates that the input message is used as-is, without any hash function applied. Therefore, implementations supporting such PQC signature algorithms MUST include the 'Identity' hash (5) in the SIGNATURE_HASH_ALGORITHMS notification. Furthermore, PQC signature algorithms requiring the 'Identity' hash MUST NOT be used with a peer that has not indicated support for the Identity hash in its notify payload. When generating a signature with a PQC signature algorithm, the IKEv2 implementation takes the InitiatorSignedOctets string or the ResponderSignedOctets string (as appropriate), logically sends it to the identity hash (which leaves it unchanged), and then passes it into the PQC signer as the message to be signed (with empty context string, if applicable). The resulting signature is placed into the Signature Value field of the Authentication Payload. When verifying a signature with a PQC signature algorithm, the IKEv2 implementation takes the InitiatorSignedOctets string or the ResponderSignedOctets string (as appropriate), logically sends it to the identity hash (which leaves it unchanged), and then passes it into the PQC signature verifier as the message to be verified (with empty context string, if applicable). IKEv2 peers supporting the PQC authentication mechanism defined in this specification MUST implement IKEv2 message fragmentation , unless IKEv2 runs over a reliable transport (e.g., ) or the underlying network is known to support sufficiently large MTUs without fragmentation issues, since PQC public keys and signatures can be significantly larger than those used in traditional algorithms. For example, ML-DSA-44 requires a public key of 1,312 bytes and a signature of 2,420 bytes, while even the smallest SLH-DSA signature is around 7,856 bytes. As guidance, IKEv2 peers should assume a minimum PMTU of 1280 bytes for IPv6 (per ) and, where legacy IPv4 networks are a consideration, an effective MTU of 576 bytes for IPv4 (per ).

Mechanisms for Signaling Supported Key Pair Types The following mechanisms can be used by peers to signal the types of digital signature algorithms and parameters they support:

• Certificate Request Payload: One method to ascertain that the key pair type the initiator wants the responder to use is through a Certificate Request payload (defined in Section 3.7 of IKEv2 ) sent by the initiator. For example, the initiator can specify that it trusts certificates issued by a certificate authority (CA) that signs with a particular PQC signature algorithm. This implies that the initiator can process signatures generated using that algorithm, thereby allowing the responder to authenticate itself using a key pair associated with the specified PQC signature scheme.
• Authentication Method Announcement: Using "Announcing Supported Authentication Methods in the Internet Key Exchange Protocol Version 2 (IKEv2)" , which enables peers to declare their supported authentication methods. This improves interoperability when IKEv2 peers are configured with multiple credential types to authenticate each other. The responder includes a SUPPORTED_AUTH_METHODS notification in the IKE_SA_INIT response message, listing the signature scheme(s) it supports under the Digital Signature authentication method. 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 digital signature scheme(s) supported by the initiator, ordered by preference.

In traditional IKEv2 deployments, peers often implicitly know the signature algorithms in use based on pre-configured certificates, trusted CAs, and IKEv2 policies. However, cryptographic agility, the ability to negotiate and use different cryptographic algorithms, is gaining increased attention for ensuring long-term security and interoperability. This requirement becomes even more relevant with the introduction of PQC algorithms, where multiple signature algorithms with varying security levels and performance characteristics may need to be supported over time.

Specifying ML-DSA within IKEv2 ML-DSA is a digital signature algorithm based on the hardness lattice problems over module lattices (i.e., the Module Learning with Errors problem (commonly referred to as MLWE)). The design of the algorithm is based on the "Fiat-Shamir with Aborts" framework introduced by Lyubashevsky that leverages rejection sampling to render lattice-based Fiat-Shamir (FS) schemes compact and secure. ML-DSA uses a uniform distribution over small integers for computing coefficients in error vectors, which simplifies implementation compared to schemes requiring discrete Gaussian sampling. ML-DSA is instantiated with three parameter sets for the PQ Security Levels 2, 3, and 5 (see Table 2 in Section 11 of PQC for Engineers ). Security properties of ML-DSA are discussed in Section 9 of PKIX Algorithm Identifiers for ML-DSA . This document specifies the use of the ML-DSA algorithm in IKEv2 at three security levels: ML-DSA-44, ML-DSA-65, and ML-DSA-87. The DER encodings of the AlgorithmIdentifier objects for ML-DSA-44, ML-DSA-65, and ML-DSA-87 are listed in .

Specifying SLH-DSA within IKEv2 SLH-DSA utilizes the concept of stateless hash-based signatures. In contrast to stateful signature algorithms such as the eXtended Merkle Signature Scheme (XMSS) or Hierarchical Signature System/Leighton-Micali Signature (HSS/LMS) , SLH-DSA eliminates the need for maintaining state information during the signing process. SLH-DSA is designed to sign up to 2^64 messages and it offers three security levels. The parameters for PQ Security Levels 1, 3, and 5 were chosen to provide AES-128, AES-192, and AES-256 bits of security respectively (see Table 2 in Section 11 of PQC for Engineers ). This document specifies the use of the SLH-DSA algorithm in IKEv2 at each level. Each security level (1, 3, and 5) defines two variants of the algorithm: a small (S) version and a fast (F) version. The small version prioritizes smaller signature sizes, making them suitable for resource-constrained IoT devices. Conversely, the fast version prioritizes speed over signature size, minimizing the time required to generate signatures. However, signature verification with the small version is faster than with the fast version. For hash function selection, the algorithm uses SHA-256 () for security level 1 and both SHA-256 and SHA-512 () for security levels 3 and 5. Alternatively, SHAKE256 () can be used across all security levels. Those hash function selections are internal to SLH-DSA implementations, and are not to be confused with those in the SIGNATURE_HASH_ALGORITHMS notification payload. ML-DSA outperforms SLH-DSA in both signature generation and validation time, as well as signature size. SLH-DSA, in contrast, offers smaller key sizes but larger signature sizes. The following combinations are defined in SLH-DSA :

• SLH-DSA-128S-SHA2
• SLH-DSA-128F-SHA2
• SLH-DSA-192S-SHA2
• SLH-DSA-192F-SHA2
• SLH-DSA-256S-SHA2
• SLH-DSA-256F-SHA2
• SLH-DSA-128S-SHAKE
• SLH-DSA-128F-SHAKE
• SLH-DSA-192S-SHAKE
• SLH-DSA-192F-SHAKE
• SLH-DSA-256S-SHAKE
• SLH-DSA-256F-SHAKE

SLH-DSA 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 in the face of a CRQC. While attacks on lattice-based schemes like ML-DSA are hypothetical as of 2026, such attacks, if realized, could compromise their security. SLH-DSA would remain unaffected by these attacks due to its distinct mathematical foundations. This ensures the continued security of systems and protocols that utilize SLH-DSA for digital signatures. The DER encodings of the AlgorithmIdentifier objects for each SLH-DSA variant are listed in .

Use of ML-DSA and SLH-DSA Both ML-DSA and SLH-DSA define deterministic and hedged signing modes, where the hedged mode incorporates fresh randomness into the signing procedure. IKEv2 peers can use either mode of ML-DSA and SLH-DSA for authentication in IKEv2, with a preference for the hedged mode (). The signing mode is a local decision made by the signer; it is not negotiated between the peers, and the verifier neither knows nor needs to know which mode was used, since verification is identical in both cases. The three security levels of ML-DSA are identified via AlgorithmIdentifier ASN.1 objects, as specified in NIST and referenced in PKIX Algorithm Identifiers for the ML-DSA . defines both a pure and a pre-hash variant of ML-DSA, but PKIX Algorithm Identifiers for the ML-DSA specifies only the pure variant. The different parameter sets of SLH-DSA are identified via AlgorithmIdentifier ASN.1 objects, as specified in NIST and referenced in PKIX Algorithm Identifiers for the SLH-DSA . defines both a pure and a pre-hash mode of SLH-DSA, but this document specifies the use of only Pure SLH-DSA, consistent with .

IANA Considerations This document makes no requests to IANA.

Security Considerations PQC signature algorithms are generally modeled to achieve strong unforgeability under adaptive chosen-message attacks (SUF-CMA; see Section 10.1.1 of PQC for Engineers ). For example, ML-DSA provides SUF-CMA security. However, some algorithms, such as SLH-DSA, achieve existential unforgeability under chosen-message attacks (EUF-CMA; see Section 10.1.1 of PQC for Engineers ). This distinction does not impact IKEv2, as the signed data in each session is unique due to the inclusion of nonces. Consequently, the oracle-based forgery attack scenarios in the EUF-CMA model do not arise in IKEv2. Different PQC signature schemes are designed to provide security levels comparable to well-established cryptographic primitives. For example, some schemes align with the US NIST post-quantum security categories (Categories 1 through 5) as discussed in ML-DSA and SLH-DSA . These categories specify target security strengths that correspond approximately to exhaustive key-search resistance for AES-128, AES-192, and AES-256, and collision-search resistance for SHA-256, SHA-384, and SHA-512. The choice of a PQC signature algorithm should be guided by the desired security level and performance requirements. ML-DSA-44, ML-DSA-65, and ML-DSA-87 are designed to offer security comparable with the SHA-256/SHA3-256 collision resistance (which is a harder problem than AES-128 key search), AES-192 key search, and AES-256 key search, respectively. Similarly, SLH-DSA-128{S,F}-{SHA2,SHAKE}, SLH-DSA-192{S,F}-{SHA2,SHAKE}, and SLH-DSA-256{S,F}-{SHA2,SHAKE} are designed to offer security comparable with the AES-128, AES-192, and AES-256 respectively. The Security Considerations section of PKIX Algorithm Identifiers for ML-DSA and PKIX Algorithm Identifiers for SLH-DSA apply to this specification as well. SLH-DSA keys are limited to 2^64 signatures. This upper bound is so large that even a IKEv2 server establishing IKEv2 sessions at an extremely high rate could not realistically reach it (at 10 billion signatures per second, it would still take over 58 years). The limit is therefore of theoretical interest only, but implementations may still track signature usage as a precautionary security measure. ML-DSA does not have a built-in signature limit, allowing for an arbitrary number of signatures to be made with the same key.

Acknowledgements Thanks to Stefaan De Cnodder, Loganaden Velvindron, Paul Wouters, Andreas Steffen, Dan Wing, Wang Guilin, Rebecca Guthrie, Jonathan Hammell, Eric Vyncke, John Mattsson, Russ Housley, Tony Li, Tero Kivinen and Daniel Van Geest for the discussion and comments.

References Normative References This specification defines a mechanism that allows implementations of the Internet Key Exchange Protocol Version 2 (IKEv2) to indicate the list of supported authentication methods to their peers while establishing IKEv2 Security Associations (SAs). This mechanism improves interoperability when IKEv2 partners are configured with multiple credentials of different types for authenticating each other. 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. This document describes the use of the Edwards-curve Digital Signature Algorithm (EdDSA) in the 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. 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. 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. This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through. Informative References This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] IANA This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols. ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods. This document adds ECDSA capability to IKE and IKEv2 without introducing any changes to existing IKE operation. [STANDARDS-TRACK] The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), and it details the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association (SA) establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. TCP encapsulation for IKE and IPsec was defined in RFC 8229. This document clarifies the specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. This documents obsoletes RFC 8229. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature. This note specifies Winternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers. This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them. Digital signatures are used within the X.509 Public Key Infrastructure, such as X.509 certificates and Certificate Revocation Lists (CRLs), as well as to sign messages. This document specifies the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in the X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also specified.

Implementation Alternatives for ML-DSA With ML-DSA, there are two different approaches to implementing the signature process. The first one is to provide the SignedOctets string to the cryptographic library to generate the full signature; this works for SLH-DSA as well. The second approach involves using the Externalμ-ML-DSA API allowed by ; specifically by the comment to line 6 of algorithm 7 of FIPS 204. In this method, the implementation calls the External μ pre-hashing mode with the SignedOctets string and the ML-DSA public key, which externalizes the message pre-hashing originally performed inside the signing operation (see Appendix D of for ML-DSA pre-hashing). The resulting μ value is then passed to the cryptographic library to execute the Externalμ-ML-DSA.Sign API, which uses μ and the ML-DSA private key to produce the signature. This document specifies only the use of ML-DSA's External μ mode and does not use HashML-DSA. This approach avoids requiring large message inputs to be processed within potentially constrained cryptographic modules, such as Hardware Security Modules (HSMs). Both approaches are considered "pure" mode and produce the same ML-DSA signature and are fully interoperable. The choice between them depends on implementation preferences, such as whether the External μ pre-hashing step is handled internally by the cryptographic module or performed explicitly by the IKEv2 implementation.

ASN.1 Objects This section lists AlgorithmIdentifier ASN.1 objects for algorithms mentioned in the document in binary form.
This section is not normative, and these values should only be used as examples. If the ASN.1 object listed in this section and the ASN.1 object specified by the algorithm differ, then the algorithm specification must be used. The generic format for the AlgorithmIdentifier ASN.1 object is defined in Section 4.1.1.2 of PKIX .

ML-DSA-44 id-ml-dsa-44 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-ml-dsa-44(17) } Parameters are absent.

ML-DSA-65 id-ml-dsa-65 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-ml-dsa-65(18) } Parameters are absent.

ML-DSA-87 id-ml-dsa-87 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-ml-dsa-87(19) } Parameters are absent.

SLH-DSA-128S-SHA2 id-slh-dsa-sha2-128s OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-slh-dsa-sha2-128s(20) } Parameters are absent.

SLH-DSA-128F-SHA2 id-slh-dsa-sha2-128f OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-slh-dsa-sha2-128f(21) } Parameters are absent.

SLH-DSA-192S-SHA2 id-slh-dsa-sha2-192s OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-slh-dsa-sha2-192s(22) } Parameters are absent.

SLH-DSA-192F-SHA2 id-slh-dsa-sha2-192f OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-slh-dsa-sha2-192f(23) } Parameters are absent.

SLH-DSA-256S-SHA2 id-slh-dsa-sha2-256s OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-slh-dsa-sha2-256s(24) } Parameters are absent.

SLH-DSA-256F-SHA2 id-slh-dsa-sha2-256f OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-slh-dsa-sha2-256f(25) } Parameters are absent.

SLH-DSA-128S-SHAKE id-slh-dsa-shake-128s OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-slh-dsa-shake-128s(26) } Parameters are absent.

SLH-DSA-128F-SHAKE id-slh-dsa-shake-128f OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-slh-dsa-shake-128f(27) } Parameters are absent.

SLH-DSA-192S-SHAKE id-slh-dsa-shake-192s OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-slh-dsa-shake-192s(28) } Parameters are absent.

SLH-DSA-192F-SHAKE id-slh-dsa-shake-192f OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-slh-dsa-shake-192f(29) } Parameters are absent.

SLH-DSA-256S-SHAKE id-slh-dsa-shake-256s OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-slh-dsa-shake-256s(30) } Parameters are absent.

SLH-DSA-256F-SHAKE id-slh-dsa-shake-256f OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-slh-dsa-shake-256f(31) } Parameters are absent.