]> Nokia

United States of America jun.hu@nokia.com

NTT DOCOMO, INC.

Japan yasufumi.morioka.dt@nttdocomo.com

Huawei

Singapore Wang.Guilin@huawei.com

sec ipsecme Post-Quantum Hybrid Authentication IKEv2 One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptographic algorithms: e.g RSA, ECDSA, which are widely deployed authentication options of IKEv2. There are new Post-Quantum Cryptographic (PQC) algorithms for digital signature like NIST , However, it takes time for new cryptographic algorithms to mature, There is security risk to use only the new algorithm before it is field proven. This document describes a hybrid PKI authentication scheme for IKEv2 that incorporates both traditional and PQC digital signature algorithms, so that authentication is secure as long as one algorithm in the hybrid scheme is 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 -05

• rework announcement section to reuse RFC9593 existing multi-octet format; no protocol format changes
• add Certificate Request section for type-1 and type-2 CERTREQ payload usage
• add Verification subsection with step-by-step AUTH payload verification procedure
• add Downgrade Attack Prevention subsection in Security Considerations
• strengthen RelatedCertificate verification from SHOULD to MUST
• update IANA Considerations to clarify only type-2 needs a new IANA AUTH_METHOD value
• editorial changes

changes in -04

• align to draft-ietf-lamps-pq-composite-sigs-14
• add text to clarify two setup types
• add text to describe the example exchange in section 5
• clarify using of pre-hash alg
• clarify sign operation in type-2
• ietf-lamps-cert-binding-for-multi-auth is now RFC9763
• ietf-lamps-dilithium-certificates is now RFC9881
• editorial changes

changes in -03

• version bump to keep doc alive

Changes in -02

• clarify the approach in the document is general
• dropping support for PreHash ML-DSA, change example to Pure Signature ML-DSA
• adding more details in signing process to align with ietf-lamps-pq-composite-sigs-04
• add text in Security Considerations to emphasize prohibit of key reuse
• clarify the both C and S bit MAY be 1 at the same time
• clarify the receiver behavior when the announcement contains no algid
• typo fixes

Changes in -01

• Only use SUPPORTED_AUTH_METHODS for algorithm combination announcement, no longer use SIGNATURE_HASH_ALGORITHMS
• add flag field in the announcement
• clarify two types of PKI setup
• add some clarifications on how AUTH payload is computed

Introduction A Cryptographically Relevant Quantum Computer (CRQC) could break traditional asymmetric cryptographic algorithms: e.g RSA, ECDSA, which are widely deployed authentication options of IKEv2. New Post-Quantum Cryptographic (PQC) algorithms for digital signature were recently published like NIST , However, by considering potential flaws in the new algorithm's specifications and implementations, it will take time for these new PQC algorithms to be field proven. So it is risky to only use PQC algorithms before they are mature. There is more detailed discussion on motivation of a hybrid approach for authentication in . This document describes a post-quantum traditional (PQ/T) hybrid digital signature authentication scheme for IKEv2 that incorporates both traditional and PQC digital signature algorithms, so that authentication is secure as long as one algorithm in the hybrid scheme is secure. Each IPsec peer announces the support of hybrid authentication via SUPPORTED_AUTH_METHODS notification as defined in , generates and verifies AUTH payload using composite signature using the procedures defined in . The approach specified in this document is a general framework for all PQC and traditional algorithms. The combinations of ML-DSA variants and traditional algorithms given in this document are instantiations of the general framework. There are two types of PQ/T hybrid PKI setup:

1. Type-1: A single certificate that has a composite key as defined in , which contains two component keys: one traditional key + one PQC key.
2. Type-2: Two certificates, one certificate with traditional algorithm key and one certificate with PQC algorithm key as described in , Each certificate MAY contain RelatedCertificate extension to associate with the other certificate.

A given deployment could use either type to provide PQ/T hybrid PKI. This document supports both types.

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 are thought to be secure against CRQC. Traditional Cryptographic algorithms: Existing asymmetric Cryptographic algorithms could be broken by CRQC, like RSA, ECDSA ..etc.

IKEv2 Key Exchange There is no changes introduced in this document to the IKEv2 key exchange process, although it MUST be also resilient to CRQC when using along with the PQ/T hybrid authentication, for example key exchange using the PPK as defined in , or hybrid key exchanges that includes PQC algorithm like via multiple key exchange process as defined in .

Exchanges The hybrid authentication exchanges is illustrated in an example depicted in , using PPK as defined in during key exchange. However, other PQC key exchanges could also be used since how key exchange is done is independent from authentication.

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

