]> Nokia

United States of America jun.hu@nokia.com

NTT DOCOMO, INC.

Japan yasufumi.morioka.dt@nttdocomo.com

Huawei

Singapore Wang.Guilin@huawei.com

Nokia

Bangalore Karnataka India k.tirumaleswar_reddy@nokia.com

Cisco Systems

sfluhrer@cisco.com

sec ipsecme Post-Quantum Hybrid Authentication IKEv2 Separate Certificates A Cryptographically Relevant Quantum Computer (CRQC) would break the traditional asymmetric algorithms, such as RSA and ECDSA, that are widely used to authenticate the Internet Key Exchange Protocol Version 2 (IKEv2). Post-quantum digital signature algorithms are intended to resist such a computer, but these new algorithms and their implementations require time to mature. This document specifies a post-quantum traditional (PQ/T) hybrid PKI authentication method for IKEv2 in which each peer uses two separate certificates: one containing a post-quantum public key and one containing a traditional public key. Authentication remains secure as long as at least one of the component signature algorithms remains secure. 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 WG Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Change Log

Changes in -00

• Initial version, this draft is the type-2 setup split from draft-hu-ipsecme-pqt-hybrid-auth.

Introduction A Cryptographically Relevant Quantum Computer (CRQC) could break traditional asymmetric cryptographic algorithms, such as RSA and ECDSA, that are widely deployed for IKEv2 authentication. Post-quantum cryptographic (PQC) digital signature algorithms, including ML-DSA , are intended to resist a CRQC. However, potential flaws in new algorithm specifications and implementations mean that relying only on a new PQC algorithm presents risk until the algorithm and its implementations have matured. The motivation for hybrid authentication is discussed further in . This document specifies PQ/T hybrid digital signature authentication for IKEv2. It combines a PQC signature algorithm and a traditional signature algorithm so that authentication remains secure as long as at least one component algorithm remains secure. There are two types of setup:

1. Each peer has one certificate which contains a single composite key as described in .
2. Each peer has two separate certificates: one certificate contains the PQC public key and the other contains the traditional public key.

This document specifies mechanism for type-2, while address type-1; The mechanism is a general framework for combinations of PQC and traditional algorithms. Combinations containing ML-DSA and traditional algorithms are examples of this framework.

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 capable of breaking real-world cryptographic systems.

Post-Quantum Cryptographic (PQC) algorithm:

An asymmetric cryptographic algorithm believed to be secure against a CRQC.

Traditional cryptographic algorithm:

An existing asymmetric cryptographic algorithm, such as RSA or ECDSA, that could be broken by a CRQC.

PQC certificate:

The certificate containing thepublic key of PQC algorithm.

Traditional certificate:

The certificate containing the public key of traditonal algorigthm.

IKEv2 Key Exchange This document does not change the IKEv2 key exchange process. When used with PQ/T hybrid authentication, the key exchange also needs to be CRQC resistant. For example, deployments can use a Post-quantum Preshared Key (PPK) as defined in , or a hybrid key exchange that includes a PQC algorithm such as ML-KEM through the multiple key exchange mechanism defined in . The authentication method specified here is independent of the selected key exchange.

Exchanges The example in illustrates hybrid authentication using a PPK during key exchange. Other quantum-resistant key exchanges can be used.

Hybrid Authentication Exchange with Separate Certificates <-- HDR, SAr1, KEr, Nr, [CERTREQ, CERTREQ], N(USE_PPK), N(SUPPORTED_AUTH_METHODS) HDR, SK {IDi, CERT, CERT, [CERTREQ, CERTREQ], [IDr,] AUTH, SAi2, TSi, TSr, N(PPK_IDENTITY, PPK_ID), N(SUPPORTED_AUTH_METHODS)} --> <-- HDR, SK {IDr, CERT, CERT, [N(PPK_IDENTITY)], AUTH} ]]>

The exchange proceeds as follows:

1. The responder announces its supported hybrid authentication combinations in a SUPPORTED_AUTH_METHODS notification in the IKE_SA_INIT response. Each combination identifies a PQC algorithm, a traditional algorithm, and a pre-hash algorithm.
2. The initiator selects one announced combination, generates the AUTH payload, and sends the corresponding PQC and traditional certificates in two CERT payloads. The initiator includes its own supported combinations in a SUPPORTED_AUTH_METHODS notification in the IKE_AUTH request.
3. The responder selects one combination announced by the initiator, generates the AUTH payload, and sends the corresponding PQC and traditional certificates in two CERT payloads in the IKE_AUTH response.

Announcement Support for this hybrid authentication method is announced using the multi-octet SUPPORTED_AUTH_METHODS format defined in . Each announcement contains:

• the new IANA-assigned AUTH_METHOD value requested by this document
• a Cert Link field
• a composite signature AlgorithmIdentifier

If the Cert Link field contains a non-zero value N, the method is intended for use with the N-th and (N+1)-th trust anchor CA references from the Certificate Request payloads, as described in . The AlgorithmIdentifier is a variable-length ASN.1 object encoded using Distinguished Encoding Rules (DER) . It identifies a combination of following:

• a PQC signature algorithm, such as id-ML-DSA-44;
• a traditional signature algorithm, such as id-RSASSA-PSS; and
• a pre-hash algorithm, such as id-sha256.

For example, a system supporting ML-DSA-44 with RSA-2048-PSS and ML-DSA-44 with ECDSA P-256 includes two multi-octet announcements:

• the new AUTH_METHOD value with AlgorithmIdentifier id-MLDSA44-RSA2048-PSS-SHA256; and
• the new AUTH_METHOD value with AlgorithmIdentifier id-MLDSA44-ECDSA-P256-SHA256.

Example SUPPORTED_AUTH_METHODS Announcements 3) | NEW_AUTH_VAL | Cert Link | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ id-MLDSA44-RSA2048-PSS-SHA256 (AlgorithmIdentifier) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (>3) | NEW_AUTH_VAL | Cert Link | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ id-MLDSA44-ECDSA-P256-SHA256 (AlgorithmIdentifier) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

This document does not change the multi-octet announcement format in . The only new protocol element is the AUTH_METHOD value requested for authentication with separate certificates.

Algorithm Combinations and Identifiers This document uses algorithm combinations and identifiers specified in , other combinations could be specified in future.

Certificate Request A peer performing this hybrid authentication method MAY send two CERTREQ payloads. The first payload contains the hash of the CA public key for the CA that issued the PQC certificate. The immediately following payload contains the hash of the CA public key for the CA that issued the traditional certificate. Each CERTREQ uses the hash-of-CA-public-key format defined in . When an announcement's Cert Link field is non-zero, its value identifies the first of the two consecutive CA references: the PQC certificate CA is the N-th reference and the traditional certificate CA is the (N+1)-th reference.

AUTH and CERT Payloads The IKEv2 AUTH payload has the format defined in :

IKEv2 AUTH Payload

The Auth Method field contains the new IANA-assigned value requested by this document. The Authentication Data field uses the format defined in :

Authentication Data in the Hybrid AUTH Payload

The AlgorithmIdentifier MUST match the selected combination previously announced by the peer. The Signature Value is generated as described in . The sender MUST place its signing PQC certificate in the first CERT payload and its signing traditional certificate in the immediately following CERT payload.

Signing The sender generates the hybrid AUTH payload as follows:

1. Select the composite signature AlgorithmIdentifier agreed through SUPPORTED_AUTH_METHODS.
2. Combine the PQC private key and traditional private key using the SerializePrivateKey operation defined in .
3. Run the Sign operation defined in with:
   • sk: the output of SerializePrivateKey;
   • M: InitiatorSignedOctets or ResponderSignedOctets, as appropriate, from ; and
   • ctx: the ASCII encoding of "IKEv2-PQT-Hybrid-Auth" (21 octets, with no null terminator).
4. Serialize the resulting CompositeSignatureValue as defined in and place the result in the Signature Value field.

defines three options for storing an ML-DSA private key. When ML-DSA is a component algorithm, the implementation MUST use an option that includes the seed because the Sign operation in requires the seed. The composite signature specification uses a pre-hash algorithm with the pure mode of ML-DSA, rather than HashML-DSA. See for the rationale.

