<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC9242 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9242.xml"> nbsp    "&#160;">
  <!ENTITY I-D.tjhai-ikev2-beyond-64k-limit SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.tjhai-ikev2-beyond-64k-limit.xml"> zwsp   "&#8203;">
  <!ENTITY I-D.ietf-ipsecme-g-ikev2 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ipsecme-g-ikev2.xml"> nbhy   "&#8209;">
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5723 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5723.xml">
<!ENTITY RFC6023 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6023.xml">
<!ENTITY RFC7296 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml">
<!ENTITY RFC7383 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7383.xml">
<!ENTITY RFC8019 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8019.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8784 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8784.xml"> wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-ipsecme-ikev2-multiple-ke-12" updates="7296" number="9370" submissionType="IETF" category="std" ipr="*trust200902" consensus="true"><?rfc compact="yes"?>
	<?rfc text-list-symbols="ooo*-o+"?>
	<?rfc subcompact="no"?>
	<?rfc sortrefs="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
	<?rfc toc="yes"?> consensus="true" ipr="trust200902" obsoletes="" updates="7296" xml:lang="en" sortRefs="true" symRefs="true"
tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.15.3 -->
  <front>

    <title abbrev="Multiple Key Exchanges in IKEv2">Multiple Key Exchanges in IKEv2</title> the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
    <seriesInfo name="RFC" value="9370"/>
    <author fullname="C. fullname="CJ. Tjhai" initials="C." initials="CJ." surname="Tjhai">
      <organization>Post-Quantum</organization>
	<address><postal><street></street>
      <address>
        <postal>
          <street/>
        </postal>
        <email>cjt@post-quantum.com</email>
      </address>
    </author>
    <author fullname="M. fullname="Martin Tomlinson" initials="M." surname="Tomlinson">
      <organization>Post-Quantum</organization>
	<address><postal><street></street>
      <address>
        <postal>
          <street/>
        </postal>
        <email>mt@post-quantum.com</email>
      </address>
    </author>
    <author fullname="G. fullname="Graham Bartlett" initials="G." surname="Bartlett">
      <organization>Quantum Secret</organization>
	<address><postal><street></street>
      <address>
        <postal>
          <street/>
        </postal>
        <email>graham.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="S. fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
      <organization>Cisco Systems</organization>
	<address><postal><street></street>
      <address>
        <postal>
          <street/>
        </postal>
        <email>sfluhrer@cisco.com</email>
      </address>
    </author>
    <author fullname="D. fullname="Daniel Van Geest" initials="D." surname="Van Geest">
      <organization>ISARA Corporation</organization>
	<address><postal><street></street>
      <address>
        <postal>
          <street/>
        </postal>
	<email>daniel.vangeest@isara.com</email>
        <email>daniel.vangeest.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="O. fullname="Oscar Garcia-Morchon" initials="O." surname="Garcia-Morchon">
      <organization>Philips</organization>
	<address><postal><street></street>
      <address>
        <postal>
          <street/>
        </postal>
        <email>oscar.garcia-morchon@philips.com</email>
      </address>
    </author>
    <author fullname="Valery Smyslov" initials="V." surname="Smyslov">
      <organization>ELVIS-PLUS</organization>
    <address><postal><street></street>
      <address>
        <postal>
          <street/>
        </postal>
        <email>svan@elvis.ru</email>
      </address>
    </author>

    <date/>
	<workgroup>Internet Engineering Task Force (IETF)</workgroup>
    <date year="2023" month="May" />

     <area>sec</area>
     <workgroup>ipsecme</workgroup>
     <keyword>post-quantum</keyword>
     <keyword>PQC</keyword>
     <keyword>hybrid</keyword>
     <keyword>hybridization</keyword>
     <keyword>hybrid key exchange</keyword>
     <keyword>key encapsulation</keyword>
     <keyword>quantum</keyword>
     <keyword>quantum-safe</keyword>
     <keyword>KEM</keyword>
     <keyword>PQ</keyword>

     <abstract>
        <t> This

