Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2)

Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2) Nokia

United States of America jun.hu@nokia.com

NTT DOCOMO, INC.

Japan yasufumi.morioka.dt@nttdocomo.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 cryptograph algorithms: e.g RSA, ECDSA; which are widely deployed authentication options of IKEv2. There are new Post-Quantum Cryptograph (PQC) algorithms for digital signature like NIST , however it takes time for new cryptograph 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 .

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 cryptograph algorithms: e.g RSA, ECDSA; which are widely deployed authentication options of IKEv2. New Post-Quantum Cryptograph (PQC) algorithms for digital signature were recently published like NIST , however consider 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 announce 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 . Following two types of setup are covered:

Type-1: A single certificate that has composite key as defined in
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 Cryptograph (PQC) algorithms: Asymmetric cryptograph algorithms are thought to be secure against CRQC. Traditional Cryptograph algorithms: Existing asymmetric cryptograph 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 include PQC algorithm via multiple key exchange process as defined in .

Exchanges The hybrid authentication exchanges is illustrated in an example depicted in , the key exchange uses PPK, 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:

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
- C and S MUST NOT be 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 include SUPPORTED_AUTH_METHODS in IKE_SA_INIT response (and potentially also in IKE_INTERMEDIATE response), while initiator include the notification in IKE_AUTH request. Sender include 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 accept 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 choose to authenticate itself using hybrid authentication, then based on its local policy and certificates, one AlgorithmIdentifier (which identify a combination of algorithms) in the hybrid authentication announcement and a PKI setup (type-1 or type-2) are chosen to create its AUTH and CERT payload(s).

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.

There is no change on data to be signed, e.g. InitiatorSignedOctets/ResponderSignedOctets as defined in
Follow Sign operation identified by A, e.g. or ; the ctx input is the string of "IKEv2-PQT-Hybrid-Auth".

Following is an initiator example:

A is id-HashMLDSA44-RSA2048-PSS-SHA256, which uses Hash ML-DSA-44
Follow with following input:
- sk is the private key of the signing composite key certificate
- M is InitiatorSignedOctets
- ctx is "IKEv2-PQT-Hybrid-Auth"
- PH is SHA256

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"
PH is SHA256

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.

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 Composite ML-DSA For use in X.509 Public Key Infrastructure and CMS Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of ML-DSA [FIPS.204] in hybrid with traditional algorithms RSA-PKCS#1v1.5, RSA-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. Hybrid signature spectrums 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 compatiblity, 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 Related Certificates for Use in Multiple Authentications within a Protocol 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. 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. Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) 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. Announcing Supported Authentication Methods in the Internet Key Exchange Protocol Version 2 (IKEv2) 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. Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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 Module-Lattice-Based Digital Signature Standard Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security 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. Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) 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.