RelatedCertificate Either signing certificate MAY contain the RelatedCertificate extension defined in . If either certificate contains this extension, the receiver MUST verify the extension according to . Failure to verify the extension MUST cause authentication to fail.

Verification The receiver verifies the hybrid AUTH payload as follows:

1. Verify that the Auth Method is the value assigned for the authentication method specified by this document.
2. Verify that the AlgorithmIdentifier matches a combination previously announced in the sender's SUPPORTED_AUTH_METHODS notification. If it does not match, reject the exchange with AUTHENTICATION_FAILED.
3. Obtain the PQC public key from the first CERT payload and the traditional public key from the immediately following CERT payload. Validate both certificate paths according to the local policy and the requirements of .
4. Both certificates MUST be accepted by local authorization policy as authenticating the same canonical IKE peer identity and PAD entry. one example is local policy requires check peer's certificates subject against peer's IKEv2 ID, then the both peer's certificates must have same subject as peer's IKEv2 ID.
5. If either certificate contains a RelatedCertificate extension, verify it as specified in .
6. Construct the composite public key using the SerializePublicKey operation defined in .
7. Run the Verify operation defined in with:
   • pk: the output of SerializePublicKey;
   • M: InitiatorSignedOctets or ResponderSignedOctets, as appropriate, from ;
   • ctx: the ASCII encoding of "IKEv2-PQT-Hybrid-Auth" (21 octets, with no null terminator); and
   • sig: the Signature Value from the Authentication Data field.
8. If Verify returns failure, reject the IKE_AUTH exchange with AUTHENTICATION_FAILED.

Security Considerations The security of PQ/T hybrid authentication is discussed in . This document also uses mechanisms defined in , , , and ; the security considerations of those documents apply. A component key used by this hybrid authentication method MUST NOT be reused for any other purpose, including authentication with only that component algorithm. Key reuse could invalidate the security properties expected from the composite signature construction. Both certificate paths MUST be validated. Accepting a valid path for only one component certificate would reduce the authentication method to a single-algorithm method. When a RelatedCertificate extension is present, its verification binds the two certificates and prevents an attacker from substituting an unrelated component certificate.

Downgrade Attack Prevention The IKE_SA_INIT exchange is not integrity-protected. An active on-path attacker can modify or remove a SUPPORTED_AUTH_METHODS notification in that exchange. If the notification is removed from the responder's IKE_SA_INIT response, an initiator supporting both hybrid and non-hybrid authentication might otherwise fall back to traditional-only authentication. A system configured to require mutual hybrid authentication for a peer MUST reject a SUPPORTED_AUTH_METHODS notification that does not contain an acceptable hybrid combination. It also MUST reject an IKE_AUTH exchange in which the peer's AUTH payload does not use the Auth Method specified by this document or does not use an AlgorithmIdentifier that was previously announced.

IANA Considerations This document requests a new value in the "IKEv2 Authentication Method" subregistry of the "Internet Key Exchange Version 2 (IKEv2) Parameters" registry:

Value	Method	Reference
TBD1	PQ/T Hybrid Digital Signature with Separate Certificates	This document

TBD1 is used in the Auth Method field of the IKEv2 AUTH payload and as the AUTH_METHOD value in a multi-octet SUPPORTED_AUTH_METHODS announcement.

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 defines a new Certificate Signing Request (CSR) attribute, relatedCertRequest, and a new X.509 certificate extension, RelatedCertificate. The use of the relatedCertRequest attribute in a CSR and the inclusion of the RelatedCertificate extension in the resulting certificate together provide additional assurance that two certificates each belong to the same end entity. This mechanism is particularly useful in the context of non-composite hybrid authentication, which enables users to employ the same certificates in hybrid authentication as in authentication done with only traditional or post-quantum algorithms. 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 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. 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. Informative References The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys. This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards and forwards compatibility, hybrid generality, and Simultaneous Verification (SV). Amazon Web Services US NIST standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This document specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange. These options allow for negotiating IKE and Child SA keys which are resistant against cryptographically relevant quantum computers. Nokia Cisco Systems Nokia NTT Huawei 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.

Acknowledgments TODO acknowledge.