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

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 -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:

Type-1: A single certificate that has a composite key as defined in , which contains two component keys: one traditional key + one PQC key.
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)]} ]]>

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.
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.
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 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 announcement 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
- 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 , the responder includes SUPPORTED_AUTH_METHODS in IKE_SA_INIT response (and potentially also in IKE_INTERMEDIATE response), while the initiator includes the notification in IKE_AUTH request. The 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 as specified in :

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

In case of type-2 setup, even though the certificate is not a 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 the 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, the receiver MAY choose AlgorithmIdentifier just according to 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.

There is no change on data to be signed, e.g. InitiatorSignedOctets/ResponderSignedOctets as defined in
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.
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:

A is id-MLDSA44-RSA2048-PSS-SHA256, which uses PQC ML-DSA-44 and traditional RSASSA-PSS with pre-hash function SHA256
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

Combine PQC key and traditional key into composite key using SerializePrivateKey operation as defined in .
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"

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 , 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.

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 Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST 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. Composite ML-DSA is applicable in applications that uses 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 EUF-CMA-level security is acceptable. 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 compatibility, hybrid generality, and simultaneous verification. Related Certificates for Use in Multiple Authentications within a Protocol 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. Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) 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. 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 Module-Lattice-Based Key-Encapsulation Mechanism 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. Post-quantum Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2) Amazon Web Services NIST standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft 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.