Hybrid Post-Quantum and Traditional Authentication for IKEv2

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 16 October 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The advent of quantum computing poses a significant threat to current cryptographic systems. Traditional cryptographic algorithms such as RSA, Diffie-Hellman, DSA, and their elliptic curve variants are vulnerable to quantum attacks. During the transition to post-quantum cryptography (PQC), uncertainty remains regarding the long-term security of both traditional and PQC algorithms. Hybrid approaches allow deployments to mitigate risk during this transition period.¶

Unlike previous migrations between cryptographic algorithms, the decision of when to migrate and which algorithms to adopt is far from straightforward. Even after the migration period, it may be advantageous for an entity's cryptographic identity to incorporate multiple public-key algorithms to enhance security.¶

Cautious implementers may opt to combine cryptographic algorithms such that a successful forgery requires breaking each of the component signature algorithms used in the hybrid construction.¶

This document defines a hybrid authentication mechanism for IKEv2 that combines traditional and post-quantum (PQC) signature algorithms using composite certificates. The security objective of this mechanism is that authentication remains secure as long as at least one of the component signature algorithms in the hybrid construction remains secure against forgery.¶

The mechanism specified in this document provides a general framework for combining PQC and traditional signature algorithms in IKEv2. Although this document primarily describes combinations involving ML-DSA [ML-DSA] variants and traditional algorithms, the framework is not limited to ML-DSA and can accommodate other PQC and traditional signature algorithm combinations.¶

The deployment model specified is:¶

Composite Certificate: A single certificate containing a composite public key and composite signature, as defined in [I-D.ietf-lamps-pq-composite-sigs]. In this model, a single certificate chain and a single AUTH payload are used to provide hybrid authentication assurance.¶

2. 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 [RFC2119] [RFC8174] 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 designed to resist attacks by cryptographically relevant quantum computers (CRQC).¶

Traditional Cryptographic algorithms: Existing asymmetric Cryptographic algorithms could be broken by CRQC, like RSA, ECDSA, etc.¶

3. IKEv2 Key Exchange

When hybrid authentication is used to achieve post-quantum security goals, the key exchange mechanism should provide comparable post-quantum resilience; otherwise, the overall security of the IKE SA will still depend on the traditional key exchange.¶

4. Exchanges

The hybrid authentication exchanges are illustrated in Figure 1, using an ML-KEM key exchange carried in an IKE_SA_INTERMEDIATE exchange as defined in [RFC9242]. The key exchange mechanism is independent of the authentication mechanism defined in this document.¶

Initiator                         Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni -->
                  <--  HDR, SAr1, KEr, Nr, [CERTREQ,]
                                      N(SUPPORTED_AUTH_METHODS)

HDR, SK {INTERMEDIATE KEi, Ni} -->
                  <--  HDR, SK {INTERMEDIATE KEr, Nr}

HDR, SK {IDi, CERT+, [CERTREQ,]
        [IDr,] AUTH, SAi2,
        TSi, TSr,
        N(SUPPORTED_AUTH_METHODS)} -->
                            <--  HDR, SK {IDr, CERT+, [CERTREQ,]
                                      AUTH}
-------------------------------------------------------------------

5. Composite Certificate

This draft extends and complements [PQC-AUTH] which defines how to use Post-Quantum Cryptographic (PQC) signature algorithms (such as ML-DSA and SLH-DSA) in IKEv2 authentication. Both drafts share the same overarching goal:¶

Enable IKEv2 to authenticate peers using PQC signature algorithms, ensuring security against quantum-capable adversaries.¶

Whereas [PQC-AUTH] specifies PQC-only authentication, this draft specifies how to deploy PQC and traditional algorithms together to provide hybrid assurance during the migration phase.¶

Both drafts:¶

• Do not require any changes to IKEv2 base protocol messages.¶

• Rely on the standard IKEv2 AUTH payload format [RFC7296].¶

• Use SUPPORTED_AUTH_METHODS ([RFC9593]). In this case, the IKEv2 peers use the SUPPORTED_AUTH_METHODS notification to advertise supported composite signature algorithms.¶

IKEv2 can use arbitrary signature algorithms as described in [RFC7427], where the "Digital Signature" authentication method replaces older signature authentication methods. Both standalone PQC signature algorithms and composite signature algorithms can be incorporated using the "Signature Algorithm" field in the AUTH payload, as defined in [RFC7427].¶

For composite signatures, a single AlgorithmIdentifier describes a composite public key and a composite signature that combines multiple constituent algorithms (e.g., a traditional and a PQC algorithm) in accordance with [I-D.ietf-lamps-pq-composite-sigs]. This allows a single certificate and AUTH payload to provide hybrid assurance without requiring multiple exchanges.¶

AlgorithmIdentifier ASN.1 objects are used to uniquely identify composite schemes, including the full parameter set for each constituent algorithm. This ensures unambiguous selection and verification of composite signature during authentication.¶

6. IKEv2 Fragmentation

Post-quantum signature algorithms and certificate chains may significantly increase the size of IKE_AUTH messages. Implementations supporting the mechanisms defined in this document MUST support IKEv2 Fragmentation as defined in [RFC7383].¶

7. Negotiation

Note: currently, this section talks mostly about the problems that we'll need to address. Eventually, it'll be updated to talk about the actual mechanism, including the bits-on-the-wire format.¶

To support brown field upgrades, we will need for an IKE device to be able to support negotiating with devices with only conventional (e.g. RSA) certificates, and with devices with composite certificates (e.g. RSA and ML-DSA). In addition, for the network to be entirely post-quantum safe, devices will need to be able to mandate that composite certificates be used. Furthermore, it would be cleaner if the device sent its policy upfront to the peer, rather than letting it try to negotiate and failing.¶

For composite certificates, this is straight-forward. A composite certificate can be listed in the SUPPORTED_AUTH_METHODS list as yet another algorithm. A device can decide to list support for both that and RSA, or it could decide to list only support for composite certificates. The existing mechanism in IKE will cleanly decide which is appropriate. The only remaining issue is one of preference (if we have multiple algorithm OIDs that are acceptable to the peer, which one should we use). This is not a security issue; instead, it is a performance issue (preferring composite would allow us to find performance problems earlier).¶

8. Security Considerations

The hybrid mechanism defined in this document aims to provide authentication security as long as at least one component signature algorithm remains secure against forgery.¶

The security of general PQ/T hybrid authentication is discussed in [RFC9794]. This document relies on mechanisms defined in [I-D.ietf-lamps-pq-composite-sigs], [RFC7427], and [RFC9593], and the security considerations of those specifications need to be taken into account.¶

Traditional signature algorithms such as ECDSA, Ed25519, and Ed448 provide existential unforgeability under chosen-message attack (EUF-CMA), which is sufficient for IKEv2 authentication. When used as the traditional component in a composite construction with ML-DSA, these algorithms contribute to defense-in-depth during the transition to post-quantum cryptography, maintaining IKEv2 authentication security as long as at least one component algorithm remains secure.¶

However, composite signature schemes do not in general preserve strong unforgeability (SUF-CMA) once the traditional component algorithm is broken, for example due to the availability of CRQCs. In such cases, a forged traditional signature component can be combined with a valid post-quantum component to produce a composite signature that verifies successfully, violating SUF. This loss of SUF is inherent to the composite construction and does not impact IKEv2, which relies only on the composite signature verification result.¶

9. IANA Considerations

None.¶

10. References

Acknowledgments

TODO acknowledge.¶

Authors' Addresses