<t>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.
	</t>

        <t> The primary application of this feature in IKEv2 is the ability to perform one or more
        post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman (EC)DH key exchange,
        so that the resulting shared key is resistant against quantum computer attacks.
	    Since there is currently no post-quantum key exchange that is as well-studied as (EC)DH,
        performing multiple key exchanges with different post-quantum algorithms along
        with the well-established classical key exchange algorithms addresses this concern, since the
        overall security is at least as strong as each individual primitive.
	</t>

        <t> Another possible application for this extension is the ability to combine several key exchanges
        in situations when no single key exchange algorithm is trusted by both initiator and responder.
        </t>

	<t> This setup.</t>

  <t>This document utilizes the IKE_INTERMEDIATE exchange, by means of which where multiple key exchanges are performed when an IKE SA is being
  established.  It also introduces a new IKEv2 exchange exchange,
  IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA
  is up (during rekeys being rekeyed or is creating additional Child SAs).
	</t>

        <t> This SAs.</t>

  <t>This document updates RFC7296 RFC 7296 by renaming a transform type 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 Transform Type from "Transform Type 4 - Diffie-Hellman 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.
        </t> IKEv2.</t>

     </abstract>
  </front>
  <middle>
    <section title="Introduction" > numbered="true" toc="default">
      <name>Introduction</name>
      <section title="Problem Description" ><t> numbered="true" toc="default">
        <name>Problem Description</name>

    <t>The Internet Key Exchange Protocol (IKEv2) version 2 (IKEv2), as specified in <xref target="RFC7296"/> target="RFC7296" format="default"/>, uses
  the Diffie-Hellman (DH) or the Elliptic Curve Diffie-Hellman (ECDH)
  algorithm, which shall be referred to as (EC)DH "(EC)DH" collectively, to
  establish a shared secret between an initiator and a responder.  The
  security of the (EC)DH algorithms relies on the difficulty to solve a
  discrete logarithm problem in multiplicative (and respectively (and, respectively,
  elliptic curve) groups when the order of the group parameter is large
  enough.  While solving such a problem remains infeasible with current
  computing power, it is believed that general purpose general-purpose quantum
  computers will be able to solve this problem, implying that the
  security of IKEv2 is compromised.  There are, however, a number of
  cryptosystems that are conjectured to be resistant against quantum computer attack. to quantum-computer attacks.  This family of cryptosystems is known as post-quantum cryptography (PQC). "post-quantum cryptography" (or "PQC").  It is sometimes also referred to as quantum-safe cryptography (QSC)
  "quantum-safe cryptography" (or "QSC") or
			quantum-resistant cryptography (QRC). "quantum-resistant cryptography"
  (or "QRC").</t>

  <t>It is essential to have the ability to perform one or more post-quantum key exchanges in conjunction with an (EC)DH key exchange so that the resulting
  shared key is resistant to quantum-computer attacks.   Since there is currently no post-quantum key exchange that
  is as well-studied as (EC)DH, performing multiple key exchanges with
  different post-quantum algorithms along with the well-established
  classical key-exchange algorithms addresses this concern, since the
  overall security is at least as strong as each individual primitive. </t>
      </section>
      <section title="Proposed Extension" >
            <t>
			This numbered="true" toc="default">
        <name>Proposed Extension</name>
        <t>This document describes a method to perform multiple successive key
        exchanges in IKEv2. It This method allows integration of PQC in IKEv2,
        while maintaining backwards backward compatibility, to derive a set of IKE keys
        that is resistant to quantum computer quantum-computer attacks.  This extension allows
        the negotiation of one or more PQC algorithm algorithms to exchange data, in
        addition to the existing (EC)DH key exchange data.  It is believed
        that the feature of using more than one post-quantum algorithms algorithm is important
        important, as many of these algorithms are relatively new new, and there may
        be a need to hedge the security risk with multiple key exchange data
        from several distinct PQC algorithms.
        </t>

        <t>IKE peers perform multiple successive key exchanges to establish
            an IKE Security Association (SA). SA.  Each exchange produces a piece of secret some shared secret, and
            these secrets are combined in a way such that:
        </t>
        <ol type="(%c)">
          <li>the final shared secret is computed from all of the component
          key exchange
            secret;</li>
            <li>the shared secret as specified in <xref target="RFC7296"/> is obtained
            unless secrets;</li>
          <li>unless both peers support and agree to use the additional key
       exchanges introduced in this specification; specification, the final shared
       secret equivalent to the shared secret specified in <xref target="RFC7296"
          format="default"/> is obtained; and</li>
          <li>if any part of the component key exchange method is a post-quantum
          algorithm, the final shared secret is post-quantum secure.</li>
        </ol>
            </t>

            <t>
			Some
        <t>Some post-quantum key exchange payloads may have sizes larger than
        the standard maximum transmission unit (MTU) size, and therefore size. Therefore, there
        could be issues with fragmentation at the IP layer.  In order to allow using
        the use of those larger payload sizes, this mechanism relies on the
        IKE_INTERMEDIATE exchange as specified in <xref target="RFC9242"/>. target="RFC9242"
        format="default"/>.  With this mechanism, the key exchange is
        initiated using a smaller, possibly classical primitive, such as
        (EC)DH.  Then, before the IKE_AUTH exchange, one or more
        IKE_INTERMEDIATE exchanges are carried out, each of which contains an
        additional key exchange.  As the IKE_INTERMEDIATE exchange is
        encrypted, the IKE fragmentation protocol <xref target="RFC7383" />
        format="default"/> can be used. The IKE SK_* values are updated after
        each exchange exchange, as described in <xref target="additional_ke"/>,
			and so target="additional_ke"
        format="default"/>; thus, the final IKE SA keys depend on all the key exchanges,
			hence they
        exchanges. Hence, the keys are secure if any of the key exchanges are
        secure.</t>
        <t>While this extension is primarily aimed for at IKE SAs due to the
        potential fragmentation issue discussed above, it also applies to
        CREATE_CHILD_SA exchanges as illustrated in <xref target="create_child_sa_exchange"/>
        target="create_child_sa_exchange" format="default"/> for
        creating/rekeying of Child SAs and rekeying of IKE SAs.</t>

            <t>
			Note
        <t>Note that readers should consider the approach defined in this
        document as providing a long term long-term solution in upgrading the IKEv2
        protocol to support post-quantum algorithms.  A short term short-term solution to
        make IKEv2 key exchange quantum secure is to use post-quantum
        pre-shared keys as specified in <xref target="RFC8784"/>.</t> target="RFC8784"
        format="default"/>.</t>

        <t> Note also that the proposed approach of performing multiple
  successive key exchanges in such a way that way, when the resulting session keys
  depend on all of them them, is not limited to only addressing the
  threat of quantum computer. computers.  It can also be used when all of the performed key
        exchanges are classical (EC)DH primitives, where where, for some various reasons
      (e.g.
        (e.g., policy requirements) requirements), it is essential to perform multiple of them. key
        exchanges.
        </t>
        <t>This specification does not attempt to address key exchanges with KE payloads
        longer than 64 Kbytes; KB; the current IKE payload format does not allow such as a
        possibility.  At the time of writing, it appears likely that there
        are a number of key exchanges available that would not have such
        a requirement.  However, if such a requirement is needed,  <xref target="I-D.tjhai-ikev2-beyond-64k-limit"/> target="I-D.tjhai-ikev2-beyond-64k-limit" format="default"/> discusses approaches
        that could be taken to exchange huge payloads.</t>

		</section>

    	<section title="Changes" >
            <t>RFC EDITOR PLEASE DELETE THIS SECTION.</t>

            <t> Changes in this draft in each version iterations.</t>

            <t>draft-ietf-ipsecme-ikev2-multiple-ke-07</t>
            <t><list style="symbols">
            <t>Editorial changes.</t>
            </list></t>

            <t>draft-ietf-ipsecme-ikev2-multiple-ke-06</t>
            <t><list style="symbols">
            <t>Updated draft with the allocated IANA values.</t>
            <t>Editorial changes following AD review.</t>
            </list></t>

            <t>draft-ietf-ipsecme-ikev2-multiple-ke-05</t>
            <t><list style="symbols">
            <t>Updated the reference to RFC9242.</t>
            <t>Editorial changes.</t>
            </list></t>

            <t>draft-ietf-ipsecme-ikev2-multiple-ke-04</t>
            <t><list style="symbols">
            <t>Introduction and initial sections are reorganized.</t>
            <t>More clarifications for error handling added.</t>
            <t>ASCII arts displaying SA payload are added.</t>
            <t>Clarification for handling multiple round trips key exchange methods added.</t>
            <t>DoS concerns added into Security Considerations section.</t>
            <t>Explicitly allow scenario when additional key exchanges are performed only after peers are authenticated.</t>
            </list></t>

            <t>draft-ietf-ipsecme-ikev2-multiple-ke-03</t>
            <t><list style="symbols">
            <t>More clarifications added.</t>
            <t>Figure illustrating initial exchange added.</t>
            <t>Minor editorial changes.</t>
            </list></t>

            <t>draft-ietf-ipsecme-ikev2-multiple-ke-02</t>
            <t><list style="symbols">
            <t>Added a reference on the handling of KE payloads larger than 64KB.</t>
            </list></t>

            <t>draft-ietf-ipsecme-ikev2-multiple-ke-01</t>
            <t><list style="symbols">
            <t>References are updated.</t>
            </list></t>

            <t>draft-ietf-ipsecme-ikev2-multiple-ke-00</t>
            <t><list style="symbols">
            <t>Draft name changed as result of WG adoption and generalization of the approach.</t>
            <t>New exchange IKE_FOLLOWUP_KE is defined for additional key exchanges performed after CREATE_CHILD_SA.</t>
            <t>Nonces are removed from all additional key exchanges.</t>
            <t>Clarification that IKE_INTERMEDIATE must be negotiated is added.</t>
            </list></t>

            <t>draft-tjhai-ipsecme-hybrid-qske-ikev2-04</t>
            <t><list style="symbols">
            <t>Clarification about key derivation in case of multiple key exchanges in CREATE_CHILD_SA is added.</t>
            <t>Resolving rekey collisions in case of multiple key exchanges is clarified.</t>
            </list></t>

            <t>draft-tjhai-ipsecme-hybrid-qske-ikev2-03</t>
            <t><list style="symbols">
            <t>Using multiple key exchanges CREATE_CHILD_SA is defined.</t>
            </list></t>

            <t>draft-tjhai-ipsecme-hybrid-qske-ikev2-02</t>
            <t><list style="symbols">
        	<t>Use new transform types to negotiate additional key exchanges,
        	rather than using the KE payloads of IKE SA.</t>
         	</list></t>

            <t>draft-tjhai-ipsecme-hybrid-qske-ikev2-01</t>
            <t><list style="symbols">
     		<t>Use IKE_INTERMEDIATE to perform multiple key exchanges in succession.</t>
     		<t>Handle fragmentation by keeping the first key exchange (a standard
     		IKE_SA_INIT with a few extra notifies) small, and encrypting the rest
     		of the key exchanges.</t>

     		<t>Simplify the negotiation of the 'extra' key exchanges.</t>
     	    </list></t>

            <t>draft-tjhai-ipsecme-hybrid-qske-ikev2-00</t>
            <t><list style="symbols">
              <t>Added a feature to allow more than one post-quantum key
              exchange algorithms to be negotiated and used to exchange a post-
              quantum shared secret.</t>
              <t>Instead of relying on TCP encapsulation to deal with IP level
              fragmentation, if such a new key exchange payload that can
              be sent as multiple fragments within IKE_SA_INIT message was introduced.</t>
    	    </list>
            </t> requirement were needed.</t>
      </section>
      <section title="Document Organization" >
            <t>
            The numbered="true" toc="default">
        <name>Document Organization</name>
        <t>The remainder of this document is organized as follows.  <xref target="specification"/>
        target="specification" format="default"/> describes how multiple key
        exchanges are performed between two IKE peers and how keying materials
        are derived for both SAs and Child SAs. <xref target="IANA"/> target="IANA"
        format="default"/> discusses IANA considerations for the namespaces
        introduced in this document, and document. <xref target="security"/> target="security"
        format="default"/> discusses security considerations.  In the Appendices sections,
        Appendices, some examples of multiple key exchanges are illustrated in
        <xref target="sample-exchanges"/>, target="sample-exchanges" format="default"/>.  <xref target="design"/>
        target="design" format="default"/> summarizes design criteria and a summary of
        alternative approaches that have been considered, but considered. These approaches are
        later discarded, are as described in <xref target="altdesign"/>. target="altdesign"
        format="default"/>.
        </t>

            <t> The
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
            "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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 "OPTIONAL"
        "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14
        BCP&nbsp;14 <xref target="RFC2119" /> target="RFC2119"/> <xref target="RFC8174" /> target="RFC8174"/> when,
        and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section title="Multiple anchor="specification" numbered="true" toc="default">
      <name>Multiple Key Exchanges" anchor="specification"> Exchanges</name>
      <section title="Design Overview"> numbered="true" toc="default">
        <name>Design Overview</name>
        <t> Most post-quantum key agreement algorithms are relatively new, and
            thus new.
        Thus, they are not fully trusted.  There are also many proposed algorithms,
            with
        algorithms that have different trade-offs and relying that rely on different
        hard problems.  The concern is that some of these hard problems may
        turn out to be easier to solve than anticipated and thus anticipated; thus, the key
        agreement algorithm may not be as secure as expected.

A hybrid solution, when multiple key exchanges are performed and the
calculated shared key depends on all of them, allows us to deal with
this uncertainty by combining a classical key exchange with a
post-quantum one, as well as leaving open the possibility of
combining it with multiple post-quantum key exchanges.</t>
        <t> In order to be able to use IKE fragmentation <xref target="RFC7383"/>
        target="RFC7383" format="default"/> for those key exchanges that may
        have long public keys, this specification utilizes the
        IKE_INTERMEDIATE exchange defined in <xref target="RFC9242"/>. target="RFC9242"
        format="default"/>.  The initial IKE_SA_INIT messages do not have any
        inherent fragmentation support within IKE; however, IKE. However, IKE_SA_INIT
        messages can include a relatively short KE payload.  The additional
        key exchanges are performed using IKE_INTERMEDIATE messages that
        follow the IKE_SA_INIT exchange. This is to allow the standard IKE
        fragmentation mechanisms (which cannot be used in IKE_SA_INIT) to be
        available for the potentially large Key Exchange payloads with
        post-quantum algorithm data.
        </t>
        <t> Note that this document assumes, assumes that each key exchange method
        requires one round trip and consumes exactly one IKE_INTERMEDIATE
        exchange.  This assumption is valid for all classic key exchange
        methods defined so far and for all post-quantum methods currently
        known.  For hypothetical future key exchange methods requiring that require
        multiple round trips to complete, a separate document should define
        how such methods are split into several IKE_INTERMEDIATE exchanges.
        </t>
        <t> In order to minimize communication overhead, only the key shares
        that are agreed to be used upon are actually exchanged.  To negotiate
        additional key exchanges exchanges, seven new Transform Types are defined.  These
        transforms and Transform Type 4 share the same Transform IDs.
        </t>

        <t> It is assumed that new Transform Type 4 identifiers will be
        assigned later for various post-quantum key exchanges <xref target="IKEV2TYPE4ID"></xref>.
        target="IKEV2TYPE4ID" format="default"/>.  This specification does not
        make a distinction between classical (EC)DH and post-quantum key
        exchanges, nor between post-quantum algorithms which that are true key
        exchanges versus and post-quantum algorithms that act as key transport mechanisms;
        mechanisms: all are treated equivalently by the protocol.  This
        document renames a field in the Key Exchange Payload from
        "Diffie-Hellman Group Num" to "Key Exchange Method". It This document also
        renames Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key
        Exchange Method (KE)";
            the (KE)". The corresponding renaming to the IANA registry
        is described in <xref target="IANA"/>.</t> target="IANA" format="default"/>.</t>
        <t> The fact that newly defined transforms share the same registry for
        possible Transform IDs with Transform Type 4, 4 allows additional key
        exchanges to be of any type - type: either post-quantum or classical (EC)DH
            one.
        (EC)DH.  This approach allows any combination of the defined key
        exchange methods to take place.  This also allows IKE peers to perform
        a single post-quantum key exchange in the IKE_SA_INIT without
        additional key exchanges, provided that the IP fragmentation is not an
        issue and that hybrid key exchange is not needed.
        </t>
        <t> The SA payload in the IKE_SA_INIT message includes one or more
        newly defined transforms which that represent the extra key exchange policy
        required by the initiator. The responder follows the usual IKEv2
        negotiation rules: it selects a single transform of each type, type and
        returns all of them in the IKE_SA_INIT response message.
        </t>

            <t>
            Then,
        <t>Then, provided that additional key exchanges are negotiated, the
        initiator and the responder perform one or more IKE_INTERMEDIATE
        exchanges. Following that, the IKE_AUTH exchange authenticates peers
        and completes IKE SA establishment.</t>

            <figure><artwork align="center"><![CDATA[

<artwork align="center" name="" type="" alt=""><![CDATA[
Initiator                             Responder
---------------------------------------------------------------------
<-- IKE_SA_INIT (additional key exchanges negotiation) -->

<-- {IKE_INTERMEDIATE (additional key exchange)} -->

                         ...

<-- {IKE_INTERMEDIATE (additional key exchange)} -->

<-- {IKE_AUTH} -->
            ]]></artwork></figure>
]]>
</artwork>

      </section>
      <section title="Protocol Details"> numbered="true" toc="default">
        <name>Protocol Details</name>
        <t> In the simplest case, the initiator starts a single key exchange
        (and has no interest in supporting multiple), and it is not concerned
        with possible fragmentation of the IKE_SA_INIT messages (either because (because either
        the key exchange that it selects is small enough not to fragment, fragment
        or the initiator is confident that fragmentation will be handled
        either by IP fragmentation, fragmentation or by transport via TCP).</t>
        <t> In this case, the initiator performs the IKE_SA_INIT for a single
        key exchange using a Transform Type 4 (possibly with a post quantum algorithm), post-quantum
        algorithm) and including the initator initiator KE payload.  If the responder
        accepts the policy, it responds with an IKE_SA_INIT response, and IKE
        continues as usual.</t>
        <t> If the initiator desires wants to negotiate multiple key exchanges, then
        the initiator uses the protocol behavior listed below.</t>
        <section anchor="negotiation" title="IKE_SA_INIT numbered="true" toc="default">
          <name>IKE_SA_INIT Round: Negotiation" > Negotiation</name>
          <t> Multiple key exchanges are negotiated using the standard IKEv2 mechanism,
          mechanism via SA payload.  For this purpose purpose, seven new transform types, namely
          types are defined: Additional Key Exchange 1 (with IANA assigned (ADDKE1) with IANA-assigned value 6),
          6, Additional Key Exchange 2 (ADDKE2) (7), Additional Key Exchange 3 (ADDKE3) (8),
          Additional Key Exchange 4 (ADDKE4) (9), Additional Key Exchange 5 (ADDKE5) (10),
          Additional Key Exchange 6 (11) (ADDKE6) (11), and Additional Key Exchange 7 (12)
                are defined. (ADDKE7) (12).
          They are collectively called Additional "Additional Key Exchange transforms (ADDKE)
          Transform Types" in this document and have slightly different semantics
          than the existing IKEv2 transform types. Transform Types.  They are interpreted as an
          indication of additional key exchange methods that peers agree to
          perform in a series of IKE_INTERMEDIATE exchanges following the
          IKE_SA_INIT exchange.  The allowed transform Transform IDs for these transform
          types are the same as the IDs for Transform Type 4, so they all
          share a single IANA registry for transform Transform IDs.
          </t>

                <t> Key
          <t>The key exchange method negotiated via Transform Type 4 always
          takes place in the IKE_SA_INIT exchange, as defined in <xref
          target="RFC7296" />. format="default"/>.  Additional key exchanges
          negotiated via newly defined transforms MUST <bcp14>MUST</bcp14> take
          place in a series of IKE_INTERMEDIATE exchanges following the
          IKE_SA_INIT exchange, performed in an order of the values of their transform types,
          Transform Types.  This is so that the key exchange negotiated using Additional
          Key Exchange i always precedes that of Additional Key Exchange i +
          1. Each additional key exchange method MUST <bcp14>MUST</bcp14> be fully
          completed before the next one is started.
          </t>

                <t> Note that with
          <t>With these semantics, Additional Key Exchange transforms note that ADDKE
          Transform Types are not associated with any particular type of key
          exchange and do not have any Transform IDs that are specific per transform type transform IDs
          Transform Type IANA registry.
                Instead  Instead, they all share a single
          registry for transform Transform IDs, namely "Key "Transform Type 4 - Key Exchange Method Transform IDs", which are also shared by Transform Type 4.
          IDs".  All key exchange
          algorithms (both classical or post-quantum) should be added to this
          registry.  This approach gives peers flexibility in defining the
          ways they want to combine different key exchange methods.
          </t>
          <t> When forming a proposal proposal, the initiator adds transforms for the
          IKE_SA_INIT exchange using Transform Type 4.  In most cases cases, they
          will contain classical (EC)DH key exchange methods,
                however it but that is not
          a requirement.  Additional key exchange methods are proposed using Additional Key Exchange
                transform types.
          ADDKE Transform Types.  All of these transform
          types are optional, optional; the initiator is free to select any of them for
          proposing additional key exchange methods.  Consequently, if none of
          the Additional Key Exchange transforms is ADDKE Transform Types are included in the proposal,
          then this proposal indicates the performing of standard IKEv2, as
          defined in <xref target="RFC7296"/>. target="RFC7296" format="default"/>.  On the other
          hand, if the initiator includes any Additional Key Exchange transform ADDKE
          Transform Type in the proposal, the responder MUST <bcp14>MUST</bcp14> select
          one of the algorithms proposed using this type.  Note that this is
          not a new requirement, but that requirement; this behavior is already specified in Section 2.7 of
          <xref target="RFC7296"/>. target="RFC7296" sectionFormat="of" section="2.7"/>.  A transform
          Transform ID NONE MAY <bcp14>MAY</bcp14> be added to those transform
          types which that contain key exchange methods that which the initiator believes is
          are optional according to its local policy.
          </t>
          <t> The responder performs the negotiation using the standard IKEv2
          procedure described in Section 3.3 of <xref target="RFC7296"/>. target="RFC7296" sectionFormat="of"
          section="3.3"/>.  However, for the Additional Key Exchange types, ADDKE Transform Types,
          the responder's choice MUST NOT <bcp14>MUST NOT</bcp14> contain duplicated
          algorithms (those with an identical Transform ID and attributes),
          except for the transform Transform ID of NONE.  An algorithm is represented as
          a transform, in transform. In some cases cases, the transform could include a set of
          associated attributes that define details of the algorithm. In this
          case, two transforms can be the same, but the attributes must be
          different.   Additionally, the order of the attributes does not
   affect the equality of the algorithm, so the following two
   transforms (ID=alg1,ATTR1=attr1,ATTR2=attr2) and
                (ID=alg1,ATTR2=attr2,ATTR1=attr1) define the same algorithm. algorithm:
   "ID=alg1, ATTR1=attr1, ATTR2=attr2" and
   "ID=alg1, ATTR2=attr2, ATTR1=attr1". If the
          responder is unable to select non-duplicated algorithm algorithms that are not duplicated for each
          proposed key exchange (either because the proposal contains too few
          choices or due to the local policy restrictions on using the
          proposed algorithms), then the responder MUST <bcp14>MUST</bcp14> reject
          the message with an error notification of type NO_PROPOSAL_CHOSEN.
          If the responder's message contains one or more duplicated choices,
          the initiator should log the error and MUST <bcp14>MUST</bcp14> treat the
          exchange as failed.  The initiator MUST NOT <bcp14>MUST NOT</bcp14> initiate
          any IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE) exchanges, exchanges so that no new
          SA is created.  If this happens in the CREATE_CHILD_SA exchange,
          then the initiator MAY <bcp14>MAY</bcp14> delete the IKE SA, SA over which
          the invalid message was received, received by sending a Delete payload.
          </t>
          <t> If the responder selects NONE for some Additional Key Exchange types ADDKE
          Transform Types (provided they are proposed by the initiator), then the any
          corresponding Additional Key Exchange(s) in the IKE_INTERMEDIATE exchange(s) MUST NOT additional key exchanges <bcp14>MUST NOT</bcp14> take place.
                Therefore

	  Therefore, if the
          initiator includes NONE in all of the Additional Key Exchange transforms ADDKE
          Transform Types and the responder selects this value for all of them,
          then no IKE_INTERMEDIATE messages exchanges performing additional key
          exchanges will take place between the peers.  Note that the
          IKE_INTERMEDIATE exchanges may still take place for other purposes.
          </t>
          <t>The initiator MAY <bcp14>MAY</bcp14> propose non-consecutive Additional Key Exchange transforms,
          ADDKE Transform Types that are not consecutive, for example example, proposing Additional Key Exchange 2
          ADDKE2 and Additional Key Exchange 5 transforms ADDKE5 Transform Types only.  The
          responder
                MUST <bcp14>MUST</bcp14> treat all of the omitted Additional Key Exchange ADDKE
          transforms as if they are were proposed with Transform ID
          NONE.</t>

                <t> Below
          <t>Below is an example of the SA payload in the initiator's IKE_SA_INIT
  request message.
                Here  Here, the abbreviation AKEi "KE" is used to denote the i-th Additional Key Exchange transform defined in this document,
                and an abbreviation KE for the Key Exchange transform,
                that which this
  document renames from the Diffie-Hellman Group transform.  Additionally, the notations PQ_KEM_1, PQ_KEM_2 PQ_KEM_2, and
          PQ_KEM_3 are used to represent some not-yet defined Transform IDs that have yet to be defined of
          some popular post-quantum key exchange methods.</t>

                <figure><artwork

