rfc9370xml2.original.xml   rfc9370.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC9242 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9242.xml">
<!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">
<!ENTITY I-D.ietf-ipsecme-g-ikev2 SYSTEM "https://xml2rfc.tools.ietf.org/public/
rfc/bibxml3/reference.I-D.ietf-ipsecme-g-ikev2.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC5723 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5723.xml">
<!ENTITY RFC6023 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6023.xml">
<!ENTITY RFC7296 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7296.xml">
<!ENTITY RFC7383 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7383.xml">
<!ENTITY RFC8019 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8019.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8784 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8784.xml">
]>
<rfc docName="draft-ietf-ipsecme-ikev2-multiple-ke-12" updates="7296" 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"?>
<front>
<title abbrev="Multiple Key Exchanges in IKEv2">Multiple Key Exchanges in
IKEv2</title>
<author fullname="C. Tjhai" initials="C." surname="Tjhai">
<organization>Post-Quantum</organization>
<address><postal><street></street>
</postal>
<email>cjt@post-quantum.com</email>
</address>
</author>
<author fullname="M. Tomlinson" initials="M." surname="Tomlinson">
<organization>Post-Quantum</organization>
<address><postal><street></street>
</postal>
<email>mt@post-quantum.com</email>
</address>
</author>
<author fullname="G. Bartlett" initials="G." surname="Bartlett">
<organization>Quantum Secret</organization>
<address><postal><street></street>
</postal>
<email>graham.ietf@gmail.com</email>
</address>
</author>
<author fullname="S. Fluhrer" initials="S." surname="Fluhrer"> <!DOCTYPE rfc [
<organization>Cisco Systems</organization> <!ENTITY nbsp "&#160;">
<address><postal><street></street> <!ENTITY zwsp "&#8203;">
</postal> <!ENTITY nbhy "&#8209;">
<email>sfluhrer@cisco.com</email> <!ENTITY wj "&#8288;">
</address> ]>
</author>
<author fullname="D. Van Geest" initials="D." surname="Van Geest"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-ipsecme-ikev
<organization>ISARA Corporation</organization> 2-multiple-ke-12" number="9370" submissionType="IETF" category="std" consensus="
<address><postal><street></street> true" ipr="trust200902" obsoletes="" updates="7296" xml:lang="en" sortRefs="true
</postal> " symRefs="true"
<email>daniel.vangeest@isara.com</email> tocInclude="true" version="3">
</address>
</author>
<author fullname="O. Garcia-Morchon" initials="O." surname="Garcia-Morcho <!-- xml2rfc v2v3 conversion 3.15.3 -->
n"> <front>
<organization>Philips</organization>
<address><postal><street></street>
</postal>
<email>oscar.garcia-morchon@philips.com</email>
</address>
</author>
<title abbrev="Multiple Key Exchanges in IKEv2">Multiple Key Exchanges in th
e Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<seriesInfo name="RFC" value="9370"/>
<author fullname="CJ. Tjhai" initials="CJ." surname="Tjhai">
<organization>Post-Quantum</organization>
<address>
<postal>
<street/>
</postal>
<email>cjt@post-quantum.com</email>
</address>
</author>
<author fullname="Martin Tomlinson" initials="M." surname="Tomlinson">
<organization>Post-Quantum</organization>
<address>
<postal>
<street/>
</postal>
<email>mt@post-quantum.com</email>
</address>
</author>
<author fullname="Graham Bartlett" initials="G." surname="Bartlett">
<organization>Quantum Secret</organization>
<address>
<postal>
<street/>
</postal>
<email>graham.ietf@gmail.com</email>
</address>
</author>
<author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
<organization>Cisco Systems</organization>
<address>
<postal>
<street/>
</postal>
<email>sfluhrer@cisco.com</email>
</address>
</author>
<author fullname="Daniel Van Geest" initials="D." surname="Van Geest">
<organization>ISARA Corporation</organization>
<address>
<postal>
<street/>
</postal>
<email>daniel.vangeest.ietf@gmail.com</email>
</address>
</author>
<author fullname="Oscar Garcia-Morchon" initials="O." surname="Garcia-Morcho
n">
<organization>Philips</organization>
<address>
<postal>
<street/>
</postal>
<email>oscar.garcia-morchon@philips.com</email>
</address>
</author>
<author fullname="Valery Smyslov" initials="V." surname="Smyslov"> <author fullname="Valery Smyslov" initials="V." surname="Smyslov">
<organization>ELVIS-PLUS</organization> <organization>ELVIS-PLUS</organization>
<address><postal><street></street> <address>
</postal> <postal>
<email>svan@elvis.ru</email> <street/>
</address> </postal>
<email>svan@elvis.ru</email>
</address>
</author> </author>
<date year="2023" month="May" />
<date/> <area>sec</area>
<workgroup>Internet Engineering Task Force (IETF)</workgroup> <workgroup>ipsecme</workgroup>
<abstract> <keyword>post-quantum</keyword>
<t> This document describes how to extend the Internet Key Exchange Prot <keyword>PQC</keyword>
ocol <keyword>hybrid</keyword>
Version 2 (IKEv2) to allow multiple key exchanges to take place <keyword>hybridization</keyword>
while computing a shared secret during a Security Association (SA) setup <keyword>hybrid key exchange</keyword>
. <keyword>key encapsulation</keyword>
</t> <keyword>quantum</keyword>
<keyword>quantum-safe</keyword>
<t> The primary application of this feature in IKEv2 is the ability to p <keyword>KEM</keyword>
erform one or more <keyword>PQ</keyword>
post-quantum key exchanges in conjunction with the classical (Elliptic C
urve) Diffie-Hellman (EC)DH key exchange,
so that the resulting shared key is resistant against quantum computer a
ttacks.
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 th
is 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 co
mbine several key exchanges
in situations when no single key exchange algorithm is trusted by both i
nitiator and responder.
</t>
<t> This document utilizes the IKE_INTERMEDIATE exchange, by means of whi
ch multiple key exchanges are
performed when an IKE SA is being established. It also introduces a new IKE
v2 exchange IKE_FOLLOWUP_KE,
which is used for the same purpose when the IKE SA is up (during rekeys or c
reating additional Child SAs).
</t>
<t> This document updates RFC7296 by renaming a transform type 4 from "D <abstract>
iffie-Hellman Group (D-H)"
to "Key Exchange Method (KE)" and renaming a field in the Key Exchange P
ayload from "Diffie-Hellman Group Num"
to "Key Exchange Method". It also renames an IANA registry for this tran
sform type
from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to
"Transform Type 4 - Key Exchange Method Transform IDs". These changes ge
neralize
key exchange algorithms that can be used in IKEv2.
</t>
</abstract>
</front>
<middle> <t>This document describes how to extend the Internet Key Exchange
<section title="Introduction" > Protocol Version 2 (IKEv2) to allow multiple key exchanges to take
<section title="Problem Description" ><t> place while computing a shared secret during a Security Association
Internet Key Exchange Protocol (IKEv2) as specified in <x (SA) setup.</t>
ref target="RFC7296"/>
uses the Diffie-Hellman (DH) or Elliptic Curve
Diffie-Hellman (ECDH) algorithm, which shall be referred
to as (EC)DH collectively,
to establish a shared secret
between an initiator and a responder. The security of th
e (EC)DH algorithms relies
on the difficulty to solve a discrete logarithm
problem in multiplicative (and respectively elliptic curv
e) 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 quantum computers will be a
ble to solve
this problem, implying that the security of IKEv2 is comp
romised.
There are, however, a number of cryptosystems that are co
njectured to
be resistant against quantum computer attack. This famil
y of
cryptosystems is known as post-quantum cryptography (PQC)
. It is
sometimes also referred to as quantum-safe cryptography (
QSC) or
quantum-resistant cryptography (QRC).
</t>
</section>
<section title="Proposed Extension" > <t>This document utilizes the IKE_INTERMEDIATE exchange, where multiple key ex
<t> changes are performed when an IKE SA is being
This document describes a method to perform multiple succ established. It also introduces a new IKEv2 exchange,
essive key IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA
exchanges in IKEv2. It allows integration of PQC in IKEv2, while is being rekeyed or is creating additional Child SAs.</t>
maintaining backwards compatibility, to derive a set of I
KE keys that
is resistant to quantum computer attacks. This extension
allows the
negotiation of one or more PQC algorithm 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 is
important as
many of these algorithms are relatively new and there may
be a need to
hedge the security risk with multiple key exchange data f
rom several
distinct PQC algorithms.
</t>
<t>IKE peers perform multiple successive key exchanges to establish <t>This document updates RFC 7296 by renaming a Transform Type 4 from
an IKE Security Association (SA). Each exchange produces a piece of "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and
secret and renaming a field in the Key Exchange Payload from "Diffie-Hellman
these secrets are combined in a way such that: Group Num" to "Key Exchange Method". It also renames an IANA
<ol type="(%c)"> registry for this Transform Type from "Transform Type 4 - Diffie-
<li>the final shared secret is computed from all of the component ke Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange
y exchange Method Transform IDs". These changes generalize key exchange
secret;</li> algorithms that can be used in IKEv2.</t>
<li>the shared secret as specified in <xref target="RFC7296"/> is ob
tained
unless both peers support and agree to use the additional key exchan
ges introduced
in this specification; and</li>
<li>if any of the component key exchange method is a post-quantum al
gorithm,
the final shared secret is post-quantum secure.</li>
</ol>
</t>
<t> </abstract>
Some post-quantum key exchange payloads may have sizes la </front>
rger than <middle>
the standard maximum transmission unit (MTU) size, and th <section numbered="true" toc="default">
erefore there could be issues with <name>Introduction</name>
fragmentation at the IP layer. In order to allow using t <section numbered="true" toc="default">
hose larger payload <name>Problem Description</name>
sizes, this mechanism relies on the IKE_INTERMEDIATE exchange as spe
cified
in <xref target="RFC9242"/>. 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 excha
nges are carried out,
each of which contains an additional key exchange. As th
e IKE_INTERMEDIATE
exchange is encrypted, the IKE fragmentation protocol <xr
ef target="RFC7383" />
can be used. The IKE SK_* values are updated after each e
xchange as described in
<xref target="additional_ke"/>,
and so the final IKE SA keys depend on all the key exchan
ges,
hence they are secure if any of the key exchanges are sec
ure.</t>
<t>While this extension is primarily aimed for IKE SAs due to the <t>The Internet Key Exchange Protocol version 2 (IKEv2), as specified in <xr
potential fragmentation issue discussed above, it also applies to ef target="RFC7296" format="default"/>, uses
CREATE_CHILD_SA exchanges as illustrated in the Diffie-Hellman (DH) or the Elliptic Curve Diffie-Hellman (ECDH)
<xref target="create_child_sa_exchange"/> for creating/rekeying of algorithm, which shall be referred to as "(EC)DH" collectively, to
Child SAs and rekeying of IKE SAs.</t> 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,
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 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 to quantum-computer attacks
. This family of cryptosystems is known as "post-quantum cryptography" (or "PQC
"). It is sometimes also referred to as
"quantum-safe cryptography" (or "QSC") or "quantum-resistant cryptography"
(or "QRC").</t>
<t> <t>It is essential to have the ability to perform one or more post-quantum key
Note that readers should consider the approach defined in exchanges in conjunction with an (EC)DH key exchange so that the resulting
this document as shared key is resistant to quantum-computer attacks. Since there is currentl
providing a long term solution in upgrading the IKEv2 pro y no post-quantum key exchange that
tocol to is as well-studied as (EC)DH, performing multiple key exchanges with
support post-quantum algorithms. A short term solution t different post-quantum algorithms along with the well-established
o make IKEv2 classical key-exchange algorithms addresses this concern, since the
key exchange quantum secure is to use post-quantum pre-sh overall security is at least as strong as each individual primitive. </t>
ared keys as </section>
specified in <xref target="RFC8784"/>.</t> <section numbered="true" toc="default">
<name>Proposed Extension</name>
<t>This document describes a method to perform multiple successive key
exchanges in IKEv2. This method allows integration of PQC in IKEv2,
while maintaining backward compatibility, to derive a set of IKE keys
that is resistant to quantum-computer attacks. This extension allows
the negotiation of one or more PQC 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 algorithm is
important, as many of these algorithms are relatively new, and there may
be a need to hedge the security risk with multiple key exchange data
from several distinct PQC algorithms.
</t>
<t> Note also that the proposed approach of performing multiple successive <t>IKE peers perform multiple successive key exchanges to establish
key exchanges an IKE SA. Each exchange produces some shared secret, and
in such a way that resulting session keys depend on all of them is not lim these secrets are combined in a way such that:
ited </t>
to only addressing the threat of quantum computer. It can also be used whe <ol type="(%c)">
n all <li>the final shared secret is computed from all of the component
of the performed key exchanges are classical (EC)DH primitives, where for key exchange secrets;</li>
some reasons <li>unless both peers support and agree to use the additional key
(e.g. policy requirements) it is essential to perform multiple of them. exchanges introduced in this specification, the final shared
</t> 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>Some post-quantum key exchange payloads may have sizes larger than
the standard maximum transmission unit (MTU) size. Therefore, there
could be issues with fragmentation at the IP layer. In order to allow
the use of those larger payload sizes, this mechanism relies on the
IKE_INTERMEDIATE exchange as specified in <xref 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, as described in <xref target="additional_ke"
format="default"/>; thus, the final IKE SA keys depend on all the key
exchanges. Hence, the keys are secure if any of the key exchanges are
secure.</t>
<t>While this extension is primarily aimed 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" format="default"/> for
creating/rekeying of Child SAs and rekeying of IKE SAs.</t>
<t>Note that readers should consider the approach defined in this
document as providing a long-term solution in upgrading the IKEv2
protocol to support post-quantum algorithms. A short-term solution to
make IKEv2 key exchange quantum secure is to use post-quantum
pre-shared keys as specified in <xref target="RFC8784"
format="default"/>.</t>
<t>This specification does not attempt to address key exchanges with KE p <t> Note also that the proposed approach of performing multiple
ayloads successive key exchanges in such a way, when the resulting session keys
longer than 64 Kbytes; the current IKE payload format does not allow suc depend on all of them, is not limited to only addressing the
h as threat of quantum computers. It can also be used when all of the performed ke
y
exchanges are classical (EC)DH primitives, where, for various reasons
(e.g., policy requirements), it is essential to perform multiple key
exchanges.
</t>
<t>This specification does not attempt to address key exchanges with KE
payloads
longer than 64 KB; the current IKE payload format does not allow such a
possibility. At the time of writing, it appears likely that there possibility. At the time of writing, it appears likely that there
are a number of key exchanges available that would not have such are a number of key exchanges available that would not have such
a requirement. However, if such a requirement is needed, a requirement. <xref target="I-D.tjhai-ikev2-beyond-64k-limit" format="
<xref target="I-D.tjhai-ikev2-beyond-64k-limit"/> discusses approaches default"/> discusses approaches
that could be taken to exchange huge payloads.</t> that could be taken to exchange huge payloads if such a requirement were
needed.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Changes" > <name>Document Organization</name>
<t>RFC EDITOR PLEASE DELETE THIS SECTION.</t> <t>The remainder of this document is organized as follows. <xref
target="specification" format="default"/> describes how multiple key
<t> Changes in this draft in each version iterations.</t> exchanges are performed between two IKE peers and how keying materials
are derived for both SAs and Child SAs. <xref target="IANA"
<t>draft-ietf-ipsecme-ikev2-multiple-ke-07</t> format="default"/> discusses IANA considerations for the namespaces
<t><list style="symbols"> introduced in this document. <xref target="security"
<t>Editorial changes.</t> format="default"/> discusses security considerations. In the
</list></t> Appendices, some examples of multiple key exchanges are illustrated in
<xref target="sample-exchanges" format="default"/>. <xref
<t>draft-ietf-ipsecme-ikev2-multiple-ke-06</t> target="design" format="default"/> summarizes design criteria and
<t><list style="symbols"> alternative approaches that have been considered. These approaches are
<t>Updated draft with the allocated IANA values.</t> later discarded, as described in <xref target="altdesign"
<t>Editorial changes following AD review.</t> format="default"/>.
</list></t> </t>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
<t>draft-ietf-ipsecme-ikev2-multiple-ke-05</t> 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
<t><list style="symbols"> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDE
<t>Updated the reference to RFC9242.</t> D</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
<t>Editorial changes.</t> "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as desc
</list></t> ribed in
BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when,
<t>draft-ietf-ipsecme-ikev2-multiple-ke-04</t> and only when, they appear in all capitals, as shown here.
<t><list style="symbols"> </t>
<t>Introduction and initial sections are reorganized.</t> </section>
<t>More clarifications for error handling added.</t> </section>
<t>ASCII arts displaying SA payload are added.</t> <section anchor="specification" numbered="true" toc="default">
<t>Clarification for handling multiple round trips key exchange meth <name>Multiple Key Exchanges</name>
ods added.</t> <section numbered="true" toc="default">
<t>DoS concerns added into Security Considerations section.</t> <name>Design Overview</name>
<t>Explicitly allow scenario when additional key exchanges are perfo <t> Most post-quantum key agreement algorithms are relatively new.
rmed only after peers are authenticated.</t> Thus, they are not fully trusted. There are also many proposed
</list></t> algorithms that have different trade-offs and that rely on different
hard problems. The concern is that some of these hard problems may
<t>draft-ietf-ipsecme-ikev2-multiple-ke-03</t> turn out to be easier to solve than anticipated; thus, the key
<t><list style="symbols"> agreement algorithm may not be as secure as expected.
<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 exchan
ges 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 exchan
ges in CREATE_CHILD_SA is added.</t>
<t>Resolving rekey collisions in case of multiple key exchanges is c
larified.</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 succ
ession.</t>
<t>Handle fragmentation by keeping the first key exchange (a stan
dard
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, a new key exchange payload that can
be sent as multiple fragments within IKE_SA_INIT message was intro
duced.</t>
</list>
</t>
</section>
<section title="Document Organization" >
<t>
The remainder of this document is organized as follows.
<xref target="specification"/> 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"/> discusses IANA considerations for the namespac
es
introduced in this document, and <xref target="security"/> discusses
security
considerations. In the Appendices sections, some examples of multip
le key exchanges
are illustrated in <xref target="sample-exchanges"/>,
<xref target="design"/> summarizes design criteria and a summary of
alternative
approaches that have been considered, but later discarded, are descri
bed
in <xref target="altdesign"/>.
</t>
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NO
T", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this docu
ment are to be interpreted
as described in BCP 14 <xref target="RFC2119" /> <xref target="RFC81
74" /> when, and only when,
they appear in all capitals, as shown here.
</t>
</section>
</section>
<section title="Multiple Key Exchanges" anchor="specification">
<section title="Design Overview">
<t> Most post-quantum key agreement algorithms are relatively new, a
nd
thus are not fully trusted. There are also many proposed algorithms
,
with different trade-offs and relying on different hard problems. T
he
concern is that some of these hard problems may turn out to be easie
r
to solve than anticipated and thus the key agreement algorithm may n
ot be
as secure as expected. A hybrid solution, when multiple key exchang
es are performed
and the calculated shared key depends on all of them, allows us to d
eal with this
uncertainty by combining a classical key exchange with a post-quantu
m
one, as well as leaving open the possibility of multiple post-quantu
m
key exchanges.</t>
<t> In order to be able to use IKE fragmentation <xref target="RFC73
83"/> for those key exchanges
that may have long public keys, this specification utilizes the IKE_
INTERMEDIATE exchange
defined in <xref target="RFC9242"/>.
The initial IKE_SA_INIT messages do not have any inherent fragmentat
ion support within IKE; however, IKE_SA_INIT messages can include a
relatively short KE payload. The additional key exchanges are perfo
rmed 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, that each key exchange method r
equires one round trip and consumes exactly one IKE_INTERMEDIATE exchange.
This assumption is valid for all classic key exchange methods define
d so far and for all post-quantum methods currently known.
For hypothetical future key exchange methods requiring multiple roun
d 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
are actually exchanged. To negotiate additional key 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 assi
gned later for
various post-quantum key exchanges <xref target="IKEV2TYP
E4ID"></xref>.
This specification does not make a distinction between classical (EC
)DH
and post-quantum key exchanges, nor post-quantum algorith
ms which are
true key exchanges versus post-quantum algorithms that ac
t as key
transport mechanisms; all are treated equivalently by the
protocol. This document renames a field in the Key Excha
nge Payload from
"Diffie-Hellman Group Num" to "Key Exchange Method". It also renames
Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange
Method (KE)";
the corresponding renaming to the IANA registry is described in <xre
f target="IANA"/>.</t>
<t> The fact that newly defined transforms share
the same registry for possible Transform IDs with Transform Type 4,
allows additional key exchanges
to be of any type - either post-quantum or classical (EC)DH
one. This approach allows any combination of the defined key exchan
ge 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 k
ey exchange is not needed.
</t>
<t> The SA payload in the IKE_SA_INIT message A hybrid solution, when multiple key exchanges are performed and the
includes one or more newly defined transforms which represent the ex calculated shared key depends on all of them, allows us to deal with
tra key exchange policy required by the this uncertainty by combining a classical key exchange with a
initiator. The responder follows the usual IKEv2 negotiation rules: post-quantum one, as well as leaving open the possibility of
it selects a single transform of each type, and combining it with multiple post-quantum key exchanges.</t>
returns all of them in the IKE_SA_INIT response message. <t> In order to be able to use IKE fragmentation <xref
</t> 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"
format="default"/>. The initial IKE_SA_INIT messages do not have any
inherent fragmentation support within 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 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 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 upon are actually exchanged. To negotiate
additional key exchanges, seven new Transform Types are defined. These
transforms and Transform Type 4 share the same Transform IDs.
</t>
<t> <t> It is assumed that new Transform Type 4 identifiers will be
Then, provided that additional key exchanges are negotiated, the ini assigned later for various post-quantum key exchanges <xref
tiator and the responder target="IKEV2TYPE4ID" format="default"/>. This specification does not
perform one or more IKE_INTERMEDIATE exchanges. Following that, the make a distinction between classical (EC)DH and post-quantum key
IKE_AUTH exchange authenticates peers exchanges, nor between post-quantum algorithms that are true key
and completes IKE SA establishment.</t> exchanges and post-quantum algorithms that act as key transport
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". This document also
renames Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key
Exchange Method (KE)". The corresponding renaming to the IANA registry
is described in <xref target="IANA" format="default"/>.</t>
<t> The fact that newly defined transforms share the same registry for
possible Transform IDs with Transform Type 4 allows additional key
exchanges to be of any type: either post-quantum or classical
(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 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 and
returns all of them in the IKE_SA_INIT response message.
</t>
<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 Initiator Responder
--------------------------------------------------------------------- ---------------------------------------------------------------------
<-- IKE_SA_INIT (additional key exchanges negotiation) --> <-- IKE_SA_INIT (additional key exchanges negotiation) -->
<-- {IKE_INTERMEDIATE (additional key exchange)} --> <-- {IKE_INTERMEDIATE (additional key exchange)} -->
... ...
<-- {IKE_INTERMEDIATE (additional key exchange)} --> <-- {IKE_INTERMEDIATE (additional key exchange)} -->
<-- {IKE_AUTH} --> <-- {IKE_AUTH} -->
]]></artwork></figure> ]]>
</section> </artwork>
<section title="Protocol Details">
<t> In the simplest case, the initiator starts a single key exchange
(and has no interest in supporting multiple), and it is not conce
rned
with possible fragmentation of the IKE_SA_INIT messages (either b
ecause
the key exchange it selects is small enough not to fragment, or t
he initiator is
confident that fragmentation will be handled either by IP fragmen
tation,
or transport via TCP).</t>
<t> In this case, the initiator performs the IKE_SA_INIT for a singl
e key exchange using a Transform Type 4
(possibly with a post quantum algorithm), and including the initator
KE payload. If the responder accepts
the policy, it responds with an IKE_SA_INIT response, and IKE contin
ues as usual.</t>
<t> If the initiator desires to negotiate multiple key exchanges, th
en the initiator uses the protocol
behavior listed below.</t>
<section anchor="negotiation" title="IKE_SA_INIT Round: Negotiation"
>
<t> Multiple key exchanges are negotiated using the standard IKE
v2 mechanism, via SA payload.
For this purpose seven new transform types, namely Additional Ke
y Exchange 1 (with IANA assigned value 6),
Additional Key Exchange 2 (7), Additional Key Exchange 3 (8), Ad
ditional Key Exchange 4 (9),
Additional Key Exchange 5 (10), Additional Key Exchange 6 (11) a
nd Additional Key Exchange 7 (12)
are defined. They are collectively called Additional Key Exchan
ge transforms in this document
and have slightly different semantics than the existing IKEv2 tr
ansform 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_I
NIT exchange. The allowed 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 IDs.
</t>
<t> Key exchange method negotiated via Transform Type 4 always t
akes place
in the IKE_SA_INIT exchange, as defined in <xref target="RFC7296
" />. Additional key exchanges negotiated via newly
defined transforms MUST take place in a series of IKE_INTERMEDIA
TE exchanges following the IKE_SA_INIT exchange,
performed in an order of the values of their transform types, so
that key exchange negotiated using Additional Key Exchange i always precedes th
at of
Additional Key Exchange i + 1. Each additional key exchange meth
od MUST be fully completed before the next one is started.
</t>
<t> Note that with these semantics, Additional Key Exchange tran
sforms are not associated
with any particular type of key exchange and do not have any spe
cific per transform type transform IDs IANA registry.
Instead they all share a single registry for transform IDs, name
ly "Key Exchange Method Transform IDs", which are also shared by Transform Type
4.
All key exchange algorithms (both classical or post-quantum) sho
uld 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 the initiator adds transforms for th
e IKE_SA_INIT exchange
using Transform Type 4. In most cases they will contain classic
al (EC)DH key exchange methods,
however it is not a requirement. Additional key exchange method
s are proposed using Additional Key Exchange
transform types. All of these transform types are optional, the
initiator is free
to select any of them for proposing additional key exchange meth
ods. Consequently,
if none of the Additional Key Exchange transforms is included in
the proposal, then this proposal
indicates performing standard IKEv2, as defined in <xref target=
"RFC7296"/>.
On the other hand, if the initiator includes any Additional Key
Exchange transform in the proposal,
the responder MUST select one of the algorithms proposed using t
his type. Note that this is not a
new requirement, but that this behavior is already specified in
Section 2.7 of <xref target="RFC7296"/>.
A transform ID NONE MAY be added to those transform types which
contain key exchange methods that
the initiator believes is optional according to its local policy
.
</t>
<t> The responder performs the negotiation using the standard IK
Ev2 procedure described in Section 3.3 of <xref target="RFC7296"/>.
However, for the Additional Key Exchange types, the responder's
choice MUST NOT contain duplicated algorithms (those with identical Transform ID
and attributes),
except for the transform ID of NONE. An algorithm is represente
d as a transform, in some 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 two transforms
(ID=alg1,ATTR1=attr1,ATTR2=attr2) and
(ID=alg1,ATTR2=attr2,ATTR1=attr1) define the same algorithm. If
the responder is unable
to select non-duplicated algorithm 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 reject the message with an error notifica
tion of type NO_PROPOSAL_CHOSEN.
If the responder's message contains one or more duplicated choice
s, the initiator
should log the error and MUST treat the exchange as failed.
The initiator MUST NOT initiate any IKE_INTERMEDIATE (or IKE_FOLL
OWUP_KE) exchanges, so that no new SA is created.
If this happens in the CREATE_CHILD_SA exchange, then the initiat
or MAY delete the IKE SA,
over which the invalid message was received, by sending a Delete
payload.
</t>
<t> If the responder selects NONE for some Additional Key Exchan
ge types (provided they are proposed by the initiator),
then the corresponding Additional Key Exchange(s) in the IKE_INT
ERMEDIATE exchange(s) MUST NOT take place.
Therefore if the initiator includes NONE in all of the Additiona
l Key Exchange transforms and the
responder selects this value for all of them, then no IKE_INTERM
EDIATE messages 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 propose non-consecutive Additional Key Exch </section>
ange transforms, for example <section numbered="true" toc="default">
proposing Additional Key Exchange 2 and Additional Key Exchange <name>Protocol Details</name>
5 transforms only. The responder <t> In the simplest case, the initiator starts a single key exchange
MUST treat all of the omitted Additional Key Exchange transforms (and has no interest in supporting multiple), and it is not concerned
as if they are proposed with with possible fragmentation of the IKE_SA_INIT messages (because either
Transform ID NONE.</t> the key exchange that it selects is small enough not to fragment
or the initiator is confident that fragmentation will be handled
either by IP 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) and including the 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 wants to negotiate multiple key exchanges, then
the initiator uses the protocol behavior listed below.</t>
<section anchor="negotiation" numbered="true" toc="default">
<name>IKE_SA_INIT Round: Negotiation</name>
<t> Multiple key exchanges are negotiated using the standard IKEv2
mechanism via SA payload. For this purpose, seven new transform
types are defined: Additional Key Exchange 1 (ADDKE1) with IANA-assign
ed value
6, Additional Key Exchange 2 (ADDKE2) (7), Additional Key Exchange 3 (
ADDKE3) (8),
Additional Key Exchange 4 (ADDKE4) (9), Additional Key Exchange 5 (ADD
KE5) (10),
Additional Key Exchange 6 (ADDKE6) (11), and Additional Key Exchange 7
(ADDKE7) (12).
They are collectively called "Additional Key Exchange (ADDKE)
Transform Types" in this document and have slightly different semantic
s
than the existing IKEv2 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 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 IDs.
</t>
<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 <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. This is so that the key exchange negotiated using Ad
ditional
Key Exchange i always precedes that of Additional Key Exchange i +
1. Each additional key exchange method <bcp14>MUST</bcp14> be fully
completed before the next one is started.
</t>
<t>With these semantics, 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 IANA registry. Instead, they all share a single
registry for Transform IDs, namely "Transform Type 4 - Key Exchange Me
thod Transform
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, the initiator adds transforms for the
IKE_SA_INIT exchange using Transform Type 4. In most cases, they
will contain classical (EC)DH key exchange methods, but that is not
a requirement. Additional key exchange methods are proposed using
ADDKE Transform Types. All of these transform
types are optional; the initiator is free to select any of them for
proposing additional key exchange methods. Consequently, if none of
the ADDKE Transform Types are included in the proposal,
then this proposal indicates the performing of standard IKEv2, as
defined in <xref target="RFC7296" format="default"/>. On the other
hand, if the initiator includes any ADDKE
Transform Type in the proposal, the responder <bcp14>MUST</bcp14> sele
ct
one of the algorithms proposed using this type. Note that this is
not a new requirement; this behavior is already specified in
<xref target="RFC7296" sectionFormat="of" section="2.7"/>. A
Transform ID NONE <bcp14>MAY</bcp14> be added to those transform
types that contain key exchange methods which the initiator believes
are optional according to its local policy.
</t>
<t> The responder performs the negotiation using the standard IKEv2
procedure described in <xref target="RFC7296" sectionFormat="of"
section="3.3"/>. However, for the ADDKE Transform Types,
the responder's choice <bcp14>MUST NOT</bcp14> contain duplicated
algorithms (those with an identical Transform ID and attributes),
except for the Transform ID of NONE. An algorithm is represented as
a transform. In some 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 define the same algorithm:
"ID=alg1, ATTR1=attr1, ATTR2=attr2" and
"ID=alg1, ATTR2=attr2, ATTR1=attr1". If the
responder is unable to select algorithms that are not duplicated for e
ach
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 <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 <bcp14>MUST</bcp14> treat the
exchange as failed. The initiator <bcp14>MUST NOT</bcp14> initiate
any IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE) exchanges so that no new
SA is created. If this happens in the CREATE_CHILD_SA exchange,
then the initiator <bcp14>MAY</bcp14> delete the IKE SA over which
the invalid message was received by sending a Delete payload.
</t>
<t> If the responder selects NONE for some ADDKE
Transform Types (provided they are proposed by the initiator), then an
y
corresponding additional key exchanges <bcp14>MUST NOT</bcp14> take pl
ace.
<t> Below is an example of the SA payload in the initiator's IKE Therefore, if the
_SA_INIT request message. initiator includes NONE in all of the ADDKE
Here the abbreviation AKEi is used to denote the i-th Additional Transform Types and the responder selects this value for all of them,
Key Exchange transform defined in this document, then no IKE_INTERMEDIATE exchanges performing additional key
and an abbreviation KE for the Key Exchange transform, exchanges will take place between the peers. Note that the
that this document renames from the Diffie-Hellman Group transfo IKE_INTERMEDIATE exchanges may still take place for other purposes.
rm. </t>
Additionally, the notations PQ_KEM_1, PQ_KEM_2 and PQ_KEM_3 are <t>The initiator <bcp14>MAY</bcp14> propose
used to ADDKE Transform Types that are not consecutive, for example, proposing
represent some not-yet defined Transform IDs of some popular pos ADDKE2 and ADDKE5 Transform Types only. The
t-quantum responder <bcp14>MUST</bcp14> treat all of the omitted ADDKE
key exchange methods.</t> transforms as if they were proposed with Transform ID
NONE.</t>
<t>Below is an example of the SA payload in the initiator's IKE_SA_INI
T
request message. Here, the abbreviation "KE" is used for the Key Exchange tra
nsform, which this
document renames from the Diffie-Hellman Group transform. Additionally, the n
otations PQ_KEM_1, PQ_KEM_2, and
PQ_KEM_3 are used to represent Transform IDs that have yet to be defin
ed of
some popular post-quantum key exchange methods.</t>
<figure><artwork align="center" ><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
SA Payload SA Payload
| |
+--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8, +--- Proposal #1 ( Proto ID = IKE(1), SPI Size = 8,
| 9 transforms, SPI = 0x35a1d6f22564f89d ) | 9 transforms, SPI = 0x35a1d6f22564f89d )
| |
+-- Transform ENCR ( ID = ENCR_AES_GCM_16 ) +-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
| +-- Attribute ( Key Length = 256 ) | +-- Attribute ( Key Length = 256 )
| |
+-- Transform KE ( ID = 4096-bit MODP Group ) +-- Transform KE ( ID = 4096-bit MODP Group )
| |
+-- Transform PRF ( ID = PRF_HMAC_SHA2_256 ) +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
| |
+-- Transform AKE2 ( ID = PQ_KEM_1 ) +-- Transform ADDKE2 ( ID = PQ_KEM_1 )
| |
+-- Transform AKE2 ( ID = PQ_KEM_2 ) +-- Transform ADDKE2 ( ID = PQ_KEM_2 )
| |
+-- Transform AKE3 ( ID = PQ_KEM_1 ) +-- Transform ADDKE3 ( ID = PQ_KEM_1 )
| |
+-- Transform AKE3 ( ID = PQ_KEM_2 ) +-- Transform ADDKE3 ( ID = PQ_KEM_2 )
| |
+-- Transform AKE5 ( ID = PQ_KEM_3 ) +-- Transform ADDKE5 ( ID = PQ_KEM_3 )
| |
+-- Transform AKE5 ( ID = NONE ) +-- Transform ADDKE5 ( ID = NONE )
]]>
]]></artwork></figure> </artwork>
<t> In this example, the initiator proposes to perform initial k
ey exchange using 4096-bit MODP group
followed by two mandatory additional key exchanges (i.e. Transfo
rms AKE2 and AKE3) using PQ_KEM_1 and
PQ_KEM_2 methods in any order, then followed by additional key e
xchange (i.e. Transform AKE5) using
PQ_KEM_3 method that may be omitted.
</t>
<t> The responder might return the following SA payload, indicat <t> In this example, the initiator proposes performing the
ing that it agrees to initial key exchange using a 4096-bit MODP Group followed by two
perform two additional key exchanges PQ_KEM_2 followed by PQ_KEM mandatory additional key exchanges (i.e., ADDKE2 and ADDKE3 Transform
_1 and does not Types)
want to perform PQ_KEM_3 additionally. using PQ_KEM_1 and PQ_KEM_2 methods in any order followed
</t> by an additional key exchange (i.e., ADDKE5 Transform 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, PQ_KEM_2
followed by PQ_KEM_1, and that it does not want to additionally perfor
m
PQ_KEM_3.
</t>
<figure><artwork align="center" ><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
SA Payload SA Payload
| |
+--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8, +--- Proposal #1 ( Proto ID = IKE(1), SPI Size = 8,
| 6 transforms, SPI = 0x8df52b331a196e7b ) | 6 transforms, SPI = 0x8df52b331a196e7b )
| |
+-- Transform ENCR ( ID = ENCR_AES_GCM_16 ) +-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
| +-- Attribute ( Key Length = 256 ) | +-- Attribute ( Key Length = 256 )
| |
+-- Transform KE ( ID = 4096-bit MODP Group ) +-- Transform KE ( ID = 4096-bit MODP Group )
| |
+-- Transform PRF ( ID = PRF_HMAC_SHA2_256 ) +-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
| |
+-- Transform AKE2 ( ID = PQ_KEM_2 ) +-- Transform ADDKE2 ( ID = PQ_KEM_2 )
| |
+-- Transform AKE3 ( ID = PQ_KEM_1 ) +-- Transform ADDKE3 ( ID = PQ_KEM_1 )
| |
+-- Transform AKE5 ( ID = NONE ) +-- Transform ADDKE5 ( ID = NONE )
]]>
]]></artwork></figure> </artwork>
<t> If the initiator includes any Additional Key Exchange transf <t> If the initiator includes any ADDKE Transform
orm types into the SA payload in the IKE_SA_INIT exchange request message, Types into the SA payload in the IKE_SA_INIT exchange request
then it MUST also negotiate the use of the IKE_INTERMEDIATE exch message, then it <bcp14>MUST</bcp14> also negotiate the use of the
ange as described in <xref target="RFC9242" />, IKE_INTERMEDIATE exchange, as described in <xref target="RFC9242"
by including INTERMEDIATE_EXCHANGE_SUPPORTED notification in the format="default"/> by including an INTERMEDIATE_EXCHANGE_SUPPORTED
same message. notification in the same message. If the responder agrees to use
If the responder agrees to use additional key exchanges while es additional key exchanges while establishing an initial IKE SA, it
tablishing initial IKE SA, <bcp14>MUST</bcp14> also return this notification in the IKE_SA_INIT
it MUST also return this notification in the IKE_SA_INIT respons response message, confirming that IKE_INTERMEDIATE exchange is
e message, supported and will be used for transferring additional key exchange
thus confirming that IKE_INTERMEDIATE exchange is supported and data. If the IKE_INTERMEDIATE exchange is not negotiated, then the
will be used for transferring additional key exchange data. peers <bcp14>MUST</bcp14> treat any ADDKE
If the IKE_INTERMEDIATE exchange is not negotiated, then the pee Transform Types in the IKE_SA_INIT exchange messages as unknown transf
rs MUST treat any Additional Key Exchange transforms orm
in the IKE_SA_INIT exchange messages as unknown transform types types and skip the proposals they appear in. If no other proposals
and skip the proposals they appear in. are present in the SA payload, the peers will proceed as if no
If no other proposals are present in the SA payload, the peers w proposal has been chosen (i.e., the responder will send a NO_PROPOSAL_
ill proceed as if no proposal is chosen CHOSEN
(i.e. the responder will send NO_PROPOSAL_CHOSEN notification). notification).
</t> </t>
<figure><artwork align="center" ><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
Initiator Responder Initiator Responder
--------------------------------------------------------------------- ---------------------------------------------------------------------
HDR, SAi1(.. AKE*...), KEi, Ni, HDR, SAi1(.. ADDKE*...), KEi, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> N(INTERMEDIATE_EXCHANGE_SUPPORTED) --->
HDR, SAr1(.. AKE*...), KEr, Nr, HDR, SAr1(.. ADDKE*...), KEr, Nr,
[CERTREQ], [CERTREQ],
<--- N(INTERMEDIATE_EXCHANGE_SUPPORTED) <--- N(INTERMEDIATE_EXCHANGE_SUPPORTED)
]]></artwork></figure> ]]>
</artwork>
<t> It is possible that an attacker manages 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 de
scribed in Section 2.4 of <xref target="RFC7296" />.
</t>
</section>
<section title="IKE_INTERMEDIATE Round: Additional Key Exchanges" <t> It is possible for an attacker to manage to send a response to
anchor="additional_ke"> the initiator's IKE_SA_INIT request before the legitimate responder
<t> For each additional key exchange agreed to in the IKE_SA_INI does. If the initiator continues to create the IKE SA using this
T exchange, response, the attempt will fail. Implementers may wish to consider
the initiator and the responder perform IKE_INTERMEDIATE strategies as described
exchange, in <xref target="RFC7296"
as described in <xref target="RFC9242"/>.</t> sectionFormat="of" section="2.4"/> to handle such an attack.
</t>
</section>
<section anchor="additional_ke" numbered="true" toc="default">
<name>IKE_INTERMEDIATE Round: Additional Key Exchanges</name>
<t> For each additional key exchange agreed to in the IKE_SA_INIT exch
ange,
the initiator and the responder perform an IKE_INTERMEDIA
TE exchange,
as described in <xref target="RFC9242" format="default"/>.</t>
<figure><artwork align="center" ><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
Initiator Responder Initiator Responder
--------------------------------------------------------------------- ---------------------------------------------------------------------
HDR, SK {KEi(n)} --> HDR, SK {KEi(n)} -->
<-- HDR, SK {KEr(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) denotes the n-th IKE_INTERMEDIATE KE payload
from the initiator
and the integer n is sequential starting from 1.</t>
<t> On receiving this, the responder sends back key exchange pay
load KEr(n),
which denotes the n-th IKE_INTERMEDIATE KE payload from the resp
onder.
As before, this message is protected with the current SK_er/SK_a
r keys.</t>
<t> The former "Diffie-Hellman Group Num" (now called "Key Excha
nge Method") field in the KEi(n) and KEr(n) payloads MUST match the
n-th negotiated additional key exchange.
<!-- Note that the negotiated transform types (the encryption t
ype, integrity type, prf type) are not modified. (do we need to say this?) -->
</t>
<t> Once this exchange is done, both sides compute an updated ke <t> The initiator sends key exchange data in the KEi(n) payload.
ying material:</t> This message is protected with the current SK_ei/SK_ai keys. The
notation "KEi(n)" denotes the n-th IKE_INTERMEDIATE KE payload from
the initiator; the integer "n" is sequential starting from
1.</t>
<t> On receiving this, the responder sends back key exchange payload
KEr(n); "KEr(n)" denotes the n-th IKE_INTERMEDIATE KE payload from the
responder. Similar to how the request is protected, this message is p
rotected with the current
SK_er/SK_ar keys.</t>
<t> The former "Diffie-Hellman Group Num" (now called "Key Exchange Me
thod") field in the KEi(n) and KEr(n) payloads <bcp14>MUST</bcp14> match the
n-th negotiated additional key exchange.</t>
<t> Once this exchange is done, both sides compute an updated keying m
aterial:</t>
<figure><artwork align="center" ><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr) SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)
]]></artwork></figure> ]]>
</artwork>
<t> where SK(n) is the resulting shared secret of this key excha <t> From this exchange, SK(n) is the resulting shared secret. Ni and N
nge, r are nonces from the IKE_SA_INIT exchange.
Ni and Nr are nonces from the IKE_SA_INIT exchange and SK_d(n-1) SK_d(n-1) is the last generated SK_d (derived from IKE_SA_INIT
is the for the first use of IKE_INTERMEDIATE and, otherwise, from the
last generated SK_d, (derived from IKE_SA_INIT for the first use previous IKE_INTERMEDIATE exchange). The other keying materials,
of IKE_INTERMEDIATE, otherwise from the previous IKE_INTERMEDIATE exchange). SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr, are generated
The other keying materials SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_ from the SKEYSEED(n) as follows:</t>
pi, SK_pr are generated from the SKEYSEED(n) as follows:</t>
<figure><artwork align="center" ><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
{SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) | {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) SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr)
]]></artwork></figure> ]]>
</artwork>
<t> Both the initiator and the responder use these updated key <t> Both the initiator and the responder use these updated key
values in the next exchange (IKE_INTERMEDIATE or IKE_AUTH ).</t> values in the next exchange (IKE_INTERMEDIATE or IKE_AUTH ).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IKE_AUTH Exchange"> <name>IKE_AUTH Exchange</name>
<t> After all IKE_INTERMEDIATE exchanges have completed, the ini <t> After all IKE_INTERMEDIATE exchanges have completed, the initiator
tiator and and
the responder perform an IKE_AUTH exchange. This exchang e is the responder perform an IKE_AUTH exchange. This exchang e is
the standard IKE exchange as described in <xref target="R FC7296"/> with the standard IKE exchange, as described in <xref target=" RFC7296" format="default"/>, with
the modification of AUTH payload calculation described in the modification of AUTH payload calculation described in
<xref target="RFC9242"/>.</t> <xref target="RFC9242" format="default"/>.</t>
</section> </section>
<section anchor="create_child_sa_exchange" numbered="true" toc="default"
<section title="CREATE_CHILD_SA Exchange" anchor="create_child_sa_ex >
change"> <name>CREATE_CHILD_SA Exchange</name>
<t> The CREATE_CHILD_SA exchange is used in IKEv2 for the purpos <t> The CREATE_CHILD_SA exchange is used in IKEv2 for the purposes
es of creating additional Child SAs, rekeying these Child SAs, and
of creating additional Child SAs, rekeying these and rekeying IK rekeying IKE SA itself. When creating or rekeying Child SAs, the
E SA itself. peers may optionally perform a key exchange to add a fresh entropy
When creating or rekeying Child SAs, the peers may optionally into the session keys. In the case of an IKE SA rekey, the key exchan
perform a key exchange to add a fresh entropy into the session k ge is
eys. mandatory. Peers supporting this specification may want to use
In case of IKE SA rekey, the key exchange is mandatory. multiple key exchanges in these situations.
Peers supporting this specification may want to use multiple key </t>
exchanges <t> Using multiple key exchanges with a CREATE_CHILD_SA exchange is
in these situations. negotiated in a similar fashion to the initial IKE exchange, see <xref
</t> target="negotiation" format="default"/>. If the initiator includes
any ADDKE Transform Types in the SA payload (along with
<t> Using multiple key exchanges with CREATE_CHILD_SA exchange i Transform Type 4), and if the responder agrees to perform additional
s negotiated key exchanges, then the additional key exchanges are performed in a
similarly as in the initial IKE exchange, see <xref target="nego series of new IKE_FOLLOWUP_KE exchanges that follow the
tiation" />. CREATE_CHILD_SA exchange. The IKE_FOLLOWUP_KE exchange is introduced
If the initiator includes any Additional Key Exchange transform especially for
in the SA payload transferring data of additional key exchanges following the one
(along with Transform Type 4) and the responder agrees to perfor performed in the CREATE_CHILD_SA. Its Exchange Type value is
m additional 44.
key exchanges, then the additional key exchanges are performed i </t>
n a series <t>
of new IKE_FOLLOWUP_KE exchanges that follows the CREATE_CHILD_S The key exchange negotiated via Transform Type 4 always takes
A exchange. place in the CREATE_CHILD_SA exchange, as per the IKEv2
The IKE_FOLLOWUP_KE exchange is introduced as a dedicated exchan specification <xref target="RFC7296" format="default"/>. Additional k
ge for transferring data of additional key exchanges ey exchanges are performed in an order
following the key exchange performed in the CREATE_CHILD_SA. Its of the values of their Transform Types so that the key exchange
Exchange Type value is 44. negotiated using Additional Key Exchange i always precedes the key exc
</t> hange
negotiated using Additional Key Exchange i + 1. Each additional key ex
<t> Key exchange negotiated via Transform Type 4 always takes pl change
ace in the CREATE_CHILD_SA exchange, as per IKEv2 specification. method <bcp14>MUST</bcp14> be fully completed before the next one is
Additional key exchanges are performed in an order of the values started. Note that this document assumes that each key exchange
of their transform types, so that method consumes exactly one IKE_FOLLOWUP_KE exchange. For the
key exchange negotiated using Transform Type n always precedes k methods that require multiple round trips, a separate document should
ey exchange negotiated using define how such methods are split into several IKE_FOLLOWUP_KE
Transform Type n + 1. Each additional key exchange method MUST b exchanges.
e fully completed before the next one is started. </t>
Note, that this document assumes, that each key exchange method <t>After an IKE SA is created, the window size may be greater than one
consumes exactly one IKE_FOLLOWUP_KE exchange. ; thus, multiple concurrent exchanges may be in progress. Therefore, it is
For the methods requiring multiple round trips, a separate docum essential to link the IKE_FOLLOWUP_KE exchanges together with the
ent should define how such corresponding CREATE_CHILD_SA exchange. Once an IKE SA is created, all IKE
methods are split into several IKE_FOLLOWUP_KE exchanges. exchanges are independent and IKEv2 doesn't have a built-in mechanism to link
</t> an exchange
with another one. A new status type notification called
<t> After an IKE SA is created the window size may be greater th "ADDITIONAL_KEY_EXCHANGE" is introduced for this purpose.
an one and multiple Its Notify Message Type value is 16441, and the Protocol ID and SPI
concurrent exchanges may be in progress, it is essential to link Size are both set to 0. The data associated with this notification
the IKE_FOLLOWUP_KE exchanges together is a blob meaningful only to the responder so that the
with the corresponding CREATE_CHILD_SA exchange. Due to the fac responder can correctly link successive exchanges. For the
t that once an IKE SA is created, all IKE exchanges initiator, the content of this notification is an opaque blob.
are independent and do not have built-in means to link one with a </t>
nother, a new status type <t> The responder <bcp14>MUST</bcp14> include this notification in a
notification ADDITIONAL_KEY_EXCHANGE is introduced for this purpo CREATE_CHILD_SA or IKE_FOLLOWUP_KE response message in case the next
se. IKE_FOLLOWUP_KE exchange is expected, filling it with some data that
Its Notify Message Type value is 16441, and Protocol ID and SPI S would allow linking the current exchange to the next one.
ize The initiator <bcp14>MUST</bcp14> send back this notification intact
are both set to 0. The data associated with this notification i in the request message of the next IKE_FOLLOWUP_KE exchange.
s a blob meaningful </t>
only to the responder, so that the responder can correctly link <t> Below is an example of CREATE_CHILD_SA exchange followed by three
successive additional key exchanges.
exchanges. For the initiator the content of this notification i </t>
s an opaque blob.
</t>
<t> The responder MUST include this notification in a CREATE_CHI
LD_SA or
IKE_FOLLOWUP_KE response message in case the next IKE_FOLLOWUP_K
E exchange is expected, filling it with
some data that would allow linking the current exchange to the n
ext one. The initiator
MUST send back this notification intact in the request message o
f 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 align="center" ><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
Initiator Responder Initiator Responder
--------------------------------------------------------------------- ---------------------------------------------------------------------
HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
<-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr,
N(ADDITIONAL_KEY_EXCHANGE)(link1)} N(ADDITIONAL_KEY_EXCHANGE)(link1)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(1), HDR(IKE_FOLLOWUP_KE), SK {KEi(1),
N(ADDITIONAL_KEY_EXCHANGE)(link1)} --> N(ADDITIONAL_KEY_EXCHANGE)(link1)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1), <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1),
N(ADDITIONAL_KEY_EXCHANGE)(link2)} N(ADDITIONAL_KEY_EXCHANGE)(link2)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(2), HDR(IKE_FOLLOWUP_KE), SK {KEi(2),
N(ADDITIONAL_KEY_EXCHANGE)(link2)} --> N(ADDITIONAL_KEY_EXCHANGE)(link2)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2), <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2),
N(ADDITIONAL_KEY_EXCHANGE)(link3)} N(ADDITIONAL_KEY_EXCHANGE)(link3)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(3), HDR(IKE_FOLLOWUP_KE), SK {KEi(3),
N(ADDITIONAL_KEY_EXCHANGE)(link3)} --> N(ADDITIONAL_KEY_EXCHANGE)(link3)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(3)} <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(3)}
]]></artwork></figure> ]]>
</artwork>
<t> The former "Diffie-Hellman Group Num" (now called "Key Excha nge Method") field in the KEi(n) and KEr(n) payloads MUST match the <t> The former "Diffie-Hellman Group Num" (now called "Key Exchange Me thod") field in the KEi(n) and KEr(n) payloads <bcp14>MUST</bcp14> match the
n-th negotiated additional key exchange. n-th negotiated additional key exchange.
</t> </t>
<t>Due to some unexpected events (e.g., a
<t> It is possible that due to some unexpected events (e.g. rebo reboot), it is possible that the initiator may lose its state, forget
ot) that it is in
the initiator may lose its state and forget that it is in the pr the process of performing additional key exchanges, and never
ocess of performing start the remaining IKE_FOLLOWUP_KE exchanges. The responder
additional key exchanges and thus never start the remaining IKE_ <bcp14>MUST</bcp14> handle this situation gracefully and delete the
FOLLOWUP_KE exchanges. associated state if it does not receive the next expected
The responder MUST handle this situation gracefully and delete IKE_FOLLOWUP_KE request after some reasonable period of time. Due to
the associated state if it does not receive the next expected various factors such as computational resource and key
IKE_FOLLOWUP_KE request after some reasonable period of time. exchange algorithm used, note that it is not possible to give normati
Note that due to various factors such as computational resource ve
and guidance on how long this timeout period should be. In general, 5-20
key exchange algorithm used, it is not possible to give a normat seconds of waiting time should be appropriate in most cases.
ive </t>
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 may take too long to
prepare and send the next IKE_FOLLOWUP_KE request or due to the n
etwork
conditions, the request is retransmitted. In this case, the messa
ge may reach the responder
when it has already deleted the associated state
following the advice above. If the responder receives an IKE_FOL
LOWUP_KE message for which it does not have a key exchange state,
it MUST send back a new error type notification
STATE_NOT_FOUND. This is a non-fatal error notification, its No
tify Message Type is 47,
Protocol ID and SPI Size are both set to 0 and the data is empty
. If the initiator receives
this notification in response to IKE_FOLLOWUP_KE exchange perfor
ming additional
key exchange, it MUST cancel this exchange and MUST treat the wh
ole series
of exchanges started from the CREATE_CHILD_SA exchange as failed
.
In most cases, the receipt of this notification is caused by pre
mature deletion
of the corresponding state on the responder (the time period bet
ween
IKE_FOLLOWUP_KE exchanges appeared too long from the responder's
point of view, e.g. due
to a temporary network failure). After receiving this notificat
ion the initiator MAY
start a new CREATE_CHILD_SA exchange which may eventually be fol
lowed by the IKE_FOLLOWUP_KE exchanges,
to retry the failed attempt. If the initiator continues to rece
ive
STATE_NOT_FOUND notifications after several retries, it MUST tre
at this situation
as a fatal error and delete IKE SA by sending a DELETE payload.
</t>
<t> When rekeying the IKE SA or the Child SA, it is possible tha
t the peers start doing this
at the same time, which is called simultaneous rekeying. Sectio
ns 2.8.1 and 2.8.2 of
<xref target="RFC7296" /> describe how IKEv2 handles this situat
ion. In a nutshell
IKEv2 follows the rule that if in case of simultaneous rekeying,
two identical new
IKE SAs (or two pairs of Child SAs) are created, then one of the
m should be deleted.
Which one is to be deleted is determined by comparing the values
of four nonces
that are used in the colliding CREATE_CHILD_SA exchanges. The IK
E SA (or pair of Child SAs)
that is created by the exchange in which the smallest nonce is u
sed should be deleted by
the initiator of this exchange.
</t>
<t> With multiple key exchanges, the SAs are not yet created whe
n the CREATE_CHILD_SA is completed,
they would be created only after the series of IKE_FOLLOWUP_KE e
xchanges is finished.
For this reason, if additional key exchanges are negotiated in t
he CREATE_CHILD_SA
exchange in which the smallest nonce is used, then because there
is nothing to delete
yet, the initiator of this exchange just stops the rekeying proc
ess and it MUST NOT
initiate the IKE_FOLLOWUP_KE exchange.
</t>
<t> In most cases, rekey collisions are resolved in the CREATE_C
HILD_SA exchange.
However, a situation may occur when due to packet loss, one of t
he peers receives the CREATE_CHILD_SA message
requesting rekey of SA that is already being rekeyed by this pee
r (i.e. the CREATE_CHILD_SA
exchange initiated by this peer has been already completed and t
he series of IKE_FOLLOWUP_KE exchanges is in progress).
In this case, a TEMPORARY_FAILURE notification MUST be sent in r
esponse to such a request.
</t>
<t> If multiple key exchanges are negotiated in the CREATE_CHILD <t>It may also take too long for the initiator to prepare
_SA exchange, then the resulting keys are and to send the next IKE_FOLLOWUP_KE request, or, due to the
network conditions, the request could be lost and retransmitted.
In
this case, the message may reach the responder when it has already
deleted the associated 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 <bcp14>MUST</bcp14> send back a new
error type notification called "STATE_NOT_FOUND". This is an error no
tification 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, 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 <bcp14>MUST</bcp14>
cancel this exchange and <bcp14>MUST</bcp14> treat the whole series
of exchanges started from the CREATE_CHILD_SA exchange as having faile
d.
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., due to a temporary
network failure). After receiving this notification, the initiator
<bcp14>MAY</bcp14> start a new CREATE_CHILD_SA 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
<bcp14>MUST</bcp14> treat this situation as a fatal error and delete
the IKE SA by sending a DELETE payload.
</t>
<t> It is possible that
the peers start rekeying the IKE SA or the Child SA at the same time,
which is called
"simultaneous rekeying". Sections <xref target="RFC7296"
section="2.8.1" sectionFormat="bare"/> and <xref target="RFC7296"
section="2.8.2" sectionFormat="bare"/> of <xref target="RFC7296"/>
describe how IKEv2 handles this situation. In a nutshell, IKEv2
follows the rule 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 to 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) 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. 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,
because there is nothing to delete yet, the initiator of this
exchange just stops the rekeying process, and it <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, 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., the CREATE_CHILD_SA exchange initiated by this peer
has already been completed, and the series of IKE_FOLLOWUP_KE
exchanges is in progress). In this case, a TEMPORARY_FAILURE
notification <bcp14>MUST</bcp14> be sent in response to such a
request.
</t>
<t> If multiple key exchanges are negotiated in the CREATE_CHILD_SA ex
change, then the resulting keys are
computed as follows.</t> computed as follows.</t>
<t>In the case of an IKE SA rekey:
</t>
<t>In case of IKE SA rekey: <artwork align="center" name="" type="" alt=""><![CDATA[
</t>
<figure><artwork align="center" ><![CDATA[
SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)) SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n))
]]></artwork></figure> ]]>
</artwork>
<t> In case of Child SA creation or rekey: <t> In the case of a Child SA creation or rekey:
</t> </t>
<figure><artwork align="center" ><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
KEYMAT = prf+ (SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n)) 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,
Nr are the shared key and nonces
from the CREATE_CHILD_SA respectively; SK(1)...SK(n) are the sha
red keys from additional key exchanges.
</t>
</section>
<section title="Interaction with IKEv2 Extensions">
<t> It is believed that this specification requires no modification t
o the IKEv2 extensions defined so far.
In particular, IKE SA resumption mechanism defined in <xref target="R
FC5723" /> can be used to resume
IKE SAs created using this specification.
</t>
<section title="Interaction with Childless IKE SA">
<t>It is possible to establish IKE SAs with post-quantum algorithms
only using additional key exchanges,
but without using IKE_INTERMEDIATE exchanges. In this case, the IKE
SA created from IKE_SA_INIT exchange
can be immediately rekeyed with CREATE_CHILD_SA using additional key
exchanges where IKE_FOLLOWUP_KE
messages are used to carry the key exchange payload. If classical k
ey 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"/>.
In this case, the initiator sends two types of
proposal in the IKE_SA_INIT request, one with and another one withou
t Additional
Key Exchange transform(s). The responder chooses the latter proposa
l type and includes
CHILDLESS_IKEV2_SUPPORTED notification in the IKE_SA_INIT response.
Assuming that
the initiator supports childless IKE SA extension, then both peers p
erforms
the modified IKE_AUTH exchange described in <xref target="RFC6023"/>
and no
Child SA is created in this exchange. The peers should then immedia
tely rekey
the IKE SA and subsequently create the Child SAs, all with additiona
l key
exchanges using CREATE_CHILD_SA exchange.</t>
<t>It is also possible for the initiator to send proposals without A
dditional Key
Exchange transform(s) in the IKE_SA_INIT message and in this instanc
e, the responder will have
no information whether or not the initiator supports the extension i
n this
specification. This may not be efficient as the responder will have
to wait for
the subsequent CREATE_CHILD_SA request to determine whether or not t
he initiator's
request is appropriate for its local policy.</t>
<t>The support for childless IKE SA is not negotiated, but it is the <t> In both cases, SK_d is from the existing IKE SA; SK(0), Ni, and
responder that Nr are the shared key and nonces from the CREATE_CHILD_SA,
indicates the support for this mode. As such, the responder cannot respectively; SK(1)...SK(n) are the shared keys from additional
enforce the key exchanges.
initiator to use this mode and therefore, it is entirely possible th </t>
at the </section>
initiator does not support this extension and sends IKE_AUTH request <section numbered="true" toc="default">
as per <name>Interaction with IKEv2 Extensions</name>
<xref target="RFC7296"/> instead of <xref target="RFC6023"/>. In th <t> It is believed that this specification requires no modification
is case, the to the IKEv2 extensions defined so far. In particular, the IKE SA
responder may respond with non-fatal error such as NO_PROPOSAL_CHOSE resumption mechanism defined in <xref target="RFC5723"
N notify message type.</t> format="default"/> can be used to resume IKE SAs created using this
specification.
</t>
<section numbered="true" toc="default">
<name>Interaction with Childless IKE SA</name>
<t>Note that if the initial IKE SA is used to transfer sensitive inf <t>It is possible to establish IKE SAs with post-quantum algorithms
ormation, then this information by
will not be protected using the additional key exchanges, which may only using IKE_FOLLOWUP_KE exchanges and without the use of
use post-quantum algorithms. In this arrangement, IKE_INTERMEDIATE exchanges. In this case, the IKE SA that is
the peers will have to use post-quantum algorithm in Transform Type created from the IKE_SA_INIT exchange, can be immediately rekeyed with
4 in order to mitigate the risk of quantum attack. </t> CREATE_CHILD_SA with additional key exchanges, where IKE_FOLLOWUP_KE
</section> messages are used for these additional key exchanges. If the classical key exch
</section> ange 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 all Child
SAs to be post-quantum secure, then the peers can avoid creating
the very first Child SA by adopting <xref target="RFC6023"
format="default"/>. In this case, the initiator sends two types
of proposals in the IKE_SA_INIT request: one with and another one
without 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, both peers perform the modified IKE_AUTH exchange
described in <xref 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
any ADDKE Transform Types in the IKE_SA_INIT 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, 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 use this mode.
Therefore, it is entirely possible that the initiator does not
support this extension and sends IKE_AUTH request as per <xref
target="RFC7296" format="default"/> instead of <xref
target="RFC6023" format="default"/>. In this case, the responder
may respond with 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> </section>
<section title="IANA Considerations" anchor="IANA"> <section anchor="IANA" numbered="true" toc="default">
<t>This document adds new exchange type into the "IKEv2 Exchange Types" <name>IANA Considerations</name>
registry:</t> <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 44 IKE_FOLLOWUP_KE
]]></artwork></figure> ]]>
</artwork>
<t>This document renames Transform Type 4 defined in "Transform Type Val ues" registry <t>This document renames Transform Type 4 defined in the "Transform Type V alues" registry
from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)".</t> from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)".</t>
<t>This document renames the IKEv2 registry originally titled "Transform T
<t>This document renames IKEv2 registry "Transform Type 4 - Diffie-Hellm ype 4 - Diffie-Hellman Group Transform IDs" to
an Group Transform IDs" to
"Transform Type 4 - Key Exchange Method Transform IDs".</t> "Transform Type 4 - Key Exchange Method Transform IDs".</t>
<t>This document adds the following Transform Types to the "Transform Type Values" registry:</t>
<t>This document adds the following Transform Types to the "Transform Ty <table anchor="transform-type-values" align="center">
pe Values" registry:</t> <name>"Transform Type Values" Registry</name>
<figure align="left"><artwork align="left"><![CDATA[ <thead>
Type Description Used In <tr>
6 Additional Key Exchange 1 (optional in IKE, AH, ESP) <th>Type</th>
7 Additional Key Exchange 2 (optional in IKE, AH, ESP) <th>Description</th>
8 Additional Key Exchange 3 (optional in IKE, AH, ESP) <th>Used In</th>
9 Additional Key Exchange 4 (optional in IKE, AH, ESP) </tr>
10 Additional Key Exchange 5 (optional in IKE, AH, ESP) </thead>
11 Additional Key Exchange 6 (optional in IKE, AH, ESP) <tbody>
12 Additional Key Exchange 7 (optional in IKE, AH, ESP) <tr>
]]></artwork></figure> <td>6</td>
<td>Additional Key Exchange 1 (ADDKE1)</td>
<td>(optional in IKE, AH, ESP)</td>
</tr>
<tr>
<td>7</td>
<td>Additional Key Exchange 2 (ADDKE2)</td>
<td>(optional in IKE, AH, ESP)</td>
</tr>
<tr>
<td>8</td>
<td>Additional Key Exchange 3 (ADDKE3)</td>
<td>(optional in IKE, AH, ESP)</td>
</tr>
<tr>
<td>9</td>
<td>Additional Key Exchange 4 (ADDKE4)</td>
<td>(optional in IKE, AH, ESP)</td>
</tr>
<tr>
<td>10</td>
<td>Additional Key Exchange 5 (ADDKE5)</td>
<td>(optional in IKE, AH, ESP)</td>
</tr>
<tr>
<td>11</td>
<td>Additional Key Exchange 6 (ADDKE6)</td>
<td>(optional in IKE, AH, ESP)</td>
</tr>
<tr>
<td>12</td>
<td>Additional Key Exchange 7 (ADDKE7)</td>
<td>(optional in IKE, AH, ESP)</td>
</tr>
</tbody>
</table>
<t>This document defines a new Notify Message Type in the "Notify Messag e Types - Status Types" registry:</t> <t>This document defines a new Notify Message Type in the "IKEv2 Notify Me ssage Types - Status Types" registry:</t>
<figure align="center"><artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
16441 ADDITIONAL_KEY_EXCHANGE 16441 ADDITIONAL_KEY_EXCHANGE
]]></artwork></figure> ]]>
</artwork>
<t>and a new Notify Message Type in the "Notify Message Types - Error Ty pes" registry:</t> <t>This document also defines a new Notify Message Type in the "IKEv2 Noti fy Message Types - Error Types" registry:</t>
<figure align="center"><artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
47 STATE_NOT_FOUND 47 STATE_NOT_FOUND
]]></artwork></figure> ]]>
</artwork>
<section title="Additional Considerations and Changes">
<t>The IANA is requested to add the following instructions for desig
nated experts
for Transform Type 4 sub-registry.</t>
<t>While adding new KE methods, the following considerations must be
applied.
A KE method must take exactly one round-trip (one IKE exchange) and
at the end
of this exchange, both peers must be able to derive the shared secre
t. In addition, any public value peers exchanged during a KE method must fit int
o a single IKE
message. If these restrictions are not met for a KE method, then th
ere must be
documentation on how this KE method is used in IKEv2.</t>
<t>The following changes to IANA are also requested. It is assumed t <t>IANA has added the following instructions for designated
hat experts for the "Transform Type 4 - Key Exchange Method Transform IDs" s
RFCXXXX refers to this specification.</t> ubregistry:</t>
<t><list style="symbols">
<t>Add a reference to RFCXXXX in the "Transform Type 4 - Diffie-He <ul><li>While adding new Key Exchange (KE) methods, the following consid
llman Group Transform IDs" erations must be
registry.</t> applied. A KE method must take exactly one round-trip (one 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 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.</li></ul>
<t>IANA has also completed the following changes. It is assumed that
[RFC9370] refers to this specification.</t>
<ul spacing="normal">
<t>Replace the note on "Transform Type 4 - Diffie-Hellman Group Tr <li><t>Added a reference to [RFC9370] in what was the "Transform Type
ansform IDs" registry with: 4 -
This registry was originally named "Transform Type 4 - Diffie-Hell Diffie-Hellman Group Transform IDs" registry.</t></li>
man Group Transform IDs" and <li><t>Replaced the Note on what was the "Transform Type 4 - Diffie-He
was renamed to its current name by [RFCXXXX]. It has been referen llman Group
ced in its original name in Transform IDs" registry with the following notes:</t>
a number of RFCs prior to [RFCXXXX]. To find out requirement leve <t>This registry was originally named "Transform Type 4 -
ls for Key Exchange Methods Diffie-Hellman Group Transform IDs" and was referenced using
for IKEv2, see [RFC8247].</t> that name in a number of RFCs published prior to [RFC9370],
which gave it the current title.</t>
<t>Add this note to "Transform Type Values" registry: Transform Ty <t>This registry is used by the "Key Exchange Method (KE)" transfor
pe "Transform Type 4 - Key m type and by all "Additional Key Exchange (ADDKE)" transform types.</t>
Exchange Method Transform IDs" was originally named "Transform Typ
e 4 - Diffie-Hellman Group
Transform IDs" and was renamed to its current name by [RFCXXXX].
It has been referenced in its
original name in a number of RFCs prior to [RFCXXXX]. All "Additi
onal Key Exchange" entries use
the same "Transform Type 4 - Key Exchange Method Transform IDs" as
the "Key Exchange Method (KE)".</t>
<t>Append RFCXXXX to the Reference column of Transform Type 4 in t <t>To find out requirement levels
he Transform Type Values registry.</t> for Key Exchange Methods for IKEv2, see <xref target="RFC8247" format="
default"/>.</t></li>
<li><t>Appended [RFC9370] to the Reference column of Transform Type 4 i
n
the "Transform Type Values" registry.</t></li>
<li><t>Added these notes to the "Transform Type Values" registry:</t>
<t>"Key Exchange Method (KE)" transform type was originally
named "Diffie-Hellman Group (D-H)" and was referenced by that name in a numb
er of RFCs
published prior to [RFC9370], which gave it the current title.</t><t>All "Ad
ditional Key Exchange (ADDKE)" entries use the same
"Transform Type 4 - Key Exchange Method Transform IDs"
registry as the "Key Exchange Method (KE)" entry.</t></li>
<t>Append this note to "Transform Type 4 - Diffie-Hellman Group Tr </ul>
ansform IDs" registry: All
"Additional Key Exchange" entries use these values as the "Key Ex
change Method (KE)".</t>
</list></t>
</section>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section title="Security Considerations" anchor="security"> <name>Security Considerations</name>
<t>The extension in this document is intended to mitigate two possible t <t>The extension in this document is intended to mitigate two possible
hreats in IKEv2, namely threats in IKEv2: the compromise of (EC)DH key exchange using
the compromise of (EC)DH key exchange using Shor's algorithm while remai Shor's algorithm while remaining backward compatible and the potential
ning backward compatible; compromise of existing or future PQC key exchange algorithms. To
and the potential compromise of existing or future PQC key exchange algo address the former threat, this extension allows the establishment of a
rithms. To address the shared secret by using multiple key exchanges: typically, one classical
former threat, this extension allows the establishment of a shared secre (EC)DH and the other one post-quantum algorithm. In order to address
t by using multiple key the latter threat, multiple key exchanges using a post-quantum algorithm
exchanges, typically one classical (EC)DH and the other one post-quantum can be performed to form the shared key.
algorithm. In order to </t>
address the latter threat, multiple key exchanges using a post-quantum a <t>Unlike key exchange methods (Transform Type 4), the Encryption
lgorithm can be composed to Algorithm (Transform Type 1), the Pseudorandom Function (Transform Type
form the shared key. 2), and the Integrity Algorithm (Transform Type 3) are not susceptible
</t> to Shor's algorithm. However, they are susceptible to Grover's attack
<xref target="GROVER" format="default"/>, which allows a quantum
<t>Unlike key exchange methods (Transform Type 4), the Encryption Algori computer to perform a brute force key search, using quadratically fewer
thm (Transform Type 1), steps than the classical counterpart. Simply increasing the key length
the Pseudorandom Function (Transform Type 2) and the Integrity Algorithm can mitigate this attack. It was previously believed that one needed to
(Transform Type 3) are double the key length of these algorithms. However, there are a number
not susceptible to Shor's algorithm. However, they are susceptible to G of factors that suggest that it is quite unlikely to achieve the
rover's attack <xref target="GROVER"/>, quadratic speedup using Grover's algorithm. According to NIST <xref
which allows a quantum computer to perform a brute force key search usin target="NISTPQCFAQ" format="default"/>, current applications can
g quadratically fewer continue using an AES algorithm with the minimum key length of 128 bits.
steps than the classical counterpart. Simply increasing the key length Nevertheless, if the data needs to remain secure for many years to come,
can mitigate this attack. one may want to consider using a longer key size for the algorithms in
It was previously believed that one needed to double the key length of t Transform Types 1-3.
hese algorithms. However, </t>
there are a number of factors that suggest that it is quite unlikely to <t>SKEYSEED is calculated from shared SK(x), using an algorithm defined
achieve the quadratic speed up
using Grover's algorithm. According to NIST <xref target="NISTPQCFAQ"/>
, current applications can
continue using AES algorithm with the minimum key length of 128 bit. Ne
vertheless, 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) using an algorithm defined
in Transform Type 2. While a quantum attacker may learn the value 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, 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 other SK(x) values generated by means of a post-quantum algorithm
ensure that the final SKEYSEED is not compromised. This assumes that ensure that the final SKEYSEED is not compromised. This assumes that
the algorithm defined in the Transform Type 2 is quantum resistant. the algorithm defined in the Transform Type 2 is quantum resistant.
</t> </t>
<t>The ordering of the additional key exchanges should not matter in
<t>The ordering of the additional key exchanges should not matter in gen general, as only the final shared secret is of interest. Nonetheless,
eral, because the strength of the running shared secret increases with every
as only the final shared secret is of interest. Nonetheless, because th additional key exchange, an implementer may want to first perform the
e strength most secure method (in some metrics) followed by less secure
of the running shared secret increases with every additional key exchang methods.</t>
e, an <t>The main focus of this document is to prevent a passive attacker from
implementer may want to first perform the most secure method (in some me performing a "harvest-and-decrypt" attack: in other words, attackers that reco
trics) and rd
followed by less secure one(s).</t> messages exchanged today and proceed to decrypt them once they have access
to cryptographically relevant quantum computers. This attack is prevented due
<t> The main focus of this document is to prevent a passive attacker to the hybrid
performing a "harvest and decrypt" attack. In other words, an attacker
that records messages exchanged today and proceeds to decrypt them once
he owns a quantum computer. This attack is prevented due to the hybrid
nature of the key exchange. Other attacks involving an active attacker nature of the key exchange. Other attacks involving an active attacker
using a quantum-computer are not completely solved by this using a quantum-computer are not completely solved by this
document. This is for two reasons.</t> document. This is for two reasons:</t>
<ul><li>The first reason is that the authentication step remains
<t> The first reason is because the authentication step remains
classical. In particular, the authenticity of the SAs established classical. In particular, the authenticity of the SAs established
under IKEv2 is protected using a pre-shared key or digital signature under IKEv2 is protected by using a pre-shared key or digital signature
algorithms. Whilst the pre-shared key option, provided the key is algorithms. While the pre-shared key option, provided the key is
long enough, is post-quantum secure, the other algorithms are not. Mor eover, long enough, is post-quantum secure, the other algorithms are not. Mor eover,
in implementations where scalability is a requirement, the pre-shared in implementations where scalability is a requirement, the pre-shared
key method may not be suitable. Post-quantum authenticity may be key method may not be suitable. Post-quantum authenticity may be
provided by using a post-quantum digital signature. provided by using a post-quantum digital signature.
</t> </li>
<li>Secondly, it should be noted that the purpose of post-quantum algorith
<t> Secondly, it should be noted that the purpose of post-quantum algori ms is
thms is
to provide resistance to attacks mounted in the future. The current to provide resistance to attacks mounted in the future. The current
threat is that encrypted sessions are subject to eavesdropping and threat is that encrypted sessions are subject to eavesdropping and are
archived with decryption by quantum computers taking place at some archived with decryption by quantum computers at some
point in the future. Until quantum computers become available there point in the future. Until quantum computers become available, there
is no point in attacking the authenticity of a connection because is no point in attacking the authenticity of a connection because
there are no possibilities for exploitation. These only occur at there are no possibilities for exploitation. These only occur at
the time of the connection, for example by mounting an on-path the time of the connection, for example, by mounting an on-path
attack. Consequently there is less urgency for attack. Consequently, there is less urgency for
post-quantum authenticity compared to post-quantum confidentiality.</t> post-quantum authenticity compared to post-quantum confidentiality.</li>
</ul>
<t> Performing multiple key exchanges while establishing IKE SA <t> Performing multiple key exchanges while establishing an IKE SA
increases the responder's susceptibility to DoS attacks, because increases the responder's susceptibility to DoS attacks because of an
of an increased amount of resources needed before the initiator increased amount of resources needed before the initiator is
is authenticated. This is especially true for post-quantum authenticated. This is especially true for post-quantum key exchange
key exchange methods, where many of them are more memory and/or CPU inte methods, where many of them are more memory and/or CPU intensive than
nsive than the classical counterparts. the classical counterparts.
</t> </t>
<t> Responders may consider recommendations from <xref target="RFC8019"
<t> Responders may consider recommendations from <xref target="RFC8019" format="default"/> to deal with increased DoS-attack susceptibility. It
/> is also possible that the responder only agrees to create an initial IKE S
to deal with increased DoS attack susceptibility. It is also possible t A
hat without performing additional key exchanges if the initiator includes
the responder only agrees to create initial IKE SA without performing such an option in its proposals. Then, peers immediately rekey the
additional key exchanges, provided the initiator includes such an option initial IKE SA with the CREATE_CHILD_SA exchange, and additional key
in its proposals. Then peers immediately rekey exchanges are performed via the IKE_FOLLOWUP_KE exchanges. In this
the initial IKE SA with the CREATE_CHILD_SA exchange and additional key case, at the point when resource-intensive operations are required, the
exchanges performed via the IKE_FOLLOWUP_KE exchanges. peers have already authenticated each other. However, in the context of
In this case, at the point when resource-intensive operations are requir hybrid post-quantum key exchanges, this scenario would leave the initial
ed, IKE SA (and initial Child SA, if it is created) unprotected against
the peers have already authenticated each other. quantum computers. Nevertheless, the rekeyed IKE SA (and Child SAs that
However, in the context of hybrid post-quantum key exchange this scenari will be created over it) will have a full protection. This is similar
o would leave to the scenario described in <xref target="RFC8784" format="default"/>.
the initial IKE SA (and initial Child SA if it is created) unprotected Depending on the arrangement and peers' policy, this scenario may or may
against quantum computers. Nevertheless the rekeyed IKE SA (and Child not be appropriate. For example, in the G-IKEv2 protocol <xref
SAs that will be created over it) will have a full protection. target="I-D.ietf-ipsecme-g-ikev2" format="default"/>, the cryptographic
This is similar to the scenario described in <xref target="RFC8784" />. materials are sent from the group controller to the group members when
Depending on the arrangement and peers' policy, this scenario may or may the initial IKE SA is created.
not be appropriate. </t>
For example, in the G-IKEv2 protocol <xref target="I-D.ietf-ipsecme-g-ike
v2"/>
the cryptographic materials are sent from the group controller to the gro
up members
when the initial IKE SA is created.
</t>
</section> </section>
</middle>
<back>
<section title="Acknowledgements" anchor="acknowledgements"> <displayreference target="I-D.ietf-ipsecme-g-ikev2" to="G-IKEV2"/>
<t> The authors would like to thank Frederic Detienne and Olivier <displayreference target="I-D.tjhai-ikev2-beyond-64k-limit" to="BEYOND-64K"/>
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 v
aluable comments.
Thanks to Paul Wouters for reviewing the document.</t>
</section>
</middle> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
296.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
242.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
023.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
383.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
019.xml"/>
<back> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<references title='Normative References'> 247.xml"/>
&RFC2119;
&RFC7296; <reference anchor="GROVER">
&RFC8174; <front>
&RFC9242; <title>A fast quantum mechanical algorithm for database search</titl
</references> e>
<references title='Informative References'>
&RFC6023;
&RFC7383;
&RFC8019;
<reference anchor="GROVER"><front>
<title>A Fast Quantum Mechanical Algorithm for Database Search</titl
e>
<author fullname="L. Grover" initials="L." surname="Grover"> <author fullname="L. Grover" initials="L." surname="Grover">
</author> </author>
<date year="1996"/> <date month="May" year="1996"/>
</front> </front>
<seriesInfo name="Proc." value="of the Twenty-Eighth Annual ACM Symp <seriesInfo name="Proc." value="of the Twenty-Eighth Annual ACM Sympos
osium on the Theory of Computing (STOC 1996)"/> ium on the Theory of Computing (STOC), pp. 212-219"/>
<seriesInfo name="DOI" value="10.48550/arXiv.quant-ph/9605043"/>
</reference> </reference>
&RFC8784;
&RFC5723; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
&I-D.ietf-ipsecme-g-ikev2; 784.xml"/>
&I-D.tjhai-ikev2-beyond-64k-limit; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<reference anchor="IKEV2TYPE4ID" target="https://www.iana.org/assignment 723.xml"/>
s/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8">
<front> <reference anchor="I-D.ietf-ipsecme-g-ikev2">
<title>Internet Key Exchange Version 2 (IKEv2) Parameters: Trans <front>
form Type 4 - Diffie-Hellman Group Transform IDs</title> <title>Group Key Management using IKEv2</title>
<author fullname="IANA"></author> <author initials="V" surname="Smyslov" fullname="Valery Smyslov">
</front> <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>
<reference anchor="IKEV2TYPE4ID" target="https://www.iana.org/assignment
s/ikev2-parameters/">
<front>
<title>Internet Key Exchange Version 2 (IKEv2) Parameters:
Transform Type 4 - Diffie-Hellman Group Transform IDs</title>
<author><organization>IANA</organization></author>
</front>
</reference> </reference>
<reference anchor="NISTPQCFAQ" target="https://csrc.nist.gov/Projects/po st-quantum-cryptography/faqs"> <reference anchor="NISTPQCFAQ" target="https://csrc.nist.gov/Projects/po st-quantum-cryptography/faqs">
<front> <front>
<title>Post-Quantum Cryptography Standardization: FAQs</title> <title>Post-Quantum Cryptography Standard</title>
<author fullname="NIST"></author> <author><organization>NIST</organization></author>
</front> <date month="January" year="2023"/>
</front>
</reference> </reference>
</references>
<section title="Sample Multiple Key Exchanges" anchor="sample-exchanges"> </references>
<t>This appendix shows some examples of multiple key exchanges. These examp </references>
les are non-normative
and they describe some message flow scenarios that may occur in establishing
an IKE or CHILD SA. Note
that some payloads that are not relevant to multiple key exchanges may be om
itted for brevity.
</t>
<section title="IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange <section anchor="sample-exchanges" numbered="true" toc="default">
Payloads" anchor="sample-ake-ike-intermediate"> <name>Sample Multiple Key Exchanges</name>
<t>The exchanges below show that the initiator proposes the use of additio <t>This appendix shows some examples of multiple key exchanges. These
nal key exchanges examples are not normative, and they describe some message flow scenarios
to establish an IKE SA. The initiator proposes three sets of additional that may occur in establishing an IKE or Child SA. Note that some
key exchanges and all of which are optional. payloads that are not relevant to multiple key exchanges may be omitted
So the responder can choose NONE for some or all of the additional excha for brevity.
nges </t>
if the proposed key exchange methods are not supported or for whatever r <section anchor="sample-ake-ike-intermediate" numbered="true" toc="default
easons the responder decides not to perform ">
<name>IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange Payloa
ds</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, all of which are
optional. 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> the additional key exchange.</t>
<figure><artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
Initiator Responder Initiator Responder
--------------------------------------------------------------------- ---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> HDR(IKE_SA_INIT), SAi1(.. ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED) N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1 Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16, Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key) 256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512) Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519) Transform KE (ID = Curve25519)
Transform AKE1 (ID = PQ_KEM_1) Transform ADDKE1 (ID = PQ_KEM_1)
Transform AKE1 (ID = PQ_KEM_2) Transform ADDKE1 (ID = PQ_KEM_2)
Transform AKE1 (ID = NONE) Transform ADDKE1 (ID = NONE)
Transform AKE2 (ID = PQ_KEM_3) Transform ADDKE2 (ID = PQ_KEM_3)
Transform AKE2 (ID = PQ_KEM_4) Transform ADDKE2 (ID = PQ_KEM_4)
Transform AKE2 (ID = NONE) Transform ADDKE2 (ID = NONE)
Transform AKE3 (ID = PQ_KEM_5) Transform ADDKE3 (ID = PQ_KEM_5)
Transform AKE3 (ID = PQ_KEM_6) Transform ADDKE3 (ID = PQ_KEM_6)
Transform AKE3 (ID = NONE) Transform ADDKE3 (ID = NONE)
<--- HDR(IKE_SA_INIT), SAr1(.. AKE*...), <--- HDR(IKE_SA_INIT), SAr1(.. ADDKE*...),
KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED) N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1 Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16, Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key) 256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512) Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519) Transform KE (ID = Curve25519)
Transform AKE1 (ID = PQ_KEM_2) Transform ADDKE1 (ID = PQ_KEM_2)
Transform AKE2 (ID = NONE) Transform ADDKE2 (ID = NONE)
Transform AKE3 (ID = PQ_KEM_5) Transform ADDKE3 (ID = PQ_KEM_5)
HDR(IKE_INTERMEDIATE), SK {KEi(1)(PQ_KEM_2)} --> HDR(IKE_INTERMEDIATE), SK {KEi(1)(PQ_KEM_2)} -->
<--- HDR(IKE_INTERMEDIATE), SK {KEr(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 {KEi(2)(PQ_KEM_5)} -->
<--- HDR(IKE_INTERMEDIATE), SK {KEr(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{ IDi, AUTH, SAi2, TSi, TSr } --->
<--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2, <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2,
TSi, TSr } TSi, TSr }
]]></artwork></figure> ]]>
</artwork>
<t>In this particular example, the responder chooses to perform two addi <t>In this particular example, the responder chooses to perform two
tional key exchanges. It selects additional key exchanges. It selects PQ_KEM_2, NONE, and PQ_KEM_5 for
PQ_KEM_2, NONE and PQ_KEM_5 for the first, second and third addition the first, second, and third additional key exchanges, respectively. As
al key exchanges respectively. per <xref target="RFC7296" format="default"/>, a set of
As per <xref target="RFC7296"/> specification, a set of keying mater keying materials is derived, in particular SK_d, SK_a[i/r], and
ials are derived, in particular SK_e[i/r]. Both peers then perform an IKE_INTERMEDIATE exchange,
SK_d, SK_a[i/r], SK_e[i/r]. Both peers then perform an IKE_INTERMED carrying PQ_KEM_2 payload, which is protected with SK_e[i/r] and
IATE exchange carrying PQ_KEM_2 payload SK_a[i/r] keys. After the completion of this IKE_INTERMEDIATE
which is protected with SK_e[i/r] and SK_a[i/r] keys. After the com exchange, the SKEYSEED is updated using SK(1), which is the PQ_KEM_2
pletion of this IKE_INTERMEDIATE exchange, shared secret, as follows.</t>
the SKEYSEED is updated using SK(1), which is the PQ_KEM_2 shared se
cret, as follows.</t>
<figure><artwork align="left" ><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
SKEYSEED(1) = prf(SK_d, SK(1) | Ni | Nr) SKEYSEED(1) = prf(SK_d, SK(1) | Ni | Nr)
]]></artwork></figure> ]]>
</artwork>
<t>The updated SKEYSEED value is then used to derive the following k eying materials</t> <t>The updated SKEYSEED value is then used to derive the following keyin g materials.</t>
<figure><artwork align="left" ><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
{SK_d(1) | SK_ai(1) | SK_ar(1) | SK_ei(1) | SK_er(1) | SK_pi(1) | {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) SK_pr(1)} = prf+ (SKEYSEED(1), Ni | Nr | SPIi | SPIr)
]]></artwork></figure> ]]>
</artwork>
<t>As per <xref target="RFC9242"/> specification, both peers compute
IntAuth_i1 and IntAuth_r1 using the SK_pi(1)
and SK_pr(1) keys respectively. These values are required in the IK
E_AUTH phase of the exchange.</t>
<t>In the next IKE_INTERMEDIATE exchange, the peers use SK_e[i/r](1) <t>As per <xref target="RFC9242" format="default"/>,
and SK_a[i/r](1) keys to protect the PQ_KEM_5 payload. both peers compute IntAuth_i1 and IntAuth_r1 using the SK_pi(1) and
After completing this exchange, keying materials are updated as belo SK_pr(1) keys, respectively. These values are required in the IKE_AUTH
w</t> 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 follows:</t>
<figure><artwork align="left" ><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
SKEYSEED(2) = prf(SK_d(1), SK(2) | Ni | Nr) 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_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) SK_pr(2)} = prf+ (SKEYSEED(2), Ni | Nr | SPIi | SPIr)
]]></artwork></figure> ]]>
</artwork>
<t>where SK(2) is the shared secret from the third additional key ex
change, i.e. PQ_KEM_5. 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, bot <t>In this update, SK(2) is the shared secret from the third
h peers continue to the IKE_AUTH exchange phase. additional key exchange, i.e., PQ_KEM_5. Then, both peers compute the
As defined in <xref target="RFC9242"/>, the values IntAuth_[i/r]2 ar values of IntAuth_[i/r]2 using the SK_p[i/r](2) keys.
e used to compute IntAuth which in turn is used to calculate </t>
the payload to be signed or MACed, i.e. InitiatorSignedOctets and Re
sponderSignedOctets.</t>
</section>
<section title="No Additional Key Exchange Used" anchor="sample-exchanges-no <t>After the completion of the second IKE_INTERMEDIATE exchange, both
ne-selected"> peers continue to the IKE_AUTH exchange phase. As defined in <xref
<t>The initiator proposes two sets of optional additional key exchanges, b target="RFC9242" format="default"/>, the values IntAuth_[i/r]2 are
ut the responder does not used to compute IntAuth, which, in turn, is used to calculate Initiator
support any of them. The responder chooses NONE for each set and conseque SignedOctets and
ntly, IKE_INTERMEDIATE ResponderSignedOctets blobs (see <xref target="RFC9242" sectionFormat="of" secti
exchange does not takes place and the exchange proceeds to IKE_AUTH phase. on="3.3.2" />).</t>
The resulting keying </section>
materials are the same as those derived with <xref target="RFC7296"/>.</t> <section anchor="sample-exchanges-none-selected" numbered="true" toc="defa
ult">
<name>No Additional Key Exchange 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. Consequently, the
IKE_INTERMEDIATE exchange does not 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"
format="default"/>.</t>
<figure><artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
Initiator Responder Initiator Responder
--------------------------------------------------------------------- ---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> HDR(IKE_SA_INIT), SAi1(.. ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED) N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1 Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16, Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key) 256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512) Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519) Transform KE (ID = Curve25519)
Transform AKE1 (ID = PQ_KEM_1) Transform ADDKE1 (ID = PQ_KEM_1)
Transform AKE1 (ID = PQ_KEM_2) Transform ADDKE1 (ID = PQ_KEM_2)
Transform AKE1 (ID = NONE) Transform ADDKE1 (ID = NONE)
Transform AKE2 (ID = PQ_KEM_3) Transform ADDKE2 (ID = PQ_KEM_3)
Transform AKE2 (ID = PQ_KEM_4) Transform ADDKE2 (ID = PQ_KEM_4)
Transform AKE2 (ID = NONE) Transform ADDKE2 (ID = NONE)
<--- HDR(IKE_SA_INIT), SAr1(.. AKE*...), <--- HDR(IKE_SA_INIT), SAr1(.. ADDKE*...),
KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED) N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1 Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16, Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key) 256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512) Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519) Transform KE (ID = Curve25519)
Transform AKE1 (ID = NONE) Transform ADDKE1 (ID = NONE)
Transform AKE2 (ID = NONE) Transform ADDKE2 (ID = NONE)
HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } ---> HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } --->
<--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2, <--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2,
TSi, TSr } TSi, TSr }
]]></artwork></figure> ]]>
</section> </artwork>
<section title="Additional Key Exchange in the CREATE_CHILD_SA Exchange only </section>
" anchor="sample-exchanges-ake-child-sas"> <section anchor="sample-exchanges-ake-child-sas" numbered="true" toc="defa
<t>The exchanges below show that the initiator does not propose the use of ult">
additional key exchanges <name>Additional Key Exchange in the CREATE_CHILD_SA Exchange Only</name
to establish an IKE SA, but they are required in order to establish a Chil >
d SA. In order <t>The exchanges below show that the initiator does not propose the
to establish a fully quantum-resistant IPsec SA, the responder includes a use of additional key exchanges to establish an IKE SA, but they are
CHILDLESS_IKEV2_SUPPORTED required in order to establish a Child SA. In order to establish a
notification in their IKE_SA_INIT response message. The initiator underst fully quantum-resistant IPsec SA, the responder includes a
ands CHILDLESS_IKEV2_SUPPORTED notification in their IKE_SA_INIT response
and supports this notification, then exchanges a modified IKE_AUTH message message. The initiator understands and supports this notification,
with the exchanges a modified IKE_AUTH message with the responder, and
responder and rekeys the IKE SA immediately with additional key exchanges. rekeys the IKE SA immediately with additional key exchanges. Any
Any Child SA will have to be created via a subsequent CREATED_CHILD_SA
Child SA will have to be created via subsequent CREATED_CHILD_SA exchange. exchange.
</t> </t>
<figure><artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
Initiator Responder Initiator Responder
--------------------------------------------------------------------- ---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1, ---> HDR(IKE_SA_INIT), SAi1, --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED) KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED)
<--- HDR(IKE_SA_INIT), SAr1, <--- HDR(IKE_SA_INIT), SAr1,
KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED), KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
N(CHILDLESS_IKEV2_SUPPORTED) N(CHILDLESS_IKEV2_SUPPORTED)
HDR(IKE_AUTH), SK{ IDi, AUTH } ---> HDR(IKE_AUTH), SK{ IDi, AUTH } --->
<--- HDR(IKE_AUTH), SK{ IDr, AUTH } <--- HDR(IKE_AUTH), SK{ IDr, AUTH }
HDR(CREATE_CHILD_SA), SK{ SAi(.. AKE*...), Ni, KEi(Curve25519) } ---> HDR(CREATE_CHILD_SA),
SK{ SAi(.. ADDKE*...), Ni, KEi(Curve25519) } --->
Proposal #1 Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16, Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key) 256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512) Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519) Transform KE (ID = Curve25519)
Transform AKE1 (ID = PQ_KEM_1) Transform ADDKE1 (ID = PQ_KEM_1)
Transform AKE1 (ID = PQ_KEM_2) Transform ADDKE1 (ID = PQ_KEM_2)
Transform AKE2 (ID = PQ_KEM_5) Transform ADDKE2 (ID = PQ_KEM_5)
Transform AKE2 (ID = PQ_KEM_6) Transform ADDKE2 (ID = PQ_KEM_6)
Transform AKE2 (ID = NONE) Transform ADDKE2 (ID = NONE)
<--- HDR(CREATE_CHILD_SA), SK{ SAr(.. AKE*...), <--- HDR(CREATE_CHILD_SA), SK{ SAr(.. ADDKE*...),
Nr, KEr(Curve25519), Nr, KEr(Curve25519),
N(ADDITIONAL_KEY_EXCHANGE)(link1) } N(ADDITIONAL_KEY_EXCHANGE)(link1) }
Proposal #1 Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16, Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key) 256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512) Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519) Transform KE (ID = Curve25519)
Transform AKE1 (ID = PQ_KEM_2) Transform ADDKE1 (ID = PQ_KEM_2)
Transform AKE2 (ID = PQ_KEM_5) Transform ADDKE2 (ID = PQ_KEM_5)
HDR(IKE_FOLLOWUP_KE), SK{ KEi(1)(PQ_KEM_2), ---> HDR(IKE_FOLLOWUP_KE), SK{ KEi(1)(PQ_KEM_2), --->
N(ADDITIONAL_KEY_EXCHANGE)(link1) } N(ADDITIONAL_KEY_EXCHANGE)(link1) }
<--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(1)(PQ_KEM_2), <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(1)(PQ_KEM_2),
N(ADDITIONAL_KEY_EXCHANGE)(link2) } N(ADDITIONAL_KEY_EXCHANGE)(link2) }
HDR(IKE_FOLLOWUP_KE), SK{ KEi(2)(PQ_KEM_5), ---> HDR(IKE_FOLLOWUP_KE), SK{ KEi(2)(PQ_KEM_5), --->
N(ADDITIONAL_KEY_EXCHANGE)(link2) } N(ADDITIONAL_KEY_EXCHANGE)(link2) }
<--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(2)(PQ_KEM_5) } <--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(2)(PQ_KEM_5) }
]]></artwork></figure> ]]>
</section> </artwork>
<section title="No Matching Proposal for Additional Key Exchanges" anchor="s </section>
ample-exchanges-no-proposal-chosen"> <section anchor="sample-exchanges-no-proposal-chosen" numbered="true" toc=
<t>The initiator proposes the combination of PQ_KEM_1, PQ_KEM_2, PQ_KEM_3, "default">
and PQ_KEM_4 as <name>No Matching Proposal for Additional Key Exchanges</name>
the additional key exchanges. The initiator indicates that either PQ_KEM_ <t>The initiator proposes the combination of PQ_KEM_1, PQ_KEM_2,
1 or PQ_KEM_2 must be PQ_KEM_3, and PQ_KEM_4 as the additional key exchanges. The initiator
used to establish an IKE SA, but Additional Key Exchange 2 is optional so indicates that either PQ_KEM_1 or PQ_KEM_2 must be used to establish
the responder an IKE SA, but ADDKE2 Transform Type is optional. Therefore, the
can either select PQ_KEM_3 or PQ_KEM_4 or omit this key exchange by select responder can either select PQ_KEM_3 or PQ_KEM_4 or omit this key
ing NONE. The responder, exchange by selecting NONE. Although the responder supports the
although supports the optional PQ_KEM_3 and PQ_KEM_4 methods, does not sup optional PQ_KEM_3 and PQ_KEM_4 methods, it does not support
port either PQ_KEM_1 or either the PQ_KEM_1 or the PQ_KEM_2 mandatory method; therefore, it resp
PQ_KEM_2 mandatory method and therefore responds with NO_PROPOSAL_CHOSEN n onds
otification. </t> with a NO_PROPOSAL_CHOSEN notification. </t>
<figure><artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
Initiator Responder Initiator Responder
--------------------------------------------------------------------- ---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. AKE*...), ---> HDR(IKE_SA_INIT), SAi1(.. ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED), KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED) N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1 Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16, Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key) 256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512) Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519) Transform KE (ID = Curve25519)
Transform AKE1 (ID = PQ_KEM_1) Transform ADDKE1 (ID = PQ_KEM_1)
Transform AKE1 (ID = PQ_KEM_2) Transform ADDKE1 (ID = PQ_KEM_2)
Transform AKE2 (ID = PQ_KEM_3) Transform ADDKE2 (ID = PQ_KEM_3)
Transform AKE2 (ID = PQ_KEM_4) Transform ADDKE2 (ID = PQ_KEM_4)
Transform AKE2 (ID = NONE) Transform ADDKE2 (ID = NONE)
<--- HDR(IKE_SA_INIT), N(NO_PROPOSAL_CHOSEN) <--- HDR(IKE_SA_INIT), N(NO_PROPOSAL_CHOSEN)
]]></artwork></figure> ]]>
</section> </artwork>
</section>
<section title="Design Criteria" anchor="design"> </section>
<t> </section>
<section anchor="design" numbered="true" toc="default">
<name>Design Criteria</name>
<t>
The design of the extension is driven by the The design of the extension is driven by the
following criteria:</t> following criteria:</t>
<ol type="%d)" spacing="normal">
<t><list style="hanging" hangIndent="5"><t hangText="1)"> <li><t>Need for PQC in IPsec</t>
Need for PQC in IPsec. Quantum computers, which might become feasible in <t>Quantum computers, which might become feasible in the near future,
the near future, pose a threat to pose a threat to our classical public key cryptography. PQC, a family
our classical public key cryptography. PQC, a family of public key cryp of public key cryptography that is believed to be resistant to
tography that is believed to these computers, needs to be integrated into the IPsec protocol suite
be resistant against these computers, needs to be integrated into the IP to restore confidentiality and authenticity.</t></li>
sec protocol suite to restore <li><t>Hybrid</t>
confidentiality and authenticity.</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
<t hangText="2)"> (non-quantum) adversaries. A hybrid post-quantum algorithm to be
Hybrid. There is currently no post-quantum key exchange that is trusted introduced, along with the well-established primitives, addresses this
at concern, since the overall security is at least as strong as each
the level that (EC)DH is trusted for against conventional (non-quantum) individual primitive.</t>
adversaries. A hybrid post-quantum algorithm to be introduced along </li>
with the well-established primitives addresses this concern, since the <li>
overall security is at least as strong as each individual primitive. <t>Focus on post-quantum confidentiality</t>
</t> <t>A passive attacker can store
all monitored encrypted IPsec communication today and decrypt it once
<t hangText="3)"> a quantum computer is available in the future. This attack can have
Focus on post-quantum confidentiality. A passive attacker serious consequences that will not be visible for years to come. On
can store all monitored encrypted IPsec communication today and decrypt i the other hand, an attacker can only perform active attacks, such as
t impersonation of the communicating peers, once a quantum computer is
once a quantum computer is available in the future. This attack can have available sometime in the future. Thus, this specification focuses
serious on confidentiality due to the urgency of this problem and presents a
consequences that will not be visible for years to come. On the other ha defense against the serious attack described above, but it does not
nd, address authentication because it is less urgent at this stage.</t>
an attacker can only perform active attacks such as impersonation of the </li>
communicating peers once a quantum computer is available, <li>
sometime in the future. Thus, this specification focuses on <t>Limit the amount of exchanged data</t>
confidentiality due to the urgency of this problem and <t>The protocol design should be
presents a defense against the serious attack described above, but such that the amount of exchanged data, such as public keys, is
it does not address authentication since it is less urgent at this stage. kept as small as possible, even if the initiator and the responder need
</t> to agree on a hybrid group or if multiple public keys need to be
exchanged.</t>
<t hangText="4)"> </li>
Limit amount of exchanged data. The protocol design should be <li>
such that the amount of exchanged data, such as public-keys, is <t>Not post-quantum specific</t>
kept as small as possible even if initiator and responder need <t>Any cryptographic algorithm could be potentially
to agree on a hybrid group or multiple public-keys need to be
exchanged.
</t>
<t hangText="5)">
Not post-quantum specific. Any cryptographic algorithm could be potentia
lly
broken in the future by currently unknown or impractical broken in the future by currently unknown or impractical
attacks: quantum computers are merely the most concrete example attacks. Quantum computers are merely the most concrete example
of this. The design does not categorize algorithms as "post-quantum" of this. The design does not categorize algorithms as "post-quantum"
or "non post-quantum" nor does it create assumptions or "non-post-quantum", nor does it create assumptions
about the properties of the algorithms, meaning that if about the properties of the algorithms; meaning that if
algorithms with different properties become necessary in the future, algorithms with different properties become necessary in the future,
this extension can be used unchanged to facilitate migration to this extension can be used unchanged to facilitate migration to
those algorithms. those algorithms.</t>
</t> </li>
<li>
<t hangText="6)"> <t>Limited amount of changes</t>
Limited amount of changes. A key goal is to limit the number of <t>A key goal is to limit the number of
changes required when enabling a post-quantum handshake. This changes required when enabling a post-quantum handshake. This
ensures easier and quicker adoption in existing implementations. ensures easier and quicker adoption in existing implementations.</t>
</t> </li>
<t hangText="7)"> <li>
Localized changes. Another key requirement is that changes to <t>Localized changes</t>
<t>Another key requirement is that changes to
the protocol are limited in scope, in particular, limiting the protocol are limited in scope, in particular, limiting
changes in the exchanged messages and in the state machine, so changes in the exchanged messages and in the state machine, so
that they can be easily implemented. that they can be easily implemented.</t>
</t> </li>
<li>
<t hangText="8)"> <t>Deterministic operation</t>
Deterministic operation. This requirement means that the hybrid <t>This requirement means that the hybrid post-quantum exchange and, thus
post-quantum exchange, and thus, the computed keys, will be based ,
on algorithms that both client and server wish to support. the computed keys will be based on algorithms that both client and
</t> server wish to support.</t>
</li>
<t hangText="9)"> <li>
Fragmentation support. Some PQC algorithms could be relatively <t>Fragmentation support</t>
bulky and they might require fragmentation. Thus, a design goal <t>Some PQC algorithms could be relatively
bulky and might require fragmentation. Thus, a design goal
is the adaptation and adoption of an existing fragmentation is the adaptation and adoption of an existing fragmentation
method or the design of a new method that allows for the method or the design of a new method that allows for the
fragmentation of the key shares. fragmentation of the key shares.</t>
</t> </li>
<li>
<t hangText="10)"> <t>Backward compatibility and interoperability</t>
Backwards compatibility and interoperability. This is a <t>This is a fundamental
fundamental requirement to ensure that hybrid post-quantum IKEv2 requirement to ensure that hybrid post-quantum IKEv2 and standard
and standard IKEv2 implementations as per <xref target="RFC7296"/> speci IKEv2 implementations as per <xref target="RFC7296" format="default"/>
fication are interoperable. are interoperable.</t>
</t> </li>
<li>
<t hangText="11)"> <t>Compliance with USA Federal Information Processing Standards (FIPS)</t
USA Federal Information Processing Standards (FIPS) compliance. IPsec is >
widely used in Federal Information <t>IPsec is widely used in Federal Information Systems, and FIPS
Systems and FIPS certification is an important requirement. certification is an important requirement. However, at the time of
However, at the time of writing, none of the algorithms that is believed writing, none of the algorithms that is believed to be post-quantum is ye
to be post-quantum is FIPS compliant yet. Nonetheless, it is possible t t
o combine FIPS compliant. Nonetheless, it is possible to combine this
this post-quantum algorithm with a FIPS compliant key establishment meth post-quantum algorithm with a FIPS-compliant key establishment method
od so that so that the overall design remains FIPS compliant <xref
the overall design remains FIPS compliant <xref target="NISTPQCFAQ"/>. target="NISTPQCFAQ" format="default"/>.</t>
</t> </li>
<li>
<t hangText="12)"> <t>Ability to use this method with multiple classical (EC)DH key
Ability to use this method with multiple classical (EC)DH key exchanges. exchanges</t>
In some situations peers have no single mutually trusted key exchange <t>In some situations, peers have no single, mutually trusted, key
algorithm (e.g., due to local policy restrictions). exchange algorithm (e.g., due to local policy restrictions). The
The ability to combine two (or more) key exchange methods ability to combine two (or more) key exchange methods in such a way
in such a way that the resulting shared key depends on all of them that the resulting shared key depends on all of them allows peers to
allows peers to communicate in this situation. communicate in this situation.</t>
</t> </li>
</ol>
</list> </section>
</t> <section anchor="altdesign" numbered="true" toc="default">
<name>Alternative Design</name>
</section> <t>
<section title="Alternative Design" anchor="altdesign">
<t>
This section gives an overview on a number of alternative approaches This section gives an overview on a number of alternative approaches
that have been considered, but later discarded. These approaches are:</ that have been considered but later discarded. These approaches are as
t> follows.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Sending the classical and post-quantum key <t>Sending the classical and post-quantum key
exchanges as a single transform<vspace blankLines="1"/> exchanges as a single transform</t>
A method to combine the various key exchanges into a single large <t>
KE payload was considered; this effort is documented in a previous versi A method to combine the various key exchanges into a single large KE
on of this payload was considered. This effort is documented in a previous
draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This does allow us version of this document (draft-tjhai-ipsecme-hybrid-qske-ikev2-01).
to cleanly apply hybrid key exchanges during the Child SA; however it This method allows us to cleanly apply hybrid key exchanges during the
does add considerable complexity, and requires an independent Child SA. However, it does add considerable complexity and requires an
fragmentation solution. independent fragmentation solution.
</t> </t>
</li>
<t>Sending post-quantum proposals and policies in KE payload <li>
only<vspace blankLines="1"/> <t>Sending post-quantum proposals and policies in the KE payload
With the objective of not introducing unnecessary notify only</t>
payloads, a method to communicate the hybrid post-quantum proposal <t>
in the KE payload during the first pass of the protocol exchange
was considered. Unfortunately, this design is susceptible to the follow
ing
downgrade attack. Consider the scenario where there is an on-path attac
ker
sitting between an initiator and a responder. The initiator proposes,
through SAi payload, to use a hybrid post-quantum group and as a fallbac
k
a Diffie-Hellman group, and through KEi payload, the initiator proposes
a list of hybrid post-quantum proposals and policies. The on-path attac
ker
intercepts this traffic and replies with N(INVALID_KE_PAYLOAD) suggestin
g
to downgrade to the fallback Diffie-Hellman group instead. The initiato
r
then resends the same SAi payload and the KEi payload containing the
public value of the fallback Diffie-Hellman group. Note that the attack
er
may forward the second IKE_SA_INIT message only to the responder, and
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 not offering
the corresponding public value in the KEi payload; and (b) the
responder has not specifically acknowledged that it does not
supported the requested hybrid group. However, the checking of this
policy introduces unnecessary protocol complexity. Therefore, in
order to fully prevent any downgrade attacks, using KE payload alone
is not sufficient and that the initiator MUST always indicate its
preferred post-quantum proposals and policies in a notify payload
in the subsequent IKE_SA_INIT messages following a
N(INVALID_KE_PAYLOAD) response.</t>
<t>New payload types to negotiate hybrid proposal and to carry post- With the objective of not introducing unnecessary notify payloads, a
quantum public values<vspace blankLines="1"/> method to communicate the hybrid post-quantum proposal in the KE
Semantically, it makes sense to use a new payload type, which payload during the first pass of the protocol exchange was considered.
mimics the SA payload, to carry a hybrid proposal. Likewise, another ne Unfortunately, this design is susceptible to the following downgrade
w attack. Consider the scenario where there is an on-path attacker
payload type that mimics the KE payload, could be used to transport hybr sitting between an initiator and a responder. Through the SAi payload, t
id he
public value. Although, in theory a new payload type could be made initiator proposes using a hybrid post-quantum group and, as a
backwards compatible by not setting its critical flag as per Section 2.5 fallback, a Diffie-Hellman group; and through the KEi payload, the
of <xref target="RFC7296" />, it is believed that it may not be that sim initiator proposes a list of hybrid post-quantum proposals and
ple policies. The on-path attacker intercepts this traffic and replies
in practice. Since with N(INVALID_KE_PAYLOAD), suggesting a downgrade to the fallback
the original release of IKEv2 in RFC4306, no new payload type has ever Diffie-Hellman group instead. The initiator then resends the same SAi
been proposed and therefore, this creates a potential risk of having a payload and the KEi payload containing the public value of the
backward compatibility issue from non-conformant IKEv2 fallback Diffie-Hellman group. Note that the attacker may forward the
implementations. Since there appears to be no other compelling advantag second IKE_SA_INIT message only to the responder. Therefore, at this
es point in time, the responder will not have the information that the
apart from a semantic one, the existing transform type and 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 offer the corresponding public value
in the KEi payload and (b) the responder has not specifically
acknowledged that it does not 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, and the initiator
<bcp14>MUST</bcp14> always indicate its preferred post-quantum
proposals and policies in a notify payload in the subsequent
IKE_SA_INIT messages following an N(INVALID_KE_PAYLOAD) response.</t>
</li>
<li>
<t>New payload types to negotiate hybrid proposals and to carry
post-quantum public 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 could be used to transport
hybrid public value. Although, in theory, a new payload type could be
made backward compatible by not setting its critical flag as per
<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 RFC 4306, no new payload type has ever
been proposed; therefore, this creates a potential risk of having a
backward-compatibility issue from nonconformant IKEv2
implementations. Since there appears to be no other compelling
advantages apart from a semantic one, the existing Transform Type and
notify payloads are used instead. notify payloads are used instead.
</t> </t>
</li>
<t>Hybrid public value payload<vspace blankLines="1"/> <li>
One way to transport the negotiated hybrid public payload, which contain <t>Hybrid public value payload</t>
s <t>
one classical Diffie-Hellman public value and one or more post-quantum One way to transport the negotiated hybrid public payload, which
public values, is to bundle these into a single KE payload. Alternative contains one classical Diffie-Hellman public value and one or more
ly, post-quantum public values, is to bundle these into a single KE
these could also be transported in a single new hybrid public value payload. Alternatively, these could also be transported in a single
payload, but following the same reasoning as above, this may not be new hybrid public value payload. However, following the same reasoning
a good idea from a backward compatibility perspective. Using a single as above may not be a good idea from a backward-compatibility
KE payload would require an encoding or formatting to be defined so perspective. Using a single KE payload would require encoding or
that both peers are able to compose and extract the individual public formatting to be defined so that both peers are able to compose and
values. However, it is believed that it is cleaner to send the hybrid extract the individual public values. However, it is believed that it
public values in multiple KE payloads--one for each group or is cleaner to send the hybrid public values in multiple KE payloads:
algorithm. Furthermore, at this point in the protocol exchange, both one for each group or algorithm. Furthermore, at this point in the
peers should have indicated support of handling multiple KE payloads. protocol exchange, both peers should have indicated support for
</t> handling multiple KE payloads.
</t>
<t>Fragmentation<vspace blankLines="1"/> </li>
Handling of large IKE_SA_INIT messages has been one of the most <li>
challenging tasks. A number of approaches have been considered <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,
and the two prominent ones that have been discarded are outlined as and the two prominent ones that have been discarded are outlined as
follows. follows.
<vspace blankLines="1"/> </t>
<t>
The first approach is to treat the entire IKE_SA_INIT message as 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 a stream of bytes, which is then split into a number of
fragments, each of which is wrapped onto a payload that will fit fragments, each of which is wrapped onto a payload that will fit
into the size of the network MTU. The payload that wraps each into the size of the network MTU. The payload that wraps each
fragment has a new payload type and it is envisaged that this new fragment has a new payload type, and it is envisaged that this new
payload type will not cause a backward compatibility issue because payload type will not cause a backward-compatibility issue because,
at this stage of the protocol, both peers should have indicated at this stage of the protocol, both peers should have indicated
support of fragmentation in the first pass of the IKE_SA_INIT support of fragmentation in the first pass of the IKE_SA_INIT
exchange. The negotiation of fragmentation is performed using a exchange. The negotiation of fragmentation is performed using a
notify payload, which also defines supporting parameters such as notify payload, which also defines supporting parameters, such as
the size of fragment in octets and the fragment identifier. The the size of fragment in octets and the fragment identifier. The
new payload that wraps each fragment of the messages in this new payload that wraps each fragment of the messages in this
exchange is assigned the same fragment identifier. Furthermore, it exchange is assigned the same fragment identifier. Furthermore, it
also has other parameters such as a fragment index and total also has other parameters, such as a fragment index and total
number of fragments. This approach has been discarded due to number of fragments. This approach has been discarded due to
its blanket approach to fragmentation. In cases where only a few its blanket approach to fragmentation. In cases where only a few
payloads need to be fragmented, this approach appears to be payloads need to be fragmented, this approach appears to be
overly complicated. overly complicated.
<vspace blankLines="1"/> </t>
Another idea that has been discarded was fragmenting an individual
<t>
Another idea that has been discarded is fragmenting an individual
payload without introducing a new payload type. The idea is to 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 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 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 payload is fragmented. As an example, if a KE payload is to be
fragmented, it may look as follows. fragmented, it may look as follows.
</t> </t>
<figure>
</list> <name>Example of How to Fragment a KE Payload</name>
</t> <artwork align="center" name="" type="" alt=""><![CDATA[
<figure><artwork align="center" ><![CDATA[
1 2 3 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 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 | | Next Payload |C|F| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Number | Fragment Identifier | | Diffie-Hellman Group Number | Fragment Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Index | Total Fragments | | Fragment Index | Total Fragments |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total KE Payload Data Length | | Total KE Payload Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Fragmented KE Payload ~ ~ Fragmented KE Payload ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]>
</artwork>
<t><list hangIndent="3" style="hanging"><t> </figure>
When the flag F is set, this means the current KE payload is a <t>
When the flag F is set, the current KE payload is a
fragment of a larger KE payload. The Payload Length field denotes fragment of a larger KE payload. The Payload Length field denotes
the size of this payload fragment in octets--including the size of the size of this payload fragment in octets: including the size of
the generic payload header. The two-octet RESERVED field the generic payload header. The 2-octet RESERVED field
following Diffie-Hellman Group Number was to be used as a fragment following Diffie-Hellman Group Number was to be used as a fragment
identifier to help assembly and disassembly of fragments. The identifier to help the assembly and disassembly of fragments. The
Fragment Index and Total Fragments fields are self-explanatory. Fragment Index and Total Fragments fields are self-explanatory.
The Total KE Payload Data Length indicates the size of the The Total KE Payload Data Length indicates the size of the
assembled KE payload data in octets. Finally, the actual fragment assembled KE payload data in octets. Finally, the actual fragment
is carried in Fragment KE Payload field.</t> is carried in Fragment KE Payload field.</t>
</list> <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
<t><list hangIndent="3" style="hanging"><t> format of a packet, and that implementers may not like the added
This approach has been discarded because it is believed that the working complexity from checking the fragmentation flag in each received
group may not want to use the RESERVED field to change the payload. More importantly, fragmenting the messages in this way
format of a packet and that implementers may not like the may leave the system to be more prone to denial-of-service (DoS)
added complexity from checking the fragmentation flag in each attacks. This issue can be solved using IKE_INTERMEDIATE <xref target="RFC
received payload. More importantly, fragmenting the messages 9242" format="default"/> to
in this way may leave the system to be more prone to denial of transport the large post-quantum key exchange payloads and using
service (DoS) attacks. By using IKE_INTERMEDIATE to transport the large the generic IKEv2 fragmentation protocol
post-quantum key exchange payloads, and using the generic IKEv2 <xref target="RFC7383" format="default"/>.</t>
fragmentation protocol <xref target="RFC7383" /> solve the issue.</t> </li>
</list> <li>
</t> <t>Group sub-identifier</t>
<t>
<t><list style="symbols"><t>Group sub-identifier<vspace blankLines="1"/> As discussed before, each group identifier is used to distinguish a
As discussed before, each group identifier is used to post-quantum algorithm. Further classification could be made on a
distinguish a post-quantum algorithm. Further classification particular post-quantum algorithm by assigning an additional value
could be made on a particular post-quantum algorithm by assigning alongside the group identifier. This sub-identifier value may be used
additional value alongside the group identifier. This sub- to assign different security-parameter sets to a given post-quantum
identifier value may be used to assign different security algorithm. However, this level of detail does not fit the principles
parameter sets to a given post-quantum algorithm. However, this of the document where it should deal with generic hybrid key exchange
level of details does not fit the principles of the document where protocol and not a specific ciphersuite. Furthermore, there are
it should deal with generic hybrid key exchange protocol, not a enough Diffie-Hellman group identifiers should this be required in the
specific ciphersuite. Furthermore, there are enough Diffie- future.
Hellman group identifiers should this be required in the future. </t>
</t> </li>
</ul>
</list>
</t>
</section> </section>
<section anchor="acknowledgements" numbered="false" toc="default">
</back> <name>Acknowledgements</name>
<t> The authors would like to thank <contact fullname="Frederic
</rfc> 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>
 End of changes. 164 change blocks. 
1694 lines changed or deleted 1472 lines changed or added

This html diff was produced by rfcdiff 1.48.