1. Responder announces the hybrid authentication support via SUPPORTED_AUTH_METHODS notification in IKE_SA_INIT response message. The notification includes the combinations of PQC, traditional, hash algorithm and type of hybrid PKI setup that responder supports.
2. Initiator chooses a combination from responder's SUPPORTED_AUTH_METHODS, uses the combination to generate the AUTH payload, along with corresponding signing certificate(s) in CERT payload(s), and includes its support of hybrid combinations in SUPPORTED_AUTH_METHODS notification of IKE_AUTH request message.
3. Responder chooses a combination from initiator's SUPPORTED_AUTH_METHODS, uses the combination to generate the AUTH payload, and includes corresponding signing certificate(s) in CERT payload(s) of IKE_AUTH response message.

Announcement Announcement of support for hybrid authentication is through the SUPPORTED_AUTH_METHODS notification as defined in , using multi-octet announcements. This document uses the existing multi-octet announcement format from with the following AUTH_METHOD values:

1. For type-1 (composite key certificate): use AUTH_METHOD value 14 (Digital Signature, as defined in ) together with the composite signature AlgorithmIdentifier as defined in .
2. For type-2 (two separate certificates): use a new IANA-assigned AUTH_METHOD value together with the composite signature AlgorithmIdentifier corresponding to the combination of the two certificates. If the Cert Link field contains a non-zero value N, it means the method is intended to be used with the N-th and N+1-th trust anchor CA from the Certificate Request payload(s). see for more details.

There is no change to the existing multi-octet announcement protocol format defined in . The only new protocol element introduced by this document is the new IANA-assigned AUTH_METHOD value for type-2. For example, if a system supports the following authentication configurations:

• A: MLDSA44 + RSA2048_PSS as type-1
• B: MLDSA44 + ECDSA-P256 as type-1
• C: MLDSA44 + RSA2048_PSS as type-2

It will include 3 multi-octet announcements in the SUPPORTED_AUTH_METHODS payload:

• Auth-method 14 with AlgorithmIdentifier id-MLDSA44-RSA2048-PSS-SHA256, for A above
• Auth-method 14 with AlgorithmIdentifier id-MLDSA44-ECDSA-P256-SHA256, for B above
• Auth-method NEW_VAL_for_TYPE2 with AlgorithmIdentifier id-MLDSA44-RSA2048-PSS-SHA256, for C above

Example SUPPORTED_AUTH_METHODS Payload with 3 Announcements 3) | 14 | Cert Link | | <- A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ id-MLDSA44-RSA2048-PSS-SHA256 (AlgorithmIdentifier) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (>3) | 14 | Cert Link | | <- B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ id-MLDSA44-ECDSA-P256-SHA256 (AlgorithmIdentifier) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (>3) | NEW_VAL_TYPE2 | Cert Link | | <- C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ id-MLDSA44-RSA2048-PSS-SHA256 (AlgorithmIdentifier) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

Each AlgorithmIdentifier is the variable-length ASN.1 object encoded using Distinguished Encoding Rules (DER) that identifies a composite signature algorithm as defined in , specifying a combination of:

• a PQC algorithm (e.g. id-ML-DSA-44)
• a traditional PKI algorithm (e.g. id-RSASA-PSS)
• a pre-hash algorithm (e.g. id-sha256)

Certificate Request This section describes how peers use Certificate Request (CERTREQ) payloads when performing hybrid authentication.

Type-1 For type-1 hybrid authentication, a single CERTREQ payload MAY be sent referencing the CA that issued the composite certificate. The CERTREQ uses the standard hash-of-CA-public-key format as defined in .

Type-2 For type-2 hybrid authentication, two CERTREQ payloads MAY be sent: the first hash refer to the PQC certificate CA (issuer of the PQC certificate), and directly follow by the hash refer to traditional certificate CA (issuer of the traditional certificate).

AUTH & CERT payload The IKEv2 AUTH payload has following format as defined in :

AUTH payload

For hybrid authentication, the Auth Method is either value 14 (Digital Signature) for type-1 or the new IANA-assigned value for type-2, as defined in The Authentication Data field follows format defined in :

Authentication Data in hybrid AUTH payload

Based on selected AlgorithmIdentifier and setup type, the Signature Value is created via procedure defined in , .

Type-1 Assume selected AlgorithmIdentifier is A.

1. There is no change on data to be signed, e.g. InitiatorSignedOctets/ResponderSignedOctets as defined in
2. Follow Sign operation identified by A, e.g. . The ctx input is the string of "IKEv2-PQT-Hybrid-Auth". This step outputs the composite signature, a CompositeSignatureValue.
3. CompositeSignatureValue is serialized per , and the output is used as Signature Value in the Authentication Data field.