<artwork align="center" ><![CDATA[ name="" type="" alt=""><![CDATA[
SA Payload
   |
   +--- Proposal #1 ( Proto ID = IKE(1), SPI size Size = 8,
         |            9 transforms,      SPI = 0x35a1d6f22564f89d )
         |
         +-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
         |     +-- Attribute ( Key Length = 256 )
         |
         +-- Transform KE ( ID = 4096-bit MODP Group )
         |
         +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
         |
         +-- Transform AKE2 ADDKE2 ( ID = PQ_KEM_1 )
         |
         +-- Transform AKE2 ADDKE2 ( ID = PQ_KEM_2 )
         |
         +-- Transform AKE3 ADDKE3 ( ID = PQ_KEM_1 )
         |
         +-- Transform AKE3 ADDKE3 ( ID = PQ_KEM_2 )
         |
         +-- Transform AKE5 ADDKE5 ( ID = PQ_KEM_3 )
         |
         +-- Transform AKE5 ADDKE5 ( ID = NONE )

                ]]></artwork></figure>
	 ]]>
</artwork>

          <t> In this example, the initiator proposes to perform performing the
          initial key exchange using a 4096-bit MODP group Group followed by two
          mandatory additional key exchanges (i.e. Transforms AKE2 (i.e., ADDKE2 and AKE3) ADDKE3 Transform Types)
          using PQ_KEM_1 and PQ_KEM_2 methods in any order, then order followed
          by an additional key exchange (i.e. (i.e., ADDKE5 Transform AKE5) Type) using the PQ_KEM_3
          method that may be omitted.
          </t>
          <t> The responder might return the following SA payload, indicating
          that it agrees to perform two additional key exchanges exchanges, PQ_KEM_2
          followed by PQ_KEM_1 PQ_KEM_1, and that it does not want to additionally perform PQ_KEM_3 additionally.
          PQ_KEM_3.
          </t>

                <figure><artwork

<artwork align="center" ><![CDATA[ name="" type="" alt=""><![CDATA[
SA Payload
   |
   +--- Proposal #1 ( Proto ID = IKE(1), SPI size Size = 8,
         |            6 transforms,      SPI = 0x8df52b331a196e7b )
         |
         +-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
         |     +-- Attribute ( Key Length = 256 )
         |
         +-- Transform KE ( ID = 4096-bit MODP Group )
         |
         +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
         |
         +-- Transform AKE2 ADDKE2 ( ID = PQ_KEM_2 )
         |
         +-- Transform AKE3 ADDKE3 ( ID = PQ_KEM_1 )
         |
         +-- Transform AKE5 ADDKE5 ( ID = NONE )

                ]]></artwork></figure>
	 ]]>
</artwork>

          <t> If the initiator includes any Additional Key Exchange transform types ADDKE Transform
          Types into the SA payload in the IKE_SA_INIT exchange request
          message, then it MUST <bcp14>MUST</bcp14> also negotiate the use of the
          IKE_INTERMEDIATE exchange exchange, as described in <xref target="RFC9242" />,
          format="default"/> by including an INTERMEDIATE_EXCHANGE_SUPPORTED
          notification in the same message.  If the responder agrees to use
          additional key exchanges while establishing an initial IKE SA, it MUST
          <bcp14>MUST</bcp14> also return this notification in the IKE_SA_INIT
          response message,
                thus confirming that IKE_INTERMEDIATE exchange is
          supported and will be used for transferring additional key exchange
          data.  If the IKE_INTERMEDIATE exchange is not negotiated, then the
          peers MUST <bcp14>MUST</bcp14> treat any Additional Key Exchange transforms ADDKE
          Transform Types in the IKE_SA_INIT exchange messages as unknown transform
          types and skip the proposals they appear in.  If no other proposals
          are present in the SA payload, the peers will proceed as if no
          proposal is has been chosen
                (i.e. (i.e., the responder will send a NO_PROPOSAL_CHOSEN
          notification).
          </t>

                <figure><artwork

<artwork align="center" ><![CDATA[ name="" type="" alt=""><![CDATA[
Initiator                          Responder
---------------------------------------------------------------------
HDR, SAi1(.. AKE*...), ADDKE*...), KEi, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED)    --->
                                   HDR, SAr1(.. AKE*...), ADDKE*...), KEr, Nr,
                                   [CERTREQ],
                           <---    N(INTERMEDIATE_EXCHANGE_SUPPORTED)
                ]]></artwork></figure>
			   ]]>
</artwork>

          <t> It is possible that for an attacker manages to manage to send a response to
          the initiator's IKE_SA_INIT request before the legitimate responder
          does.  If the initiator continues to create the IKE SA using this
          response, the attempt will fail.  Implementers may wish to consider a possible defense technique
         strategies as described
   in Section 2.4 of <xref target="RFC7296" />.
          sectionFormat="of" section="2.4"/> to handle such an attack.
          </t>
        </section>
        <section title="IKE_INTERMEDIATE anchor="additional_ke" numbered="true" toc="default">
          <name>IKE_INTERMEDIATE Round: Additional Key Exchanges" anchor="additional_ke"> Exchanges</name>
          <t> For each additional key exchange agreed to in the IKE_SA_INIT exchange,
        		the initiator and the responder perform an IKE_INTERMEDIATE exchange,
                as described in <xref target="RFC9242"/>.</t>

                <figure><artwork target="RFC9242" format="default"/>.</t>

<artwork align="center" ><![CDATA[ name="" type="" alt=""><![CDATA[
Initiator                          Responder
---------------------------------------------------------------------
HDR, SK {KEi(n)}    -->
                            <--    HDR, SK {KEr(n)}
                ]]></artwork></figure>
			    ]]>
</artwork>

          <t> The initiator sends key exchange data in the KEi(n) payload.
          This message is protected with the current SK_ei/SK_ai keys.  The
          notation KEi(n) "KEi(n)" denotes the n-th IKE_INTERMEDIATE KE payload from
          the initiator
                and initiator; the integer n "n" is sequential starting from
          1.</t>
          <t> On receiving this, the responder sends back key exchange payload KEr(n),
                which
          KEr(n); "KEr(n)" denotes the n-th IKE_INTERMEDIATE KE payload from the
          responder.
                As before,  Similar to how the request is protected, this message is protected with the current
          SK_er/SK_ar keys.</t>
          <t> The former "Diffie-Hellman Group Num" (now called "Key Exchange Method") field in the KEi(n) and KEr(n) payloads MUST <bcp14>MUST</bcp14> match the
                n-th negotiated additional key exchange.
                <!--  Note that the negotiated transform types (the encryption type, integrity type, prf type) are not modified. (do we need to say this?) -->
                </t> exchange.</t>
          <t> Once this exchange is done, both sides compute an updated keying material:</t>

                <figure><artwork

