draft-kampanakis-ml-kem-ikev2-02.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.2 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-kampanakis-ml-kem-ikev2-02" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.2 -->
  <front>
    <title abbrev="ML-KEM IKEv2">Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
    <seriesInfo name="Internet-Draft" value="draft-kampanakis-ml-kem-ikev2"/>
    <author fullname="Panos Kampanakis">
      <organization>Amazon Web Services</organization>
      <address>
        <email>kpanos@amazon.com</email>
      </address>
    </author>
    <author fullname="Gerardo Ravago">
      <organization>Amazon Web Services</organization>
      <address>
        <email>gcr@amazon.com</email>
      </address>
    </author>
    <date/>
    <area>Security</area>
    <workgroup>IPSECME</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>[EDNOTE: The intention of this draft is to get IANA KE codepoints for ML-KEM. It could be a standards track draft given that ML-KEM will see a lot of adoption, an AD sponsored draft, or even an individual stable draft which gets codepoints from Expert Review. The approach is to be decided by the IPSECME WG. ]</t>

      <t>NIST recently standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft specifies how to use ML-KEM as an additional key exchange in IKEv2 along with traditional key exchanges. This Post-Quantum Traditional Hybrid Key Encapsulation Mechanism approach allows for negotiating IKE and Child SA keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM.</t>
    </abstract>
  </front>
  <middle>

<section anchor="introduction">
      <name>Introduction</name>
      <t>A Cryptanalytically-relevant Quantum Computer (CRQC), if it became a reality, could threaten public key encryption algorithms used today for key exchange. Someone storing encrypted communications which use (Elliptic Curve) Diffie-Hellman ((EC)DH) to negotiate keys could decrypt these communications in the future after a CRQC was available. This includes Internet Key Exchange Protocol Version 2 (IKEv2, which the security is based on using the (EC)DH key exchange in the IKE_SA_INIT messages</t>
      <t>To address this concern, <xref target="RFC8784"/> introduced Post-quantum Preshared Keys as a temporary option for stirring a pre-shared key of adequate entropy in the derived Child SA encryption keys in order to provide quantum-resistance. Since then, <xref target="RFC9242"/> defined how to do additional large message exchanges by using new IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages. As post-quantum keys are usually larger than common network Maximum Transport Units (MTU), IKE_INTERMEDIATE messages can be fragmented which could allow for the peers to do post-quantum key exchanges without IP fragmentation. <xref target="RFC9370"/> defined how to do up to seven additional key exchanges by using IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages and deriving new SKEYSEED and KEYMAT key materials. This allows for new post-quantum key exchanges to be used in the derived IKE and Child SA keys and provide quantum resistance.</t>
      <t>NIST has been working on a public project <xref target="NIST-PQ"/> for standardizing quantum-resistant algorithms which include key encapsulation and signatures. At the end of Round 3, they picked Kyber as the first Key Encapsulation Mechanism (KEM) for standardization <xref target="I-D.draft-cfrg-schwabe-kyber-04"/>. Kyber was then standardized as Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM) in <xref target="FIPS203-ipd"/>. ML-KEM was standardized in 2024 <xref target="FIPS203"/>. [ EDNOTE: Reference normatively the ratified version <xref target="I-D.draft-cfrg-schwabe-kyber-04"/> if it is ever ratified. Otherwise keep a normative reference of <xref target="FIPS203"/>. And remove the reference to <xref target="FIPS203-ipd"/>. ]</t>
      <t>This document describes how ML-KEM can be used as the quantum-resistant KEM in IKEv2 by using one additional IKE_INTERMEDIATE or IKE_FOLLOWUP_KE key exchange after an initial key exchange in IKE_SA_INIT or CREATE_CHILD_SA respectively. This approach of combining a quantum-resistant with a classical algorithm, is commonly called Post-Quantum Traditional (PQ/T) Hybrid <xref target="I-D.ietf-pquip-pqt-hybrid-terminology-02"/> key exchange and combines the security of a well-established algorithm with relatively new quantum-resistant algorithms which could theoretically have unknown issues. The result is a new Child SA key or an IKE or Child SA rekey with keying material which is safe against a CRQC. This specification is a profile of <xref target="RFC9370"/> and registers new algorithm identifiers for ML-KEM key exchanges in IKEv2.</t>
      <section anchor="kems">
        <name>KEMs</name>
        <t>In the context of the NIST Post-Quantum Cryptography Standardization Project <xref target="NIST-PQ"/>, key exchange algorithms are formulated as KEMs, which consist of three steps:</t>
        <ul spacing="normal">
          <li>
            <t>'KeyGen() -&gt; (pk, sk)': A probabilistic key generation algorithm, which generates a public key 'pk' and a secret key 'sk'.</t>
          </li>
          <li>
            <t>'Encaps(pk) -&gt; (ct, ss)': A probabilistic encapsulation algorithm, which takes as input a public key 'pk' and outputs a ciphertext 'ct' and shared secret 'ss'.</t>
          </li>
          <li>
            <t>'Decaps(sk, ct) -&gt; ss': A decapsulation algorithm, which takes as input a secret key 'sk' and ciphertext 'ct' and outputs a shared secret 'ss', or in some cases a distinguished error value.</t>
          </li>
        </ul>
        <t>The main security property for KEMs standardized by NIST is indistinguishability under adaptive chosen ciphertext attacks (IND-CCA2), which means that shared secret values should be indistinguishable from random strings even given the ability to have arbitrary ciphertexts decapsulated. IND-CCA2 corresponds to security against an active attacker, and the public key / secret key pair can be treated as a long-term key or reused.  A weaker security notion is indistinguishability under chosen plaintext attacks (IND-CPA), which means that the shared secret values should be indistinguishable from random strings given a copy of the public key. IND-CPA roughly corresponds to security against a passive attacker, and sometimes corresponds to one-time key exchange.</t>
      </section>
      <section anchor="ml-kem">
        <name>ML-KEM</name>
        <t>ML-KEM is a standardized lattice-based key encapsulation mechanism <xref target="FIPS203"/>. [ EDNOTE: Reference normatively the ratified version <xref target="I-D.draft-cfrg-schwabe-kyber-04"/> if it is ever ratified. Otherwise keep a normative reference of <xref target="FIPS203"/>. ]</t>
        <t>ML-KEM is using Module Learning with Errors as its underlying primitive which is a structured lattices variant that offers good performance and relatively small and balanced key and ciphertext sizes. ML-KEM was standardized with three parameters, ML-KEM-512, ML-KEM-768, and ML-KEM-1024. These were mapped by NIST to the three security levels defined in the NIST PQC Project, Level 1, 3, and 5. These levels correspond to the hardness of breaking AES-128, AES-192 and AES-256 respectively.</t>
        <t>This specification introduces ML-KEM-768 and ML-KEM-1024 to IKEv2 key exchanges as conservative security level parameters which will not have material performance impact on IKEv2/IPsec tunnels which usually stay up for long periods of time. Since the ML-KEM-768 and ML-KEM-1024 public key and ciphertext sizes can exceed the typical network MTU, these key exchanges could require two or three network IP packets from both the initiator and the responder. [ EDNOTE: Consider adding ML-KEM-512 which would fit in one packet. ] </t>
      </section>
      <section anchor="conventions-and-definitions">
        <name>Conventions and Definitions</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      </section>