Note: uses a pre-hash algorithm with pure mode (Algorithm 2), not the HashML-DSA as defined in , see for the rationale. Following is an initiator example:

1. A is id-MLDSA44-RSA2048-PSS-SHA256, which uses PQC ML-DSA-44 and traditional RSASSA-PSS with pre-hash function SHA256
2. Follow with following inputs:
   • sk is the private key of the signing composite key certificate
   • M is InitiatorSignedOctets
   • ctx is "IKEv2-PQT-Hybrid-Auth"

The signing composite certificate MUST be the first CERT payload.

Type-2

1. Combine PQC key and traditional key into composite key using SerializePrivateKey operation as defined in .
2. Follow Sign operation as

Note: defines 3 options for ML-DSA private key storage, this document requires options that include seed since Sign operation of only supports seed. With example in :

• sk is the combined private key, e.g. output of SerializePrivateKey
• M is InitiatorSignedOctets
• ctx is "IKEv2-PQT-Hybrid-Auth" (21 octets, no null terminator)

The signing PQC certificate MUST be the first CERT payload in the IKEv2 message, while traditional certificate MUST be the second CERT payload.

RelatedCertificate In type-2 setup, the signing certificate MAY contain RelatedCertificate extension, then the receiver MUST verify the extension according to . Failed verification MUST cause authentication to fail.

Verification This section specifies how a receiver verifies the hybrid AUTH payload produced by the signing procedures defined in and . The receiver performs the following steps:

1. Determine the setup type from the Auth Method and AlgorithmIdentifier:
   • Type-1: if Auth Method is 14 and the AlgorithmIdentifier is one of algorithms defined in
   • Type-2: if Auth Method is the new IANA assigned value
2. Verify that setup and AlgorithmIdentifier matches one of the combinations previously announced in the SUPPORTED_AUTH_METHODS notification. If no match is found, the receiver MUST reject the exchange with AUTHENTICATION_FAILED.
3. Obtain public key from the CERT payload(s):
   • For type-1: obtain the composite public key from the composite certificate in the first CERT payload.
   • For type-2: obtain the PQC public key from the PQC certificate (first CERT payload) and the traditional public key from the traditional certificate (second CERT payload). Reconstruct the composite public key using the SerializePublicKey operation as defined in .
4. Run the Verify operation as defined in with the following inputs:
   • pk: the composite public key obtained in step 4
   • M: InitiatorSignedOctets or ResponderSignedOctets as defined in , depending on which peer's AUTH payload is being verified
   • ctx: the ASCII encoding of the string "IKEv2-PQT-Hybrid-Auth" (21 octets, no null terminator)
   • sig: the Signature Value from the Authentication Data field
5. If the Verify operation returns failure, the receiver MUST reject the IKE_AUTH exchange with AUTHENTICATION_FAILED.

Security Considerations The security of general PQ/T hybrid authentication is discussed in . This document uses mechanisms defined in , and , so the security discussion in the corresponding RFCs also apply. One important security consideration mentioned in worth repeating here is that component key used in either or MUST NOT be reused in any other cases including single-algorithm case.

Downgrade Attack Prevention The IKE_SA_INIT exchange is not integrity-protected, and an active attacker on the network path can modify or remove the SUPPORTED_AUTH_METHODS notification from an IKE_SA_INIT message. If such a notification is stripped from the responder's IKE_SA_INIT response, an initiator that supports both hybrid and non-hybrid authentication may fall back to traditional-only authentication without being aware of the attack. To prevent downgrade attacks, for a system that is configured to require mutual hybrid authentication for a given peer MUST NOT accept peer's SUPPORTED_AUTH_METHODS that doesn't contain expected hybrid authentication method & algorithm, also MUST NOT accept an IKE_AUTH exchange in which the remote peer's AUTH payload uses a non-hybrid Auth Method.

IANA Considerations This document requests a new value in the "IKEv2 Authentication Method" subregistry under the IANA "Internet Key Exchange Version 2 (IKEv2) Parameters" registry for the type-2 (two-certificate) PQ/T hybrid authentication method. Type-1 (composite key certificate) hybrid authentication reuses the existing AUTH_METHOD value 14 (Digital Signature) and requires no new IANA allocation.

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. SandboxAQ Naval Postgraduate School SandboxAQ UK National Cyber Security Centre 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/forwards compatibility, hybrid generality, and simultaneous verification. 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 how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs. This document updates RFC 7296 by renaming a Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. 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 safe against cryptographically relevant quantum computers.

Acknowledgments TODO acknowledge.