rfc9867xml2.original.xml   rfc9867.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<rfc category="std" submissionType="IETF" ipr="trust200902" docName="draft-ietf-
ipsecme-ikev2-qr-alt-10">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc toc="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="I
<?rfc symrefs="yes" ?> ETF" ipr="trust200902" docName="draft-ietf-ipsecme-ikev2-qr-alt-10" number="9867
<?rfc sortrefs="no"?> " consensus="true" updates="" obsoletes="" xml:lang="en" tocInclude="true" symRe
<?rfc iprnotified="no" ?> fs="true" sortRefs="false" version="3">
<?rfc strict="yes" ?>
<front> <front>
<title abbrev="Enhanced Use of PPKs in IKEv2">Mixing Preshared Keys in t <title abbrev="Enhanced Mixing PSKs in IKEv2 for PQ Security">Mixing Preshar
he IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of IKEv2 for Post-quant ed Keys in the IKE_INTERMEDIATE and CREATE_CHILD_SA Exchanges of the Internet Ke
um Security</title> y Exchange Protocol Version 2 (IKEv2) for Post-Quantum Security</title>
<author initials='V.' surname="Smyslov" fullname='Valery Smyslov'> <seriesInfo name="RFC" value="9867"/>
<organization>ELVIS-PLUS</organization> <author initials="V." surname="Smyslov" fullname="Valery Smyslov">
<address> <organization>ELVIS-PLUS</organization>
<postal> <address>
<street>PO Box 81</street> <postal>
<city>Moscow (Zelenograd)</city> <street>PO Box 81</street>
<code>124460</code> <city>Moscow (Zelenograd)</city>
<country>RU</country> <code>124460</code>
</postal> <country>Russian Federation</country>
<phone>+7 495 276 0211</phone> </postal>
<email>svan@elvis.ru</email> <phone>+7 495 276 0211</phone>
</address> <email>svan@elvis.ru</email>
</author> </address>
<date/> </author>
<date month="September" year="2025"/>
<keyword>internet key exchange</keyword> <keyword>internet key exchange</keyword>
<keyword>quantum computer</keyword> <keyword>quantum computer</keyword>
<keyword>post quantum</keyword> <keyword>post quantum</keyword>
<keyword>post-quantum</keyword> <keyword>post-quantum</keyword>
<keyword>quantum safe</keyword> <keyword>quantum safe</keyword>
<keyword>PPK</keyword> <keyword>PPK</keyword>
<abstract> <abstract>
<t> An Internet Key Exchange protocol version 2 (IKEv2) extension de <t> An Internet Key Exchange Protocol Version 2 (IKEv2) extension defined
fined in RFC8784 allows IPsec in RFC 8784 allows IPsec
traffic to be protected against someone storing VPN communications t traffic to be protected against someone storing VPN communications
oday
and decrypting them later, when (and if) a Cryptographically Relevan t Quantum Computer (CRQC) is available. and decrypting them later, when (and if) a Cryptographically Relevan t Quantum Computer (CRQC) is available.
The protection is achieved by means of a Post-quantum Preshared Key (PPK) which is mixed into the session keys calculation. The protection is achieved by means of a Post-quantum Preshared Key (PPK) that is mixed into the session keys calculation.
However, this protection does not cover an initial IKEv2 Security As sociation (SA), which might be unacceptable in some scenarios. However, this protection does not cover an initial IKEv2 Security As sociation (SA), which might be unacceptable in some scenarios.
This specification defines an alternative way to provide protection against quantum computers, which This specification defines an alternative way to provide protection against quantum computers, which
is similar to the solution defined in RFC8784, but also protects the is similar to the solution defined in RFC 8784, but it also protects
initial IKEv2 SA. the initial IKEv2 SA.
</t> </t>
<t> RFC 8784 assumes that PPKs are static and thus they are only used when
<t> RFC8784 assumes that PPKs are static and thus they are only used an initial IKEv2 SA is created. If a fresh PPK is available before t
when he IKE SA expires,
an initial IKEv2 SA is created. If a fresh PPK is available before t
he IKE SA expired,
then the only way to use it is to delete the current IKE SA and crea te a new one from scratch, which is inefficient. then the only way to use it is to delete the current IKE SA and crea te a new one from scratch, which is inefficient.
This specification defines a way to use PPKs in active IKEv2 SAs for creating additional IPsec SAs and rekey operations. This specification defines a way to use PPKs in active IKEv2 SAs for creating additional IPsec SAs and rekey operations.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section>
<section title="Introduction"> <name>Introduction</name>
<t> The Internet Key Exchange protocol version 2, defined in <xref t <t> The Internet Key Exchange Protocol Version 2 (IKEv2), defined in <xref
arget="RFC7296" />, target="RFC7296"/>,
is used in the IPsec architecture for performing authenticated key e xchange. is used in the IPsec architecture for performing authenticated key e xchange.
An extension to IKEv2 for mixing preshared keys for post-quantum sec urity is defined in <xref target="RFC8784" />. An extension to IKEv2 for mixing preshared keys for post-quantum sec urity is defined in <xref target="RFC8784"/>.
This extension allows today's IPsec traffic to be protected against future quantum computers. This extension allows today's IPsec traffic to be protected against future quantum computers.
The protection is achieved by means of using a Post-quantum Preshare d Key (PPK) which is mixed into the session keys calculation. The protection is achieved by means of using a Post-quantum Preshare d Key (PPK) that is mixed into the session keys calculation.
At the time this extension was being developed, the consensus in the IPsecME At the time this extension was being developed, the consensus in the IPsecME
WG was that the IPsec traffic was more important to be protected tha WG was that it was more important to protect the IPsec traffic than
n the IKE traffic. the IKE traffic.
<!-- At the time this extension was being developed, it was a consen It was believed that information transferred over IKE SA (including peers' ident
sus in the IPsecME WG that it was the IPsec traffic ities) is less important
that mostly needed to be protected. --> It was believed that informa and that extending the protection to also cover the initial IKE SA w
tion transferred over IKE SA (including peers' identities) is less important ould require serious modifications to the core IKEv2 protocol.
and extending the protection to also cover initial IKE SA would requ
ire serious modifications to core IKEv2 protocol.
One of the goals was to minimize such changes. It was also decided t hat immediate rekey of initial IKE SA One of the goals was to minimize such changes. It was also decided t hat immediate rekey of initial IKE SA
would add this protection to the new IKE SA (albeit it would not pro vide protection of the identity of the peers). would add this protection to the new IKE SA (albeit it would not pro vide protection of the identity of the peers).
</t> </t>
<t> However, in some situations, it is desirable to have this protection f
<t> However, in some situations it is desirable to have this protect or the IKE SA from the very beginning,
ion for the IKE SA from the very beginning,
when an initial IKE SA is created. An example of such a situation is the Group Key Management protocol using IKEv2, when an initial IKE SA is created. An example of such a situation is the Group Key Management protocol using IKEv2,
defined in <xref target="I-D.ietf-ipsecme-g-ikev2" />. In this proto defined in <xref target="I-D.ietf-ipsecme-g-ikev2"/>. In this protoc
col group policy and session keys are transferred ol, the group policy and session keys are transferred
from a Group Controller/Key Server (GCKS) to the Group Members (GM) from a Group Controller/Key Server (GCKS) to the Group Members (GMs)
immediately once an initial IKE SA is created. immediately once an initial IKE SA is created.
While session keys are additionally protected with a key derived fro m SK_d (and thus are immune to quantum computers if PPKs While session keys are additionally protected with a key derived fro m SK_d (and thus are immune to quantum computers if PPKs
<xref target="RFC8784" /> are employed), the other sensitive data, i <xref target="RFC8784"/> are employed), the other sensitive data, in
ncluding group policy, is not. cluding group policy, is not.
</t> </t>
<t> Another issue with using PPKs as defined in <xref target="RFC8784"/> i
<t> Another issue with using PPKs as it is defined in <xref target=" s that this approach assumes that PPKs are static entities,
RFC8784" /> is that this approach assumes that PPKs are static entities, which are changed very infrequently. For this reason, PPKs are only
which are changed very infrequently. For this reason PPKs are only u used once when an initial IKE SA is established.
sed once - when an initial IKE SA is established. This restriction makes it difficult to use PPKs as defined in <xref
This restriction makes it difficult to use PPKs as defined in <xref target="RFC8784"/> when
target="RFC8784" /> when they are changed relatively frequently, for example, via the use of
they are changed relatively frequently, for example via the use of Q Quantum Key Distribution (QKD).
uantum Key Distribution (QKD).
If a fresh PPK becomes available before the IKE SA is expired, there is no way to use it except If a fresh PPK becomes available before the IKE SA is expired, there is no way to use it except
for deleting this IKE SA and re-creating a new one from scratch usin for deleting the IKE SA and recreating a new one from scratch using
g the fresh PPK. the fresh PPK.
</t> </t>
<t> Some time after the protocol extension for mixing preshared keys in IK
<t> Some time after the protocol extension for mixing preshared keys Ev2 for post-quantum security was defined in <xref target="RFC8784"/>,
in IKEv2 for post-quantum security was defined in <xref target="RFC8784" />, a new IKE_INTERMEDIATE exchange for IKEv2 <xref target="RFC9242"/> w
a new IKE_INTERMEDIATE exchange for IKEv2 <xref target="RFC9242" /> as developed. While the primary motivation for developing
was developed. While the primary motivation for developing this exchange was to allow multiple key exchanges to be used in IKEv
this exchange was to allow multiple key exchanges to be used in IKEv 2 (which is defined in <xref target="RFC9370"/>),
2 (which is defined in <xref target="RFC9370" />),
the IKE_INTERMEDIATE exchange itself can be used for other purposes too. the IKE_INTERMEDIATE exchange itself can be used for other purposes too.
</t> </t>
<t> This specification defines the use of PPKs in the IKE_INTERMEDIATE exc
<t> This specification defines the use of PPKs in the IKE_INTERMEDIA hange of IKEv2 for post-quantum security,
TE exchange of IKEv2 for post-quantum security,
which allows getting full protection against quantum computers for i nitial IKE SA. which allows getting full protection against quantum computers for i nitial IKE SA.
</t> </t>
<t> This specification also defines the use of PPKs in the CREATE_CHILD_SA
<t> This specification also defines the use of PPKs in the CREATE_CH exchange
ILD_SA exchange for creating additional IPsec SAs and for rekeying IKE and IPsec SAs
for creating additional IPsec SAs and for rekeying of IKE and IPsec .
SAs. This allows implementations to leverage fresh PPKs without the need
This allows implementations to leverage fresh PPKs without the need to delete the IKE SA and create it from scratch.
to delete IKE SA and create it from scratch. </t>
</t> <t> This specification does not replace the approach defined in <xref targ
et="RFC8784"/>.
<t> This specification does not replace the approach defined in RFC
8784.
Both approaches for using PPKs in IKEv2 can be used depending on the circumstances Both approaches for using PPKs in IKEv2 can be used depending on the circumstances
(see <xref target="comparison" />). (see <xref target="comparison"/>).
</t> </t>
</section> </section>
<section anchor="mustshouldmay">
<section anchor="mustshouldmay" title="Terminology and Notation"> <name>Terminology and Notation</name>
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NO <t>
T", "SHOULD", "SHOULD NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this docu IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
ment are to be interpreted NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
as described in BCP 14 <xref target="RFC2119" /> <xref target="RFC81 RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
74" /> when, and only when, "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
they appear in all capitals, as shown here. be interpreted as
</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t> This document uses the terms defined in <xref target="RFC7296" / >. In particular, <t> This document uses the terms defined in <xref target="RFC7296"/>. In p articular,
readers should be familiar with the terms "initiator" and "responder " as used in that document. readers should be familiar with the terms "initiator" and "responder " as used in that document.
</t> </t>
<t> The approach defined in <xref target="RFC8784"/> is referred to as "us
<t> The approach defined in RFC 8784 is referred to as "using PPKs i ing PPKs in the IKE_AUTH exchange" or simply
n the IKE_AUTH exchange" or simply
"using PPKs in IKE_AUTH" throughout this document. "using PPKs in IKE_AUTH" throughout this document.
</t> </t>
</section> </section>
<section anchor="protocol">
<section anchor="protocol" title="Protocol Description"> <name>Protocol Description</name>
<section anchor="init" title="Creating Initial IKE SA"> <section anchor="init">
<t> The IKE initiator which supports the IKE_INTERMEDIATE exchange a <name>Creating Initial IKE SA</name>
nd wants to use PPK to protect initial IKE SA <t> The IKE initiator, which supports the IKE_INTERMEDIATE exchange and
wants to use a PPK to protect the initial IKE SA,
includes the INTERMEDIATE_EXCHANGE_SUPPORTED notification and a noti fication of type USE_PPK_INT in the IKE_SA_INIT request. includes the INTERMEDIATE_EXCHANGE_SUPPORTED notification and a noti fication of type USE_PPK_INT in the IKE_SA_INIT request.
If the responder supports the IKE_INTERMEDIATE exchange and is willi ng to use PPK for initial IKE SA protection, If the responder supports the IKE_INTERMEDIATE exchange and is willi ng to use PPK for initial IKE SA protection,
it includes both these notifications in the IKE_SA_INIT response. it includes both these notifications in the IKE_SA_INIT response.
</t> </t>
<artwork align="left"><![CDATA[
<figure align="center">
<artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
HDR, SAi1, KEi, Ni, HDR, SAi1, KEi, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED), N(INTERMEDIATE_EXCHANGE_SUPPORTED),
N(USE_PPK_INT) ---> N(USE_PPK_INT) --->
<--- HDR, SAr1, KEr, Nr, [CERTREQ,] <--- HDR, SAr1, KEr, Nr, [CERTREQ,]
N(INTERMEDIATE_EXCHANGE_SUPPORTED), N(INTERMEDIATE_EXCHANGE_SUPPORTED),
N(USE_PPK_INT) N(USE_PPK_INT)]]></artwork>
]]></artwork>
</figure>
<t> The USE_PPK_INT is a Status Type IKEv2 notification. Its Notify
Message Type
is &lt;TBA1 by IANA&gt;, Protocol ID and SPI Size are both set t
o 0.
This specification does not define any data that this notificati
on may contain,
so the Notification Data is left empty. However, future extensio
ns of this specification may make use of it.
Implementations <bcp14>MUST</bcp14> ignore any data in the notif
ication they do not understand.
</t>
<t> Note that this negotiation is independent from negotiation of us
ing PPKs as specified in <xref target="RFC8784" />.
An initiator that supports both the use of PPKs in IKE_AUTH <xref ta
rget="RFC8784" /> and in IKE_INTERMEDIATE <bcp14>MAY</bcp14> include both
the USE_PPK_INT and the USE_PPK notifications if
configured to so. However, if the responder supports both specificat
ions
and is configured to use PPKs, it has to choose one to use, thus it
<bcp14>MUST</bcp14> return
either USE_PPK_INT or USE_PPK notification in the response, but not
both.
</t>
<t> If the initiator did not propose using this extension in the IKE <t> The USE_PPK_INT is a Status Type IKEv2 notification. Its Notify
_SA_INIT request and responder's policy Message Type is 16445; the Protocol ID is set to 0; the Security
Parameter Index (SPI) is absent, so the SPI Size is set to 0 too. This
specification does not define any data that this notification may
contain, so the Notification Data is left empty. However, future
extensions of this specification may make use of it. Implementations
<bcp14>MUST</bcp14> ignore any data in the notification that they do
not understand.
</t>
<t> Note that this negotiation is independent from the negotiation of us
ing PPKs as specified in <xref target="RFC8784"/>.
An initiator that supports both the use of PPKs in IKE_AUTH <xref ta
rget="RFC8784"/> and IKE_INTERMEDIATE <bcp14>MAY</bcp14> include both
the USE_PPK_INT and USE_PPK notifications if
configured to do so. However, if the responder supports both specifi
cations
and is configured to use PPKs, it has to choose one to use; thus, it
<bcp14>MUST</bcp14> return
either a USE_PPK_INT or a USE_PPK notification in the response but n
ot both.
</t>
<t> If the initiator did not propose using this extension in the IKE_SA_
INIT request and the responder's policy
mandates protecting initial IKE SA with a PPK, then the responder <b cp14>MUST</bcp14> return the NO_PROPOSAL_CHOSEN notification. mandates protecting initial IKE SA with a PPK, then the responder <b cp14>MUST</bcp14> return the NO_PROPOSAL_CHOSEN notification.
</t> </t>
<t> If the negotiation was successful, the initiator includes one or mor
<t> If the negotiation was successful, the initiator includes one or e
more PPK_IDENTITY_KEY notifications in the IKE_INTERMEDIATE request with
PPK_IDENTITY_KEY notification into the IKE_INTERMEDIATE request with PPK identities that the initiator believes
PPK identities the initiator believes are appropriate for the IKE SA being created.
are appropriate for the IKE SA being created, </t>
</t> <t> The PPK_IDENTITY_KEY is a Status Type IKEv2 notification. Its Notify
Message Type
<t> The PPK_IDENTITY_KEY is a Status Type IKEv2 notification. Its No is 16446; the Protocol ID and the SPI Size fields are both set to 0.
tify Message Type The format of the Notification Data is shown below in <xref target="
is &lt;TBA2 by IANA&gt;, Protocol ID and SPI Size fields are both se ppk_identity_key_format"/>.
t to 0. </t>
The format of the notification data is shown below on <xref target="
ppk_identity_key_format" />.
</t>
<figure title="PPK_IDENTITY_KEY Notification Data Format" anchor="pp <figure anchor="ppk_identity_key_format">
k_identity_key_format"> <name>PPK_IDENTITY_KEY Notification Data Format</name>
<preamble></preamble> <artwork><![CDATA[
<artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ PPK_ID ~ ~ PPK_ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ PPK Confirmation + + PPK Confirmation +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork> </figure>
<postamble></postamble>
</figure>
<t>Where:</t>
<t><list style="symbols">
<t>PPK_ID (variable) -- PPK_ID as defined in Section 5.1 of <xref
target="RFC8784" />.
The receiver can determine the length of PPK_ID by subtracting 8
(the length of PPK Confirmation) from the Notification Data length.
</t>
<t>PPK Confirmation (8 octets) -- value, which allows the responde
r to check whether it has the same PPK as the initiator for a given PPK_ID.
This field contains the first 8 octets of a string computed as prf
( PPK, Ni | Nr | SPIi | SPIr ),
where prf is the negotiated PRF; PPK is the key value for a specif
ied PPK_ID; Ni, Nr, SPIi, SPIr -- nonces and IKE SPIs for the SA being establish
ed.
</t>
</list>
</t>
<t> If a series of the IKE_INTERMEDIATE exchanges takes place, the P <t>Where:</t>
PK_IDENTITY_KEY notification(s) <dl spacing="normal" newline="false">
<bcp14>MUST</bcp14> be sent in the last one, i.e. in the IKE_INTERME <dt>PPK_ID (variable):</dt><dd> PPK_ID as defined in <xref
DIATE exchange immediately preceding the IKE_AUTH exchange. target="RFC8784" section="5.1"/>. The receiver can determine the
If the last IKE_INTERMEDIATE exchange contains other payloads aimed length of PPK_ID by subtracting 8 (the length of PPK Confirmation)
for some other purpose, from the Notification Data length.</dd>
then the notification(s) <bcp14>MAY</bcp14> be piggybacked with thes <dt>PPK Confirmation (8 octets):</dt><dd><t>A value that allows the
e payloads. responder to check whether it has the same PPK as the initiator for
a given PPK_ID. This field contains the first 8 octets of a string
computed as prf( PPK, Ni | Nr | SPIi | SPIr ), where:</t>
<ul spacing="compact">
<li>"prf" is the negotiated PRF;</li>
<li>PPK is the key value for a specified PPK_ID;</li>
<li>Ni, Nr, SPIi, SPIr are nonces and IKE SPIs for the SA being estab
lished.</li>
</ul>
</dd>
</dl>
<t>If a series of the IKE_INTERMEDIATE exchanges takes place, the
PPK_IDENTITY_KEY notification(s) <bcp14>MUST</bcp14> be sent in the
last one, i.e., in the IKE_INTERMEDIATE exchange immediately preceding
the IKE_AUTH exchange. If this IKE_INTERMEDIATE exchange contains
other payloads aimed for some other purpose, then the notification(s)
<bcp14>MAY</bcp14> be piggybacked with these payloads. Note that
future IKEv2 extensions utilizing the IKE_INTERMEDIATE exchange may
allow one or more of these exchanges to happen after the one concerned
with PPK for the case when such extensions are negotiated.</t>
<figure align="center"> <artwork align="left"><![CDATA[
<artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
HDR, SK { ... N(PPK_IDENTITY_KEY, PPK_ID_1) HDR, SK { ... N(PPK_IDENTITY_KEY, PPK_ID_1)
[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ... [, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} ---> [, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->]]></artwork>
]]></artwork>
</figure>
Depending on the responder's capabilities and policy the following s <t>
ituations are possible. Depending on the responder's capabilities and policy, the following
</t> situations are possible:
</t>
<ol> <!-- [rfced] Sections 3.1 and 3.2: We're having trouble parsing "one
of the PPKs which IDs were sent" and "initiator's one". Would the
following match the intended meaning or is there another way this
can be written for clarity and consistency?
<li anchor="case1"> If the responder is configured with one of the a) Section 3.1:
PPKs
which IDs were sent by the initiator and this PPK matches the init
iator's one
<!-- If the responder is configured with a PPK, which ID was among
IDs sent by the initiator, and this PPK matches the initiator's one -->
(based on the information from the PPK Confirmation field), then t
he responder selects this PPK
and returns back its identity in the PPK_IDENTITY notification. Th
e PPK_IDENTITY notification
is defined in <xref target="RFC8784" />.
<figure align="center"> Original:
<artwork align="left"><![CDATA[ 1. If the responder is configured with one of the PPKs which IDs
Initiator Responder were sent by the initiator and this PPK matches the initiator's
<--- HDR, SK { ... N(PPK_IDENTITY, PPK_ID_i)} one (based on the information from the PPK Confirmation field),
]]></artwork> then the responder selects this PPK and returns back its identity
</figure> in the PPK_IDENTITY notification.
In this case the IKE_AUTH exchange is performed as defined in IKEv Perhaps:
2 <xref target="RFC7296" />. 1. If the responder is configured with a PPK that was among the
However, the keys for the IKE SA are computed using PPK, as descri IDs sent by the initiator, and if this PPK matches the
bed in <xref target="init_keys" />. initiator's PPK (based on the information from the PPK
If the responder returns a PPK identity that was not proposed by t Confirmation field), then the responder selects this PPK and
he initiator, then the initiator returns its identity in the PPK_IDENTITY notification.
<bcp14>MUST</bcp14> treat this as a fatal and abort the IKE SA est
ablishment.
</li>
<li anchor="case2"> If the responder does not have any of the PPKs b) Section 3.1:
which IDs were sent by the initiator
or it has some of the proposed PPKs, but their values mismatch the
initiator's ones
(based on the information from the PPK Confirmation field), and us
ing PPK is mandatory for the responder,
then it <bcp14>MUST</bcp14> return AUTHENTICATION_FAILED notificat
ion and abort creating the IKE SA.
<figure align="center"> Original
<artwork align="left"><![CDATA[ 2. If the responder does not have any of the PPKs which IDs were
Initiator Responder sent by the initiator or it has some of the proposed PPKs, but
<--- HDR, SK {... N(AUTHENTICATION_FAILED)} their values mismatch the initiator's ones (based on the
]]></artwork> information from the PPK Confirmation field), and using PPK is
</figure> mandatory for the responder, then it MUST return
AUTHENTICATION_FAILED notification and abort creating the IKE SA.
</li> Perhaps:
2. If the responder does not have any of the PPKs that were among
the IDs sent by the initiator, or if the responder has some of
the proposed PPKs but their values are mismatched from the
initiator's PPKs (based on the information from the PPK
Confirmation field), and if using PPK is mandatory for the
responder, then it MUST return an AUTHENTICATION_FAILED
notification and abort creating the IKE SA.
<li anchor="case3"> <!-- If the responder does not have any of the c) Section 3.2:
PPKs which IDs were sent by the initiator -->
If the responder does not have any PPKs proposed by the initiator
or it has some of the proposed PPKs, but their values mismatch the
initiator's ones
(based on the information from the PPK Confirmation field), and us
ing PPK is optional for the responder,
then it does not include any PPK_IDENTITY notification to the resp
onse.
<figure align="center"> Original:
<artwork align="left"><![CDATA[ In case the responder does not support (or is not configured for)
Initiator Responder using PPKs in the CREATE_CHILD_SA exchange, or does not have any of
<--- HDR, SK {...} the PPKs which IDs were sent by the initiator, or it has some of
]]></artwork> proposed PPKs, but their values mismatch the initiator's ones (based
</figure> on the information from the PPK Confirmation field), then it does not
include any PPK_IDENTITY notification in the response and new SA is
created as defined in IKEv2 [RFC7296].
In this case the initiator cannot achieve quantum computer resista Perhaps:
nce using the proposed PPKs. If the responder does not support (or is not configured for)
If this is a requirement for the initiator, then it <bcp14>MUST</b using PPKs in the CREATE_CHILD_SA exchange or does not have any of
cp14> abort creating the IKE SA. the PPKs that were among the IDs sent by the initiator, or if the
Otherwise, the initiator continues with the IKE_AUTH exchange as d responder has some of proposed PPKs but their values are mismatched
escribed in IKEv2 <xref target="RFC7296" />. from the initiator's PPKs (based on the information from the PPK
</li> Confirmation field), then it does not include any PPK_IDENTITY
</ol> notifications in the response, and new SA is created as defined in
IKEv2 [RFC7296].
<t><xref target="responders_behavior"/> summarizes the above logic f d) Section 3.2:
or the responder:
</t>
<table title="Responder's behavior" anchor="responders_behavior"> Original:
<thead> If using PPKs in CREATE_CHILD_SA is mandatory for the responder and
<tr> the initiator does not include any PPK_IDENTITY_KEY notification in
<th>Received USE_PPK_INT</th> the request or the responder does not have any of the PPKs which IDs
<th>Supports USE_PPK_INT</th> were sent by the initiator, or it has some of proposed PPKs, but
<th>Has one of proposed PPKs</th> their values mismatch the initiator's ones (based on the information
<th>PPK is mandatory for initial IKE SA</th> from the PPK Confirmation field), then the responder MUST return the
<th>Action</th> NO_PROPOSAL_CHOSEN notification.
</tr>
</thead>
<tbody>
<tr>
<td>No</td>
<td>*</td>
<td>*</td>
<td>No</td>
<td><xref target="RFC8784" /> (if proposed) or standard IKEv2
protocol</td>
</tr>
<tr>
<td>No</td>
<td>Yes</td>
<td>*</td>
<td>Yes</td>
<td>Send NO_PROPOSAL_CHOSEN</td>
</tr>
<tr>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>*</td>
<td><xref target="case1"/> (use this extension)</td>
</tr>
<tr>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
<td>Yes</td>
<td><xref target="case2"/> (abort negotiation)</td>
</tr>
<tr>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
<td>No</td>
<td><xref target="case3"/> (standard IKEv2 protocol)</td>
</tr>
</tbody>
</table>
<t> Since the responder selects a PPK before it knows the identity o Perhaps:
f the initiator, a situation may occur, If using PPKs in CREATE_CHILD_SA is mandatory for the responder and
when the responder agrees to use some PPK in the IKE_INTERMEDIATE ex the initiator does not include any PPK_IDENTITY_KEY notification in
change, but during the IKE_AUTH exchange the request, or if the responder does not have any of the PPKs that
were among the IDs sent by the initiator, or if the responder has some
of the proposed PPKs but with mismatched values from the initiator's PPKs
(based on the information from the PPK Confirmation field), then the
responder MUST return the NO_PROPOSAL_CHOSEN notification.
-->
<ol type="1">
<li anchor="case1">
<t>If the responder is configured with a PPK with an ID that is
among the IDs sent by the initiator, and if this PPK matches the
initiator's PPK (based on the information from the PPK
Confirmation field), then the responder selects this PPK and
returns its identity in the PPK_IDENTITY notification. The
PPK_IDENTITY notification is defined in <xref target="RFC8784"/>.
</t>
<artwork align="left"><![CDATA[
Initiator Responder
---------------------------------------------------------------
<--- HDR, SK { ... N(PPK_IDENTITY, PPK_ID_i)}]]></artwork>
<t>
In this case, the IKE_AUTH exchange is performed as defined in IKE
v2 <xref target="RFC7296"/>.
However, the keys for the IKE SA are computed using PPK, as descri
bed in <xref target="init_keys"/>.
If the responder returns a PPK identity that was not proposed by t
he initiator, then the initiator
<bcp14>MUST</bcp14> treat this as fatal and abort the IKE SA estab
lishment.
</t>
</li>
<li anchor="case2">
<t>If the responder does not have a PPK with an ID that matches any
of IDs sent by the initiator, or if the responder has some of the
proposed PPKs but their values are mismatched from the initiator's
PPKs (based on the information from the PPK Confirmation field),
and if using PPK is mandatory for the responder, then it
<bcp14>MUST</bcp14> return an AUTHENTICATION_FAILED notification
and abort creating the IKE SA.
</t>
<artwork align="left"><![CDATA[
Initiator Responder
---------------------------------------------------------------
<--- HDR, SK {... N(AUTHENTICATION_FAILED)}]]></artwork>
</li>
<li anchor="case3">
<t>
If the responder does not have any PPKs proposed by the initiator,
or if it has only some of the proposed PPKs but their values misma
tch the initiator's ones
(based on the information from the PPK Confirmation field), and if
using PPK is optional for the responder,
then it does not include any PPK_IDENTITY notification to the resp
onse.
</t>
<artwork align="left"><![CDATA[
Initiator Responder
---------------------------------------------------------------
<--- HDR, SK {...}]]></artwork>
<t>
In this case, the initiator cannot achieve quantum computer resist
ance using the proposed PPKs.
If this is a requirement for the initiator, then it <bcp14>MUST</b
cp14> abort creating the IKE SA.
Otherwise, the initiator continues with the IKE_AUTH exchange as d
escribed in IKEv2 <xref target="RFC7296"/>.
</t>
</li>
</ol>
<t><xref target="responders_behavior"/> summarizes the above logic for t
he responder:</t>
<table anchor="responders_behavior">
<name>Responder's Behavior</name>
<thead>
<tr>
<th>Received USE_PPK_INT</th>
<th>Supports USE_PPK_INT</th>
<th>Has one of the proposed PPKs</th>
<th>PPK is mandatory for initial IKE SA</th>
<th>Action</th>
</tr>
</thead>
<tbody>
<tr>
<td>No</td>
<td>*</td>
<td>*</td>
<td>No</td>
<td>
<xref target="RFC8784"/> (if proposed) or standard IKEv2 protoco
l</td>
</tr>
<tr>
<td>No</td>
<td>Yes</td>
<td>*</td>
<td>Yes</td>
<td>Send NO_PROPOSAL_CHOSEN</td>
</tr>
<tr>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>*</td>
<td>
<xref target="case1"/> (use this extension)</td>
</tr>
<tr>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
<td>Yes</td>
<td>
<xref target="case2"/> (abort negotiation)</td>
</tr>
<tr>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
<td>No</td>
<td>
<xref target="case3"/> (standard IKEv2 protocol)</td>
</tr>
</tbody>
</table>
<t> Since the responder selects a PPK before it knows the identity of th
e initiator, a situation may occur
where the responder agrees to use some PPK in the IKE_INTERMEDIATE e
xchange but then, during the IKE_AUTH exchange,
discovers that this particular PPK is not associated with the initia tor's identity in its local policy. discovers that this particular PPK is not associated with the initia tor's identity in its local policy.
Note that the responder does have this PPK, but it is just not liste Note that the responder does have this PPK, but it is just not liste
d among the PPKs for using with this initiator. d among the PPKs to be used with this initiator.
In this case the responder <bcp14>SHOULD</bcp14> abort negotiation a In this case, the responder <bcp14>SHOULD</bcp14> abort negotiation
nd return back the AUTHENTICATION_FAILED notification and return back the AUTHENTICATION_FAILED notification
to be consistent with its policy. However, the responder <bcp14>MAY< /bcp14> continue creating IKE SA using the negotiated to be consistent with its policy. However, the responder <bcp14>MAY< /bcp14> continue creating IKE SA using the negotiated
"wrong" PPK if this is acceptable according to its local policy. "wrong" PPK if this is acceptable according to its local policy.
</t> </t>
<section anchor="init_keys">
<section anchor="init_keys" title="Computing IKE SA Keys"> <name>Computing IKE SA Keys</name>
<t> Once the PPK is negotiated in the last IKE_INTERMEDIATE exchan <t>Once the PPK is negotiated in the IKE_INTERMEDIATE exchange, the
ge, the IKE SA keys are recalculated. IKE SA keys are recalculated. Note that if the IKE SA keys are also
Note that if the IKE SA keys are also recalculated as the result o recalculated as a result of other actions performed in this
f the other actions performed in the IKE_INTERMEDIATE exchange IKE_INTERMEDIATE exchange (for example, as defined in <xref
(for example, as defined in <xref target= "RFC9370" />), then appl target="RFC9370"/>), then applying the PPK <bcp14>MUST</bcp14> be
ying the PPK done after all of them so that recalculating IKE SA keys with the
<bcp14>MUST</bcp14> be done after all of them, so that recalculati PPK is the last action before they are used in the next
ng IKE SA keys with the PPK exchange. Note that future IKEv2 extensions utilizing the
is the last action before they are used in the IKE_AUTH exchange. IKE_INTERMEDIATE exchange may update this requirement for the case
</t> when such extensions are negotiated.
</t>
<t> The IKE SA keys are computed differently compared to how PPKs <t> The IKE SA keys are computed differently compared to how PPKs
are used in IKE_AUTH. are used in IKE_AUTH. A new SKEYSEED' value is computed using the
A new SKEYSEED' value is computed using the negotiated PPK and the negotiated PPK and the most recently computed SK_d key. Note that
most recently computed SK_d key. the PPK is applied to SK_d exactly how it is specified in <xref
Note that the PPK is applied to SK_d exactly how it is specified i target="RFC8784"/>, and the result is used as SKEYSEED'.
n <xref target="RFC8784" />, </t>
and the result is used as SKEYSEED'. <artwork align="left"><![CDATA[
SKEYSEED' = prf+ (PPK, SK_d)]]></artwork>
<figure align="center"> <t>
<artwork align="left"><![CDATA[ Then the SKEYSEED' is used to recalculate all SK_* keys as defined
SKEYSEED' = prf+ (PPK, SK_d) in <xref target="RFC7296" section="2.14"/>.
]]></artwork>
</figure>
Then the SKEYSEED' is used to recalculate all SK_* keys as defined
in Section 2.14 of <xref target="RFC7296" />.
<figure align="center"> </t>
<artwork align="left"><![CDATA[ <artwork align="left"><![CDATA[
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr ) = prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr )]]></artwor
k>
]]></artwork> <t>
</figure>
In the formula above, Ni and Nr are nonces from the IKE_SA_INIT ex change, and SPIi and SPIr are the SPIs of the IKE SA being created. In the formula above, Ni and Nr are nonces from the IKE_SA_INIT ex change, and SPIi and SPIr are the SPIs of the IKE SA being created.
Note that SK_d, SK_pi, and SK_pr are not individually recalculated Note that SK_d, SK_pi, and SK_pr are not individually recalculated
using PPK, as it is defined in <xref target="RFC8784" />. using PPK, as defined in <xref target="RFC8784"/>.
</t> </t>
<t> The resulting keys are then used in the IKE_AUTH exchange and in t
<t> The resulting keys are then used in the IKE_AUTH exchange and he created IKE SA.
in the created IKE SA. </t>
</t> </section>
</section> </section>
</section> <section anchor="create_child_sa">
<name>Using PPKs in the CREATE_CHILD_SA Exchange</name>
<section anchor="create_child_sa" title="Using PPKs in the CREATE_CHIL <t> If a fresh PPK is available to both peers at the time when an IKE SA
D_SA Exchange"> is active,
<t> If a fresh PPK is available to both peers at the time when an IK
E SA is active,
peers <bcp14>MAY</bcp14> use this fresh PPK without creating a new I KE SA from scratch peers <bcp14>MAY</bcp14> use this fresh PPK without creating a new I KE SA from scratch
when they have a need to create additional IPsec SAs or to rekey exi sting SAs. when they have a need to create additional IPsec SAs or to rekey exi sting SAs.
In this case the PPK can be used for creating additional IPsec SAs a In this case, the PPK can be used for creating additional IPsec SAs
nd for rekeying both IKE and IPsec SAs and for rekeying both IKE and IPsec SAs
regardless whether the current IKE SA was created with the use of a regardless of whether the current IKE SA was created with the use of
PPK a PPK
(no matter how: in IKE_AUTH, in IKE_INTERMEDIATE or in CREATE_CHILD_ (no matter how: in IKE_AUTH, in IKE_INTERMEDIATE, or in CREATE_CHILD
SA) or not. _SA) or not.
</t> </t>
<t> If the initiator wants to use a PPK in the CREATE_CHILD_SA exchange,
<t> If the initiator wants to use a PPK in the CREATE_CHILD_SA excha it includes one or more
nge, it includes one or more PPK_IDENTITY_KEY notifications containing PPK identities that the in
PPK_IDENTITY_KEY notification containing PPK identities the initiato itiator believes
r believes are appropriate for the SA being created in the CREATE_CHILD_SA requ
are appropriate for the SA being created, into the CREATE_CHILD_SA r est.
equest. In this case, the PPK Confirmation field contains the first 8 octets
The PPK Confirmation field in this case contains the first 8 octets of a string computed as prf( PPK, Ni | SPIi | SPIr ),
of a string computed as prf( PPK, Ni | SPIi | SPIr ), where Ni is the initiator's nonce from the CREATE_CHILD_SA request a
where Ni is the initiator's nonce from the CREATE_CHILD_SA request a nd SPIi/SPIr are the SPIs of the current IKE SA.
nd SPIi/SPIr - SPIs of the current IKE SA.
If the responder supports using PPKs in the CREATE_CHILD_SA exchange and is configured and ready to do it, If the responder supports using PPKs in the CREATE_CHILD_SA exchange and is configured and ready to do it,
then it sends back the PPK_IDENTITY notification containing the ID o f the selected PPK, as depicted in figures below. then it sends back the PPK_IDENTITY notification containing the ID o f the selected PPK, as depicted in the figures below.
<figure align="center" title="CREATE_CHILD_SA Exchange for Creating or Rekeying </t>
Child SAs"> <figure>
<artwork align="left"><![CDATA[ <name>CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs</nam
e>
<artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
HDR, SK {[N(REKEY_SA),] SA, Ni, [KEi,] TSi, TSr, HDR, SK {[N(REKEY_SA),] SA, Ni, [KEi,] TSi, TSr,
N(PPK_IDENTITY_KEY, PPK_ID_1) N(PPK_IDENTITY_KEY, PPK_ID_1)
[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ... [, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} ---> [, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->
<--- HDR, SK {SA, Nr [KEr,] TSi, TSr, <--- HDR, SK {SA, Nr [KEr,] TSi, TSr,
N(PPK_IDENTITY, PPK_ID_i)} N(PPK_IDENTITY, PPK_ID_i)}]]></artwork>
]]></artwork> </figure>
</figure> <figure>
<name>CREATE_CHILD_SA Exchange for Rekeying IKE SA</name>
<figure align="center" title="CREATE_CHILD_SA Exchange for Rekeying IKE SA"> <artwork align="left"><![CDATA[
<artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
HDR, SK {SA, Ni, KEi, HDR, SK {SA, Ni, KEi,
N(PPK_IDENTITY_KEY, PPK_ID_1) N(PPK_IDENTITY_KEY, PPK_ID_1)
[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ... [, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} ---> [, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->
<--- HDR, SK {SA, Nr, KEr, <--- HDR, SK {SA, Nr, KEr,
N(PPK_IDENTITY, PPK_ID_i)} N(PPK_IDENTITY, PPK_ID_i)}]]></artwork>
]]></artwork> </figure>
</figure>
In case the responder does not support (or is not configured for) us
ing PPKs in the CREATE_CHILD_SA exchange, or does not have any of the PPKs
which IDs were sent by the initiator, or it has some of proposed PPK
s, but their values mismatch the initiator's ones
(based on the information from the PPK Confirmation field), then it
does not include any PPK_IDENTITY notification in the response
and new SA is created as defined in IKEv2 <xref target="RFC7296" />.
If this is inappropriate for the initiator,
it can immediately delete this SA.
</t>
<t> If using PPKs in CREATE_CHILD_SA is mandatory for the responder
and the initiator does not include any PPK_IDENTITY_KEY notification in the requ
est
or the responder does not have any of the PPKs which IDs were sent b
y the initiator, or it has some of proposed PPKs, but their values mismatch
the initiator's ones (based on the information from the PPK Confirma
tion field), then the responder <bcp14>MUST</bcp14> return the NO_PROPOSAL_CHOSE
N
notification.
</t>
<t> Otherwise the new SA is created using the selected PPK.
</t>
<section anchor="create_child_sa_keys" title="Computing Keys"> <t>
<t> For the purpose of calculation session keys for the new SA, th If the responder does not support (or is not configured for) using
e current SK_d key is first PPKs in the CREATE_CHILD_SA exchange or does not have a PPK with an
ID that matches any of IDs sent by the initiator, or if the
responder has some of the proposed PPKs but their values are
mismatched from the initiator's PPKs (based on the information from
the PPK Confirmation field), then it will not include any
PPK_IDENTITY notifications in the response, and new SA is created as
defined in IKEv2 <xref target="RFC7296"/>. If this is inappropriate
for the initiator, it can immediately delete this SA.
</t>
<t>
If using PPKs in CREATE_CHILD_SA is mandatory for the responder, and
the initiator does not include any PPK_IDENTITY_KEY notifications in
the request, or if the responder does not have a PPK with an ID that
matches any of IDs sent by the initiator, or if the responder has
some of the proposed PPKs but with mismatched values from the
initiator's PPKs (based on the information from the PPK Confirmation
field), then the responder <bcp14>MUST</bcp14> return the
NO_PROPOSAL_CHOSEN notification.
</t>
<t> Otherwise, the new SA is created using the selected PPK.
</t>
<section anchor="create_child_sa_keys">
<name>Computing Keys</name>
<t> For the purpose of calculation session keys for the new SA, the cu
rrent SK_d key is first
mixed with the selected PPK: mixed with the selected PPK:
<figure align="center"> </t>
<artwork align="left"><![CDATA[ <artwork align="left"><![CDATA[
SK_d' = prf+ (PPK, SK_d) SK_d' = prf+ (PPK, SK_d)]]></artwork>
]]></artwork> <t>
</figure>
The resulting key SK_d' is then used instead of SK_d in all formul as for computing keys for the new SA The resulting key SK_d' is then used instead of SK_d in all formul as for computing keys for the new SA
(Sections 2.17 and 2.18 of <xref target="RFC7296" />, Section 2.2. (Sections <xref target="RFC7296" sectionFormat="bare" section="2.1
4 of <xref target="RFC9370" />). 7"/> and <xref target="RFC7296" sectionFormat="bare" section="2.18"/> of <xref t
</t> arget="RFC7296"/> and <xref target="RFC9370" section="2.2.4"/>).
</t>
<t> Note that if the PPK that was used for the IKE SA establishmen <t> Note that if the PPK that was used for the IKE SA establishment is
t is not changed, then there is no point not changed, then there is no point
to use it in the CREATE_CHILD_SA exchange. to use it in the CREATE_CHILD_SA exchange.
</t> </t>
</section>
</section>
</section> </section>
</section>
<section anchor="security" title="Security Considerations"> </section>
<t> Security considerations of using Post-quantum Preshared Keys <section anchor="security">
in the IKEv2 protocol are discussed in <xref target="RFC8784" />. <name>Security Considerations</name>
<t> Security considerations for using Post-quantum Preshared Keys
in the IKEv2 protocol are discussed in <xref target="RFC8784"/>.
Unlike using PPKs in IKE_AUTH, this specification makes even initial IKE SA quantum Unlike using PPKs in IKE_AUTH, this specification makes even initial IKE SA quantum
secure. In addition, a PPK is mixed into the SK_* keys calculation secure. In addition, a PPK is mixed into the SK_* keys calculation
before the IKE_AUTH exchange starts, and since the PPK is used in au thentication too, before the IKE_AUTH exchange starts, and since the PPK is used in au thentication too,
this exchange is quantum secure even against an active attacker. this exchange is quantum secure even against an active attacker.
</t> </t>
<t> This specification relies on the IKE_INTERMEDIATE exchange.
<t> This specification relies on the IKE_INTERMEDIATE exchange. Refer to <xref target="RFC9242"/> for discussion of related security
Refer to <xref target="RFC9242" /> for discussion of related securit issues.
y issues. </t>
</t>
<t> Section 4 of <xref target="RFC9370" /> discusses the potential i
mpact
of appearing a CRQC to various cryptographic primitives used in IKEv
2.
It is worth to repeat here that it is believed that security of symm
etric
key cryptographic primitives will not be affected by CRQC.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document defines two new Notify Message Types in the "IKEv2
Notify Message Status Types" registry:</t>
<figure align="center">
<artwork align="left"><![CDATA[
<TBA1> USE_PPK_INT
<TBA2> PPK_IDENTITY_KEY
]]></artwork>
</figure>
</section>
<section title="Acknowledgements" anchor="acknowledgements">
<t> Author would like to thank Paul Wouters for valuable comments an
d Tero Kivinen
who made a thorough review of the document and proposed a lot of tex
t improvements, and who also
pointed out to the problem of mismatched preshared keys. Thanks to R
ebecca Guthrie
for providing comments and proposals for the document and to Mikhail
Borodin for discovering
the problem of calculating PPK Confirmation in CREATE_CHILD_SA.
</t>
</section>
</middle>
<back> <t> <xref target="RFC9370" section="4"/> discusses the potential impact
<references title='Normative References'> of when a CRQC is accessible on various cryptographic primitives used in
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. IKEv2. It is worthwhile to repeat here that it is believed that the
RFC.2119.xml" ?> security of symmetric key cryptographic primitives will not be affected
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. by CRQC.
RFC.8174.xml" ?> </t>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. </section>
RFC.7296.xml" ?> <section anchor="iana">
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <name>IANA Considerations</name>
RFC.8784.xml" ?> <t>Per this document, IANA has added the following Notify Message Types in
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. the "IKEv2 Notify Message Status Types" registry:</t>
RFC.9242.xml" ?>
</references>
<references title='Informative References'> <dl spacing="compact" newline="false">
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference <dt>16445</dt><dd>USE_PPK_INT</dd>
.I-D.ietf-ipsecme-g-ikev2.xml" ?> <dt>16446</dt><dd>PPK_IDENTITY_KEY</dd>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. </dl>
RFC.9370.xml" ?> </section>
</references>
<section anchor="comparison" title="Comparison of this Specification wit </middle>
h RFC8784"> <back>
<displayreference target="I-D.ietf-ipsecme-g-ikev2" to="G-IKEV2"/>
<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.8
174.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
784.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
242.xml"/>
</references>
<references>
<name>Informative References</name>
<t> This specification is not intended to be a replacement for using <!-- [I-D.ietf-ipsecme-g-ikev2] IESG State: RFC Ed Queue (in AUTH48) as of 09/18
PPKs in IKE_AUTH as defined in <xref target="RFC8784" />. /25 -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-ipsecme-g-ikev2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
370.xml"/>
</references>
</references>
<section anchor="comparison">
<name>Comparison of this Specification with RFC 8784</name>
<t> This specification is not intended to be a replacement for using PPKs
in IKE_AUTH as defined in <xref target="RFC8784"/>.
Instead, it is supposed to be used in situations where the approach defined there Instead, it is supposed to be used in situations where the approach defined there
does not meet the requirements, like the need to make the initial IK E SA quantum-secure or does not meet the requirements, like the need to make the initial IK E SA quantum-secure or
the need to choose between several available PPKs. the need to choose between several available PPKs.
However, if the peers support both using PPKs in IKE_AUTH and this s pecification, However, if the peers support both using PPKs in IKE_AUTH and this s pecification,
then the latter may also be used in situations where using PPKs in I KE_AUTH suffices then the latter may also be used in situations where using PPKs in I KE_AUTH suffices
(e.g., when initial IKE SA is not required to be quantum-protected). (e.g., when the initial IKE SA is not required to be quantum-protect
</t> ed).
</t>
<t> The approach defined in this document has the following advantag <t> The approach defined in this document has the following advantages:
es: </t>
<list style="numbers"> <ol spacing="normal" type="1">
<t> The main advantage of using PPK in the IKE_INTERMEDIATE exch <li>
ange instead of the IKE_AUTH exchange is that it allows IKE_AUTH to be fully pro <t> The main advantage of using PPK in the IKE_INTERMEDIATE exchange i
tected. nstead of the IKE_AUTH exchange is that it allows IKE_AUTH to be fully protected
.
This means that the ID payloads and any other sensitive content sent in the IKE_AUTH are protected against quantum computers. This means that the ID payloads and any other sensitive content sent in the IKE_AUTH are protected against quantum computers.
The same is true for the sensitive data sent in the GSA_AUTH exc The same is true for the sensitive data sent in the GSA_AUTH exc
hange is the G-IKEv2 protocol <xref target="I-D.ietf-ipsecme-g-ikev2" />. hange in the G-IKEv2 protocol <xref target="I-D.ietf-ipsecme-g-ikev2"/>.
</t> </t>
<t> In addition to the IKE_AUTH exchange being fully protected, </li>
the initial IKE SA is also fully protected, which is important when <li>
sensitive information is transferred over initial IKE SA. Exampl <t> In addition to the IKE_AUTH exchange being fully protected, the in
es of such itial IKE SA is also fully protected, which is important when
situation are the CREATE_CHILD_SA exchange of IKEv2 and the GSA_ sensitive information is transferred over initial IKE SA. Exampl
REGISTRATION exchange of G-IKEv2 <xref target="I-D.ietf-ipsecme-g-ikev2" />. es of such a
</t> situation are the CREATE_CHILD_SA exchange of IKEv2 and the GSA_
<t> As the PPK exchange happens as separate exchange before IKE_ REGISTRATION exchange of G-IKEv2 <xref target="I-D.ietf-ipsecme-g-ikev2"/>.
AUTH this means that initiator can propose several PPKs and </t>
responder can pick one. This is not possible when PPK exchange h </li>
appens in the IKE_AUTH. This feature could simplify PPK <li>
<t> As the PPK exchange happens as a separate exchange before IKE_AUTH
, this means that initiator can propose several PPKs and
the responder can pick one. This is not possible when the PPK ex
change happens in the IKE_AUTH. This feature could simplify PPK
rollover. rollover.
</t> </t>
<t> With this specification there is no need for the initiator t </li>
o calculate the content of the AUTH payload twice (with and <li>
<t> With this specification there is no need for the initiator to calc
ulate the content of the AUTH payload twice (with and
without PPK) to support a situation when using PPK is optional f or both sides. without PPK) to support a situation when using PPK is optional f or both sides.
</t> </t>
</list> </li>
</ol>
<t>
The main disadvantage of the approach defined in this document is th at it always requires an additional round trip (the IKE_INTERMEDIATE exchange) The main disadvantage of the approach defined in this document is th at it always requires an additional round trip (the IKE_INTERMEDIATE exchange)
to set up IKE SA and initial IPsec SA. However, if the IKE_INTERMEDI to set up the IKE SA and the initial IPsec SA. However, if the IKE_I
ATE exchange has to be used for some other purposes in any case, NTERMEDIATE exchange has to be used for some other purposes in any case,
then the PPK related payloads can be piggybacked with other payloads then the PPK-related payloads can be piggybacked with other payloads
, thus eliminating this penalty. , thus eliminating this penalty.
</t> </t>
</section> </section>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t> Author would like to thank <contact fullname="Paul Wouters"/> for
valuable comments and <contact fullname="Tero Kivinen"/> who made a
thorough review of the document and proposed a lot of text improvements,
and who also pointed out to the problem of mismatched preshared
keys. Thanks to <contact fullname="Rebecca Guthrie"/> for providing
comments and proposals for the document and to <contact
fullname="Mikhail Borodin"/> for discovering the problem of calculating
PPK Confirmation in CREATE_CHILD_SA.</t>
</section>
</back>
</back>
</rfc> </rfc>
 End of changes. 71 change blocks. 
582 lines changed or deleted 628 lines changed or added

This html diff was produced by rfcdiff 1.48.