</section>
    
    <section anchor="ml-kem-in-ikev2">
      <name>ML-KEM in IKEv2</name>
      <section anchor="ml-kem-in-ikeintermediate-messages">
        <name>ML-KEM in IKE_INTERMEDIATE or CREATE_CHILD_SA messages</name>
        <t>ML-KEM key exchanges can be negotiated in IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages as defined in <xref target="RFC9370"/>. We summarize them here for completeness. </t> 
		<t>Section 2.2.2 of <xref target="RFC9370"/> specifies that KEi(0), KEr(0) are regular key exchange messages in the first IKE_SA_INIT exchange which end up generating a set of keying material, SK_d, SK_a[i/r], and SK_e[i/r]. The peers then perform an IKE_INTERMEDIATE exchange, carrying new Key Exchange payloads. These are protected with the SK_e[i/r] and SK_a[i/r] keys which were derived from the IKE_SA_INIT as per Section 3.3.1 of <xref target="RFC9242"/>. KEi(1) and KEr(1) are the subsequent key exchange messages which carry the ML-KEM public key of a keypair (sk, pk) generated by the initiator with ML-KEM KeyGen() and the 256-bit ML-KEM shared secret SK(1) encapsulated by the responder to a ciphertext ct by using Encaps(pk) respectively. The public key and the ciphertext are encoded as raw bytes in little-endian encoding. [ EDNOTE: Confirm this makes sense. ] The initiator then decapsulates the 256-bit ML-KEM shared secret SK(1) from the ciphertext ct by using its private key sk in Decaps(sk, ct). Both peers have now reached a common SK(1) at the end of this KE(1) key exchange. The ML-KEM shared secret is stirred into new keying material SK_d, SK_a[i/r], and SK_e[i/r] as defined in Section 2.2.2 of <xref target="RFC9370"/>. Afterwards the peers continue to the IKE_AUTH exchange phase as defined in Section 3.3.2 of <xref target="RFC9242"/>.</t>
		<t>ML-KEM can also be used to create or rekey a Child SA or rekey the IKE SA by using a IKE_FOLLOWUP_KE message after a CREATE_CHILD_SA message. After the ML-KEM additional key exchange KE(1) has taken place using and IKE_FOLLOWUP_KE exchange, the IKE or Child SA are rekeyed by stirring the new ML-KEM shared secret SK(1) in SKEYSEED and KEYMAT as specified in Section 2.2.4 of <xref target="RFC9370"/>.</t>
		<t>ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts can exceed typical network MTUs (1500 bytes). Thus, IKE_INTERMEDIATE messages carrying ML-KEM public keys and ciphertexts may be IKEv2 fragmented as per <xref target="RFC7383"/>. IKE_FOLLOWUP_KE messages carrying ML-KEM public keys and ciphertexts cannot be IKEv2 fragmented. Thus, ML-KEM-1024 Key Exchange Method identifier TBD37 <bcp14>SHOULD</bcp14> only be used in IKE_INTERMEDIATE exchanges. It <bcp14>SHOULD NOT</bcp14> be used in IKE_FOLLOWUP_KE messages until there is a separate document which defines how such exchanges are split in several messages. [EDNOTE: Confirm ML-KEM-768 fits the MTU with captures, otherwise recommend against ML-KE-768 in IKE_FOLLOWUP_KE as well.] [ EDNOTE: Consider adding ML-KEM-512 which would fit in one packet. ] </t>
		<t>Although, this document focuses on using ML-KEM as the second key exchange in a PQ/T Hybrid KEM <xref target="I-D.ietf-pquip-pqt-hybrid-terminology-02"/> scenario, ML-KEM-768 Key Exchange Method identifier TBD36 <bcp14>MAY</bcp14> be used in IKE_SA_INIT as a quantum-resistant-only key exchange because the encapsulation key is 1184 bytes, which assuming an additional 250 bytes of IKE header data, can fit in typical network MTUs of 1500 bytes. [EDNOTE: Confirm it fits the MTU with captures.] ML-KEM-1024 Key Exchange Method identifier TBD37 <bcp14>SHOULD NOT</bcp14> be used in IKE_SA_INIT messages which could exceed typical network MTUs and cannot be IKEv2 fragmented. [ EDNOTE: Consider adding ML-KEM-512 which would fit in one packet. ] </t>
      </section>
      <section anchor="key-exchange-payload">
        <name>Key Exchange Payload</name>
        <t>HDR, the IKE header, of the IKE_INTERMEDIATE messages carrying the ML-KEM key exchange has a Next Payload value of 34 (Key Exchange), Exchange Type of 43 (IKE_INTERMEDIATE) and Message ID of 1 assuming this is the first additional key exchange (ADDKE1). For IKE_FOLLOWUP_KE messages carrying the ML-KEM key exchange, the Exchange Type would be 44 (IKE_FOLLOWUP_KE).</t>
        <t>The IKE_INTERMEDIATE or IKE_FOLLOWUP_KE payload is shown below as defined in Section 3.4 of <xref target="RFC7296"/>:</t>
        <artwork><![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|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Key Exchange Method Num    |           RESERVED             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       Key Exchange Data                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
]]></artwork>
        <ul spacing="normal">
          <li>
            <t>Payload Length: The ML-KEM-768 public key is 1184 bytes, so the Payload Length field from the initiator would be 1192. The ML-KEM-768 ciphertext is 1088 bytes, so the Payload Length from the responder would be 1096. The ML-KEM-1024 public key is 1568 bytes, so the Payload Length field from the initiator would be 1576. The ML-KEM-1024 ciphertext is 1568 bytes, so the Payload Length from the responder would be 1576. [ EDNOTE: Consider adding ML-KEM-512 which would fit in one packet. ] </t>
          </li>
          <li>
            <t>The Key Exchange Method Num identifier is TBD36 for ML-KEM-768 or TBD37 for ML-KEM-1024. [ EDNOTE: Consider adding ML-KEM-512 which would fit in one packet. ] </t>
          </li>
          <li>
            <t>The Key Exchange Data is the 1184 or 1568 octets of the ML-KEM-768 or ML-KEM-1024 public key respectively for the message from the initiator. The response from the responder is 1088 or 1568 octets as the size of the ML-KEM-768 or ML-KEM-1024 ciphertexts respectively. [ EDNOTE: Consider adding ML-KEM-512 which would fit in one packet. ] </t>
          </li>
        </ul>
      </section>
      <section anchor="receipent-tests">
        <name>Recipient Tests</name>
        <t>Receiving and handling of malformed ML-KEM public key or ciphertext <bcp14>MUST</bcp14> follow the input validation described in <xref target="FIPS203"/>. [ EDNOTE: Reference normatively the ratified version <xref target="I-D.draft-cfrg-schwabe-kyber-04"/> if it is ever ratified. Otherwise keep a normative reference of <xref target="FIPS203"/>. ] In particular, entities receiving the ML-KEM public key to encapsulate to <bcp14>MUST</bcp14> perform the type and modulus checks in Sections 6.1 of <xref target="FIPS203"/> and reject the ML-KEM public key, if malformed. Entities receiving an ML-KEM ciphertext for decapsulation <bcp14>MUST</bcp14> perform the ciphertext and decapsulation key type checks in Section 6.2 of <xref target="FIPS203"/> and reject the ciphertext or key, if malformed. [ EDNOTE: Reference normatively the ratified version <xref target="I-D.draft-cfrg-schwabe-kyber-04"/> if it is ever ratified. Otherwise keep a normative reference of <xref target="FIPS203"/>. ] These checks could be performed separately before performing the encapsulation or decapsulation steps or be part of them. </t>
        <t>Note that during decapsulation, ML-KEM uses implicit rejection which leads the decapsulating entity to implicitly reject the decapsulated shared secret by setting it to a hash of the ciphertext together with a random value stored in the ML-KEM secret when the re-encrypted shared secret does not match the original one. [ EDNOTE: Confirm implicit rejection is still used after <xref target="FIPS203"/> is ratified or change this paragraph. ]</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>All security considerations from <xref target="RFC9242"/> and <xref target="RFC9370"/> apply to the ML-KEM exchanges described in this specification.</t>
      <t>The ML-KEM public key generated by the initiator and the ciphertext generated by the responder use randomness (usually a seed) which must be independent of any other random seed used in the IKEv2 negotiation. For example, at the initiator, the ML-KEM and (EC)DH keypairs used in a PQ/T Hybrid key exchange should not be generated from the same seed.</t>
      <t>Although ML-KEM is IND-CCA2 secure, reusing the same ML-KEM keypair does not offer forward secrecy. The initiator should generate a new ML-KEM keypair with every ML-KEM key exchange.</t>    
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to assign two values for the names "mlkem-768" and "mlkem-1024" in the IKEv2 "Transform Type 4 - Key Exchange Method Transform IDs" and has listed this document as the reference.  The Recipient Tests field should also point to this document:</t>
      <table anchor="tab1">
        <name>Updates to the IANA "Transform Type 4 - Key Exchange Method Transform IDs" table</name>
        <thead>
          <tr>
            <th align="left">Number</th>
            <th align="left">Name</th>
            <th align="left">Status</th>
            <th align="left">Recipient Tests</th>
            <th align="left">Reference</th>
          </tr>
        </thead>
        <tbody> 
          <tr>
            <td align="left">TBD35</td>
            <td align="left">mlkem-512</td>
            <td align="left"> </td>
            <td align="left">[TBD, this draft, <xref target="receipent-tests"/>],</td>
            <td align="left">[TBD, this draft] [ EDNOTE: Consider adding ML-KEM-512. ]</td>
          </tr>
          <tr>
            <td align="left">TBD36</td>
            <td align="left">mlkem-768</td>
            <td align="left"> </td>
            <td align="left">[TBD, this draft, <xref target="receipent-tests"/>],</td>
            <td align="left">[TBD, this draft]</td>
          </tr>
          <tr>
            <td align="left">TBD37</td>
            <td align="left">mlkem-1024</td>
            <td align="left"> </td>
            <td align="left">[TBD, this draft, <xref target="receipent-tests"/>],</td>
            <td align="left">[TBD, this draft]</td>
          </tr>
          <tr>
            <td align="left">37-1023</td>
            <td align="left">Unassigned</td>
            <td align="left"> </td>
            <td align="left"> </td>
            <td align="left"> </td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="FIPS203">
          <front>
            <title>*** BROKEN REFERENCE ***</title>
            <author>
              <organization/>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC9242">
          <front>
            <title>Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
            <author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
            <date month="May" year="2022"/>
            <abstract>
              <t>This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment. The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9242"/>
          <seriesInfo name="DOI" value="10.17487/RFC9242"/>
        </reference>
        <reference anchor="RFC9370">
          <front>
            <title>Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
            <author fullname="CJ. Tjhai" initials="CJ." surname="Tjhai"/>
            <author fullname="M. Tomlinson" initials="M." surname="Tomlinson"/>
            <author fullname="G. Bartlett" initials="G." surname="Bartlett"/>
            <author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
            <author fullname="D. Van Geest" initials="D." surname="Van Geest"/>
            <author fullname="O. Garcia-Morchon" initials="O." surname="Garcia-Morchon"/>
            <author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
            <date month="May" year="2023"/>
          </front>
          <seriesInfo name="RFC" value="9370"/>
          <seriesInfo name="DOI" value="10.17487/RFC9370"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC7296">
          <front>
            <title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
            <author fullname="C. Kaufman" initials="C." surname="Kaufman"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="Y. Nir" initials="Y." surname="Nir"/>
            <author fullname="P. Eronen" initials="P." surname="Eronen"/>
            <author fullname="T. Kivinen" initials="T." surname="Kivinen"/>
            <date month="October" year="2014"/>
          </front>
          <seriesInfo name="STD" value="79"/>
          <seriesInfo name="RFC" value="7296"/>
          <seriesInfo name="DOI" value="10.17487/RFC7296"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
	<reference anchor="I-D.ietf-pquip-pqt-hybrid-terminology-02" target="https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqt-hybrid-terminology-02">
	  <front>
	    <title>Terminology for Post-Quantum Traditional Hybrid Schemes</title>
	    <author initials="F." surname="D" fullname="Florence D">
	      <organization>UK National Cyber Security Centre</organization>
	    </author>
	    <date month="February" day="2" year="2024"/>
          </front>
	  <seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqt-hybrid-terminology-02"/>
	</reference>
        <reference anchor="FIPS203-ipd" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf">
          <front>
            <title>Module-Lattice-based Key-Encapsulation Mechanism Standard</title>
            <author>
              <organization>National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2023" month="August" day="24"/>
          </front>
          <seriesInfo name="NIST" value="Federal Information Processing Standards"/>
        </reference>
        <reference anchor="NIST-PQ">
          <front>
            <title>Post-Quantum Cryptography</title>
            <author>
              <organization>National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date/>
          </front>
          <seriesInfo name="https://csrc.nist.gov/projects/post-quantum-cryptography" value=""/>
        </reference>
        <reference anchor="RFC8784">
          <front>
            <title>Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security</title>
            <author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
            <author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
            <date month="June" year="2020"/>
            <abstract>
              <t>The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8784"/>
          <seriesInfo name="DOI" value="10.17487/RFC8784"/>
        </reference>
        <reference anchor="I-D.draft-cfrg-schwabe-kyber-04" target="https://datatracker.ietf.org/doc/html/draft-cfrg-schwabe-kyber-04">
          <front>
            <title>Kyber Post-Quantum KEM</title>
            <author fullname="Peter Schwabe" initials="P." surname="Schwabe">
              <organization>MPI-SP &amp; Radboud University</organization>
            </author>
            <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
              <organization>Cloudflare</organization>
            </author>
            <date month="January" day="2" year="2024"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-cfrg-schwabe-kyber-04"/>
        </reference>
        <reference anchor="RFC7383">
          <front>
            <title>Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation</title>
            <author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
            <date month="November" year="2014"/>
            <abstract>
              <t>This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7383"/>
          <seriesInfo name="DOI" value="10.17487/RFC7383"/>
        </reference>
      </references>
    </references>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The authors would like to thank Valery Smyslov, Graham Bartlett, Scott Fluhrer, Ben S, and Leonie Bruckert for their valuable feedback.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9Vc7XLbNpf+z6vAOj9s7ysptpw4jqftu6qlNB7HjmM77Xby