<artwork align="center" ><![CDATA[ name="" type="" alt=""><![CDATA[
SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)
                ]]></artwork></figure>
]]>
</artwork>

          <t> where From this exchange, SK(n) is the resulting shared secret of this key exchange, secret. Ni and Nr are nonces from the IKE_SA_INIT exchange and exchange.
          SK_d(n-1) is the last generated SK_d, SK_d (derived from IKE_SA_INIT
          for the first use of IKE_INTERMEDIATE, otherwise IKE_INTERMEDIATE and, otherwise, from the
          previous IKE_INTERMEDIATE exchange).  The other keying materials materials,
          SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr and SK_pr, are generated
          from the SKEYSEED(n) as follows:</t>

                <figure><artwork

<artwork align="center" ><![CDATA[ name="" type="" alt=""><![CDATA[
{SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) |
 SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr)
                ]]></artwork></figure>
 ]]>
</artwork>

          <t> Both the initiator and the responder use these updated key
        		values in the next exchange (IKE_INTERMEDIATE or IKE_AUTH).</t>
        </section>
        <section title="IKE_AUTH Exchange"> numbered="true" toc="default">
          <name>IKE_AUTH Exchange</name>
          <t> After all IKE_INTERMEDIATE exchanges have completed, the initiator and
        		the responder perform an IKE_AUTH exchange.  This exchange is
        		the standard IKE exchange exchange, as described in <xref target="RFC7296"/> target="RFC7296" format="default"/>, with
			the modification of AUTH payload calculation described in
			<xref target="RFC9242"/>.</t> target="RFC9242" format="default"/>.</t>
        </section>
        <section title="CREATE_CHILD_SA Exchange" anchor="create_child_sa_exchange"> anchor="create_child_sa_exchange" numbered="true" toc="default">
          <name>CREATE_CHILD_SA Exchange</name>
          <t> The CREATE_CHILD_SA exchange is used in IKEv2 for the purposes
          of creating additional Child SAs, rekeying these Child SAs, and
          rekeying IKE SA itself.  When creating or rekeying Child SAs, the
          peers may optionally perform a key exchange to add a fresh entropy
          into the session keys.  In the case of an IKE SA rekey, the key exchange is
          mandatory.  Peers supporting this specification may want to use
          multiple key exchanges in these situations.
          </t>
          <t> Using multiple key exchanges with a CREATE_CHILD_SA exchange is
          negotiated
                similarly as in a similar fashion to the initial IKE exchange, see <xref
          target="negotiation" />. format="default"/>.  If the initiator includes
          any Additional Key Exchange transform ADDKE Transform Types in the SA payload (along with
          Transform Type 4) 4), and if the responder agrees to perform additional
          key exchanges, then the additional key exchanges are performed in a
          series of new IKE_FOLLOWUP_KE exchanges that follows follow the
          CREATE_CHILD_SA exchange.  The IKE_FOLLOWUP_KE exchange is introduced as a dedicated exchange especially for
transferring data of additional key exchanges following the key exchange one
performed in the CREATE_CHILD_SA.  Its Exchange Type value is
44.
          </t>
          <t> Key
	    The key exchange negotiated via Transform Type 4 always takes
          place in the CREATE_CHILD_SA exchange, as per the IKEv2 specification.
          specification <xref target="RFC7296" format="default"/>.  Additional key exchanges are performed in an order
          of the values of their transform types, Transform Types so that the key exchange
          negotiated using Transform Type n Additional Key Exchange i always precedes the key exchange
          negotiated using
                Transform Type n Additional Key Exchange i + 1. Each additional key exchange
          method MUST <bcp14>MUST</bcp14> be fully completed before the next one is
          started.
                Note,  Note that this document assumes, assumes that each key exchange
          method consumes exactly one IKE_FOLLOWUP_KE exchange.  For the
          methods requiring that require multiple round trips, a separate document should
          define how such methods are split into several IKE_FOLLOWUP_KE
          exchanges.
          </t>

                <t> After
          <t>After an IKE SA is created created, the window size may be greater than one and one; thus, multiple concurrent exchanges may be in progress, progress.  Therefore, it is
essential to link the IKE_FOLLOWUP_KE exchanges together with the
corresponding CREATE_CHILD_SA exchange.  Due to the fact that once  Once an IKE SA is created, all IKE
  exchanges are independent and do not IKEv2 doesn't have a built-in means mechanism to link one an exchange
  with another, a another one. A new status type notification ADDITIONAL_KEY_EXCHANGE called
  "ADDITIONAL_KEY_EXCHANGE" is introduced for this purpose.
          Its Notify Message Type value is 16441, and the Protocol ID and SPI
          Size are both set to 0.  The data associated with this notification
          is a blob meaningful only to the responder, responder so that the
          responder can correctly link successive exchanges.  For the initiator
          initiator, the content of this notification is an opaque blob.
          </t>
          <t> The responder MUST <bcp14>MUST</bcp14> include this notification in a
          CREATE_CHILD_SA or IKE_FOLLOWUP_KE response message in case the next
          IKE_FOLLOWUP_KE exchange is expected, filling it with some data that
          would allow linking the current exchange to the next one.
          The initiator
                MUST <bcp14>MUST</bcp14> send back this notification intact
          in the request message of the next IKE_FOLLOWUP_KE exchange.
          </t>
          <t> Below is an example of CREATE_CHILD_SA exchange followed by three additional key exchanges.
          </t>

                <figure><artwork

<artwork align="center" ><![CDATA[ name="" type="" alt=""><![CDATA[
Initiator                             Responder
---------------------------------------------------------------------
HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
                          <--  HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr,
                                   N(ADDITIONAL_KEY_EXCHANGE)(link1)}

HDR(IKE_FOLLOWUP_KE), SK {KEi(1),
 N(ADDITIONAL_KEY_EXCHANGE)(link1)} -->
                               <--  HDR(IKE_FOLLOWUP_KE), SK {KEr(1),
                                   N(ADDITIONAL_KEY_EXCHANGE)(link2)}

HDR(IKE_FOLLOWUP_KE), SK {KEi(2),
 N(ADDITIONAL_KEY_EXCHANGE)(link2)} -->
                               <--  HDR(IKE_FOLLOWUP_KE), SK {KEr(2),
                                   N(ADDITIONAL_KEY_EXCHANGE)(link3)}

HDR(IKE_FOLLOWUP_KE), SK {KEi(3),
 N(ADDITIONAL_KEY_EXCHANGE)(link3)} -->
                               <--  HDR(IKE_FOLLOWUP_KE), SK {KEr(3)}
                ]]></artwork></figure>
			       ]]>
</artwork>

          <t> The former "Diffie-Hellman Group Num" (now called "Key Exchange Method") field in the KEi(n) and KEr(n) payloads MUST <bcp14>MUST</bcp14> match the
                n-th negotiated additional key exchange.
          </t>

                <t> It is possible that due
          <t>Due to some unexpected events (e.g. reboot) (e.g., a
          reboot), it is possible that the initiator may lose its state and state, forget that it is in
          the process of performing additional key exchanges exchanges, and thus never
          start the remaining IKE_FOLLOWUP_KE exchanges.  The responder MUST
          <bcp14>MUST</bcp14> handle this situation gracefully and delete the
          associated state if it does not receive the next expected
          IKE_FOLLOWUP_KE request after some reasonable period of time.
                Note that due  Due to various factors such as computational resource and key
          exchange algorithm used, note that it is not possible to give a  normative
          guidance on how long this timeout period should be. In general, 5-20
          seconds of waiting time should be appropriate in most cases.
          </t>

                <t> It is also possible that the initiator

          <t>It may also take too long for the initiator to prepare
and to send the next IKE_FOLLOWUP_KE request or request, or, due to the
network conditions, the request is could be lost and retransmitted.
  In
          this case, the message may reach the responder when it has already
          deleted the associated state state, following the advice above.  If the
          responder receives an IKE_FOLLOWUP_KE message for which it does not
          have a key exchange state, it MUST <bcp14>MUST</bcp14> send back a new
          error type notification
                STATE_NOT_FOUND. called "STATE_NOT_FOUND".  This is a non-fatal an error notification, its notification that is not fatal to the IKE SA.
  Its Notify Message Type value is 47, its Protocol ID and SPI Size are
  both set to 0 0, and the data is empty.  If the
          initiator receives this notification in response to an IKE_FOLLOWUP_KE
          exchange performing an additional key exchange, it MUST <bcp14>MUST</bcp14>
          cancel this exchange and MUST <bcp14>MUST</bcp14> treat the whole series
          of exchanges started from the CREATE_CHILD_SA exchange as having failed.
          In most cases, the receipt of this notification is caused by the
          premature deletion of the corresponding state on the responder (the
          time period between IKE_FOLLOWUP_KE exchanges appeared to be too
          long from the responder's point of view, e.g. e.g., due to a temporary
          network failure).  After receiving this notification notification, the initiator MAY
          <bcp14>MAY</bcp14> start a new CREATE_CHILD_SA exchange exchange, which may
          eventually be followed by the IKE_FOLLOWUP_KE exchanges, to retry
          the failed attempt.  If the initiator continues to receive
          STATE_NOT_FOUND notifications after several retries, it MUST
          <bcp14>MUST</bcp14> treat this situation as a fatal error and delete
          the IKE SA by sending a DELETE payload.
          </t>
          <t> When It is possible that
          the peers start rekeying the IKE SA or the Child SA, it is possible that the peers start doing this SA at the same time, which is called simultaneous rekeying.
          "simultaneous rekeying".  Sections 2.8.1 <xref target="RFC7296"
          section="2.8.1" sectionFormat="bare"/> and 2.8.2 of <xref target="RFC7296" />
          section="2.8.2" sectionFormat="bare"/> of <xref target="RFC7296"/>
          describe how IKEv2 handles this situation.  In a nutshell nutshell, IKEv2
          follows the rule that if that, in the case of simultaneous rekeying, if two
          identical new IKE SAs (or two pairs of Child SAs) are created, then
          one of them should be deleted.  Which one is to be deleted delete is
          determined by comparing the values of four nonces that are used in
          the colliding CREATE_CHILD_SA exchanges. The IKE SA (or pair of
          Child SAs)
                that is created by the exchange in which the smallest
          nonce is used should be deleted by the initiator of this exchange.
          </t>
          <t> With multiple key exchanges, the SAs are not yet created when
          the CREATE_CHILD_SA is completed, completed. Instead, they would be created
          only after the series of IKE_FOLLOWUP_KE exchanges is finished.  For
          this reason, if additional key exchanges are negotiated in the
          CREATE_CHILD_SA exchange in which the smallest nonce is used, then then,
          because there is nothing to delete yet, the initiator of this
          exchange just stops the rekeying process process, and it MUST NOT <bcp14>MUST
          NOT</bcp14> initiate the IKE_FOLLOWUP_KE exchange.
          </t>
          <t> In most cases, rekey collisions are resolved in the
          CREATE_CHILD_SA exchange.  However, a situation may occur when when, due
          to packet loss, one of the peers receives the CREATE_CHILD_SA
          message requesting the rekey of an SA that is already being rekeyed by
          this peer (i.e. (i.e., the CREATE_CHILD_SA exchange initiated by this peer
          has been already completed been completed, and the series of IKE_FOLLOWUP_KE
          exchanges is in progress).  In this case, a TEMPORARY_FAILURE
          notification MUST <bcp14>MUST</bcp14> be sent in response to such a
          request.
          </t>
          <t> If multiple key exchanges are negotiated in the CREATE_CHILD_SA exchange, then the resulting keys are
                computed as follows.</t>
          <t>In the case of an IKE SA rekey:
          </t>

                <figure><artwork

<artwork align="center" ><![CDATA[ name="" type="" alt=""><![CDATA[
SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n))
                ]]></artwork></figure>
]]>
</artwork>

          <t> In the case of a Child SA creation or rekey:
          </t>

                <figure><artwork

