]> 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, so there is security risk to use only the new algorithm before it is field proven. This document describes a IKEv2 hybrid authentication scheme that could contain both traditional and PQC 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 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 an IKEv2 hybrid authentication scheme that contains both traditional and PQC 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 like the procedures defined in . The approach in this document could be a general framework that for all PQC and traditional algorithms, the combinations of ML-DSA variants and traditional algorithms are considered as instantiations of the general framework. Following two types of setup are covered:

1. Type-1: A single certificate that has composite key as defined in
2. Type-2: Two certificates, one with traditional algorithm key and one with PQC algorithm key

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 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 it could be other key exchanges that involves PQC algorithm since how key exchange is done is transparent to 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)]} ]]>

Announcement Announcement of support hybrid authentication is through SUPPORTED_AUTH_METHODS notification as defined in , which includes a list of acceptable authentication methods announcements. this document defines a hybrid authentication announcements with following format:

Hybrid Authentication Announcement =2) | Auth Method | Cert Link 1 | Alg 1 flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alg 1 Len | | +-+-+-+-+-+-+-+-+ | ~ AlgorithmIdentifier 1 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert Link 2 | Alg 2 flag | Alg 2 Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ AlgorithmIdentifier 2 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert Link 3 | Alg 3 flag | Alg 3 Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ AlgorithmIdentifier N ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]>

The announcement includes a list of N algorithms could be used for hybrid signature

• Auth Method: A new value to be allocated by IANA
• Cert Link N: Links corresponding signature algorithm N with a particular CA. as defined in
• Alg N Flag:
  • C: set to 1 if the algorithm could be used in type-1 setup
  • S: set to 1 if the algorithm could be used in type-2 setup
  • Both C and S MAY be set to 1 but MUST NOT set to zero at the same time
  • RESERVED: set to 0

Algorithm Flag

• AlgorithmIdentifier N: The variable-length ASN.1 object that is encoded using Distinguished Encoding Rules (DER) and identifies the algorithm of a composite signature as defined in .

Sending Announcement As defined in , responder includes SUPPORTED_AUTH_METHODS in IKE_SA_INIT response (and potentially also in IKE_INTERMEDIATE response), while initiator includes the notification in IKE_AUTH request. Sender includes a hybrid authentication announcement in SUPPORTED_AUTH_METHODS, which contains 0 or N composite signature AlgorithmIdentifiers sender accepts, each AlgorithmIdentifier identifies a combination of algorithms:

• a traditional PKI algorithm with corresponding hash algorithm (e.g. id-RSASA-PSS with id-sha256)
• a PQC algorithm (e.g. id-ML-DSA-44)
  • in case of Hash ML-DSA, there is also a pre-hash algorithm (e.g. id-sha256)

In case of type-2 setup, even though the certificate is not composite key certificate, system still uses a composite signature algorithm that corresponds to the combination of two certificates PKI algorithms and hash algorithm(s). C and S bits in flag field are set according to whether sender accepts the algorithm combination in type-1/type-2 setup. Announcement without any AlgorithmIdentifiers signals that there is no particular restrictions on algorithm.

Receiving Announcement If hybrid authentication announcement is received, and receiver chooses to authenticate itself using hybrid authentication, then based on its local policy and certificates, one AlgorithmIdentifier (which identifies a combination of algorithms) in the hybrid authentication announcement and a PKI setup (type-1 or type-2) is chosen to create its AUTH and CERT payload(s). If there is no AlgorithmIdentifier in the announcement, receiver MAY choose AlgorithmIdentifier just base on its local policy and certificates.

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

AUTH payload

For hybrid authentication, the AUTH Method has value 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 , the output is used as Signature Value in the Authentication Data field.

note: in case ML-DSA, only pure signature mode as defined in is used, the PreHash ML-DSA mode MUST NOT be used, see for the rationale. Following is an initiator example:

1. A is id-MLDSA44-RSA2048-PSS, which uses pure signature mode id-ML-DSA-44 and id-RSASSA-PSS with id-sha256
2. Follow with following input:
   • 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 The procedure is same as Type-1, use private key of traditional and PQC certificate accordingly; e.g. in Sign procedure define in , the mldsaSK is the private key of ML-DSA certificate, while tradSK is the private key of traditional certificate. With the example in :

• mldsaSK is the private key of ML-DSA certificate, tradSK is the private key of the RSA certificate
• M is InitiatorSignedOctets
• ctx is "IKEv2-PQT-Hybrid-Auth"

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 SHOULD verify the extension according to , failed verification SHOULD fail authentication.

Security Considerations The security of general PQ/T hybrid authentication is discussed in . This document uses mechanisms defined in , and , 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.

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

References Normative References Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of ML-DSA [FIPS.204] in hybrid with traditional algorithms RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet security best practices and regulatory requirements. Composite ML-DSA is applicable in any application that uses X.509, PKIX, and CMS data structures and protocols that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA. 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. Discussion of this work is encouraged to happen on the IETF PQUIP mailing list pqc@ietf.org or on the GitHub repository which contains the draft: https://github.com/dconnolly/draft-ietf-pquip-hybrid- signature-spectrums National Security Agency National Security Agency National Security Agency This document defines a new 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. 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 FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. 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.

Acknowledgments TODO acknowledge.