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- <!DOCTYPE rfc [
ipsecme-ikev2-qr-alt-10"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="I ETF" ipr="trust200902" docName="draft-ietf-ipsecme-ikev2-qr-alt-10" number="9867 " consensus="true" updates="" obsoletes="" xml:lang="en" tocInclude="true" symRe fs="true" sortRefs="false" version="3">
<?rfc toc="yes" ?> <!-- [rfced] Document title and abbreviated title.
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front> a) Please note that the document title has been updated as
<title abbrev="Enhanced Use of PPKs in IKEv2">Mixing Preshared Keys in t follows. The abbreviation "IKEv2" has been expanded
he IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of IKEv2 for Post-quant per Section 3.6 of RFC 7322 ("RFC Style Guide").
um Security</title>
<author initials='V.' surname="Smyslov" fullname='Valery Smyslov'>
<organization>ELVIS-PLUS</organization>
<address>
<postal>
<street>PO Box 81</street>
<city>Moscow (Zelenograd)</city>
<code>124460</code>
<country>RU</country>
</postal>
<phone>+7 495 276 0211</phone>
<email>svan@elvis.ru</email>
</address>
</author>
<date/>
<keyword>internet key exchange</keyword> Additionally, may we make the document title more concise by
<keyword>quantum computer</keyword> removing "IKE_INTERMEDIATE" and "CREATE_CHILD_SA", as they are
<keyword>post quantum</keyword> not mentioned in the Abstract, and by potentially adding "PPK",
<keyword>post-quantum</keyword> which is mentioned in the Abstract? Please let us know if one
<keyword>quantum safe</keyword> of the suggestions below retains the intended meaning or if
<keyword>PPK</keyword> you prefer otherwise.
<abstract> Original:
<t> An Internet Key Exchange protocol version 2 (IKEv2) extension de Mixing Preshared Keys in the IKE_INTERMEDIATE and in the
fined in RFC8784 allows IPsec CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security
traffic to be protected against someone storing VPN communications t
oday Current:
Mixing Preshared Keys in the IKE_INTERMEDIATE and
CREATE_CHILD_SA Exchanges of the Internet Key Exchange
Protocol Version 2 (IKEv2) for Post-Quantum Security
Perhaps A:
Mixing Preshared Keys in Exchanges of the Internet
Key Exchange Protocol Version 2 (IKEv2) for
Post-Quantum Security
or
Perhaps B:
Enhanced Use of Post-Quantum Preshared Keys (PPKs) in the
Internet Key Exchange Protocol Version 2 (IKEv2) for
Post-Quantum Security
b) Please verify that the abbreviated title that spans the header
of the PDF file still matches the document title.
Original/Current:
Enhanced Use of PPKs in IKEv2
-->
<front>
<title abbrev="Enhanced Use of PPKs in IKEv2">Mixing Preshared Keys in the I
KE_INTERMEDIATE and CREATE_CHILD_SA Exchanges of the Internet Key Exchange Proto
col Version 2 (IKEv2) for Post-Quantum Security</title>
<seriesInfo name="RFC" value="9867"/>
<author initials="V." surname="Smyslov" fullname="Valery Smyslov">
<organization>ELVIS-PLUS</organization>
<address>
<postal>
<street>PO Box 81</street>
<city>Moscow (Zelenograd)</city>
<code>124460</code>
<country>Russian Federation</country>
</postal>
<phone>+7 495 276 0211</phone>
<email>svan@elvis.ru</email>
</address>
</author>
<date month="September" year="2025"/>
<keyword>internet key exchange</keyword>
<keyword>quantum computer</keyword>
<keyword>post quantum</keyword>
<keyword>post-quantum</keyword>
<keyword>quantum safe</keyword>
<keyword>PPK</keyword>
<abstract>
<t> An Internet Key Exchange Protocol Version 2 (IKEv2) extension defined
in RFC 8784 allows IPsec
traffic to be protected against someone storing VPN communications
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 n the IKE traffic. WG was that it was more important to protect the IPsec traffic than the IKE traffic.
<!-- At the time this extension was being developed, it was a consen sus in the IPsecME WG that it was the IPsec traffic <!-- At the time this extension was being developed, it was a consen sus in the IPsecME WG that it was the IPsec traffic
that mostly needed to be protected. --> It was believed that informa tion transferred over IKE SA (including peers' identities) is less important that mostly needed to be protected. --> It was believed that informa tion transferred over IKE SA (including peers' identities) is less important
and extending the protection to also cover initial IKE SA would requ ire serious modifications to core IKEv2 protocol. and that extending the protection to also cover the initial IKE SA w ould require serious modifications to the 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 <t> The USE_PPK_INT is a Status Type IKEv2 notification. Its Notify Mess
Message Type age Type
is &lt;TBA1 by IANA&gt;, Protocol ID and SPI Size are both set t is 16445; the Protocol ID and Security Parameter Index (SPI) Siz
o 0. e are both set to 0.
This specification does not define any data that this notificati on may contain, 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. 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 Implementations <bcp14>MUST</bcp14> ignore any data in the notif
ication they do not understand. ication that they do not understand.
</t> </t>
<t> Note that this negotiation is independent from the negotiation of us
<t> Note that this negotiation is independent from negotiation of us ing PPKs as specified in <xref target="RFC8784"/>.
ing PPKs as specified in <xref target="RFC8784" />. An initiator that supports both the use of PPKs in IKE_AUTH <xref ta
An initiator that supports both the use of PPKs in IKE_AUTH <xref ta rget="RFC8784"/> and IKE_INTERMEDIATE <bcp14>MAY</bcp14> include both
rget="RFC8784" /> and in IKE_INTERMEDIATE <bcp14>MAY</bcp14> include both the USE_PPK_INT and USE_PPK notifications if
the USE_PPK_INT and the USE_PPK notifications if configured to do so. However, if the responder supports both specifi
configured to so. However, if the responder supports both specificat cations
ions and is configured to use PPKs, it has to choose one to use; thus, it
and is configured to use PPKs, it has to choose one to use, thus it <bcp14>MUST</bcp14> return
<bcp14>MUST</bcp14> return either a USE_PPK_INT or a USE_PPK notification in the response but n
either USE_PPK_INT or USE_PPK notification in the response, but not ot both.
both. </t>
</t> <t> If the initiator did not propose using this extension in the IKE_SA_
INIT request and the responder's policy
<t> If the initiator did not propose using this extension in the IKE
_SA_INIT request and 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 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
length of PPK_ID by subtracting 8 (the length of PPK Confirmation)
from the Notification Data length.</dd>
<dt>PPK Confirmation (8 octets):</dt><dd><t>A value that allows the
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_I
DENTITY_KEY notification(s)
<bcp14>MUST</bcp14> be sent in the last one, i.e., in the IKE_INTERM
EDIATE exchange immediately preceding the IKE_AUTH exchange.
If the last IKE_INTERMEDIATE exchange contains other payloads aimed for some other purpose, If the last IKE_INTERMEDIATE exchange contains other payloads aimed for some other purpose,
then the notification(s) <bcp14>MAY</bcp14> be piggybacked with thes e payloads. then the notification(s) <bcp14>MAY</bcp14> be piggybacked with thes e payloads.
<figure align="center"> </t>
<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
Original:
1. If the responder is configured with one of the PPKs which IDs
were sent by the initiator and this PPK matches the initiator's
one (based on the information from the PPK Confirmation field),
then the responder selects this PPK and returns back its identity
in the PPK_IDENTITY notification.
Perhaps:
1. If the responder is configured with a PPK that was 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.
b) Section 3.1:
Original
2. If the responder does not have any of the PPKs 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 using PPK is
mandatory for the responder, then it MUST return
AUTHENTICATION_FAILED notification and abort creating the IKE SA.
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.
c) Section 3.2:
Original:
In case the responder does not support (or is not configured for)
using 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 PPKs, 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 [RFC7296].
Perhaps:
If the responder does not support (or is not configured for)
using PPKs in the CREATE_CHILD_SA exchange or does not have any of
the PPKs that were among the IDs sent by the initiator, or if the
responder has some of proposed PPKs but their values are mismatched
from the initiator's PPKs (based on the information from the PPK
Confirmation field), then it does not include any PPK_IDENTITY
notifications in the response, and new SA is created as defined in
IKEv2 [RFC7296].
d) Section 3.2:
Original:
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 request or the responder does not have any of the PPKs which IDs
were sent by the initiator, or it has some of proposed PPKs, but
their values mismatch the initiator's ones (based on the information
from the PPK Confirmation field), then the responder MUST return the
NO_PROPOSAL_CHOSEN notification.
Perhaps:
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 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 one of the PPKs
which IDs were sent by the initiator and this PPK matches the init iator's one 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 --> <!-- 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 (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 and returns back its identity in the PPK_IDENTITY notification. Th e PPK_IDENTITY notification
is defined in <xref target="RFC8784" />. is defined in <xref target="RFC8784"/>.
</t>
<figure align="center"> <artwork align="left"><![CDATA[
<artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
--------------------------------------------------------------- ---------------------------------------------------------------
<--- HDR, SK { ... N(PPK_IDENTITY, PPK_ID_i)} <--- HDR, SK { ... N(PPK_IDENTITY, PPK_ID_i)}]]></artwork>
]]></artwork> <t>
</figure> In this case, the IKE_AUTH exchange is performed as defined in IKE
v2 <xref target="RFC7296"/>.
In this case the IKE_AUTH exchange is performed as defined in IKEv However, the keys for the IKE SA are computed using PPK, as descri
2 <xref target="RFC7296" />. bed in <xref target="init_keys"/>.
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 If the responder returns a PPK identity that was not proposed by t he initiator, then the initiator
<bcp14>MUST</bcp14> treat this as a fatal and abort the IKE SA est <bcp14>MUST</bcp14> treat this as fatal and abort the IKE SA estab
ablishment. lishment.
</li> </t>
</li>
<li anchor="case2"> If the responder does not have any of the PPKs <li anchor="case2">
which IDs were sent by the initiator <t> If the responder does not have any of the PPKs which IDs were se
or it has some of the proposed PPKs, but their values mismatch the nt by the initiator,
initiator's ones or if it has some of the proposed PPKs but their values mismatch t
he initiator's ones
(based on the information from the PPK Confirmation field), and us ing PPK is mandatory for the responder, (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. then it <bcp14>MUST</bcp14> return AUTHENTICATION_FAILED notificat ion and abort creating the IKE SA.
</t>
<figure align="center"> <artwork align="left"><![CDATA[
<artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
--------------------------------------------------------------- ---------------------------------------------------------------
<--- HDR, SK {... N(AUTHENTICATION_FAILED)} <--- HDR, SK {... N(AUTHENTICATION_FAILED)}]]></artwork>
]]></artwork> </li>
</figure> <li anchor="case3">
<t> <!-- If the responder does not have any of the PPKs which IDs we
</li> re sent by the initiator -->
If the responder does not have any PPKs proposed by the initiator,
<li anchor="case3"> <!-- If the responder does not have any of the or if it has only some of the proposed PPKs but their values misma
PPKs which IDs were sent by the initiator --> tch the initiator's ones
If the responder does not have any PPKs proposed by the initiator (based on the information from the PPK Confirmation field), and if
or it has some of the proposed PPKs, but their values mismatch the using PPK is optional for the responder,
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. then it does not include any PPK_IDENTITY notification to the resp onse.
</t>
<figure align="center"> <artwork align="left"><![CDATA[
<artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
--------------------------------------------------------------- ---------------------------------------------------------------
<--- HDR, SK {...} <--- HDR, SK {...}]]></artwork>
]]></artwork> <t>
</figure> In this case, the initiator cannot achieve quantum computer resist
ance using the proposed PPKs.
In this case the initiator cannot achieve quantum computer resista
nce using the proposed PPKs.
If this is a requirement for the initiator, then it <bcp14>MUST</b cp14> abort creating the IKE SA. 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 Otherwise, the initiator continues with the IKE_AUTH exchange as d
escribed in IKEv2 <xref target="RFC7296" />. escribed in IKEv2 <xref target="RFC7296"/>.
</li>
</ol>
<t><xref target="responders_behavior"/> summarizes the above logic f
or the responder:
</t> </t>
</li>
<table title="Responder's behavior" anchor="responders_behavior"> </ol>
<thead> <t><xref target="responders_behavior"/> summarizes the above logic for t
<tr> he responder:</t>
<th>Received USE_PPK_INT</th> <table anchor="responders_behavior">
<th>Supports USE_PPK_INT</th> <name>Responder's Behavior</name>
<th>Has one of proposed PPKs</th> <thead>
<th>PPK is mandatory for initial IKE SA</th> <tr>
<th>Action</th> <th>Received USE_PPK_INT</th>
</tr> <th>Supports USE_PPK_INT</th>
</thead> <th>Has one of the proposed PPKs</th>
<tbody> <th>PPK is mandatory for initial IKE SA</th>
<tr> <th>Action</th>
<td>No</td> </tr>
<td>*</td> </thead>
<td>*</td> <tbody>
<td>No</td> <tr>
<td><xref target="RFC8784" /> (if proposed) or standard IKEv2 <td>No</td>
protocol</td> <td>*</td>
</tr> <td>*</td>
<tr> <td>No</td>
<td>No</td> <td>
<td>Yes</td> <xref target="RFC8784"/> (if proposed) or standard IKEv2 protoco
<td>*</td> l</td>
<td>Yes</td> </tr>
<td>Send NO_PROPOSAL_CHOSEN</td> <tr>
</tr> <td>No</td>
<tr> <td>Yes</td>
<td>Yes</td> <td>*</td>
<td>Yes</td> <td>Yes</td>
<td>Yes</td> <td>Send NO_PROPOSAL_CHOSEN</td>
<td>*</td> </tr>
<td><xref target="case1"/> (use this extension)</td> <tr>
</tr> <td>Yes</td>
<tr> <td>Yes</td>
<td>Yes</td> <td>Yes</td>
<td>Yes</td> <td>*</td>
<td>No</td> <td>
<td>Yes</td> <xref target="case1"/> (use this extension)</td>
<td><xref target="case2"/> (abort negotiation)</td> </tr>
</tr> <tr>
<tr> <td>Yes</td>
<td>Yes</td> <td>Yes</td>
<td>Yes</td> <td>No</td>
<td>No</td> <td>Yes</td>
<td>No</td> <td>
<td><xref target="case3"/> (standard IKEv2 protocol)</td> <xref target="case2"/> (abort negotiation)</td>
</tr> </tr>
</tbody> <tr>
</table> <td>Yes</td>
<td>Yes</td>
<t> Since the responder selects a PPK before it knows the identity o <td>No</td>
f the initiator, a situation may occur, <td>No</td>
when the responder agrees to use some PPK in the IKE_INTERMEDIATE ex <td>
change, but during the IKE_AUTH exchange <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 last IKE_INTERMEDIATE exchange,
ge, the IKE SA keys are recalculated. the IKE SA keys are recalculated.
Note that if the IKE SA keys are also recalculated as the result o f the other actions performed in the IKE_INTERMEDIATE exchange Note that if the IKE SA keys are also recalculated as the result o f the other actions performed in the IKE_INTERMEDIATE exchange
(for example, as defined in <xref target= "RFC9370" />), then appl (for example, as defined in <xref target="RFC9370"/>), then applyi
ying the PPK ng the PPK
<bcp14>MUST</bcp14> be done after all of them, so that recalculati <bcp14>MUST</bcp14> be done after all of them so that recalculatin
ng IKE SA keys with the PPK g IKE SA keys with the PPK
is the last action before they are used in the IKE_AUTH exchange. is the last action before they are used in the IKE_AUTH exchange.
</t> </t>
<t> The IKE SA keys are computed differently compared to how PPKs are
used in IKE_AUTH.
<t> The IKE SA keys are computed differently compared to how PPKs <!--[rfced] Is the use of the apostrophe in "SKEYSEED'" correct? We
are used in IKE_AUTH. ask as only "SKEYSEED" appears in RFCs 7296 and 8784. We note
that there are five instances in this document.
One example
Original:
A new SKEYSEED' value is computed using the
negotiated PPK and the most recently computed
SK_d key.
-->
A new SKEYSEED' value is computed using the negotiated PPK and the most recently computed SK_d key. A new SKEYSEED' value is computed using the negotiated PPK and the most recently computed SK_d key.
Note that the PPK is applied to SK_d exactly how it is specified i n <xref target="RFC8784" />, Note that the PPK is applied to SK_d exactly how it is specified i n <xref target="RFC8784"/>,
and the result is used as SKEYSEED'. and the result is used as SKEYSEED'.
<figure align="center"> </t>
<artwork align="left"><![CDATA[ <artwork align="left"><![CDATA[
SKEYSEED' = prf+ (PPK, SK_d) SKEYSEED' = prf+ (PPK, SK_d)]]></artwork>
]]></artwork> <t>
</figure>
Then the SKEYSEED' is used to recalculate all SK_* keys as defined in Section 2.14 of <xref target="RFC7296" />. Then the SKEYSEED' is used to recalculate all SK_* keys as defined in <xref target="RFC7296" section="2.14"/>.
<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> <t>
In case the responder does not support (or is not configured for) us 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 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 which IDs were sent by the initiator, or if it has some of proposed
s, but their values mismatch the initiator's ones PPKs but their values mismatch the initiator's PPKs
(based on the information from the PPK Confirmation field), then it does not include any PPK_IDENTITY notification in the response (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, and a new SA is created as defined in IKEv2 <xref target="RFC7296"/> . If this is inappropriate for the initiator,
it can immediately delete this SA. it can immediately delete this SA.
</t> </t>
<t> If using PPKs in CREATE_CHILD_SA is mandatory for the responder, and
<t> If using PPKs in CREATE_CHILD_SA is mandatory for the responder the initiator does not include any PPK_IDENTITY_KEY notifications in the reques
and the initiator does not include any PPK_IDENTITY_KEY notification in the requ t,
est or if the responder does not have any of the PPKs which IDs were sen
or the responder does not have any of the PPKs which IDs were sent b t by the initiator, or it has some of proposed PPKs but their values mismatch
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 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. notification.
</t> </t>
<t> Otherwise, the new SA is created using the selected PPK.
<t> Otherwise the new SA is created using the selected PPK. </t>
</t> <section anchor="create_child_sa_keys">
<name>Computing Keys</name>
<section anchor="create_child_sa_keys" title="Computing Keys"> <t> For the purpose of calculation session keys for the new SA, the cu
<t> For the purpose of calculation session keys for the new SA, th rrent SK_d key is first
e current 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 <!-- [rfced] We're having trouble parsing "impact of appearing a CRQC
mpact to". Is "appearing" the preferred term, or could this sentence be
of appearing a CRQC to various cryptographic primitives used in IKEv rephrased as shown below for clarity?
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"> Original:
<t>This document defines two new Notify Message Types in the "IKEv2 Section 4 of [RFC9370] discusses the potential impact of appearing a
Notify Message Status Types" registry:</t> CRQC to various cryptographic primitives used in IKEv2.
<figure align="center">
<artwork align="left"><![CDATA[
<TBA1> USE_PPK_INT
<TBA2> PPK_IDENTITY_KEY
]]></artwork>
</figure>
</section>
<section title="Acknowledgements" anchor="acknowledgements"> Perhaps:
<t> Author would like to thank Paul Wouters for valuable comments an Section 4 of [RFC9370] discusses the potential impact of when a
d Tero Kivinen CRQC is accessible to various cryptographic primitives used in IKEv2.
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 appearing a CRQC to various cryptographic primitives used in IKEv
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. 2.
RFC.2119.xml" ?> It is worthwhile to repeat here that it is believed that the securit
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. y of symmetric
RFC.8174.xml" ?> key cryptographic primitives will not be affected by CRQC.
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. </t>
RFC.7296.xml" ?> </section>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <section anchor="iana">
RFC.8784.xml" ?> <name>IANA Considerations</name>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference. <t>Per this document, IANA has added the following Notify Message Types in
RFC.9242.xml" ?> the "IKEv2 Notify Message Status Types" registry:</t>
</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>
<!-- [rfced] Some author comments are present in the XML. Please confirm that
no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication.
-->
<!-- [rfced] FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Security Parameter Index (SPI)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back>
</rfc> </rfc>
 End of changes. 84 change blocks. 
534 lines changed or deleted 674 lines changed or added

This html diff was produced by rfcdiff 1.48.