<artwork align="center" ><![CDATA[ name="" type="" alt=""><![CDATA[
KEYMAT = prf+ (SK_d, SK(0) | Ni | Nr | SK(1) |  ... SK(n))
                ]]></artwork></figure>
]]>
</artwork>

          <t> In both cases, SK_d is from the existing IKE SA; SK(0), Ni, and
          Nr are the shared key and nonces from the CREATE_CHILD_SA CREATE_CHILD_SA,
          respectively; SK(1)...SK(n) are the shared keys from additional
          key exchanges.
          </t>
        </section>
        <section title="Interaction numbered="true" toc="default">
          <name>Interaction with IKEv2 Extensions"> Extensions</name>
          <t> It is believed that this specification requires no modification
          to the IKEv2 extensions defined so far.  In particular, the IKE SA
          resumption mechanism defined in <xref target="RFC5723" />
          format="default"/> can be used to resume IKE SAs created using this
          specification.
          </t>
          <section title="Interaction numbered="true" toc="default">
            <name>Interaction with Childless IKE SA"> SA</name>

            <t>It is possible to establish IKE SAs with post-quantum algorithms by
only using additional key exchanges,
            but IKE_FOLLOWUP_KE exchanges and without using the use of
IKE_INTERMEDIATE exchanges.  In this case, the IKE SA that is
created from the IKE_SA_INIT exchange exchange, can be immediately rekeyed with
CREATE_CHILD_SA using with additional key exchanges exchanges, where IKE_FOLLOWUP_KE
messages are used to carry the for these additional key exchange payload. exchanges.  If the classical key exchange method is used in the
            IKE_SA_INIT message, the very first Child SA created in IKE_AUTH
            will offer no resistance against the quantum threats.
            Consequently, if the peers' local policy requires that all Child
            SAs to be post-quantum secure, then the peers can avoid creating
            the very first Child SA by adopting <xref target="RFC6023"/>. target="RFC6023"
            format="default"/>.  In this case, the initiator sends two types
            of
            proposal proposals in the IKE_SA_INIT request, request: one with and another one
            without Additional
            Key Exchange transform(s). ADDKE Transform Types.  The responder
            chooses the latter proposal type and includes a
            CHILDLESS_IKEV2_SUPPORTED notification in the IKE_SA_INIT
            response.  Assuming that the initiator supports childless IKE SA
            extension, then both peers performs perform the modified IKE_AUTH exchange
            described in <xref target="RFC6023"/> target="RFC6023" format="default"/>, and no
            Child SA is created in this exchange.  The peers should then
            immediately rekey the IKE SA and subsequently create the Child
            SAs, all with additional key exchanges using a CREATE_CHILD_SA
            exchange.</t>
            <t>It is also possible for the initiator to send proposals without Additional Key
            Exchange transform(s)
            any ADDKE Transform Types in the IKE_SA_INIT message and in message.
            In this instance, the responder will have no information
            about whether or not the initiator supports the extension in this
            specification.  This may not be efficient efficient, as the responder will
            have to wait for the subsequent CREATE_CHILD_SA request to
            determine whether or not the initiator's request is appropriate
            for its local policy.</t>
            <t>The support for childless IKE SA is not negotiated, but it is
            the responder that indicates the support for this mode.  As such,
            the responder cannot enforce that the initiator to use this mode and therefore, mode.
            Therefore, it is entirely possible that the initiator does not
            support this extension and sends IKE_AUTH request as per <xref target="RFC7296"/>
            target="RFC7296" format="default"/> instead of <xref target="RFC6023"/>.
            target="RFC6023" format="default"/>.  In this case, the responder
            may respond with non-fatal an error that is not fatal, such as the NO_PROPOSAL_CHOSEN
            notify message type.</t>
            <t>Note that if the initial IKE SA is used to transfer sensitive
            information, then this information will not be protected using the
            additional key exchanges, which may use post-quantum algorithms.
            In this arrangement, the peers will have to use post-quantum
            algorithm in Transform Type 4 in order to mitigate the risk of
            quantum attack. </t>
          </section>
        </section>
      </section>
    </section>

    <section title="IANA Considerations" anchor="IANA"> anchor="IANA" numbered="true" toc="default">

      <name>IANA Considerations</name>
      <t>This document adds a new exchange type into the "IKEv2 Exchange
      Types" registry:</t>

<figure align="center"><artwork align="left"><![CDATA[

<artwork align="left" name="" type="" alt=""><![CDATA[
44         IKE_FOLLOWUP_KE
]]></artwork></figure>
]]>
</artwork>

      <t>This document renames Transform Type 4 defined in the "Transform Type Values" registry
        from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)".</t>
      <t>This document renames the IKEv2 registry originally titled "Transform Type 4 - Diffie-Hellman Group Transform IDs" to
        "Transform Type 4 - Key Exchange Method Transform IDs".</t>
      <t>This document adds the following Transform Types to the "Transform Type Values" registry:</t>
        <figure align="left"><artwork align="left"><![CDATA[

<table anchor="transform-type-values" align="center">
  <name>"Transform Type     Description                   Used In
-----------------------------------------------------------------
6        Additional Values" Registry</name>
  <thead>
    <tr>
      <th>Type</th>
      <th>Description</th>
      <th>Used In</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>6</td>
      <td>Additional Key Exchange 1     (optional (ADDKE1)</td>
      <td>(optional in IKE, AH, ESP)
7        Additional ESP)</td>
    </tr>
    <tr>
      <td>7</td>
      <td>Additional Key Exchange 2     (optional (ADDKE2)</td>
      <td>(optional in IKE, AH, ESP)
8        Additional ESP)</td>
    </tr>
    <tr>
      <td>8</td>
      <td>Additional Key Exchange 3     (optional (ADDKE3)</td>
      <td>(optional in IKE, AH, ESP)
9        Additional ESP)</td>
    </tr>
    <tr>
      <td>9</td>
      <td>Additional Key Exchange 4     (optional (ADDKE4)</td>
      <td>(optional in IKE, AH, ESP)
10       Additional ESP)</td>
    </tr>
    <tr>
      <td>10</td>
      <td>Additional Key Exchange 5     (optional (ADDKE5)</td>
      <td>(optional in IKE, AH, ESP)
11       Additional ESP)</td>
    </tr>
    <tr>
      <td>11</td>
      <td>Additional Key Exchange 6     (optional (ADDKE6)</td>
      <td>(optional in IKE, AH, ESP)
12       Additional ESP)</td>
    </tr>
    <tr>
      <td>12</td>
      <td>Additional Key Exchange 7     (optional (ADDKE7)</td>
      <td>(optional in IKE, AH, ESP)
        ]]></artwork></figure> ESP)</td>
    </tr>
  </tbody>
</table>

      <t>This document defines a new Notify Message Type in the "Notify "IKEv2 Notify Message Types - Status Types" registry:</t>

        <figure align="center"><artwork align="left"><![CDATA[

<artwork align="left" name="" type="" alt=""><![CDATA[
16441       ADDITIONAL_KEY_EXCHANGE
        ]]></artwork></figure>

        <t>and
]]>
</artwork>

      <t>This document also defines a new Notify Message Type in the "Notify "IKEv2 Notify Message Types - Error Types" registry:</t>

        <figure align="center"><artwork align="left"><![CDATA[

<artwork align="left" name="" type="" alt=""><![CDATA[
47         STATE_NOT_FOUND
        ]]></artwork></figure>

        <section title="Additional Considerations and Changes">

            <t>The IANA is requested to add
]]>
</artwork>

        <t>IANA has added the following instructions for designated
        experts for Transform the "Transform Type 4 sub-registry.</t>

            <t>While - Key Exchange Method Transform IDs" subregistry:</t>

        <ul><li>While adding new KE Key Exchange (KE) methods, the following considerations must be
        applied.  A KE method must take exactly one round-trip (one IKE exchange) IKEv2
        exchange), and at the end of this exchange, both peers must be able to
        derive the shared secret. In addition, any public value that peers
        exchanged during a KE method must fit into a single IKE
            message. IKEv2 payload.  If
        these restrictions are not met for a KE method, then there must be
        documentation on how this KE method is used in IKEv2.</t>

            <t>The following changes to IANA are IKEv2.</li></ul>
        <t>IANA has also requested. completed the following changes. It is assumed that
            RFCXXXX
            [RFC9370] refers to this specification.</t>
            <t><list style="symbols">

              <t>Add
            <ul spacing="normal">

          <li><t>Added a reference to RFCXXXX [RFC9370] in what was the "Transform Type 4 -
          Diffie-Hellman Group Transform IDs"
              registry.</t>

              <t>Replace registry.</t></li>
          <li><t>Replaced the note Note on what was the "Transform Type 4 - Diffie-Hellman Group
          Transform IDs" registry with:
              This with the following notes:</t>
              <t>This registry was originally named "Transform Type 4 -
     Diffie-Hellman Group Transform IDs" and was renamed to its current name by [RFCXXXX].  It has been referenced in its original using
     that name in a number of RFCs published prior to [RFCXXXX].  To [RFC9370],
	      which gave it the current title.</t>

	      <t>This registry is used by the "Key Exchange Method (KE)" transform type and by all "Additional Key Exchange (ADDKE)" transform types.</t>

	      <t>To find out requirement levels
	  for Key Exchange Methods for IKEv2, see [RFC8247].</t>

              <t>Add this note <xref target="RFC8247" format="default"/>.</t></li>
	  <li><t>Appended [RFC9370] to the Reference column of Transform Type 4 in
     the "Transform Type Values" registry: Transform Type registry.</t></li>
          <li><t>Added these notes to the "Transform Type 4 - Key Values" registry:</t>
	  <t>"Key Exchange Method Transform IDs" (KE)" transform type was originally
    named "Transform Type 4 - Diffie-Hellman "Diffie-Hellman Group
              Transform IDs" (D-H)" and was renamed to its current name by [RFCXXXX].  It has been referenced in its
              original by that name in a number of RFCs
    published prior to [RFCXXXX].  All [RFC9370], which gave it the current title.</t><t>All "Additional Key Exchange" Exchange (ADDKE)" entries use the same
    "Transform Type 4 - Key Exchange Method Transform IDs"
    registry as the "Key Exchange Method (KE)".</t>

              <t>Append RFCXXXX to the Reference column of Transform Type 4 in the Transform Type Values registry.</t>

              <t>Append this note to "Transform Type 4 - Diffie-Hellman Group Transform IDs" registry: All
               "Additional Key Exchange" entries use these values as the "Key Exchange Method (KE)".</t>
            </list></t>
        </section> (KE)" entry.</t></li>

        </ul>

    </section>
    <section title="Security Considerations" anchor="security"> anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The extension in this document is intended to mitigate two possible
      threats in IKEv2, namely IKEv2: the compromise of (EC)DH key exchange using
      Shor's algorithm while remaining backward compatible; compatible and the potential
      compromise of existing or future PQC key exchange algorithms.  To
      address the former threat, this extension allows the establishment of a
      shared secret by using multiple key
        exchanges, typically exchanges: typically, one classical
      (EC)DH and the other one post-quantum algorithm.  In order to address
      the latter threat, multiple key exchanges using a post-quantum algorithm
      can be composed performed to form the shared key.
      </t>
      <t>Unlike key exchange methods (Transform Type 4), the Encryption
      Algorithm (Transform Type 1), the Pseudorandom Function (Transform Type 2)
      2), and the Integrity Algorithm (Transform Type 3) are not susceptible
      to Shor's algorithm.  However, they are susceptible to Grover's attack
      <xref target="GROVER"/>, target="GROVER" format="default"/>, which allows a quantum
      computer to perform a brute force key search search, using quadratically fewer
      steps than the classical counterpart.  Simply increasing the key length
      can mitigate this attack.  It was previously believed that one needed to
      double the key length of these algorithms.  However, there are a number
      of factors that suggest that it is quite unlikely to achieve the
      quadratic speed up speedup using Grover's algorithm.  According to NIST <xref target="NISTPQCFAQ"/>,
      target="NISTPQCFAQ" format="default"/>, current applications can
      continue using an AES algorithm with the minimum key length of 128 bit. bits.
      Nevertheless, if the data needs to remain secure for many years to come,
      one may want to consider using a longer key size for the algorithms in
      Transform Types 1-3.
      </t>
      <t>SKEYSEED is calculated from shared SK(x) SK(x), using an algorithm defined
    	in Transform Type 2.  While a quantum attacker may learn the value
    	of SK(x), if this value is obtained by means of a classical key exchange,
    	other SK(x) values generated by means of a post-quantum algorithm
    	ensure that the final SKEYSEED is not compromised.  This assumes that
    	the algorithm defined in the Transform Type 2 is quantum resistant.
      </t>
      <t>The ordering of the additional key exchanges should not matter in
      general, as only the final shared secret is of interest.  Nonetheless,
      because the strength of the running shared secret increases with every
      additional key exchange, an implementer may want to first perform the
      most secure method (in some metrics) and followed by less secure one(s).</t>

        <t> The
      methods.</t>
      <t>The main focus of this document is to prevent a passive attacker from
  performing a "harvest and decrypt" attack.  In "harvest-and-decrypt" attack: in other words, an attacker attackers that records record
  messages exchanged today and proceeds proceed to decrypt them once
        he owns a they have access
  to cryptographically relevant quantum computer. computers.  This attack is prevented due to the hybrid
        nature of the key exchange.  Other attacks involving an active attacker
        using a quantum-computer are not completely solved by this
        document.  This is for two reasons.</t>

        <t> The reasons:</t>
      <ul><li>The first reason is because that the authentication step remains
        classical.  In particular, the authenticity of the SAs established
        under IKEv2 is protected by using a pre-shared key or digital signature
        algorithms.  Whilst  While the pre-shared key option, provided the key is
        long enough, is post-quantum secure, the other algorithms are not.   Moreover,
        in implementations where scalability is a requirement, the pre-shared
        key method may not be suitable.  Post-quantum authenticity may be
        provided by using a post-quantum digital signature.
        </t>

        <t> Secondly,
      </li>
      <li>Secondly, it should be noted that the purpose of post-quantum algorithms is
        to provide resistance to attacks mounted in the future.  The current
        threat is that encrypted sessions are subject to eavesdropping and are
        archived with decryption by quantum computers taking place at some
        point in the future.  Until quantum computers become available available, there
        is no point in attacking the authenticity of a connection because
        there are no possibilities for exploitation.  These only occur at
        the time of the connection, for example example, by mounting an on-path
        attack.  Consequently  Consequently, there is less urgency for
        post-quantum authenticity compared to post-quantum confidentiality.</t> confidentiality.</li></ul>
      <t> Performing multiple key exchanges while establishing an IKE SA
      increases the responder's susceptibility to DoS attacks, attacks because of an
      increased amount of resources needed before the initiator is
      authenticated.  This is especially true for post-quantum key exchange
      methods, where many of them are more memory and/or CPU intensive than
      the classical counterparts.
      </t>
      <t> Responders may consider recommendations from <xref target="RFC8019" />
      format="default"/> to deal with increased DoS attack DoS-attack susceptibility.  It
      is also possible that the responder only agrees to create an initial IKE SA
      without performing additional key exchanges, provided exchanges if the initiator includes
      such an option in its proposals.  Then  Then, peers immediately rekey the
      initial IKE SA with the CREATE_CHILD_SA exchange exchange, and additional key
      exchanges are performed via the IKE_FOLLOWUP_KE exchanges.  In this
      case, at the point when resource-intensive operations are required, the
      peers have already authenticated each other.  However, in the context of
      hybrid post-quantum key exchange exchanges, this scenario would leave the initial
      IKE SA (and initial Child SA SA, if it is created) unprotected against
      quantum computers. Nevertheless Nevertheless, the rekeyed IKE SA (and Child SAs that
      will be created over it) will have a full protection.  This is similar
      to the scenario described in <xref target="RFC8784" />. format="default"/>.
      Depending on the arrangement and peers' policy, this scenario may or may
      not be appropriate.  For example, in the G-IKEv2 protocol <xref target="I-D.ietf-ipsecme-g-ikev2"/>
      target="I-D.ietf-ipsecme-g-ikev2" format="default"/>, the cryptographic
      materials are sent from the group controller to the group members when
      the initial IKE SA is created.
      </t>
    </section>

    <section title="Acknowledgements" anchor="acknowledgements">
        <t> The authors would like to thank Frederic Detienne and Olivier
        Pelerin for their comments and suggestions, including the idea to
        negotiate the post-quantum algorithms using the existing KE payload.
        The authors are also grateful to Tobias Heider and Tobias Guggemos for valuable comments.
        Thanks to Paul Wouters for reviewing the document.</t>
    </section>
  </middle>
  <back>
        <references title='Normative References'>
    	&RFC2119;
    	&RFC7296;
    	&RFC8174;
	&RFC9242;