ZjIQCUlcUyRLUFbVOL2WvZa9sn3OAUCC+nCStrszdWZiiSSA8/mcD4But9uB
LmUafZBJlqpjURYzFcR5wZ902d3be77XDaIsTOUUt6NCjsr2rZzmMpW3sW5P
k/atmrbjW3XXDUJZHgtdRkGYpVqleqaPxTbNuB3k8XEgRJmFuLJQehtfdFaU
hRpp78pi6l8o4zLBmluXmS7bv8xkWs6m4uViWMSROFMLMfg1nMh0rMQ8Lifi
/FX7bHAu4lSUEyVO01IVqSqbD14WGUjIEvGjKnScpaIrdk7PBnfd3a1ADoeF
usNydiK+vhXo2XAaa3r4ZpGDmtPBzYtAFkoei2sVzoq4XATzrLgdF9ksx+3L
68HJ+SC4nR9XNLT7JLUgkiXGf+z3bgafglu1wKgIQmmLyzcCX4VyVIIFXpzu
1VxVlzwJrA4J5KycZAXNC4EKMZoliVHdpUwzLc4q1fHtrBjLNP5NluDvWPSm
8jcI5Sc1BG/FXRwqLfgxNZVxcixuc5rjPyQ/1gmzabC6zA+qkEWUiSt5J8fZ
H1hkHBaNFdKsmGLonSIDegH5dvcOjkX/9Wlnf69zuNc9enxxen3ToTsd3ApE
EKejNWPacU7ixo+zq/MsmiWq/UqWJahoD6VWLNb2IA1lrmcJUyzOFQk51lNx
TZ4C7rZ4mkrSwjJ5LC54hEygeo1VZqUS2agapgV+ixtMl2ZJNl6IHaJ8lycw
xtHd6x60947a3Sd8UasiVprYcavQgGPxQkWQMq1iGQWVMG1IEg+P6/WMavgR
N8Fl/8WxmJRlro8fP07vknw21B0wV3bG2d1j+kBXHpPMmnLtQHydPBpB5UxF
+/JNU5rspW+sl54Ui7zMxoXMJ4v/Q2ntH7Yhsk3CcmyGughrHvMi+y8Vlvpx
7sFKO/QIDoJ2uy3kUJeFDMsgeDfoX7y+GRyLmwl5WqlSljhoLSexNpgo8KHM
xBiIc9q76ImzgQizSOUZntekA+vJHXFa4s4sicRQCSl0xS0tdmsnG8N0Ccdk
6QBgHicJWKQhSVbS2jLKcqKjBTmJXl/oHKCbFTBhnqMFGQtF00jQHMV3cTSD
qLHeMFF2mfkkDidEs24QW2RTQGauilJcqbtYzTvMucwhOokBhlWQH6kwjrDg
cGEw12Cf+OmHjngvgoD0JQoVQl7JouI0/g0jDFcgXaRqbtCv4XNT53MtS2QI
JrHijFyUpOn0VkDlNHNpJmH2Yj2ZYk2iulKPzkHrCAYiJtmcyMdMTraSTA3y
jGJjj0kTjitaKpQVFCzHJuxAbW6c2BkkSQylhOJkVtypXdGPR1iz/VIlyVSm
lqCJwe9KnFgwmxsbSdU4K2OIALNjJfaAk0kMY7nuEVHaSgPxR2g5gk7GMobz
CDZf4HqywOqYcAHBJOqO5OICJ8A0h4sVxq+gL9gKPyzmSt6mwA4IBxzWQonZ
qjERQylUCF11AuMd0ziKEhUEjyjKFQDSkGQQBD3j+utJqdDBkiJ2Tq7enOy2
RDyixYYqRAiBTSC6JoirLeso5QQX4HUC0JRAuNZcaB2yFZmMM4ThyVQb8yiz
SC5YnEaNrMWOuM6mCikO7BBPQ752BgyAZKazFMTSdE7EZB+f0afY2Rmc7PZf
7pI9OdUpoydDORyE1iBpY7qldWymMpqVM6gTRgqBSEESEXMyyTuEQ3JWazZm
xjgNk1n09fnN49NLrUJRztJUJY7Hmub1xga/nnFEGZz0X67kKCA+Lmjkh+ve
h9OL0xt4itZyrHQHzn+TkUfBPbVBSaSEIShuiY8f/3n14uTo2dGTT58ITdl4
oIVGlneJgRNZmHis2UNFqaZ5huRiIQzwsYoROApWpxR5odp2EJHKEKkwIdhT
tEy+cCJH9IRBe9x61sSM4zkkZ9AHFAsvBXaqFcQJyaagDkVTMl//Br6ed590
wVekRnGKFSzYRJkHLyKRBcMKC6sSqSdug4ok2dOLm8HV+aB/iqTRjeiInhZ+
8DI0EybMNDB+YRYoKH6kbHRgC6ZCWao4l7/GUwy5KWSKiAGIf5vGAP2d85u3
cMRNa2oHwKNCjglcwZsFZjZLxjBWCMk3VwQzhu9lQj1+CT+zGQLmZTUtu0bH
yfLg2d5aWc5y+qBNdKvl2py9kuZmnsjijS2wwK/PBj9fDwZ9vo7P570bnhPp
Ex6Sibae2ADs+UMcmjDJqLRkeusdjq4s2Zvw7c3G1An8YajAPKmUWCQUdOho
8xvI0KZpEKHxFBd/aYSzZhNFagQ1SnUoY5BWe4GZKNTxOJUEWhBIj8END0Xk
cFfZDB8OWnRtIfI4vCUPXgwJ2bRBu7jQFrQ2JNk7iD67SxSbZ4Acp+1+x9Sg
4agYt3U4mcuhat/SEu29g0+fOna5uVkvbaYduPjVSf+OCYi7pMGPH71ighZz
2RkmbiyEZykxrQfQw++ESySv1EgVirCjqm4Sk0MV+IIQE4k7i+BfwrSNnzBN
uERRzdERrzFlMY81aVLlhCtuOZiVIwF6a5DZgwoLNc3ulKGoehDWvCKA90B6
zrKycEYODAPXYREPbaJl5eNnb9YQGgbol7i141K09tx7xY8bAcnET5o5TCTq
oJDzMQrPy1WyC1cmq4UVzxKWnUFd3yEphZY8hj5VdwpF9zj7wwei1CGEcx/d
zM5MVLfoYTNRkwWYdeGyozixmvCQT7ImxnB/wlOirvJUAYhIWc2FX14s4Y+T
KSHHo0ckZh0EpwaJEJBL9WtpyhjFNZ3YWMNVVZnzxctVlGktKaQGFQpNVIaS
cxkLIEqq1B7JEFg0hBSKMjSFug15ptiGY/6g0p1d0f5O7OS3LaFvd7ePRY9E
NpTDGLl+aTPCsUpVIZsZYasqcfie0jVM0pDt/HabhYw6DJmaMkXEtr7d7tDi
BhGwrFk+RE2l9brlm7XLyuqlvFWcw8Qp0t4NJCAQ4iYRGMY5vJZ1sx2W5q7N
ayyV21obCvuKKdQQTFgylbhD9EXq6yhaYp/XXEdHTeUqRVxxwuI0Em14vGZp
RyShdDxDTYanVVHgmTuZzFSHgANZkKQRtpFGYqWy02TvZCNNVAUysJnGmkva
ambWBEYh+FCkiWTOEBdOMo0I4PEB0EeRjWzn9KLfPjnpdXedRKYK+ZCpuJuc
MbGgY+Jq9qWVE2UKZuRTEX7pkrJRbSpvV8bDGSyFgNCJBGmyGMYl57I1ddrT
GoG3oxEOUgClUN5H2uQ9VloVvEDDIXNs+FNFy9V4vqk99rWcS+TuFpZLLq8i
k2VTZdsG3kwdABaKYLsjYFVUKELAFQFp5jDsAXVYLeSJjNM1SrjsrdMBkf6X
6MGoAE5F6b+FulomVsiXwPRsNp4gBn9W1pAcosuKrMnoy3hKiXJzBgSxNt1o
gGOH4dhAdhC4Hq/m0ndduyRpZCsPtEv+lgnHe18EJvSbLE28UrJIY9dqGRB6
GNiCs7B1JRx+8yKexrxIFX+ps1bMQspSK/FpGBGidFoaG8tGIwqe4yxD0q0K
7pMSeSbqVk0PPaWOEF0cyoQeMApYQkgNPenN+aBpFXF0y2UhYStYumUfbz/d
71afnx0eGYuy3/eRRnKmApnOIUAgZp57WAgTIzXayOnMNYFeEl2VTrb4MDH+
zYmL3i0IGM+J/Rbl7LToU7eUnaA2ZrcQnDKiZhFpcQjg4PqjN7hu73dBOH94
3uW56HP36SFlWEh5jDS5M7AmC3JtAO2JYVkKRIHJEJtJjuTmglbFnTG0phA8
eVvr4FYqoMsgcZW6+SYQT3MgKpVVvODa5gnX2sZRF1SRUsjitiAmirOIBUSO
73UJHmLOA+p1psVYDZ6VMrheLnJOcau6/uZty7aZlotscOtoLdQvsxg2hDGC
a3UyGjcFyvCcEM21gIcZ2ywhbUxdIk6GI1sTsE2oAmGBoewkS+9MW9wUsX0y
PE7ctYnznDFn1OfeOn97fbPVMr8F4Ik+Xw3evD29GvTp8/XL3qtX1YfAPnH9
8vXbV/36Uz3y5PX5+eCibwbjqmhcCrbOez9vGeveen15c/r6ovdqy3iEX7dQ
jmrKdQpTRY6YwyExcAUNe9H3J5f/89/7T2ya3t3ffw4wNF+O9p9RR2vOzSDO
lVJI3Hylcjggv5WcIRGgAL7jUiYAAclRbZ4KKJwiw7+/I8m8PxbfDMN8/8l3
9gIx3LjoZNa4yDJbvbIy2AhxzaU1y1TSbFxfknST3t7Pje9O7t7Fb/6ZAJpE
e//on98FATWSl7Y6hRcjXeW2to1TRY+m4dvkpupxRg9OYppqiGV+AdaiIRRr
jAcknJ9mGh9w3e3+YqDOwtg2dZv+YvsoFI4afdqds8Gu6x4759w1oFnXu40R
+2Kn1++fDfZ3TeuOoErQjrR4YoLLaZ8A5+Ap+fXBoVcSMtrU3xhsmpB843s0
PiFoprYsNdw2mkLMzGCVChBgsoK5pF2kRkucpGK5paKe4WUVWXgfi3h04bLa
oakwnObnhFLb+sFvP9Mcm5t9Q8Ccsul4c92Kd/bFVSNgCB0qVKS///47ymc3
9jM/V25a2jD5/I8QD98PXvavdjx2kTZf92KE7rNB3BIXcSt4d7Hjs/5h8J8n
L3sXP2DE28vL11c3g/7u+3b7u+BzhOPnG9Czbr2C1ytaXzLH6s8FJPzuZHB1
A+h6/0VzfAFLQSUY/0mi9kx8hGx29nc/kWy/mu/mdNdnmKygyYI1E7kxvbc3
L3dFp9P5mgVXR7OhBUAk9SvXTQa8rhVvsoluB/+Wm0VsBzt7u6wf/OaAVqgx
SoTC+d7StqZ1DLcPxZ1Z35+qagWln7mrFbdplrpemnESPookm5e7PvsQkfw/
yHfx4+K9CYf4qtzXom6EV1jQ8GSzOcDVxcKGg5qaIPieUhO7y0BNXpu72WZd
EwDcuBYiQlEw4dRJa6BrLhdJJqOqJUUEAv1KCLxO3lXNgmPI8OfvzHKK/jne
CGKcMg86B519T5m8f2Qw+YGNC9ownBHrtMdqa3ealWbrrs4GkRlPYBnQLrgP
rnXm6fpkkbcXlQruL1EXDI9w34AF4lpzhlZvEqoKUzpPwFQVco7JSmNnSVyW
iWorlO6UztJTWMMvVJFIwtSmJjmbcpuKTpIpOlHQjFMzrZbC7bZezqLrKpnD
FqqR9jCuzlQ0GwyaY1aj/YYSoN4CrZqBHbr+1UzSHQMgtVl4afQXS2A5gHk9
IyOOzzFZre4xWnGJcSim7+w2ttC3RHazy9gRnvdxCZVmc9qyD6nDJ92GI1aS
jb0h5udsQAJotEJgmxsN3YDavgU1+r26DVmFbNpWfnZwRO0J/XUVl14quah2
o/MG5GZhgmzDZDNVpUXJR4/2G+Z8cmdYy4Oa6nE6U65adqhew24+kVq5fnxj
795gEIezlhuMmkByYmJbVw/tz1pw8zy7gfem7yguSN92LdNU47zxCXJSjxpI
uiKM8zs88+RArMZFI1W7lW1y0H2oRM+mhhbqDfo7fxu2a6vs1jQI1jBqIbru
8Czh84PYvBaI1wkpdrXYUNGGtmy0UGrIflJD7LPu80NEXz5zxmF7bZjfX3Ot
u+baQSD28HBXHCCjfioOxTNxJJ5/zbXgH+0/+S+4bxqJuD+5RzY7uB5c/Tjo
g8j7ilz3yCuVjqED+3P/l9Agmu5xrspJFomL2VQ0SGhQVv/8VTT8mZ/74PcN
dxqc9WUpNzz3+19Aw5+WgzProL2kb3Mg0kPYZhKwv3/0xETFltAGDpfsZRSr
+khT1aV0nr4J8tZUj7za825nmSAvxNEje0dHDxOEJTcvV6cePNfzw8Zyy008
eubp4WfW+0sF8PTZGoqWJPBZir5CArwejIKW3OSq9S41DTl4uqYv0WxWmHb3
A1F73Ur+XrjtYnnHbjZWBHyeB9PVja/lYS5U0MlEOhDIx1pMbhDW+1Cmd81H
jZZOMtXRivrNeaZ1TBtVS7PX9KyTJsODjaHsUhAW6zFD8Cu1s5LNzR7PKP2+
T3Vaa1NOscbO/F6RVhsNoybOHvagFvbnCfUTsKVNgzpf4tpK2sOm67o1Xq6x
uV5dqVCpFWyrNpMJryuZ3bsla2tkk7ikLT8d/H+oSzfkPZ2HuwXeeehqv9Wr
p+2hOLl0LE4fC9MDc5comf8WFI12nEDpCvKHmP4rdk0fg+45CzYHCJwtrPYc
mqWBmS9uFjYrFU116ruG0DW5HWWW17OhVr/MeIe15Y6eN0yDRVyXwZWF+xyv
aRI6wXwkXo0MSBVx/bGoPqr6qqqv5uaqSx/pCnebjHz/IXY8ClpOwDT08jQ2
v5y4b9wukDsTWosFXlV6YeWuW584p2MiutpWotEeR44d4ZhxnDg2HA/2dyE+
VbSwmGd5xPIkhdid/GXadKWbumralH+vaXLYs5NgnatC2kthhAt5Zyqmjedj
v3K1x+HpIHVvVk4+xPumf2y/FvsWB2zfx6jHuhhrhmXUWm2lQ/Yeh3bHLfKx
g1njOtDporbRzeRU8kJpuUS8hQduw1HzvmU20u2zMgm5PSCqzvV1PIZIX1uI
xjJVq7pxZ5hkQyp1T+h8CPeC6uLNHYZjCVgnMtuP3h3TXLd3qZq97tF2ikpG
pntD5+IG1NY9eXn6qv+BDmJXgviJcCh0K/M5FDuRt0ANW+ZIOG9yeqC7rsQr
+Sw21h7RGXPvaLgt2bXit/1YvU6hOi5ndoOn3tSw73GYowl0QL5OVWxiYeCN
EofNnPJ+IBaYxtQ5HUk9ocUtLW7fiWRXi4a7QBu4i6ugU0UyMrkXr1+9ev3T
28sPmMjHLRPQXeSzZ55hXUP4nOYoaU63lHHB556ZKjg0vwxSbawBpvd2nYVv
ZJQmchhugH11b86nsx64FgUorj1ZjmsOhy0nNXba6LTnRSfGKpBhYdPYZ7Vv
yOZGYcZoBgwPF433c0xwtGlCrXpzrOjGCxlfIM9KDIzabmPQe5mBSW8t9fTs
DXCw3FR+UDYVXUuR+wHZIPe6Qr6Qx4TONwgiWnx8REeV4hxX2iVd+RQEV3Tl
znSNAcH4L2HnHSG+JtYmV5vOBNJ1lcJb3aOM3ycwLkD5AhA1jkyUauzH/02P
O5362yUtwiD4udJ8+ssIcH1/HrDgtbTpK4vLIZ49GGJcbUpHqGaw54mi03a1
52hx6HYcKqosVPOR3rVL8ztalRY7YrBKco1InjpHjRY1n6xfptg/n8kvZPhP
M9fE0gob4KL7GS68mc3bYMtc/F0sxoYhK4Oq9KyRXivaIi+J5qHCteqes6Xm
ecEVpfCRa7o85ANqVZL4mWG5eek4CC4y3uWXdLqz+UwFWhzx42kOg4JkjJbq
EjlRMtL2DZlqNL+lV9pzs24oH2OqVOwfmV2qDIDXqP9Ku63BezvIuSaONc84
ymysSC8mlkt3htR0x+l9wZXCwi4xd/sxBe33uPcJm2REmTLlP9Qcmn3ErIjH
MWVRWarWbf2skRI1pktzlIv2PPhlB9/y6UVNZ6gEqDbXof47WQaf4jdv5QaP
6qMrJ3T0PrLH5qHGHr9kbG+GjZumFFrJuJvvK+R5snC5i5VUfSCnAdzlyiHA
jqGN355eposv8ruoKBB0aRJbOoc7Tvksm024XUeD/hKBFlvThP40xbPDoy1z
+st8p1bDlpeOowjaWjnM0l7bZ6ofO+3rLRvktKC3APhYXuM8mW6+PdMRnBQs
h1HTAbSnmlF/0gtzcVoaIXrzHQfBvTsJcu8fC1l/deXKPXX1Z9Mhl2r4uaA3
bQXXc6UsESbuV0i790Dx/s+vLqj9RwtWavHa+Pfi3c33/ZaoX6inFyqXM4xP
71vrHn1PbW5e4NBbgFtKf2yBTSscPKNZD+ysb1NjgSryVlnpv6/5/Gdl+fFY
PCrlcN/86YVvt95yca2rPUdyln/9IZv+15bgvw+whfrdvOc9lOEtuWUvvE2z
eaIibm5q0JCyNano260R7FZtffL+UIKhyBxoRL5Dhm/+/oMWc7b0JL61e6Qy
vRU/yoTOeVxPFzrJ7tiNSfTk1Xywn3ZVgRwze8TOsOk8A7jxvxT2JcPGRgAA

-->

</rfc>