]> Nokia

Bangalore Karnataka India k.tirumaleswar_reddy@nokia.com

Cisco Systems

sfluhrer@cisco.com

Nokia

jun.hu@nokia.com

NTT

yasufumi.morioka.dt@nttdocomo.com

Huawei

Wang.Guilin@huawei.com

Security IP Security Maintenance and Extensions Post-Quantum Hybrid Authentication IKEv2 A Cryptographically Relevant Quantum Computer (CRQC) can break traditional public-key algorithms (e.g., RSA, ECDSA), which are typically used for authentication in IKEv2. Combining the post-quantum ML-DSA signature algorithm with a traditional signature algorithm provides protection against potential weaknesses or implementation flaws in ML-DSA. This draft defines a hybrid PKI authentication method for IKEv2 using composite certificates that ensures authentication remains secure as long as at least one of the component signature algorithms remains unbroken. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the IP Security Maintenance and Extensions Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The advent of quantum computing poses a significant threat to current cryptographic systems. Traditional cryptographic algorithms such as RSA, Diffie-Hellman, DSA, and their elliptic curve variants are vulnerable to quantum attacks. During the transition to post-quantum cryptography (PQC), uncertainty remains regarding the long-term security of both traditional and PQC algorithms. Hybrid approaches allow deployments to mitigate risk during this transition period. Unlike previous migrations between cryptographic algorithms, the decision of when to migrate and which algorithms to adopt is far from straightforward. Even after the migration period, it may be advantageous for an entity's cryptographic identity to incorporate multiple public-key algorithms to enhance security. Cautious implementers may opt to combine cryptographic algorithms such that a successful forgery requires breaking each of the component signature algorithms used in the hybrid construction. This document defines a hybrid authentication mechanism for IKEv2 that combines traditional and post-quantum (PQC) signature algorithms using composite certificates. The security objective of this mechanism is that authentication remains secure as long as at least one of the component signature algorithms in the hybrid construction remains secure against forgery. The mechanism specified in this document provides a general framework for combining PQC and traditional signature algorithms in IKEv2. Although this document primarily describes combinations involving ML-DSA variants and traditional algorithms, the framework is not limited to ML-DSA and can accommodate other PQC and traditional signature algorithm combinations. The deployment model specified is: Composite Certificate: A single certificate containing a composite public key and composite signature, as defined in . In this model, a single certificate chain and a single AUTH payload are used to provide hybrid authentication assurance.

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. Cryptographically Relevant Quantum Computer (CRQC): A quantum computer that is capable of breaking real-world cryptographic systems. Post-Quantum Cryptographic (PQC) algorithms: Asymmetric cryptographic algorithms designed to resist attacks by cryptographically relevant quantum computers (CRQC). Traditional Cryptographic algorithms: Existing asymmetric Cryptographic algorithms could be broken by CRQC, like RSA, ECDSA, etc.

IKEv2 Key Exchange When hybrid authentication is used to achieve post-quantum security goals, the key exchange mechanism should provide comparable post-quantum resilience; otherwise, the overall security of the IKE SA will still depend on the traditional key exchange.

Exchanges The hybrid authentication exchanges are illustrated in , using an ML-KEM key exchange carried in an IKE_SA_INTERMEDIATE exchange as defined in . The key exchange mechanism is independent of the authentication mechanism defined in this document.

Hybrid Authentication Exchanges with ML-KEM via IKE_SA_INTERMEDIATE <-- HDR, SAr1, KEr, Nr, [CERTREQ,] N(SUPPORTED_AUTH_METHODS) HDR, SK {INTERMEDIATE KEi, Ni} --> <-- HDR, SK {INTERMEDIATE KEr, Nr} HDR, SK {IDi, CERT+, [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr, N(SUPPORTED_AUTH_METHODS)} --> <-- HDR, SK {IDr, CERT+, [CERTREQ,] AUTH} ------------------------------------------------------------------- ]]>

Composite Certificate This draft extends and complements which defines how to use Post-Quantum Cryptographic (PQC) signature algorithms (such as ML-DSA and SLH-DSA) in IKEv2 authentication. Both drafts share the same overarching goal: Enable IKEv2 to authenticate peers using PQC signature algorithms, ensuring security against quantum-capable adversaries. Whereas specifies PQC-only authentication, this draft specifies how to deploy PQC and traditional algorithms together to provide hybrid assurance during the migration phase. Both drafts:

• Do not require any changes to IKEv2 base protocol messages.
• Rely on the standard IKEv2 AUTH payload format .
• Use SUPPORTED_AUTH_METHODS (). In this case, the IKEv2 peers use the SUPPORTED_AUTH_METHODS notification to advertise supported composite signature algorithms.