<displayreference target="I-D.ietf-ipsecme-g-ikev2" to="G-IKEV2"/>
<displayreference target="I-D.tjhai-ikev2-beyond-64k-limit" to="BEYOND-64K"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9242.xml"/>
      </references>
    <references title='Informative References'>
        &RFC6023;
        &RFC7383;
        &RFC8019;
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6023.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7383.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8019.xml"/>

	 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8247.xml"/>

        <reference anchor="GROVER"><front> anchor="GROVER">
          <front>
            <title>A Fast Quantum Mechanical Algorithm fast quantum mechanical algorithm for Database Search</title> database search</title>
            <author fullname="L. Grover" initials="L." surname="Grover">
            </author>
            <date month="May" year="1996"/>
          </front>
          <seriesInfo name="Proc." value="of the Twenty-Eighth Annual ACM Symposium on the Theory of Computing (STOC 1996)"/> (STOC), pp. 212-219"/>
	  <seriesInfo name="DOI" value="10.48550/arXiv.quant-ph/9605043"/>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8784.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5723.xml"/>

         <reference anchor="I-D.ietf-ipsecme-g-ikev2">
	   <front>
	     <title>Group Key Management using IKEv2</title>
	     <author initials="V" surname="Smyslov" fullname="Valery Smyslov">
	       <organization>ELVIS-PLUS</organization>
	     </author>
	     <author initials="B" surname="Weis" fullname="Brian Weis">
	       <organization>Independent</organization>
	     </author>
	     <date month="April" day="19" year="2023"/>
	   </front>
	   <seriesInfo name="Internet-Draft" value="draft-ietf-ipsecme-g-ikev2-09"/>
	 </reference>

         <reference anchor="I-D.tjhai-ikev2-beyond-64k-limit">
	   <front>
	     <title>Beyond 64KB Limit of IKEv2 Payloads</title>
	     <author initials="CJ." surname="Tjhai" fullname="CJ. Tjhai">
	       <organization>Post-Quantum</organization>
	     </author>
	     <author initials="T." surname="Heider" fullname="Tobias Heider">
	       <organization>genua GmbH</organization>
	     </author>
	     <author initials="V." surname="Smyslov" fullname="Valery Smyslov">
	       <organization>ELVIS-PLUS</organization>
	     </author>
	     <date month="July" day="28" year="2022"/>
	   </front>
	   <seriesInfo name="Internet-Draft" value="draft-tjhai-ikev2-beyond-64k-limit-03"/>
	 </reference>
        &RFC8784;
        &RFC5723;
        &I-D.ietf-ipsecme-g-ikev2;
	&I-D.tjhai-ikev2-beyond-64k-limit;

        <reference anchor="IKEV2TYPE4ID" target="https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8"> target="https://www.iana.org/assignments/ikev2-parameters/">
          <front>
            <title>Internet Key Exchange Version 2 (IKEv2) Parameters:
            Transform Type 4 - Diffie-Hellman Group Transform IDs</title>
                <author fullname="IANA"></author>
	    <author><organization>IANA</organization></author>
          </front>
        </reference>

        <reference anchor="NISTPQCFAQ" target="https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs">
          <front>
            <title>Post-Quantum Cryptography Standardization: FAQs</title>
                <author fullname="NIST"></author> Standard</title>
	    <author><organization>NIST</organization></author>
	    <date month="January" year="2023"/>
          </front>
        </reference>

      </references>
    </references>

    <section title="Sample anchor="sample-exchanges" numbered="true" toc="default">
      <name>Sample Multiple Key Exchanges" anchor="sample-exchanges"> Exchanges</name>
      <t>This appendix shows some examples of multiple key exchanges.  These
      examples are non-normative not normative, and they describe some message flow scenarios
      that may occur in establishing an IKE or CHILD Child SA.  Note that some
      payloads that are not relevant to multiple key exchanges may be omitted
      for brevity.
      </t>
      <section title="IKE_INTERMEDIATE anchor="sample-ake-ike-intermediate" numbered="true" toc="default">
        <name>IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange Payloads" anchor="sample-ake-ike-intermediate"> Payloads</name>
        <t>The exchanges below show that the initiator proposes the use of
        additional key exchanges to establish an IKE SA.  The initiator
        proposes three sets of additional key exchanges and exchanges, all of which are
        optional.
        So  Therefore, the responder can choose NONE for some or all of
        the additional exchanges if the proposed key exchange methods are not
        supported or for whatever reasons the responder decides not to perform
        the additional key exchange.</t>

        <figure><artwork align="center"><![CDATA[

<artwork align="center" name="" type="" alt=""><![CDATA[
Initiator                     Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. AKE*...), ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
    Proposal #1
    Transform ECR (ID = ENCR_AES_GCM_16,
                    256-bit key)
    Transform PRF (ID = PRF_HMAC_SHA2_512)
    Transform KE (ID = Curve25519)
    Transform AKE1 ADDKE1 (ID = PQ_KEM_1)
    Transform AKE1 ADDKE1 (ID = PQ_KEM_2)
    Transform AKE1 ADDKE1 (ID = NONE)
    Transform AKE2 ADDKE2 (ID = PQ_KEM_3)
    Transform AKE2 ADDKE2 (ID = PQ_KEM_4)
    Transform AKE2 ADDKE2 (ID = NONE)
    Transform AKE3 ADDKE3 (ID = PQ_KEM_5)
    Transform AKE3 ADDKE3 (ID = PQ_KEM_6)
    Transform AKE3 ADDKE3 (ID = NONE)
                   <--- HDR(IKE_SA_INIT), SAr1(.. AKE*...), ADDKE*...),
                        KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
                        N(INTERMEDIATE_EXCHANGE_SUPPORTED)
                        Proposal #1
                          Transform ECR (ID = ENCR_AES_GCM_16,
                                         256-bit key)
                          Transform PRF (ID = PRF_HMAC_SHA2_512)
                          Transform KE (ID = Curve25519)
                          Transform AKE1 ADDKE1 (ID = PQ_KEM_2)
                          Transform AKE2 ADDKE2 (ID = NONE)
                          Transform AKE3 ADDKE3 (ID = PQ_KEM_5)

HDR(IKE_INTERMEDIATE), SK {KEi(1)(PQ_KEM_2)} -->
                   <--- HDR(IKE_INTERMEDIATE), SK {KEr(1)(PQ_KEM_2)}
HDR(IKE_INTERMEDIATE), SK {KEi(2)(PQ_KEM_5)} -->
                   <--- HDR(IKE_INTERMEDIATE), SK {KEr(2)(PQ_KEM_5)}

HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } --->
                      <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2,
                           TSi, TSr }
        ]]></artwork></figure>
			   ]]>
</artwork>

        <t>In this particular example, the responder chooses to perform two
        additional key exchanges.  It selects PQ_KEM_2, NONE NONE, and PQ_KEM_5 for
        the first, second second, and third additional key exchanges exchanges, respectively.  As
        per <xref target="RFC7296"/> specification, target="RFC7296" format="default"/>, a set of
        keying materials are is derived, in particular SK_d, SK_a[i/r], and
        SK_e[i/r].  Both peers then perform an IKE_INTERMEDIATE exchange exchange,
        carrying PQ_KEM_2 payload payload, which is protected with SK_e[i/r] and
        SK_a[i/r] keys.  After the completion of this IKE_INTERMEDIATE
        exchange, the SKEYSEED is updated using SK(1), which is the PQ_KEM_2
        shared secret, as follows.</t>

            <figure><artwork

<artwork align="left" ><![CDATA[ name="" type="" alt=""><![CDATA[
SKEYSEED(1) = prf(SK_d, SK(1) | Ni | Nr)
            ]]></artwork></figure>
]]>
</artwork>

        <t>The updated SKEYSEED value is then used to derive the following keying materials</t>

            <figure><artwork materials.</t>

<artwork align="left" ><![CDATA[ name="" type="" alt=""><![CDATA[
{SK_d(1) | SK_ai(1) | SK_ar(1) | SK_ei(1) | SK_er(1) | SK_pi(1) |
 SK_pr(1)} = prf+ (SKEYSEED(1), Ni | Nr | SPIi | SPIr)
            ]]></artwork></figure>
 ]]>
