<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.43 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ipsecme-pq-hybrid-auth-01" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.35.0 -->
  <front>
    <title abbrev="IKEv2 Composite Signatures">Use of Composite Signatures in IKEv2</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-ipsecme-pq-hybrid-auth-01"/>
    <author fullname="Tirumaleswar Reddy">
      <organization>Nokia</organization>
      <address>
        <postal>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <country>India</country>
        </postal>
        <email>k.tirumaleswar_reddy@nokia.com</email>
      </address>
    </author>
    <author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
      <organization>Cisco Systems</organization>
      <address>
        <email>sfluhrer@cisco.com</email>
      </address>
    </author>
    <author initials="J." surname="Hu" fullname="Jun HU">
      <organization>Nokia</organization>
      <address>
        <email>jun.hu@nokia.com</email>
      </address>
    </author>
    <author initials="Y." surname="Morioka" fullname="Yasufumi Morioka">
      <organization>NTT</organization>
      <address>
        <email>yasufumi.morioka.dt@nttdocomo.com</email>
      </address>
    </author>
    <author initials="G." surname="Wang" fullname="Guilin Wang">
      <organization>Huawei</organization>
      <address>
        <email>Wang.Guilin@huawei.com</email>
      </address>
    </author>
    <date year="2026" month="November" day="02"/>
    <area>Security</area>
    <workgroup>IP Security Maintenance and Extensions</workgroup>
    <keyword>Post-Quantum</keyword>
    <keyword>Hybrid Authentication</keyword>
    <keyword>IKEv2</keyword>
    <abstract>
      <?line 74?>

<t>A Cryptographically Relevant Quantum Computer (CRQC) can break traditional public-key algorithms (e.g., RSA, ECDSA), which are typically used for authentication in IKEv2. Combining the post-quantum ML-DSA signature algorithm with a traditional signature algorithm provides protection against potential weaknesses or implementation flaws in ML-DSA. This draft defines a hybrid PKI authentication method for IKEv2 using composite certificates that ensures authentication remains secure as long as at least one of the component signature algorithms remains unbroken.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://tireddy2.github.io/ipsecme-pqt-hybrid/draft-ietf-ipsecme-pq-hybrid-auth.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-ipsecme-pq-hybrid-auth/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        IP Security Maintenance and Extensions Working Group mailing list (<eref target="mailto:ipsec@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ipsec/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ipsec/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/tireddy2/ipsecme-pqt-hybrid"/>.</t>
    </note>
  </front>
  <middle>
    <?line 78?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <t>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 <xref target="ML-DSA"/> variants and traditional algorithms, the framework is not limited to ML-DSA and can accommodate other PQC and traditional signature algorithm combinations. PQ/PQ composite signature algorithms (<xref target="RFC9794"/>), once defined, can be used with the mechanism in this document without change.</t>
      <t>The deployment model specified is:</t>
      <t>Composite Certificate:
   A single certificate containing a composite public key and composite signature, as defined in <xref target="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.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