IKEv2 can use arbitrary signature algorithms as described in , where the "Digital Signature" authentication method replaces older signature authentication methods. Both standalone PQC signature algorithms and composite signature algorithms can be incorporated using the "Signature Algorithm" field in the AUTH payload, as defined in . For composite signatures, a single AlgorithmIdentifier describes a composite public key and a composite signature that combines multiple constituent algorithms (e.g., a traditional and a PQC algorithm) in accordance with . This allows a single certificate and AUTH payload to provide hybrid assurance without requiring multiple exchanges. AlgorithmIdentifier ASN.1 objects are used to uniquely identify composite schemes, including the full parameter set for each constituent algorithm. This ensures unambiguous selection and verification of composite signature during authentication.

Composite Certificate Processing Authentication using composite certificates follows the generic digital signature authentication method defined in and the AUTH computation defined in Section 2.15 of . If one or more IKE_SA_INTERMEDIATE exchanges occurred, the signed octets are constructed as specified in . The end-entity certificate MUST contain a composite public key as defined in . The composite signature algorithm used in the AUTH payload MUST correspond to the composite public key algorithm in the certificate. A mismatch between the AUTH signature algorithm and the certificate public key algorithm MUST cause the IKE_SA negotiation to fail. Signature generation and verification are performed using the composite signature scheme as defined in . Any internal hashing or message preprocessing is performed as specified by that document.

IKEv2 Fragmentation Post-quantum signature algorithms and certificate chains may significantly increase the size of IKE_AUTH messages. Implementations supporting the mechanisms defined in this document MUST support IKEv2 Fragmentation as defined in .

Negotiation Note: currently, this section talks mostly about the problems that we'll need to address. Eventually, it'll be updated to talk about the actual mechanism, including the bits-on-the-wire format. To support brown field upgrades, we will need for an IKE device to be able to support negotiating with devices with only conventional (e.g. RSA) certificates, and with devices with composite certificates (e.g. RSA and ML-DSA). In addition, for the network to be entirely post-quantum safe, devices will need to be able to mandate that composite certificates be used. Furthermore, it would be cleaner if the device sent its policy upfront to the peer, rather than letting it try to negotiate and failing. For composite certificates, this is straight-forward. A composite certificate can be listed in the SUPPORTED_AUTH_METHODS list as yet another algorithm. A device can decide to list support for both that and RSA, or it could decide to list only support for composite certificates. The existing mechanism in IKE will cleanly decide which is appropriate. The only remaining issue is one of preference (if we have multiple algorithm OIDs that are acceptable to the peer, which one should we use). This is not a security issue; instead, it is a performance issue (preferring composite would allow us to find performance problems earlier).

Security Considerations The hybrid mechanism defined in this document aims to provide authentication security as long as at least one component signature algorithm remains secure against forgery. The security of general PQ/T hybrid authentication is discussed in . This document relies on mechanisms defined in , , and , and the security considerations of those specifications need to be taken into account. Traditional signature algorithms such as ECDSA, Ed25519, and Ed448 provide existential unforgeability under chosen-message attack (EUF-CMA), which is sufficient for IKEv2 authentication. When used as the traditional component in a composite construction with ML-DSA, these algorithms contribute to defense-in-depth during the transition to post-quantum cryptography, maintaining IKEv2 authentication security as long as at least one component algorithm remains secure. However, composite signature schemes do not in general preserve strong unforgeability (SUF-CMA) once the traditional component algorithm is broken, for example due to the availability of CRQCs. In such cases, a forged traditional signature component can be combined with a valid post-quantum component to produce a composite signature that verifies successfully, violating SUF. This loss of SUF is inherent to the composite construction and does not impact IKEv2, which relies only on the composite signature verification result.

Downgrade Considerations The AUTH computation in IKEv2 signs the IKE_SA_INIT exchange as specified in Section 2.15 of . Therefore, negotiation signals exchanged during IKE_SA_INIT (such as SUPPORTED_AUTH_METHODS ) are cryptographically bound to the authentication exchange and cannot be modified by an active attacker without causing authentication failure. If hybrid authentication is required by local policy, implementations MUST enforce that the negotiated authentication method satisfies that policy. Specifically, if composite authentication is required, receipt of a non-composite certificate or non-composite signature algorithm during IKE_AUTH MUST cause the IKE_SA negotiation to fail.

IANA Considerations None.

References Normative References Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines in certain regions. Composite ML-DSA is applicable in applications that use X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where existential unforgeability (EUF-CMA) level security is acceptable. 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. 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 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. This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment. The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established. 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. 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. Nokia ELVIS-PLUS Cisco Systems 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. Informative References One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum 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.

Acknowledgments TODO acknowledge.