</artwork>

        <t>As per <xref target="RFC9242"/> specification, target="RFC9242" format="default"/>,
        both peers compute IntAuth_i1 and IntAuth_r1 using the SK_pi(1) and
        SK_pr(1) keys keys, respectively.  These values are required in the IKE_AUTH
        phase of the exchange.</t>
        <t>In the next IKE_INTERMEDIATE exchange, the peers use SK_e[i/r](1)
        and SK_a[i/r](1) keys to protect the PQ_KEM_5 payload.  After
        completing this exchange, keying materials are updated as below</t>

            <figure><artwork follows:</t>

<artwork align="left" ><![CDATA[ name="" type="" alt=""><![CDATA[
SKEYSEED(2) = prf(SK_d(1), SK(2) | Ni | Nr)
{SK_d(2) | SK_ai(2) | SK_ar(2) | SK_ei(2) | SK_er(2) | SK_pi(2) |
    SK_pr(2)} = prf+ (SKEYSEED(2), Ni | Nr | SPIi | SPIr)
            ]]></artwork></figure>

            <t>where
    ]]>
</artwork>

        <t>In this update, SK(2) is the shared secret from the third
        additional key exchange, i.e. i.e., PQ_KEM_5.  Both  Then, both peers then compute the
        values of IntAuth_[i/r]2 using the SK_p[i/r](2) keys.
        </t>

        <t>After the completion of the second IKE_INTERMEDIATE exchange, both
        peers continue to the IKE_AUTH exchange phase.  As defined in <xref target="RFC9242"/>,
        target="RFC9242" format="default"/>, the values IntAuth_[i/r]2 are
        used to compute IntAuth which IntAuth, which, in turn turn, is used to calculate
            the payload to be signed or MACed, i.e.  InitiatorSignedOctets and ResponderSignedOctets.</t>
ResponderSignedOctets blobs (see <xref target="RFC9242" sectionFormat="of" section="3.3.2" />).</t>
      </section>
      <section title="No anchor="sample-exchanges-none-selected" numbered="true" toc="default">
        <name>No Additional Key Exchange Used" anchor="sample-exchanges-none-selected"> Used</name>
        <t>The initiator proposes two sets of optional additional key
        exchanges, but the responder does not support any of them.  The
        responder chooses NONE for each set and consequently, set. Consequently, the
        IKE_INTERMEDIATE exchange does not takes place take place, and the exchange
        proceeds to the IKE_AUTH phase.  The resulting keying materials are the
        same as those derived with <xref target="RFC7296"/>.</t>

      <figure><artwork align="center"><![CDATA[ target="RFC7296"
        format="default"/>.</t>

<artwork align="center" name="" type="" alt=""><![CDATA[
Initiator                     Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. AKE*...), ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
  Proposal #1
    Transform ECR (ID = ENCR_AES_GCM_16,
                   256-bit key)
    Transform PRF (ID = PRF_HMAC_SHA2_512)
    Transform KE (ID = Curve25519)
    Transform AKE1 ADDKE1 (ID = PQ_KEM_1)
    Transform AKE1 ADDKE1 (ID = PQ_KEM_2)
    Transform AKE1 ADDKE1 (ID = NONE)
    Transform AKE2 ADDKE2 (ID = PQ_KEM_3)
    Transform AKE2 ADDKE2 (ID = PQ_KEM_4)
    Transform AKE2 ADDKE2 (ID = NONE)
                   <--- HDR(IKE_SA_INIT), SAr1(.. AKE*...), ADDKE*...),
                        KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
                        N(INTERMEDIATE_EXCHANGE_SUPPORTED)
                          Proposal #1
                            Transform ECR (ID = ENCR_AES_GCM_16,
                                           256-bit key)
                            Transform PRF (ID = PRF_HMAC_SHA2_512)
                            Transform KE (ID = Curve25519)
                            Transform AKE1 ADDKE1 (ID = NONE)
                            Transform AKE2 ADDKE2 (ID = NONE)

HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } --->
                   <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2,
                        TSi, TSr }
      ]]></artwork></figure>
			]]>
</artwork>

      </section>
      <section title="Additional anchor="sample-exchanges-ake-child-sas" numbered="true" toc="default">
        <name>Additional Key Exchange in the CREATE_CHILD_SA Exchange only" anchor="sample-exchanges-ake-child-sas"> Only</name>
        <t>The exchanges below show that the initiator does not propose the
        use of additional key exchanges to establish an IKE SA, but they are
        required in order to establish a Child SA.  In order to establish a
        fully quantum-resistant IPsec SA, the responder includes a
        CHILDLESS_IKEV2_SUPPORTED notification in their IKE_SA_INIT response
        message.  The initiator understands and supports this notification, then
        exchanges a modified IKE_AUTH message with the
      responder responder, and
        rekeys the IKE SA immediately with additional key exchanges.  Any
        Child SA will have to be created via a subsequent CREATED_CHILD_SA
        exchange.
        </t>

      <figure><artwork align="center"><![CDATA[

<artwork align="center" name="" type="" alt=""><![CDATA[
Initiator                     Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1, --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED)
                   <--- HDR(IKE_SA_INIT), SAr1,
                        KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
                        N(CHILDLESS_IKEV2_SUPPORTED)

HDR(IKE_AUTH), SK{ IDi, AUTH  } --->
                   <--- HDR(IKE_AUTH), SK{ IDr, AUTH }

HDR(CREATE_CHILD_SA),
      SK{ SAi(.. AKE*...), ADDKE*...), Ni, KEi(Curve25519) } --->
  Proposal #1
    Transform ECR (ID = ENCR_AES_GCM_16,
                   256-bit key)
    Transform PRF (ID = PRF_HMAC_SHA2_512)
    Transform KE (ID = Curve25519)
    Transform AKE1 ADDKE1 (ID = PQ_KEM_1)
    Transform AKE1 ADDKE1 (ID = PQ_KEM_2)
    Transform AKE2 ADDKE2 (ID = PQ_KEM_5)
    Transform AKE2 ADDKE2 (ID = PQ_KEM_6)
    Transform AKE2 ADDKE2 (ID = NONE)
                   <--- HDR(CREATE_CHILD_SA), SK{ SAr(.. AKE*...), ADDKE*...),
                        Nr, KEr(Curve25519),
                        N(ADDITIONAL_KEY_EXCHANGE)(link1) }
                          Proposal #1
                            Transform ECR (ID = ENCR_AES_GCM_16,
                                           256-bit key)
                            Transform PRF (ID = PRF_HMAC_SHA2_512)
                            Transform KE (ID = Curve25519)
                            Transform AKE1 ADDKE1 (ID = PQ_KEM_2)
                            Transform AKE2 ADDKE2 (ID = PQ_KEM_5)

HDR(IKE_FOLLOWUP_KE), SK{ KEi(1)(PQ_KEM_2), --->
N(ADDITIONAL_KEY_EXCHANGE)(link1) }
                  <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(1)(PQ_KEM_2),
                        N(ADDITIONAL_KEY_EXCHANGE)(link2) }

HDR(IKE_FOLLOWUP_KE), SK{ KEi(2)(PQ_KEM_5), --->
N(ADDITIONAL_KEY_EXCHANGE)(link2) }
                  <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(2)(PQ_KEM_5) }
      ]]></artwork></figure>
		  ]]>
</artwork>

      </section>
      <section title="No anchor="sample-exchanges-no-proposal-chosen" numbered="true" toc="default">
        <name>No Matching Proposal for Additional Key Exchanges" anchor="sample-exchanges-no-proposal-chosen"> Exchanges</name>
        <t>The initiator proposes the combination of PQ_KEM_1, PQ_KEM_2,
        PQ_KEM_3, and PQ_KEM_4 as the additional key exchanges.  The initiator
        indicates that either PQ_KEM_1 or PQ_KEM_2 must be used to establish
        an IKE SA, but Additional Key Exchange 2 ADDKE2 Transform Type is optional so optional. Therefore, the
        responder can either select PQ_KEM_3 or PQ_KEM_4 or omit this key
        exchange by selecting NONE.  The responder,
      although  Although the responder supports the
        optional PQ_KEM_3 and PQ_KEM_4 methods, it does not support
        either the PQ_KEM_1 or the PQ_KEM_2 mandatory method and therefore method; therefore, it responds
        with a NO_PROPOSAL_CHOSEN notification.  </t>

      <figure><artwork align="center"><![CDATA[

<artwork align="center" name="" type="" alt=""><![CDATA[
Initiator                     Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. AKE*...), ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
  Proposal #1
    Transform ECR (ID = ENCR_AES_GCM_16,
                   256-bit key)
    Transform PRF (ID = PRF_HMAC_SHA2_512)
    Transform KE (ID = Curve25519)
    Transform AKE1 ADDKE1 (ID = PQ_KEM_1)
    Transform AKE1 ADDKE1 (ID = PQ_KEM_2)
    Transform AKE2 ADDKE2 (ID = PQ_KEM_3)
    Transform AKE2 ADDKE2 (ID = PQ_KEM_4)
    Transform AKE2 ADDKE2 (ID = NONE)
                         <--- HDR(IKE_SA_INIT), N(NO_PROPOSAL_CHOSEN)
      ]]></artwork></figure>
			 ]]>