<t>Cryptographically Relevant Quantum Computer (CRQC): A quantum computer that is capable of breaking real-world cryptographic systems.</t>
      <t>Post-Quantum Cryptographic (PQC) algorithms: Asymmetric cryptographic algorithms designed to resist attacks by cryptographically relevant quantum computers (CRQC).</t>
      <t>Traditional Cryptographic algorithms: Existing asymmetric Cryptographic  algorithms could be broken by CRQC, like RSA, ECDSA, etc.</t>
    </section>
    <section anchor="ikev2-key-exchange">
      <name>IKEv2 Key Exchange</name>
      <t>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.</t>
    </section>
    <section anchor="exchanges">
      <name>Exchanges</name>
      <t>The hybrid authentication exchanges are illustrated in <xref target="hybrid-auth-figure"/>, using, as an example, an ML-KEM key exchange carried in an IKE_SA_INTERMEDIATE exchange as defined in <xref target="RFC9242"/>. The key exchange mechanism is independent of the authentication mechanism defined in this document.</t>
      <figure anchor="hybrid-auth-figure">
        <name>Example Hybrid Authentication Exchanges with ML-KEM via IKE_SA_INTERMEDIATE</name>
        <artwork><![CDATA[
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}
-------------------------------------------------------------------
]]></artwork>
      </figure>
    </section>
    <section anchor="composite-certificate">
      <name>Composite Certificate</name>
      <t>This draft extends and complements <xref target="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:</t>
      <t>Enable IKEv2 to authenticate peers using PQC signature algorithms, ensuring security against quantum-capable adversaries.</t>
      <t>Whereas <xref target="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.</t>
      <t>Both drafts:</t>
      <ul spacing="normal">
        <li>
          <t>Do not require any changes to IKEv2 base protocol messages.</t>
        </li>
        <li>
          <t>Rely on the standard IKEv2 AUTH payload format <xref target="RFC7296"/>.</t>
        </li>
        <li>
          <t>Use SUPPORTED_AUTH_METHODS (<xref target="RFC9593"/>). In this case, the IKEv2 peers use the SUPPORTED_AUTH_METHODS notification to advertise supported composite signature algorithms.</t>
        </li>
      </ul>
      <t>IKEv2 can use arbitrary signature algorithms as described in <xref target="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 <xref target="RFC7427"/>.</t>
      <t>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 <xref target="I-D.ietf-lamps-pq-composite-sigs"/>. This allows a single certificate and AUTH payload to provide hybrid assurance without requiring multiple exchanges.</t>
      <t>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.</t>
      <section anchor="composite-certificate-processing">
        <name>Composite Certificate Processing</name>
        <t>Authentication using composite certificates follows the generic digital signature authentication method defined in <xref target="RFC7427"/> and the AUTH computation defined in Section 2.15 of <xref target="RFC7296"/>. If one or more IKE_SA_INTERMEDIATE exchanges occurred, the signed octets are constructed as specified in <xref target="RFC9242"/>.</t>
        <t>The end-entity certificate <bcp14>MUST</bcp14> contain a composite public key as defined in <xref target="I-D.ietf-lamps-pq-composite-sigs"/>. The composite signature algorithm used in the AUTH payload <bcp14>MUST</bcp14> correspond to the composite public key algorithm in the certificate. A mismatch between the AUTH signature algorithm and the certificate public key algorithm <bcp14>MUST</bcp14> cause the IKE_SA negotiation to fail.</t>
        <t>Signature generation and verification are performed using the composite signature scheme as defined in <xref target="I-D.ietf-lamps-pq-composite-sigs"/>. Any internal hashing or message preprocessing is performed as specified by that document.</t>
      </section>
    </section>
    <section anchor="ikev2-fragmentation">
      <name>IKEv2 Fragmentation</name>
      <t>Post-quantum signature algorithms and certificate chains may significantly increase the size of IKE_AUTH messages. Implementations supporting the mechanisms defined in this document <bcp14>MUST</bcp14> support IKEv2 Fragmentation as defined in <xref target="RFC7383"/>.</t>
    </section>
    <section anchor="negotiation">
      <name>Negotiation</name>
      <t>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.</t>
      <t>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.</t>
      <t>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).</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>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.</t>
      <t>The security of general PQ/T hybrid authentication is discussed in <xref target="RFC9794"/>. This document relies on mechanisms defined in <xref target="I-D.ietf-lamps-pq-composite-sigs"/>, <xref target="RFC7427"/>, and <xref target="RFC9593"/>, and the security considerations of those specifications need to be taken into account.</t>
      <section anchor="euf-cma-and-suf-cma">
        <name>EUF-CMA and SUF-CMA</name>
        <t>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.</t>
        <t>However, a composite signature is strongly unforgeable (SUF-CMA) only if every one of its component signature algorithms is. Ed25519 and Ed448 are strongly unforgeable, but ECDSA is not. The composite schemes that use ECDSA therefore do not provide SUF-CMA even today. Once CRQCs are available, the traditional component algorithms are no longer secure, so none of the composite schemes, other than those that use RSA-PKCS#1 v1.5, will provide SUF-CMA. This exception arises because for a given key and message the PKCS#1 v1.5 signature is unique.</t>
        <t>This does not impact IKEv2, which requires only EUF-CMA security from its signature schemes. This is sufficient because the octets signed in the AUTH payload are unique to each IKE SA: they include the peer's IKE_SA_INIT message and both nonces (Section 2.15 of <xref target="RFC7296"/>). Impersonating a peer therefore requires forging a signature over the signed octets of a new IKE SA, which is exactly what EUF-CMA prevents. Losing SUF-CMA only lets an attacker produce a different valid signature over octets that have already been signed. Such a signature cannot be reused in another IKE SA and so provides no advantage in IKEv2.</t>
        <t>Composite ML-DSA can therefore continue to be used after CRQCs arrive. Migration to pure post-quantum authentication <xref target="PQC-AUTH"/> is a deployment choice, not a security requirement.</t>
      </section>
      <section anchor="key-reuse">
        <name>Key Reuse</name>
        <t>The key reuse requirements in Section 3.1 of <xref target="I-D.ietf-lamps-pq-composite-sigs"/> apply. The component keys of a composite key <bcp14>MUST NOT</bcp14> be reused in other composite keys, in other contexts, or as standalone keys.</t>
      </section>
      <section anchor="downgrade-considerations">
        <name>Downgrade Considerations</name>
        <t>The AUTH computation in IKEv2 signs the IKE_SA_INIT exchange as specified in Section 2.15 of <xref target="RFC7296"/>. Therefore, negotiation signals exchanged during IKE_SA_INIT (such as <tt>SUPPORTED_AUTH_METHODS</tt> <xref target="RFC9593"/>) are cryptographically bound to the authentication exchange and cannot be modified by an active attacker without causing authentication failure.</t>
        <t>If hybrid authentication is required by local policy, implementations <bcp14>MUST</bcp14> enforce that the negotiated authentication method satisfies that policy.</t>
        <t>Specifically, if composite authentication is required, receipt of a non-composite certificate or non-composite signature algorithm during IKE_AUTH <bcp14>MUST</bcp14> cause the IKE_SA negotiation to fail. This applies to stand-alone PQC algorithms as well as traditional ones. A peer that accepts both composite ML-DSA and stand-alone ML-DSA can be downgraded to stand-alone ML-DSA, leaving authentication dependent on ML-DSA alone and removing the protection the composite provides.</t>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>None.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="I-D.ietf-lamps-pq-composite-sigs">
          <front>
            <title>Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure</title>
            <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
              <organization>Entrust Limited</organization>
            </author>
            <author fullname="John Gray" initials="J." surname="Gray">
              <organization>Entrust Limited</organization>
            </author>
            <author fullname="Massimiliano Pala" initials="M." surname="Pala">
              <organization>OpenCA Labs</organization>
            </author>
            <author fullname="Jan Klaußner" initials="J." surname="Klaußner">
              <organization>Bundesdruckerei GmbH</organization>
            </author>
            <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
              <organization>Cisco Systems</organization>
            </author>
            <date day="21" month="April" year="2026"/>
            <abstract>
              <t>   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.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pq-composite-sigs-19"/>
        </reference>
        <reference anchor="RFC7296">
          <front>
            <title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
            <author fullname="C. Kaufman" initials="C." surname="Kaufman"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="Y. Nir" initials="Y." surname="Nir"/>
            <author fullname="P. Eronen" initials="P." surname="Eronen"/>
            <author fullname="T. Kivinen" initials="T." surname="Kivinen"/>
            <date month="October" year="2014"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="79"/>
          <seriesInfo name="RFC" value="7296"/>
          <seriesInfo name="DOI" value="10.17487/RFC7296"/>
        </reference>
        <reference anchor="RFC7427">
          <front>
            <title>Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)</title>
            <author fullname="T. Kivinen" initials="T." surname="Kivinen"/>
            <author fullname="J. Snyder" initials="J." surname="Snyder"/>
            <date month="January" year="2015"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7427"/>
          <seriesInfo name="DOI" value="10.17487/RFC7427"/>
        </reference>
        <reference anchor="RFC9593">
          <front>
            <title>Announcing Supported Authentication Methods in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
            <author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
            <date month="July" year="2024"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9593"/>
          <seriesInfo name="DOI" value="10.17487/RFC9593"/>
        </reference>
        <reference anchor="RFC9242">
          <front>
            <title>Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
            <author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
            <date month="May" year="2022"/>
            <abstract>
              <t>This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment. The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9242"/>
          <seriesInfo name="DOI" value="10.17487/RFC9242"/>
        </reference>
        <reference anchor="RFC7383">
          <front>
            <title>Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation</title>
            <author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
            <date month="November" year="2014"/>
            <abstract>
              <t>This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7383"/>
          <seriesInfo name="DOI" value="10.17487/RFC7383"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="PQC-AUTH">
          <front>
            <title>Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC</title>
            <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
              <organization>Nokia</organization>
            </author>
            <author fullname="Valery Smyslov" initials="V." surname="Smyslov">
              <organization>ELVIS-PLUS</organization>
            </author>
            <author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
              <organization>Cisco Systems</organization>
            </author>
            <date day="20" month="August" year="2026"/>
            <abstract>
              <t>   Signature-based authentication methods are utilized in the Internet
   Key Exchange Version 2 (IKEv2).  The current version of the IKEv2
   protocol, specified in RFC 7296, supports traditional digital
   signatures.

   This document specifies a generic mechanism for integrating post-
   quantum cryptographic (PQC) digital signature algorithms into the
   IKEv2 protocol.  The approach allows for seamless inclusion of any
   PQC signature scheme within the existing authentication framework of
   IKEv2.  Additionally, it outlines how Module-Lattice-Based Digital
   Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH-
   DSA), can be employed as authentication methods within the IKEv2
   protocol, as they have been standardized by US NIST.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ipsecme-ikev2-pqc-auth-12"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="ML-DSA" target="https://doi.org/10.6028/NIST.FIPS.204">
          <front>
            <title>Module-Lattice-Based Digital Signature Standard</title>
            <author>
              <organization/>
            </author>
            <date year="2024" month="August"/>
          </front>
          <seriesInfo name="NIST" value="FIPS 204"/>
        </reference>
        <reference anchor="RFC9794">
          <front>
            <title>Terminology for Post-Quantum Traditional Hybrid Schemes</title>
            <author fullname="F. Driscoll" initials="F." surname="Driscoll"/>
            <author fullname="M. Parsons" initials="M." surname="Parsons"/>
            <author fullname="B. Hale" initials="B." surname="Hale"/>
            <date month="June" year="2025"/>
            <abstract>
              <t>One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9794"/>
          <seriesInfo name="DOI" value="10.17487/RFC9794"/>
        </reference>
      </references>
    </references>
    <?line 234?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA7Vb7XIbN7L9P0+BlX/EypKjSLHXtjbJhpHoSGvrIyJdqVQq