</artwork>

      </section>
    </section>
    <section title="Design Criteria" anchor="design"> anchor="design" numbered="true" toc="default">
      <name>Design Criteria</name>
      <t>
        The design of the extension is driven by the
        following criteria:</t>

    	<t><list style="hanging" hangIndent="5"><t hangText="1)">
    	Need
      <ol type="%d)" spacing="normal">
        <li><t>Need for PQC in IPsec.  Quantum IPsec</t>
	<t>Quantum computers, which might become feasible in the near future,
	pose a threat to our classical public key cryptography.  PQC, a family
	of public key cryptography that is believed to be resistant against to
	these computers, needs to be integrated into the IPsec protocol suite
	to restore confidentiality and authenticity.</t>

    	<t hangText="2)">
    	Hybrid.  There authenticity.</t></li>
        <li><t>Hybrid</t>
	<t>There is currently no post-quantum key exchange that is trusted at
	the level that (EC)DH is trusted for defending against conventional
	(non-quantum) adversaries.  A hybrid post-quantum algorithm to be introduced
	introduced, along with the well-established primitives primitives, addresses this
	concern, since the overall security is at least as strong as each
	individual primitive.
    	</t>

    	<t hangText="3)">
    	Focus primitive.</t>
    	</li>
        <li>
    	<t>Focus on post-quantum confidentiality.  A confidentiality</t>
	<t>A passive attacker can store
    	all monitored encrypted IPsec communication today and decrypt it once
    	a quantum computer is available in the future.  This attack can have
    	serious consequences that will not be visible for years to come.  On
    	the other hand, an attacker can only perform active attacks attacks, such as
    	impersonation of the communicating peers peers, once a quantum computer is available,
    	available sometime in the future.  Thus, this specification focuses
    	on confidentiality due to the urgency of this problem and presents a
    	defense against the serious attack described above, but it does not
    	address authentication since because it is less urgent at this stage.
    	</t>

    	<t hangText="4)">
    	Limit stage.</t>
    	</li>
        <li>
    	<t>Limit the amount of exchanged data.  The data</t>
	<t>The protocol design should be
    	such that the amount of exchanged data, such as public-keys, public keys, is
        kept as small as possible possible, even if the initiator and the responder need
        to agree on a hybrid group or if multiple public-keys public keys need to be
        exchanged.
    	</t>

    	<t hangText="5)">
    	Not
        exchanged.</t>
    	</li>
        <li>
    	<t>Not post-quantum specific.  Any specific</t>
	<t>Any cryptographic algorithm could be potentially
    	broken in the future by currently unknown or impractical
        attacks: quantum
        attacks. Quantum computers are merely the most concrete example
        of this.  The design does not categorize algorithms as "post-quantum"
    	or "non post-quantum" "non-post-quantum", nor does it create assumptions
        about the properties of the algorithms, algorithms; meaning that if
        algorithms with different properties become necessary in the future,
        this extension can be used unchanged to facilitate migration to
        those algorithms.
    	</t>

    	<t hangText="6)">
    	Limited algorithms.</t>
    	</li>
        <li>
    	<t>Limited amount of changes.  A changes</t>
	<t>A key goal is to limit the number of
    	changes required when enabling a post-quantum handshake.  This
        ensures easier and quicker adoption in existing implementations.
    	</t>

    	<t hangText="7)">
    	Localized changes.  Another implementations.</t>
    	</li>

        <li>
    	<t>Localized changes</t>
	<t>Another key requirement is that changes to
    	the protocol are limited in scope, in particular, limiting
        changes in the exchanged messages and in the state machine, so
        that they can be easily implemented.
    	</t>

    	<t hangText="8)">
    	Deterministic operation.  This implemented.</t>
    	</li>
        <li>
    	<t>Deterministic operation</t>
	<t>This requirement means that the hybrid post-quantum exchange, and exchange and, thus,
	the computed keys, keys will be based on algorithms that both client and
	server wish to support.
    	</t>

    	<t hangText="9)">
    	Fragmentation support.  Some support.</t>
    	</li>
        <li>
    	<t>Fragmentation support</t>
	<t>Some PQC algorithms could be relatively
    	bulky and they might require fragmentation.  Thus, a design goal
        is the adaptation and adoption of an existing fragmentation
        method or the design of a new method that allows for the
        fragmentation of the key shares.
    	</t>

    	<t hangText="10)">
    	Backwards shares.</t>
    	</li>
        <li>
    	<t>Backward compatibility and interoperability.  This interoperability</t>
	<t>This is a fundamental
    	requirement to ensure that hybrid post-quantum IKEv2 and standard
    	IKEv2 implementations as per <xref target="RFC7296"/> specification target="RFC7296" format="default"/>
    	are interoperable.
    	</t>

    	<t hangText="11)"> interoperable.</t>
    	</li>
        <li>
    	<t>Compliance with USA Federal Information Processing Standards (FIPS) compliance.  IPsec (FIPS)</t>
	<t>IPsec is widely used in Federal Information
    	Systems Systems, and FIPS
	certification is an important requirement.  However, at the time of
	writing, none of the algorithms that is believed to be post-quantum is yet
	FIPS compliant yet. compliant.  Nonetheless, it is possible to combine this
	post-quantum algorithm with a FIPS compliant FIPS-compliant key establishment method
	so that the overall design remains FIPS compliant <xref target="NISTPQCFAQ"/>.
    	</t>

        <t hangText="12)">
        Ability
	target="NISTPQCFAQ" format="default"/>.</t>
    	</li>
        <li>
        <t>Ability to use this method with multiple classical (EC)DH key exchanges.
        In
        exchanges</t>
        <t>In some situations situations, peers have no single single, mutually trusted trusted, key
        exchange algorithm (e.g., due to local policy restrictions).  The
        ability to combine two (or more) key exchange methods in such a way
        that the resulting shared key depends on all of them allows peers to
        communicate in this situation.
        </t>

        </list>
    	</t> situation.</t>
        </li>
      </ol>
    </section>
    <section title="Alternative Design" anchor="altdesign"> anchor="altdesign" numbered="true" toc="default">
      <name>Alternative Design</name>
      <t>
        This section gives an overview on a number of alternative approaches
        that have been considered, considered but later discarded.  These approaches are:</t>

        <t><list style="symbols"> are as follows.</t>
      <ul spacing="normal">
        <li>
          <t>Sending the classical and post-quantum key
        exchanges as a single transform<vspace blankLines="1"/> transform</t>
          <t>
        A method to combine the various key exchanges into a single large KE
        payload was considered; this considered. This effort is documented in a previous
        version of this
        draft document (draft-tjhai-ipsecme-hybrid-qske-ikev2-01).
        This does allow method allows us to cleanly apply hybrid key exchanges during the
        Child SA; however SA. However, it does add considerable complexity, complexity and requires an
        independent fragmentation solution.
          </t>
        </li>
        <li>
          <t>Sending post-quantum proposals and policies in the KE payload
        only<vspace blankLines="1"/>
        only</t>
        <t>

        With the objective of not introducing unnecessary notify payloads, a
        method to communicate the hybrid post-quantum proposal in the KE
        payload during the first pass of the protocol exchange was considered.
        Unfortunately, this design is susceptible to the following downgrade
        attack.  Consider the scenario where there is an on-path attacker
        sitting between an initiator and a responder.  The initiator proposes,
        through Through the SAi payload, to use the
        initiator proposes using a hybrid post-quantum group and and, as a fallback
        fallback, a Diffie-Hellman group, group; and through the KEi payload, the
        initiator proposes a list of hybrid post-quantum proposals and
        policies.  The on-path attacker intercepts this traffic and replies
        with N(INVALID_KE_PAYLOAD) N(INVALID_KE_PAYLOAD), suggesting
        to a downgrade to the fallback
        Diffie-Hellman group instead.  The initiator then resends the same SAi
        payload and the KEi payload containing the public value of the
        fallback Diffie-Hellman group.  Note that the attacker may forward the
        second IKE_SA_INIT message only to the responder, and
        therefore responder. Therefore, at this
        point in time, the responder will not have the information that the
        initiator prefers the hybrid group. Of course, it is possible for the
        responder to have a policy to reject an IKE_SA_INIT message that (a)
        offers a hybrid group but does not offering offer the corresponding public value
        in the KEi payload; payload and (b) the responder has not specifically
        acknowledged that it does not
        supported support the requested hybrid group.
        However, the checking of this policy introduces unnecessary protocol
        complexity.  Therefore, in order to fully prevent any downgrade
        attacks, using a KE payload alone is not sufficient sufficient, and that the initiator MUST
        <bcp14>MUST</bcp14> always indicate its preferred post-quantum
        proposals and policies in a notify payload in the subsequent
        IKE_SA_INIT messages following a an N(INVALID_KE_PAYLOAD) response.</t>
        </li>
        <li>
          <t>New payload types to negotiate hybrid proposal proposals and to carry post-
        quantum
          post-quantum public values<vspace blankLines="1"/> values</t>
          <t>
        Semantically, it makes sense to use a new payload type, which mimics
        the SA payload, to carry a hybrid proposal.  Likewise, another new
        payload type that mimics the KE payload, payload could be used to transport
        hybrid public value.  Although, in theory theory, a new payload type could be
        made
        backwards backward compatible by not setting its critical flag as per Section 2.5
        of
        <xref target="RFC7296" />, sectionFormat="of" section="2.5"/>, it is
        believed that it may not be that simple in practice.  Since the
        original release of IKEv2 in RFC4306, RFC 4306, no new payload type has ever
        been proposed and proposed; therefore, this creates a potential risk of having a
        backward compatibility
        backward-compatibility issue from non-conformant nonconformant IKEv2
        implementations.  Since there appears to be no other compelling
        advantages apart from a semantic one, the existing transform type Transform Type and
        notify payloads are used instead.
          </t>
        </li>
        <li>
          <t>Hybrid public value payload<vspace blankLines="1"/> payload</t>
          <t>
        One way to transport the negotiated hybrid public payload, which
        contains one classical Diffie-Hellman public value and one or more
        post-quantum public values, is to bundle these into a single KE
        payload.  Alternatively, these could also be transported in a single
        new hybrid public value
        payload, but payload. However, following the same reasoning
        as above, this above may not be a good idea from a backward compatibility backward-compatibility
        perspective.  Using a single KE payload would require an encoding or
        formatting to be defined so that both peers are able to compose and
        extract the individual public values.  However, it is believed that it
        is cleaner to send the hybrid public values in multiple KE payloads--one payloads:
        one for each group or algorithm.  Furthermore, at this point in the
        protocol exchange, both peers should have indicated support of for
        handling multiple KE payloads.
          </t>

        <t>Fragmentation<vspace blankLines="1"/>
        Handling
        </li>
        <li>
          <t>Fragmentation</t>
          <t>
        The handling of large IKE_SA_INIT messages has been one of the most
        challenging tasks.  A number of approaches have been considered considered,
        and the two prominent ones that have been discarded are outlined as
        follows.
        <vspace blankLines="1"/>
          </t>
          <t>
        The first approach is to treat the entire IKE_SA_INIT message as
        a stream of bytes, which is then split it into a number of
        fragments, each of which is wrapped onto a payload that will fit
        into the size of the network MTU.  The payload that wraps each
        fragment has a new payload type type, and it is envisaged that this new
        payload type will not cause a backward compatibility backward-compatibility issue because because,
        at this stage of the protocol, both peers should have indicated
        support of fragmentation in the first pass of the IKE_SA_INIT
        exchange.  The negotiation of fragmentation is performed using a
        notify payload, which also defines supporting parameters parameters, such as
        the size of fragment in octets and the fragment identifier.  The
        new payload that wraps each fragment of the messages in this
        exchange is assigned the same fragment identifier. Furthermore, it
        also has other parameters parameters, such as a fragment index and total
        number of fragments.  This approach has been discarded due to
        its blanket approach to fragmentation.  In cases where only a few
        payloads need to be fragmented, this approach appears to be
        overly complicated.
        <vspace blankLines="1"/>
          </t>

          <t>
        Another idea that has been discarded was is fragmenting an individual
        payload without introducing a new payload type.  The idea is to
        use the 9-th bit (the bit after the critical flag in the RESERVED
        field) in the generic payload header as a flag to mark that this
        payload is fragmented.  As an example, if a KE payload is to be
        fragmented, it may look as follows.
          </t>

        </list>
        </t>

        <figure><artwork
	  <figure>
	    <name>Example of How to Fragment a KE Payload</name>
<artwork align="center" ><![CDATA[ name="" type="" alt=""><![CDATA[
                 1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|F| RESERVED  |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Diffie-Hellman Group Number  |     Fragment Identifier       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Fragment Index        |        Total Fragments        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Total KE Payload Data Length                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       Fragmented KE Payload                   ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]></artwork></figure>

        <t><list hangIndent="3" style="hanging"><t>
]]>
</artwork>
</figure>
        <t>
        When the flag F is set, this means the current KE payload is a
        fragment of a larger KE payload.  The Payload Length field denotes
        the size of this payload fragment in octets--including octets: including the size of
        the generic payload header.  The two-octet 2-octet RESERVED field
        following Diffie-Hellman Group Number was to be used as a fragment
        identifier to help the assembly and disassembly of fragments.  The
        Fragment Index and Total Fragments fields are self-explanatory.
        The Total KE Payload Data Length indicates the size of the
        assembled KE payload data in octets.  Finally, the actual fragment
        is carried in Fragment KE Payload field.</t>

        </list>
        </t>

        <t><list hangIndent="3" style="hanging"><t>

        <t>
        This approach has been discarded because it is believed that the
        working group may not want to use the RESERVED field to change the
        format of a packet packet, and that implementers may not like the added
        complexity from checking the fragmentation flag in each received
        payload. More importantly, fragmenting the messages in this way
     may leave the system to be more prone to denial of
        service denial-of-service (DoS)
     attacks.  By  This issue can be solved using IKE_INTERMEDIATE <xref target="RFC9242" format="default"/> to
     transport the large post-quantum key exchange payloads, payloads and using
     the generic IKEv2 fragmentation protocol
        <xref target="RFC7383" /> solve the issue.</t>
        </list>
        </t>

        <t><list style="symbols"><t>Group sub-identifier<vspace blankLines="1"/> format="default"/>.</t>
      </li>
        <li>
          <t>Group sub-identifier</t>
          <t>
        As discussed before, each group identifier is used to distinguish a
        post-quantum algorithm.  Further classification could be made on a
        particular post-quantum algorithm by assigning an additional value
        alongside the group identifier.  This sub-
        identifier sub-identifier value may be used
        to assign different security
        parameter security-parameter sets to a given post-quantum
        algorithm.  However, this level of details detail does not fit the principles
        of the document where it should deal with generic hybrid key exchange protocol,
        protocol and not a specific ciphersuite.  Furthermore, there are
        enough Diffie-
        Hellman Diffie-Hellman group identifiers should this be required in the
        future.
          </t>

        </list>
        </t>
        </li>
      </ul>
    </section>
    <section anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t> The authors would like to thank <contact fullname="Frederic
      Detienne"/> and <contact fullname="Olivier Pelerin"/> for their comments
      and suggestions, including the idea to negotiate the post-quantum
      algorithms using the existing KE payload.  The authors are also grateful
      to <contact fullname="Tobias Heider"/> and <contact fullname="Tobias
      Guggemos"/> for valuable comments.  Thanks to <contact fullname="Paul
      Wouters"/> for reviewing the document.</t>
    </section>
  </back>
</rfc>