lQVnQBKr4QwzmCHNdSnPss+yT3ZPN4D5IIeys/deV9mmhhigu9F9+nQD6vf7
QaGLRJ2Kg3dGiWwqzrLFMjO6UGKkZ6ksylwZoVNx+Wa4OjkI5GSSqxWG88+d
ow+CSBZqluWbU2GKOAjiLErlAmvEuZwWfa2KaV8vjYoWqr/8rT/fTHId92VZ
zPsJ3jRFYMrJQhujs7TYLPHi5XD8WognQiYmw9o6jdVS4Z+0OOiJAxXrIsu1
TOiHy8F3+C/L8elu/PogSMvFROWnQYyZT4MoS41KTWlORZGXKoAmXwYyVxKz
jlRU5rrYHATrLL+f5Vm5JD1vhf9CXEmdFiqVaaSETGMxfI+fSErofK82eC0+
DURf3Gam6P9QyrQoF/TzBWsoBtAQImuYB+/QF2zEYKXSErIJ8UfXFMKa5+BH
CKzTmfieJqDnC6kTMhRZ+VsyeJjlM/pC5tEcX8yLYmlOj45oHD3SKxX6YUf0
4GiSZ2ujjniGI3pzpot5OcG7hc5VHG9Ojuo9LNwm0ji7hY01/PjQzhDqrOPN
o4/6RjgvFslBENDnLCc7YzEhpmWSWO8a67xcyESZtczFHS3JA6CRTPW/2Oan
4jq715KfR7DuqfhOpjOZZLniZ7ma8ag3Moczy3s3MivTgrz5Mo3dy8oZ+D4s
Gqv+yop+m9IaYZQtDryQOoXDjULxOinnucr5mRV6FGVF0XoOeU/FmTZRJkYb
U6iFaa5opnbotxGNoEXIj+pF/h6Ki7Ix/9/LVFy8qyeu9XcT/rNMw3lZy9ye
7qdQXCG0MmcJO+dP0pTTcqFbX/Hs4no8bk6+cSPDhR0ZxsW3aVEAELKFF75e
7PtQ/IjtaKz0fakTYE/1lBe5KOVa6eYyPCC0g7+d89c8eZBm+QIbv+Louuyf
s48DZBZLQ94VefTqGz0zNObu9dmLk1d/8R+fnbxwH189f/Wl/3jy7MQP+PIl
ngY6ndYL4Zurt/3z0eCURXTwepXFZaL6b2WB+Ff976RRsTjXCAmZ1NgpRgVi
XOYxv8qQBdSYlaYQJ1+cPOOnRuVaGVrSLgCjX47Gp+L15e0Io+ygQuYzhSD0
MRhnmkP7+IvwL1+cvDyiV0J6I7RvkFovXj2D9EG/3xdyYopcRkUQDMRZvlkW
2SyXyzmQK0k2iK1ErQBuwkEcZ4GyULl4enb3w9mhiGQqkCbkPUBWApwRU9By
WU4SHfUBlMBxpAegwcKIpyqchT1xNxr0xPAMZjvsiTVWmgOqFOGbW7Qkg8HM
QrZQtEpNIUkx0SnBIAaIJWHwb05AuyHCVHauBBBr/CtkS9CuYcs8W+kYqRAf
ChXx0nIGbMbWLPEEAuHNNXROlTEYB0n1YpmoBb6ykk4TueZUaqUJxXiujc2J
IlZTjRchiEU8cfvmclvThQLwWRvY5FsaUrZyYhGpvNBTGo6ZirksBKU6yt9b
M+UUN6mBK0WspRFJhpnwP95JlIROWcpsgCzJC6R4vcswppqsTJEy7lUaWhda
6DhOVBA8AWoWObyfbRYEY8wo4xVNh/n9BkXsQaQOdGE70FqsDAYWQDxIVmQC
8ub0atR0SmEsTsKijV1sD2kIbEpyLmNd7lxPp1r1L1SSLGSKn+kh5VlornOB
x3oJu9HCKyVWEjQjLQz75qpMUpXLSaJIMq8JAlxG95DlHPnb+SKcCymbTY+R
Lc9sSLkRT28RPT1YknaS8v6msi4yE2DBT0jb1UfALewWEk+AMScZXLnpyKQH
pmwoH3ouIpdwZBnNydZJkq3hgcsk25C3GhJygTlmcCSRa3MvYq8LHLahzBJQ
lMXY8Hdpou8Rc6CGOisN3oZGNMSIiSrWSqV7t6PHCsUK+YymhBpruKoVgSax
rMchQr2J+F7G2bIQkGiKfD/NMxgDsunZvECIIBvHoRjCzwTiC9BEq1RiOcl7
QhegShsIST6JHZEzRfIzzqSCQqbYfGa2hNex/YKE0GmU5cuMBV2USaER8nuQ
DqNVOmci53cNpjtDbLLNKrRQuWGhSDtyeYY19RF/5nCX9DkC/oAUkQ4zlZMH
/VZqAgFGZNpGhX3/xOBm1AVk0VCHTEShwZ05nEOKZwKxLCpJ9F0c28GwCBbQ
ZtGAMRbdaWl2/LcVLRwg+yTdD4YEtaoRKpN/EoKvHMJB/los7ZDz/xMx99tz
Zx2XYdxehhY+a2nNEnED/HJ71NyJKmFJMVOEU/CIHKSKahs2flSlS4YIgrzH
c6Bp5NpBglxUzuY7i+oFIBLpGitHuZ5gfbuOQwOdrrJkRYu6lPzhg/3w8NAA
1y1ZtsGi1gNrpxk2QAOuYAREi5uWpiAWIiMsv8iISQmgI3DgE5VtiR3iraPb
Hxre1Wmepx8+OB718AAYzyjSbUAAaZgTKRtQzDmK1k7u7B+NyUoEBgbMlNv5
GqQFlFJJ0wHAX4O6HD+r3Z9pIpGfdJa04oJcj9IMbYdsKGfhSzB8kR13te6R
5zvVSPQPHz5Grh8eQhABF20keo9z/K5IcwjEy1ZfD96NL8RSbpJMxpx42YaU
SK2L74EaacB9CG1hO7CQsywl0sFeSNOfk/TsAMbaltSlCt6Ig6t3ozH1Euh/
cX3Dn++GP7y7vBue0+fRxeDt2+pD4EaMLm7evT2vP9Vvnt1cXQ2vz+3LeCpa
j4KDq8FPB5Z1HNzcji9vrgdvD3Y9gvlwRk5EHYEcyZZ8XprAxxpvxXdnt//5
9/EzbMmf4Iwnx8evEFr2h5fHL+CZnF/talmKSLU/wnSbAKRAIZfSBiQgUHJJ
1YnhzTbzbJ0KBBCZ8/OfyTK/nIqvJtHy+Nk37gEp3HrobdZ6yDbbfbLzsjVi
x6OOZSprtp5vWbot7+Cn1s/e7o2HX/0tobzbP375t2/gQn+8DkLttkVwmYdI
Ji2wLlNH4m0+MeP/pA8fTOI9BDcImq2ldmnmkmONR1jebBaoGnLir/vYA5wH
UW0DCixBI9s4Cismm/ZrrHTuld7WzDitCaoa2Hq2Z+FTMXyPxRh7ajHbo5ty
RlkJs8D5bZVBwtFyPcHMsy4fe0IVUch1B7OLNwjr4XuLokHwI3HLbrzQpgIW
8COtVls1ZEUfZhkHReEwQ7nJm2l5zsJ6fCILSVsotGYkcydaAaL+apPTWhtl
J85WlLGTFr2n59BJIL2tNX1X0L+2Eyqy1FcaleWbwrFBvBkc4HWbwb9haxys
UBKrLjzON5u1Uz1DLnh46FnyxThBrPm9JCpLEEPp+M3wqm2nSOa5oyySCcWv
o8Gvl9fj4d3V8PxyMB7WQ7ezjOu+UDIZ7ze/Jp5RdYi96fYy0cYKLcCFzX7/
/ffgkrKELMCY9v25UwZ0L1Y5Fb7/2z/BxfldD3usj3vizVD3xLUW/f43we6y
X6HKFm50zqNzjMbfn8+Gd2Ngb++Xjre6/lw/Hb27vb25Gw/Pf6Vs++vVcHxx
cz46DJw0b8SH1gY5wR4+LtnumyzkQ3Pmc0xGIv+5U/SfL8/z3i/MAtguJ73q
q/EIb45Hef1kryb7RN0rNBZ9RKjH/9DKD/8nzkAO+OFUPNkNO9tY/PpgaKOt
+4yhDnnLOV04rrTsiruDB8eUOkikL/S4W6XoDCI2FTu0dashmoEc1Cf1v64I
oe/mA6ZXJyCGEWvBPIRqel8xgl8Q9AKCxUdzXDf79n2dRgkwentBnw+rymUL
BULxHfVMWCviOEyxqFREgWExmM5GkKII88GvhymjuKtbs+ZswHZFSdDWoVRl
dEnZsy05GlJBuy/yXFroe2ZAXbLcSOr2hpy5QA/Ixt7EMKGn/4YW7DOdayvY
c5DG21aPdsa25URnSdTqW8wUl04dlNtz7LpD1OqyzKWh1NMwMoz4uTjPuGxz
nQmsvRHeTbGGte4Er3KzNYuyBGhtjJyRIT4n2rXx+c64frl7qVUq2J68zRrU
1EfWwNt0zNmNEb5+e/7qS9RvdbkSSZ+V7SJ+n62r7JkL+tnIcU0/3swC+V2Y
crnMckqoj5eTsJtdjypHWk3mE40tyjfd/s+5slEIWL2fnbygBL0m72F5D3YO
HQ72NJpzeIeMqJWdILc1F+0ablws2R1JqBuyLwj2VZUtumfL5UZ7LXahxUrU
JyYD/86BgGsnVbeq6Qq75eqfKtvAzK9tN2RbHNMoUatVLrn3h5XyRovjkeJZ
dirabnlVfUNuBemi5Gpv54hE7vTGZLu7yzBHHY885phkyP+00pzBnRvBprsu
p+Va0fUYGPjehQ1w2rRKxYpewu5dRh2MrsNj16EzrWq/TPVvJYW+bb9ON03L
RnOkIGwY/CUpqzY5nQ0Lot5wUfJgxZ002//stLUzhD82KVOJLZqV1J41qHvc
sQ9MgWCuwxsEs2uTHSRuZRxk2D0pVtzmGTVv8RJs046xR496ppndOFKZe33w
v9hF+Ueidode26DwJyB2y22FZ19rjB85e5yEx8/JBk2gFZdT2xDNxSLL1aMs
HwAT8blObFHW1aNZVCjnAlWLlPsd7a5nsyiwdQ2oSd816JsezB0K1/HaG7H/
RVdr7Bu++8Cs1URvxZATCapzAUFeXrRma4pWTedmaugWigGyrkG2g2P7A5dq
tS6R/P42DdS5mBVR+mxn91GkapZRUeSS21TqBMavQdl2nLujhTZ0qXLKzi1M
77Khjev/alsGIBXcJyOwBA9hGkfuaJkEnVUtq3ijkrGWqeVik41F60ZV6FsL
r3M5q453XWum6hbszXvbzU572NM47iSISyMie46M6n9xm4hszxtakSFx2Tph
Np5bVEzM17hmb5FrN9i916VXVw1O1x443J6I69oTguA6owsL7ow22TjyaRxO
AI7uqflrSEM5oQTBB/V5Bra7cOcua/UZMDtVrhETx4gN5Ao6yCtKakDRmR0N
oV76Mpau7U9zN+aUEQ2u9d9ODCBSBnS5j8/9NVFQyxUJQLLKGHQDKnWkolyC
08aUYdbKdl9YRHdOSF2ZWK105Bu0/lDYT1XFC9bnrGxHu6qMeXtU9achOGd8
amodtpDedm13J9iTF6pZ+DVbFh2GAXgt7KpteUAakEVSoAadqFj5SZCccm27
AyanIML1yo2Naui8IP5X1BynSzJ3EBIGr8ucSgvKEXwYu/ZdvihREhgi9NSd
D7N1DXks9g5yAao22JZpnqWFB05i5j0B4JnbRmsqElWw0TF1kfOBrd8KS2kI
ufD9DglsW53dmDzZnS/3qwPmQfc7nr4m2hQ19u8pFRLuuRqxAT2RqT2lqhlJ
MPDK05x0Th6zmfkt71+0i/b0n88uoRg3ROkOSuE6p1tvss81X99zcmozqu/U
ts6ryOvZCXiv+MyPl7B1PfFJumOwzMnYdh5e1B5xWtA1paKB7ugUkDxFmUIM
8in2HZE2l6vGsXqdlW4uz/05LSFsFKll4f2vdgQrCE3uGrJrdrvD0PYy3OGh
rCtxFuivdBmtUNLeDiA1fGpgbmuFfmplzduszHqvvU9Rci0L3Ixbr1dop2Se
gPAeMopWtz3PgOKwobs80erTfrxhKaS21ww8Md+ifHXHYc/x9aPn1p92Nt1s
WPtz59sfjsb7m+6xNlFpTJPN8Qmqvx/llQMeUeui2br9w7Sg166KKVAaNX91
8afWImrth20lZ1TEW34QuecNGCwknU6AeWRcipWWMTwRw3ev+2dXri1lP7cP
SjoZg+9puaONYXzy/PnxKyvoMH727GW11xyj7hpamfKmyAnADUqU1JsG2YDg
ad/zH3vII546uapbdwRz5RSqaTJ6fUtju3HGJynMbKXZOXqoHWmLa7cuO/iW
JKuGKUy7AwBgR3ldFsq2qqaoylRfp/0YwT5vNpw+8XpVj25FVwfeXVr9kQjZ
FxfY7YtsrVYEQN3Fv00kmJ1uNfqdAnY9dW5xaHESCEizbDw6Utr72MUSUELn
Ig0PIYjsWrAnYFzrWQ4Ld4oZW1ZbpKUSwA6mDKWmVNbFtpHnfdApQHLTVsRy
E4obQj06qbOlnFzRjXNefb/TNCkz3kkz3gyu4CO+fWBo3a37Nu1GQFZzABux
lQ7IjP3bN2ejJ8didRw+79kctqWCbwS8p8xiqxZtmLjYWoiJn5hpUtS3enxk
kUSNBdo7b7sY9b0pZZOQXizBWa1T+kisLm6xO3j8qFyUb7yRU2yXS8YJ345k
LzmfLtrS2hXaXZUpN15YVL62Rg0Te/R4yjcFHJ1WVbL9zNQl/uW4MgWZhXlJ
SpdhwEgf6RkccjmjcpOllihLnrnhbZVByIXtiFp36tZ3tA+whgQ8r534DZRT
72Fxvv8Ax/DWpRuMdJQRircZF4bepXkPEm5IpA47sd6SL7ZCT2SxKXOXQqxk
gjy3JZiThp2QSY1MUODFdPMQHmRFDsWI0b7xLigfeceEdPddBE8R3VEwmdhk
9XWvNKuvMtYXtppXg9z5SMSh4W1LaKvT0hcwFtj54qSP3Zx+R0RcVc19glqS
sYW3W3jaOqxgKtW4wYSEBFrb2yZhbpd9rf2ET/DvSP36ng5boznSNBtSX1IH
cfpJhIA4arJp4B7jD5ZwnlMjCy3rL7m0N8RuR2skdyKrL9JCvS8M03FqLdQN
chppdTxHqckVZicD3OnCVcdZ5Cqm0Zmx4dc8P281yx5t2Y29M/Ra/R32xsRU
k8Y+9TZXrA7f/tFd5PyjybMObVNv52oJyve6CbbnWoK/2efCYpHFVZuGr/vx
tc4qPqtLdNL2mbYmperPpuzL6X6C6tyM10iyiH6TgavP3tYFf2P9Q1GGjVzC
saW1qzg7bsNyD9bgJ8PncvyOnZ36aZ5k2rZHs8u8X0rUvypSelk46MvSfneJ
Cm9sf9nF+RtbzU746e1Ad6SA8NL2WI/9vl+fDLWPrtYKSVi2r/9ipKES26UB
qva40jM2p0TbiMZQ2FilAXQT4iouxOJtaTwFBc1bdXhJ4yZJWi3FL9KCwJ9s
Vf3SSf3LIVuNXAfPtns4uB7sxPk1JnS/OjGB89K4QXSfZutExdyNM8GHU/vL
jCr++mCKkFR0YD++Ob+BXfxIzPE/+mgT7dU5AAA=

-->

</rfc>
