rfc8784xml2.original.xml   rfc8784.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC4648 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4648.xml">
<!ENTITY RFC2409 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2409.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3552.xml">
<!ENTITY RFC8126 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8126.xml">
<!ENTITY RFC6023 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6023.xml">
<!ENTITY RFC6030 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6030.xml">
<!ENTITY RFC7296 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7296.xml">
<!ENTITY RFC7619 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7619.xml">
<!ENTITY RFC8019 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8019.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-ipsecme-qr-ikev2-11" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="Mixing PSK in IKEv2 for PQ Resistance">Mixing Preshared Keys
in IKEv2 for Post-quantum Security</title>
<!-- add 'role="editor"' below for the editors if appropriate --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
docName="draft-ietf-ipsecme-qr-ikev2-11" number="8784" ipr="trust200902" ob
soletes=""
updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
tocDepth="4" symRefs="true" sortRefs="true" consensus="true" version="3">
<!-- Another author who claims to be an editor --> <!-- xml2rfc v2v3 conversion 2.41.0 -->
<author fullname="Scott Fluhrer" initials="S.F." <front>
surname="Fluhrer"> <title abbrev="Mixing PSKs in IKEv2 for PQ Security">Mixing Preshared
Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for
Post-quantum Security</title>
<seriesInfo name="RFC" value="8784"/>
<author fullname="Scott Fluhrer" initials="S." surname="Fluhrer">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<email>sfluhrer@cisco.com</email> <email>sfluhrer@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Panos Kampanakis" initials="P.K." <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
surname="Kampanakis">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<email>pkampana@cisco.com</email> <email>pkampana@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="David McGrew" initials="D.M." <author fullname="David McGrew" initials="D." surname="McGrew">
surname="McGrew">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<email>mcgrew@cisco.com</email> <email>mcgrew@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Valery Smyslov" initials="V.S." <author fullname="Valery Smyslov" initials="V." surname="Smyslov">
surname="Smyslov">
<organization>ELVIS-PLUS</organization> <organization>ELVIS-PLUS</organization>
<address> <address>
<phone>+7 495 276 0211</phone> <phone>+7 495 276 0211</phone>
<email>svan@elvis.ru</email> <email>svan@elvis.ru</email>
</address> </address>
</author> </author>
<date /> <date month="June" year="2020"/>
<!-- Meta-data Declarations -->
<area>Security</area> <area>Security</area>
<workgroup>Internet Engineering Task Force</workgroup> <workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<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>quantum secure</keyword> <keyword>quantum secure</keyword>
<keyword>quantum resistant</keyword> <keyword>quantum resistant</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>The possibility of quantum computers poses a serious challenge to crypt
ographic algorithms deployed widely today. <t>The possibility of quantum computers poses a serious challenge to
IKEv2 is one example of a cryptosystem that could be broken; cryptographic algorithms deployed widely today. The Internet Key Exchange
someone storing VPN communications today could decrypt them at a later Protocol Version 2 (IKEv2) is one example of a cryptosystem that could
time when a quantum computer is available. be broken; someone storing VPN communications today could decrypt them
It is anticipated that IKEv2 will be extended to support quantum-secure ke at a later time when a quantum computer is available. It is anticipated
y exchange that IKEv2 will be extended to support quantum-secure key exchange
algorithms; however that is not likely to happen in the near term. algorithms; however, that is not likely to happen in the near term. To
To address this problem before then, this document describes an extension address this problem before then, this document describes an extension
of IKEv2 of IKEv2 to allow it to be resistant to a quantum computer by using
to allow it to be resistant to a quantum computer, by using preshared keys preshared keys.</t>
.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>Recent achievements in developing quantum computers demonstrate that it <name>Introduction</name>
is probably feasible
to build a cryptographically significant one. If such a computer is implem
ented, many of the cryptographic algorithms
and protocols currently in use would be insecure. A quantum computer woul
d be able to solve DH and ECDH problems
in polynomial time <xref target="I-D.hoffman-c2pq"/>, and this would imply
that the security
of existing IKEv2 <xref target="RFC7296"/> systems would be compromised.
IKEv1 <xref target="RFC2409"/>, when used with strong preshared keys, is not
vulnerable to quantum attacks, because those keys are one of the inputs to
the key derivation function.
If the preshared key has sufficient entropy and the PRF, encryption and au
thentication transforms are quantum-secure, then the
resulting system is believed to be quantum-secure, that is, secure against
classical attackers of today or future attackers with a quantum computer.</t>
<t>Recent achievements in developing quantum computers demonstrate that
it is probably feasible to build one that is cryptographically significant
. If
such a computer is implemented, many of the cryptographic algorithms and
protocols currently in use would be insecure. A quantum computer would
be able to solve Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman
(ECDH) problems in polynomial time <xref target="I-D.hoffman-c2pq"
format="default"/>, and this would imply that the security of existing
IKEv2 <xref target="RFC7296" format="default"/> systems would be
compromised. IKEv1 <xref
target="RFC2409" format="default"/>, when used with strong preshared
keys, is not vulnerable to quantum attacks because those keys are one of
the inputs to the key derivation function. If the preshared key has
sufficient entropy and the Pseudorandom Function (PRF), encryption, and au
thentication
transforms are quantum secure, then the resulting system is believed to
be quantum secure -- that is, secure against classical attackers of
today or future attackers with a quantum computer.</t>
<t>This document describes a way to extend IKEv2 to have a similar <t>This document describes a way to extend IKEv2 to have a similar
property; assuming that the two end systems share a long secret key, property; assuming that the two end systems share a long secret key,
then the resulting exchange is quantum-secure. then the
resulting exchange is quantum secure.
By bringing post-quantum security to IKEv2, this document removes the need By bringing post-quantum security to IKEv2, this document removes the need
to use an obsolete version of the Internet Key Exchange in order to achiev e to use an obsolete version of IKE in order to achieve
that security goal.</t> that security goal.</t>
<t>The general idea is that we add an additional secret that is shared <t>The general idea is that we add an additional secret that is shared
between the initiator and the responder; this secret is in addition between the initiator and the responder; this secret is in addition to
to the authentication method that is already provided within IKEv2. the authentication method that is already provided within IKEv2. We
We stir this secret into the SK_d value, which is used to generate the key stir this secret into the SK_d value, which is used to generate the key
material material (KEYMAT) for the Child Security Associations (SAs) and the
(KEYMAT) and the SKEYSEED for the child SAs; this secret provides quantum SKEYSEED for the IKE SAs created as a result
resistance to the IPsec SAs (and any child IKE SAs). We also stir the secr of the initial IKE SA rekey. This secret provides quantum resistance to
et the IPsec SAs and any subsequent IKE SAs. We also stir the secret into the
into the SK_pi, SK_pr values; this allows both sides to detect a secret mi SK_pi and SK_pr values;
smatch cleanly.</t> this allows both sides to detect a secret mismatch cleanly.</t>
<t>It was considered important to minimize the changes to IKEv2. <t>It was considered important to minimize the changes to IKEv2.
The existing mechanisms to do authentication and key exchange remain The existing mechanisms to perform authentication and key exchange remain
in place (that is, we continue to do (EC)DH, and potentially PKI in place (that is, we continue to perform (EC)DH and potentially PKI
authentication if configured). This document does not replace the authenti cation authentication if configured). This document does not replace the authenti cation
checks that the protocol does; instead, they are checks that the protocol does; instead, they are
strengthened by using an additional secret key.</t> strengthened by using an additional secret key.</t>
<section numbered="true" toc="default">
<section title="Changes"> <name>Requirements Language</name>
<t>RFC EDITOR PLEASE DELETE THIS SECTION.</t> <t>
<t>Changes in this draft in each version iterations.</t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<t>draft-ietf-ipsecme-qr-ikev2-11 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
<list style="symbols"> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t>Updates the IANA section based on Eric V.'s IESG Review.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<t>Updates based on IESG Reviews (Alissa, Adam, Barry, Alexey, be interpreted as
Mijra, Roman, Martin.</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</list></t> when, and only when, they appear in all capitals, as shown here.
</t>
<t>draft-ietf-ipsecme-qr-ikev2-10
<list style="symbols">
<t>Addresses issues raised during IETF LC.</t>
</list></t>
<t>draft-ietf-ipsecme-qr-ikev2-09
<list style="symbols">
<t>Addresses issues raised in AD review.</t>
</list></t>
<t>draft-ietf-ipsecme-qr-ikev2-08
<list style="symbols">
<t>Editorial changes.</t>
</list></t>
<t>draft-ietf-ipsecme-qr-ikev2-07
<list style="symbols">
<t>Editorial changes.</t>
</list></t>
<t>draft-ietf-ipsecme-qr-ikev2-06
<list style="symbols">
<t>Editorial changes.</t>
</list></t>
<t>draft-ietf-ipsecme-qr-ikev2-05
<list style="symbols">
<t>Addressed comments received during WGLC.</t>
</list></t>
<t>draft-ietf-ipsecme-qr-ikev2-04
<list style="symbols">
<t>Using Group PPK is clarified based on comment from Quynh Dang.</t>
</list></t>
<t>draft-ietf-ipsecme-qr-ikev2-03
<list style="symbols">
<t>Editorial changes and minor text nit fixes.</t>
<t>Integrated Tommy P. text suggestions.</t>
</list></t>
<t>draft-ietf-ipsecme-qr-ikev2-02
<list style="symbols">
<t>Added note that the PPK is stirred in the initial IKE SA set
up only. </t>
<t>Added note about the initiator ignoring any content in the P
PK_IDENTITY notification from the responder.</t>
<t>fixed Tero's suggestions from 2/6/1028</t>
<t>Added IANA assigned message types where necessary.</t>
<t>fixed minor text nits </t>
</list></t>
<t>draft-ietf-ipsecme-qr-ikev2-01
<list style="symbols">
<t>Nits and minor fixes. </t>
<t>prf is replaced with prf+ for the SK_d and SK_pi/r calculati
ons.</t>
<t>Clarified using PPK in case of EAP authentication.</t>
<t>PPK_SUPPORT notification is changed to USE_PPK to better reflect it
s purpose.</t>
</list></t>
<t>draft-ietf-ipsecme-qr-ikev2-00
<list style="symbols">
<t>Migrated from draft-fluhrer-qr-ikev2-05 to draft-ietf-ipsecme-qr-ik
ev2-00 that is a WG item.</t>
</list></t>
<t>draft-fluhrer-qr-ikev2-05
<list style="symbols">
<t>Nits and editorial fixes.</t>
<t>Made PPK_ID format and PPK Distributions subsection of the PPK sect
ion. Also added an Operational Considerations section.</t>
<t>Added comment about Child SA rekey in the Security Considera
tions section.</t>
<t>Added NO_PPK_AUTH to solve the cases where a PPK_ID is not c
onfigured for a responder.</t>
<t>Various text changes and clarifications.</t>
<t>Expanded Security Considerations section to describe some se
curity concerns and how they should be addressed.</t>
</list></t>
<t>draft-fluhrer-qr-ikev2-03
<list style="symbols">
<t>Modified how we stir the PPK into the IKEv2 secret state.</t>
<t>Modified how the use of PPKs is negotiated.</t>
</list></t>
<t>draft-fluhrer-qr-ikev2-02
<list style="symbols">
<t>Simplified the protocol by stirring in the
preshared key into the child SAs; this avoids the problem of
having the responder decide which preshared key to use (as it
knows the initiator identity at that point); it does mean that
someone with a quantum computer can recover the initial IKE
negotiation.</t>
<t>Removed positive endorsements of various algorithms. Retained warni
ngs
about algorithms known to be weak against a quantum computer.</t>
</list></t>
<t>draft-fluhrer-qr-ikev2-01
<list style="symbols">
<t>Added explicit guidance as to what IKE and IPsec algorithms are qua
ntum resistant.</t>
</list></t>
<t>draft-fluhrer-qr-ikev2-00
<list style="symbols">
<t>We switched from using vendor ID's to transmit the additional data
to notifications.</t>
<t>We added a mandatory cookie exchange to allow the server to communi
cate to the client before the initial exchange.</t>
<t>We added algorithm agility by having the server tell the client wha
t algorithm to use in the cookie exchange.</t>
<t>We have the server specify the PPK Indicator Input, which allows
the server to make a trade-off between the efficiency for
the search of the clients PPK, and the anonymity of the client.</t>
<t>We now use the negotiated PRF (rather than a fixed HMAC-SHA256) to
transform the nonces during the KDF.</t>
</list></t>
</section>
<section title="Requirements Language">
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted
as described in BCP 14 <xref target="RFC2119" /> <xref target="RFC8174"
/> when, and only when,
they appear in all capitals, as shown here.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<name>Assumptions</name>
<section title="Assumptions"> <t> We assume that each IKE peer has a list of Post-quantum Preshared
<t>We assume that each IKE peer has a list of Post-quantum Preshared Keys Keys (PPKs) along with their identifiers (PPK_ID), and any potential IKE
(PPK) along with their identifiers (PPK_ID), initiator selects which PPK to use with any specific responder. In
and any potential IKE initiator selects which PPK to use with any specific addition, implementations have a configurable flag that determines
responder. whether this PPK is mandatory. This PPK is
In addition, implementations have a configurable flag that determines whet independent of the preshared key (if any) that the IKEv2 protocol uses
her this to perform authentication (because the preshared key in IKEv2 is not
post-quantum preshared key is mandatory. used for any key derivation and thus doesn't protect against quantum
This PPK is independent of the preshared key (if any) that the IKEv2 proto computers). The PPK-specific configuration that is assumed to be on
col uses to perform authentication each node consists of the following tuple:</t>
(because the preshared key in IKEv2 is not used for any key derivation, an <artwork align="left" name="" type="" alt=""><![CDATA[
d thus doesn't protect against quantum computers).
The PPK specific configuration that is assumed to be on each node consists
of the following tuple:</t>
<figure align="center">
<artwork align="left"><![CDATA[
Peer, PPK, PPK_ID, mandatory_or_not Peer, PPK, PPK_ID, mandatory_or_not
]]></artwork> ]]></artwork>
</figure> <t>We assume the reader is familiar with the payload notation defined in
</section> <xref target="RFC7296" sectionFormat="of" section="1.2"/>.</t>
</section>
<section anchor="Exchanges" title="Exchanges"> <section anchor="Exchanges" numbered="true" toc="default">
<t>If the initiator is configured to use a post-quantum preshared key with <name>Exchanges</name>
the responder (whether or not <t>If the initiator is configured to use a PPK with the responder (whether
the use of the PPK is mandatory), then it MUST include a notification USE_ or not
PPK in the IKE_SA_INIT request message as follows:</t> the use of the PPK is mandatory), then it <bcp14>MUST</bcp14> include a
notification USE_PPK in the IKE_SA_INIT request message as follows:</t>
<figure align="center"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
HDR, SAi1, KEi, Ni, N(USE_PPK) ---> HDR, SAi1, KEi, Ni, N(USE_PPK) --->
]]></artwork> ]]></artwork>
</figure>
<t>N(USE_PPK) is a status notification payload with the type 16435; <t>N(USE_PPK) is a status notification payload with the type 16435;
it has a protocol ID of 0, no SPI and no notification data associated with it has a protocol ID of 0, no Security Parameter Index (SPI), and no notif
it.</t> ication data associated with it.</t>
<t>If the initiator needs to resend this initial message with a COOKIE not ification, then the resend would include the USE_PPK notification <t>If the initiator needs to resend this initial message with a COOKIE not ification, then the resend would include the USE_PPK notification
if the original message did (see Section 2.6 of <xref target="RFC7296" />) if the original message did (see <xref target="RFC7296"
.</t> sectionFormat="of" section="2.6"/>).</t>
<t>If the responder does not support this specification or does not have a ny PPK configured, <t>If the responder does not support this specification or does not have a ny PPK configured,
then it ignores the received notification (as defined in <xref target="RFC 7296" /> for unknown status notifications) then it ignores the received notification (as defined in <xref target="RFC 7296" format="default"/> for unknown status notifications)
and continues with the IKEv2 protocol as normal. and continues with the IKEv2 protocol as normal.
Otherwise the responder replies with the IKE_SA_INIT message including a U Otherwise, the responder replies with the IKE_SA_INIT message, including a
SE_PPK notification in the response:</t> USE_PPK notification in the response:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[
<figure align="center">
<artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
<--- HDR, SAr1, KEr, Nr, [CERTREQ,] N(USE_PPK) <--- HDR, SAr1, KEr, Nr, [CERTREQ,] N(USE_PPK)
]]></artwork> ]]></artwork>
</figure>
<t>When the initiator receives this reply, it checks whether the responder included the USE_PPK notification. <t>When the initiator receives this reply, it checks whether the responder included the USE_PPK notification.
If the responder did not and the flag mandatory_or_not indicates that usin If the responder did not include the USE_PPK notification and the flag man
g PPKs is mandatory for communication with this responder, datory_or_not indicates that using PPKs is mandatory for communication with this
then the initiator MUST abort the exchange. This situation may happen in c responder,
ase of misconfiguration, then the initiator <bcp14>MUST</bcp14> abort the exchange. This
when the initiator believes it has a mandatory-to-use PPK for the responde situation may happen in case of misconfiguration, i.e., when the
r, while the responder either doesn't support initiator believes it has a mandatory-to-use PPK for the responder and the
PPKs at all or doesn't have any PPK configured for the initiator. See <xre responder either doesn't support
f target="Security"/> for discussion PPKs at all or doesn't have any PPK configured for the initiator. See <xre
f target="Security" format="default"/> for discussion
of the possible impacts of this situation.</t> of the possible impacts of this situation.</t>
<t>If the responder did not include the USE_PPK notification and using a P PK for this particular responder is optional, <t>If the responder did not include the USE_PPK notification and using a P PK for this particular responder is optional,
then the initiator continues with the IKEv2 protocol as normal, without us ing PPKs.</t> then the initiator continues with the IKEv2 protocol as normal, without us ing PPKs.</t>
<t>If the responder did include the USE_PPK notification, then the initiat or selects a PPK, along with its <t>If the responder did include the USE_PPK notification, then the initiat or selects a PPK, along with its
identifier PPK_ID. Then, it computes this modification of the standard IKE identifier PPK_ID. Then, it computes this modification of the standard
v2 key derivation from Section 2.14 of <xref target="RFC7296" />:</t> IKEv2 key derivation from <xref target="RFC7296"
sectionFormat="of" section="2.14"/>:</t>
<figure align="center"> <sourcecode name="" type="pseudocode"><![CDATA[
<artwork align="left"><![CDATA[
SKEYSEED = prf(Ni | Nr, g^ir) SKEYSEED = prf(Ni | Nr, g^ir)
{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)
SK_d = prf+ (PPK, SK_d') SK_d = prf+ (PPK, SK_d')
SK_pi = prf+ (PPK, SK_pi') SK_pi = prf+ (PPK, SK_pi')
SK_pr = prf+ (PPK, SK_pr') SK_pr = prf+ (PPK, SK_pr')
]]></artwork> ]]></sourcecode>
</figure> <t> That is, we use the standard IKEv2 key derivation process, except
that the three resulting subkeys SK_d, SK_pi, and SK_pr
<t> That is, we use the standard IKEv2 key derivation process except that
the three resulting subkeys SK_d, SK_pi, SK_pr
(marked with primes in the formula above) are then run through the prf+ ag ain, this time using the PPK as the key. (marked with primes in the formula above) are then run through the prf+ ag ain, this time using the PPK as the key.
The result is the unprimed versions of these keys which are then used as i nputs to subsequent steps of the The result is the unprimed versions of these keys, which are then used as inputs to subsequent steps of the
IKEv2 exchange.</t> IKEv2 exchange.</t>
<t> Using a prf+ construction ensures that it is always possible to get
<t> Using a prf+ construction ensures that it is always possible to get th the resulting keys of the same size as the initial ones, even if the
e resulting keys of the same size as the initial ones, underlying PRF has an output size different from its key size. Note that
even if the underlying PRF has output size different from its key size. No at the time of this writing, all PRFs defined for use in IKEv2 (see the
te, that at the time of this writing, all "Transform Type 2 - Pseudorandom Function Transform IDs" subregistry
PRFs defined for use in IKEv2 <xref target="IKEV2-IANA-PRFS" /> had output <xref target="IANA-IKEV2" format="default"/>) have an output size equal to the (
size equal to the (preferred) key size. preferred) key size. For such PRFs, only the first
For such PRFs only the first iteration of prf+ is needed: </t> iteration of prf+ is needed: </t>
<sourcecode name="" type="pseudocode"><![CDATA[
<figure align="center">
<artwork align="left"><![CDATA[
SK_d = prf (PPK, SK_d' | 0x01) SK_d = prf (PPK, SK_d' | 0x01)
SK_pi = prf (PPK, SK_pi' | 0x01) SK_pi = prf (PPK, SK_pi' | 0x01)
SK_pr = prf (PPK, SK_pr' | 0x01) SK_pr = prf (PPK, SK_pr' | 0x01)
]]></artwork> ]]></sourcecode>
</figure> <t>Note that the PPK is used in SK_d, SK_pi, and SK_pr calculations only
during the initial IKE SA setup. It <bcp14>MUST NOT</bcp14> be used when
<t>Note that the PPK is used in SK_d, SK_pi and SK_pr calculation only these subkeys
during the initial IKE SA setup. It MUST NOT be used when these subkeys are calculated as result of IKE SA rekey, resumption, or other similar
are calculated as result of IKE SA rekey, resumption or other similar operations.</t>
operation.</t>
<t>The initiator then sends the IKE_AUTH request message, including the PP K_ID value as follows:</t> <t>The initiator then sends the IKE_AUTH request message, including the PP K_ID value as follows:</t>
<figure align="center">
<artwork align="left"><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,] HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, [IDr,] AUTH, SAi2,
TSi, TSr, N(PPK_IDENTITY, PPK_ID), [N(NO_PPK_AUTH)]} ---> TSi, TSr, N(PPK_IDENTITY, PPK_ID), [N(NO_PPK_AUTH)]} --->
]]></artwork> ]]></artwork>
</figure>
<t>PPK_IDENTITY is a status notification with the type 16436; <t>PPK_IDENTITY is a status notification with the type 16436;
it has a protocol ID of 0, no SPI and a notification data that consists of the identifier PPK_ID.</t> it has a protocol ID of 0, no SPI, and notification data that consists of the identifier PPK_ID.</t>
<t>A situation may happen when the responder has some PPKs, but doesn't ha <t>A situation may happen when the responder has some PPKs but doesn't hav
ve a PPK with the PPK_ID received e a PPK with the PPK_ID received
from the initiator. In this case the responder cannot continue with PPK (i from the initiator. In this case, the responder cannot continue with the
n particular, it cannot PPK (in particular, it cannot
authenticate the initiator), but the responder could be able to continue w authenticate the initiator), but the responder could be able to continue
ith normal IKEv2 protocol if the initiator with the normal IKEv2 protocol if the initiator
provided its authentication data computed as in normal IKEv2, without usin provided its authentication data computed as in the normal IKEv2 without u
g PPKs. For this purpose, sing PPKs. For this purpose,
if using PPKs for communication with this responder is optional for the in itiator (based on the mandatory_or_not flag), if using PPKs for communication with this responder is optional for the in itiator (based on the mandatory_or_not flag),
then the initiator MUST include a NO_PPK_AUTH notification in the above me then the initiator <bcp14>MUST</bcp14> include a NO_PPK_AUTH notification
ssage. This notification informs the responder in the above message. This notification informs the responder
that PPK is optional and allows for authenticating the initiator without u that PPKs are optional and allows for authenticating the initiator
sing PPK.</t> without using PPKs.</t>
<t>NO_PPK_AUTH is a status notification with the type 16437; it has a <t>NO_PPK_AUTH is a status notification with the type 16437; it has a
protocol ID of 0 and no SPI. The Notification Data field contains protocol ID of 0 and no SPI. The Notification Data field contains
the initiator's authentication data computed using SK_pi', which has the initiator's authentication data computed using SK_pi', which has
been computed without using PPKs. This is the same data that would been computed without using PPKs. This is the same data that would
normally be placed in the Authentication Data field of an AUTH payload. normally be placed in the Authentication Data field of an AUTH payload.
Since the Auth Method field is not present in the notification, the Since the Auth Method field is not present in the notification, the
authentication method used for computing the authentication data MUST authentication method used for computing the authentication data <bcp14>MU
be the same as method indicated in the AUTH payload. Note that if the ST</bcp14>
be the same as the method indicated in the AUTH payload. Note that if the
initiator decides to include the NO_PPK_AUTH notification, the initiator initiator decides to include the NO_PPK_AUTH notification, the initiator
needs to perform authentication data computation twice, which may needs to perform authentication data computation twice, which may
consume computation power (e.g., if digital signatures are involved).</t> consume computation power (e.g., if digital signatures are involved).</t>
<t>When the responder receives this encrypted exchange, it first computes the values:</t> <t>When the responder receives this encrypted exchange, it first computes the values:</t>
<sourcecode name="" type="pseudocode"><![CDATA[
<figure align="center">
<artwork align="left"><![CDATA[
SKEYSEED = prf(Ni | Nr, g^ir) SKEYSEED = prf(Ni | Nr, g^ir)
{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)
]]></artwork> ]]></sourcecode>
</figure>
<t>The responder then uses the SK_ei/SK_ai values to decrypt/check the mes sage and then scans through the payloads for the PPK_ID <t>The responder then uses the SK_ei/SK_ai values to decrypt/check the mes sage and then scans through the payloads for the PPK_ID
attached to the PPK_IDENTITY notification. If no PPK_IDENTITY notification is found and the peers successfully attached to the PPK_IDENTITY notification. If no PPK_IDENTITY notification is found and the peers successfully
exchanged USE_PPK notifications in the IKE_SA_INIT exchange, then the resp exchanged USE_PPK notifications in the IKE_SA_INIT exchange, then the
onder MUST send back AUTHENTICATION_FAILED responder <bcp14>MUST</bcp14> send back an AUTHENTICATION_FAILED
notification and then fail the negotiation.</t> notification and then fail the negotiation.</t>
<t>If the PPK_IDENTITY notification contains a PPK_ID that is not known to the responder or is not configured <t>If the PPK_IDENTITY notification contains a PPK_ID that is not known to the responder or is not configured
for use for the identity from IDi payload, then the responder checks wheth for use for the identity from the IDi payload, then the responder checks w
er using PPKs for this initiator is mandatory hether using PPKs for this initiator is mandatory
and whether the initiator included NO_PPK_AUTH notification in the message and whether the initiator included a NO_PPK_AUTH notification in the messa
. If using PPKs is mandatory or no NO_PPK_AUTH ge. If using PPKs is mandatory or no NO_PPK_AUTH
notification is found, then then the responder MUST send back AUTHENTICATI notification is found, then the responder <bcp14>MUST</bcp14> send
ON_FAILED notification and then fail the negotiation. back an AUTHENTICATION_FAILED notification and then fail the negotiation.
Otherwise (when PPK is optional and the initiator included NO_PPK_AUTH Otherwise (when a PPK is optional and the initiator included a NO_PPK_A
notification) the responder MAY UTH notification), the responder <bcp14>MAY</bcp14>
continue regular IKEv2 protocol, except that it uses the data from the NO_ continue the regular IKEv2 protocol, except that it uses the data from the
PPK_AUTH notification as the NO_PPK_AUTH notification as the
authentication data (which usually resides in the AUTH payload), for the p authentication data (which usually resides in the AUTH payload) for the pu
urpose of the initiator authentication. rpose of the initiator authentication.
Note, that Authentication Method is still indicated in the AUTH payload.</ Note that the authentication method is still indicated in the AUTH payload
t> .</t>
<t><xref target="table1"/> summarizes the above logic for the responder:</
<t>This table summarizes the above logic for the responder:</t> t>
<table align="left" anchor="table1">
<figure align="center"> <thead>
<artwork align="left"><![CDATA[ <tr>
Received Received Configured PPK is <th align="left">Received USE_PPK</th>
USE_PPK NO_PPK_AUTH with PPK Mandatory Action <th align="left">Received NO_PPK_AUTH</th>
No * No * Standard IKEv2 protocol <th align="left">Configured with PPK</th>
No * Yes No Standard IKEv2 protocol <th align="left">PPK is Mandatory</th>
No * Yes Yes Abort negotiation <th align="left">Action</th>
Yes No No * Abort negotiation </tr>
Yes Yes No Yes Abort negotiation </thead>
Yes Yes No No Standard IKEv2 protocol <tbody>
Yes * Yes * Use PPK <tr>
]]></artwork> <td align="left">No</td>
</figure> <td align="left">*</td>
<td align="left">No</td>
<t>If PPK is in use, then the responder extracts the corresponding PPK and <td align="left">*</td>
computes the following values:</t> <td align="left">Standard IKEv2 protocol</td>
</tr>
<figure align="center"> <tr>
<artwork align="left"><![CDATA[ <td align="left">No</td>
<td align="left">*</td>
<td align="left">Yes</td>
<td align="left">No</td>
<td align="left">Standard IKEv2 protocol</td>
</tr>
<tr>
<td align="left">No</td>
<td align="left">*</td>
<td align="left">Yes</td>
<td align="left">Yes</td>
<td align="left">Abort negotiation</td>
</tr>
<tr>
<td align="left">Yes</td>
<td align="left">No</td>
<td align="left">No</td>
<td align="left">*</td>
<td align="left">Abort negotiation</td>
</tr>
<tr>
<td align="left">Yes</td>
<td align="left">Yes</td>
<td align="left">No</td>
<td align="left">Yes</td>
<td align="left">Abort negotiation</td>
</tr>
<tr>
<td align="left">Yes</td>
<td align="left">Yes</td>
<td align="left">No</td>
<td align="left">No</td>
<td align="left">Standard IKEv2 protocol</td>
</tr>
<tr>
<td align="left">Yes</td>
<td align="left">*</td>
<td align="left">Yes</td>
<td align="left">*</td>
<td align="left">Use PPK</td>
</tr>
</tbody>
</table>
<t>If a PPK is in use, then the responder extracts the corresponding PPK a
nd computes the following values:</t>
<sourcecode name="" type="pseudocode"><![CDATA[
SK_d = prf+ (PPK, SK_d') SK_d = prf+ (PPK, SK_d')
SK_pi = prf+ (PPK, SK_pi') SK_pi = prf+ (PPK, SK_pi')
SK_pr = prf+ (PPK, SK_pr') SK_pr = prf+ (PPK, SK_pr')
]]></artwork> ]]></sourcecode>
</figure>
<t>The responder then continues with the IKE_AUTH exchange (validating the AUTH payload that the initiator included) as usual <t>The responder then continues with the IKE_AUTH exchange (validating the AUTH payload that the initiator included) as usual
and sends back a response, which includes the PPK_IDENTITY notification wi th no data to indicate that the PPK is and sends back a response, which includes the PPK_IDENTITY notification wi th no data to indicate that the PPK is
used in the exchange:</t> used in the exchange:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[
<figure align="center">
<artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
------------------------------------------------------------------ ------------------------------------------------------------------
<-- HDR, SK {IDr, [CERT,] <-- HDR, SK {IDr, [CERT,]
AUTH, SAr2, AUTH, SAr2,
TSi, TSr, N(PPK_IDENTITY)} TSi, TSr, N(PPK_IDENTITY)}
]]></artwork> ]]></artwork>
</figure>
<t>When the initiator receives the response, then it checks for the <t>When the initiator receives the response, it checks for the
presence of the PPK_IDENTITY notification. If it receives one, it presence of the PPK_IDENTITY notification. If it receives one, it
marks the SA as using the configured PPK to generate SK_d, SK_pi, marks the SA as using the configured PPK to generate SK_d, SK_pi, and
SK_pr (as shown above); the content of the received PPK_IDENTITY (if SK_pr (as shown above); the content of the received PPK_IDENTITY (if
any) MUST be ignored. If the initiator does not receive the any) <bcp14>MUST</bcp14> be ignored. If the initiator does not receive
PPK_IDENTITY, it MUST either fail the IKE SA negotiation sending the the
AUTHENTICATION_FAILED notification in the Informational exchange (if PPK_IDENTITY, it <bcp14>MUST</bcp14> either fail the IKE SA negotiation
the PPK was configured as mandatory), or continue without using the sending the
AUTHENTICATION_FAILED notification in the INFORMATIONAL exchange (if
the PPK was configured as mandatory) or continue without using the
PPK (if the PPK was not configured as mandatory and the initiator PPK (if the PPK was not configured as mandatory and the initiator
included the NO_PPK_AUTH notification in the request).</t> included the NO_PPK_AUTH notification in the request).</t>
<t>If the Extensible Authentication Protocol (EAP) is used in the IKE_AUTH
<t>If EAP is used in the IKE_AUTH exchange, then the initiator doesn't inc exchange, then the initiator doesn't
lude AUTH payload include the AUTH payload
in the first request message, however the responder sends back AUTH payloa in the first request message; however, the responder sends back the AUTH p
d in the first reply. ayload in the first reply.
The peers then exchange AUTH payloads after EAP is successfully completed. The peers then exchange AUTH payloads after EAP is successfully completed.
As a result, the responder sends AUTH payload twice - in the first IKE_AUT As a result, the responder sends the AUTH payload twice -- in the first
H reply message and and last IKE_AUTH reply message -- while the initiator sends the AUTH payl
in the last one, while the initiator sends AUTH payload only in the last I oad only in the last IKE_AUTH request.
KE_AUTH request. See more details about EAP authentication in IKEv2 in <xref target="RFC729
See more details about EAP authentication in IKEv2 in Section 2.16 of <xre 6" sectionFormat="of" section="2.16"/>.</t>
f target="RFC7296" />.</t> <t>The general rule for using a PPK in the IKE_AUTH exchange, which
covers the EAP authentication case too, is that the initiator includes a
<t>The general rule for using PPK in the IKE_AUTH exchange, which covers E PPK_IDENTITY (and optionally a NO_PPK_AUTH) notification in the request
AP authentication case too, message containing the AUTH payload. Therefore, in case of EAP, the
is that the initiator includes PPK_IDENTITY (and optionally NO_PPK_AUTH responder always computes the AUTH payload in the first IKE_AUTH reply
) notification in the request message without using a PPK (by means of SK_pr'), since PPK_ID is not
message containing AUTH payload. Therefore, in case of EAP the responde yet known to the responder. Once the IKE_AUTH request message containing
r always computes the AUTH the PPK_IDENTITY notification is received, the responder follows the
payload in the first IKE_AUTH reply message without using PPK (by means rules described above for the non-EAP authentication case. </t>
of SK_pr'), since PPK_ID is <artwork align="left" name="" type="" alt=""><![CDATA[
not yet known to the responder. Once the IKE_AUTH request message conta
ining the PPK_IDENTITY notification
is received, the responder follows the rules described above for the non-E
AP authentication case. </t>
<figure align="center">
<artwork align="left"><![CDATA[
Initiator Responder Initiator Responder
---------------------------------------------------------------- ----------------------------------------------------------------
HDR, SK {IDi, [CERTREQ,] HDR, SK {IDi, [CERTREQ,]
[IDr,] SAi2, [IDr,] SAi2,
TSi, TSr} --> TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH, <-- HDR, SK {IDr, [CERT,] AUTH,
EAP} EAP}
HDR, SK {EAP} --> HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)} <-- HDR, SK {EAP (success)}
HDR, SK {AUTH, HDR, SK {AUTH,
N(PPK_IDENTITY, PPK_ID) N(PPK_IDENTITY, PPK_ID)
[, N(NO_PPK_AUTH)]} --> [, N(NO_PPK_AUTH)]} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr <-- HDR, SK {AUTH, SAr2, TSi, TSr
[, N(PPK_IDENTITY)]} [, N(PPK_IDENTITY)]}
]]></artwork> ]]></artwork>
</figure>
<t>Note that the diagram above shows both the cases when the responder <t>Note that the diagram above shows both the cases when the responder
uses PPK uses a PPK and when it chooses not to use it (provided the initiator has
and when it chooses not to use it (provided the initiator has included NO_ included the NO_PPK_AUTH notification); thus, the responder's
PPK_AUTH notification), PPK_IDENTITY notification is marked as optional. Also, note that the
and thus the responder's PPK_IDENTITY notification is marked as optional. IKE_SA_INIT exchange using a PPK is as described above (including
Also, note that the IKE_SA_INIT exchange in case of PPK is as described ab exchange of the USE_PPK notifications), regardless of whether or not EAP i
ove (including exchange of s
the USE_PPK notifications), regardless whether EAP is employed in the I employed in the IKE_AUTH.</t>
KE_AUTH or not.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Upgrade procedure"> <name>Upgrade Procedure</name>
<t>This algorithm was designed so that someone can introduce PPKs into an existing IKE network <t>This algorithm was designed so that someone can introduce PPKs into an existing IKE network
without causing network disruption.</t> without causing network disruption.</t>
<t>In the initial phase of the network upgrade, the network administrator <t>In the initial phase of the network upgrade, the network administrator
would visit each IKE node, and configure: would visit each IKE node and configure:
<list style="symbols"> </t>
<t>The set of PPKs (and corresponding PPK_IDs) that this node wou <ul spacing="normal">
ld need to know.</t>
<t>For each peer that this node would initiate to, which PPK will be use <li>The set of PPKs (and corresponding PPK_IDs) that this node would nee
d.</t> d to know.</li>
<t>That the use of PPK is currently not mandatory.</t> <li>The PPK that will be used for each peer that this node would
</list></t> initiate to.</li>
<li>The value "false" for the mandatory_or_not flag for each peer
that this node would initiate to (thus indicating that the use of PPKs
is not mandatory).</li>
</ul>
<t>With this configuration, the node will continue to operate with nodes t hat have not yet been upgraded. <t>With this configuration, the node will continue to operate with nodes t hat have not yet been upgraded.
This is due to the USE_PPK notification and the NO_PPK_AUTH notificatio n; if the initiator has not been upgraded, it will not send the USE_PPK This is due to the USE_PPK notification and the NO_PPK_AUTH notificatio n; if the initiator has not been upgraded, it will not send the USE_PPK
notification (and so the responder will know that the peers will not us e a PPK). If the responder has not been upgraded, it notification (and so the responder will know that the peers will not us e a PPK). If the responder has not been upgraded, it
will not send the USE_PPK notification (and so the initiator will know to not use a PPK). If both peers will not send the USE_PPK notification (and so the initiator will know to not use a PPK). If both peers
have been upgraded, but the responder isn't yet configured with the PPK have been upgraded but the responder isn't yet configured with the PPK
for the initiator, then the responder for the initiator, then the responder
could do standard IKEv2 protocol if the initiator sent NO_PPK_AUTH noti could continue with the standard IKEv2 protocol if the initiator sent a
fication. NO_PPK_AUTH notification.
If both the responder and initiator have been upgraded and properly con If both the responder and initiator have been upgraded and properly con
figured, they will both realize it, and the Child SAs will be quantum-secure.</t figured, they will both realize it, and the Child SAs will be quantum secure.</t
> >
<t>As an optional second step, after all nodes have been upgraded, the adm
<t>As an optional second step, after all nodes have been upgraded, then th inistrator should then go back through
e administrator should then go back through the nodes and mark the use of a PPK as mandatory. This will not affect
the nodes, and mark the use of PPK as mandatory. This will not affect the strength against a passive attacker, but
the strength against a passive attacker, but
it would mean that an active attacker with a quantum computer (which is sufficiently fast to be able to break the (EC)DH it would mean that an active attacker with a quantum computer (which is sufficiently fast to be able to break the (EC)DH
in real-time) would not be able to perform a downgrade attack.</t> in real time) would not be able to perform a downgrade attack.</t>
</section> </section>
<section numbered="true" toc="default">
<name>PPK</name>
<section numbered="true" toc="default">
<name>PPK_ID Format</name>
<t>This standard requires that both the initiator and the responder
have a secret PPK value, with the responder selecting the PPK based on
the PPK_ID that the initiator sends. In this standard, both the
initiator and the responder are configured with fixed PPK and PPK_ID
values and perform the lookup based on the PPK_ID value. It is anticipa
ted
that later specifications will extend this technique to allow
dynamically changing PPK values. To facilitate such an extension, we
specify that the PPK_ID the initiator sends will have its first octet
be the PPK_ID type value. This document defines two values for the
PPK_ID type:
</t>
<ul spacing="normal">
<li>PPK_ID_OPAQUE (1) - For this type, the format of the PPK_ID (and
the PPK itself) is not specified by this document; it is assumed to
be mutually intelligible by both the initiator and the responder.
This PPK_ID type is intended for those implementations that choose
not to disclose the type of PPK to active attackers.</li>
<section title="PPK"> <li>PPK_ID_FIXED (2) - In this case, the format of the PPK_ID and
<section title="PPK_ID format"> the PPK are fixed octet strings; the remaining bytes of the PPK_ID
<t>This standard requires that both the initiator and the responder have are a configured value. We assume that there is a fixed mapping
a secret PPK value, with the responder selecting the PPK based on the PPK_ID th between PPK_ID and PPK, which is configured locally to both the
at the initiator and the responder. The responder can use the PPK_ID to
initiator sends. In this standard, both the initiator and the responder look up the corresponding PPK value. Not all implementations are
are configured with fixed PPK and PPK_ID values, and do the able to configure arbitrary octet strings; to improve the potential
look up based on PPK_ID value. interoperability, it is recommended that, in the PPK_ID_FIXED case,
It is anticipated that later specifications will extend this technique t both the PPK and the PPK_ID strings be limited to the base64
o allow dynamically changing PPK values. character set <xref target="RFC4648" format="default"/>.</li>
To facilitate such an extension, we specify that the PPK_ID the initiato </ul>
r sends will have its first
octet be the PPK_ID Type value. This document defines two values for PPK
_ID Type:
<list style="symbols">
<t>PPK_ID_OPAQUE (1) - for this type the format of the PPK_ID (and the
PPK itself) is not specified by this document; it is
assumed to be mutually intelligible by both by initiator and the respo
nder. This PPK_ID type is intended
for those implementations that choose not to disclose the type of PPK
to active attackers.</t>
<t>PPK_ID_FIXED (2) - in this case the format of the PPK_ID and the PP
K are fixed octet strings; the remaining bytes of the
PPK_ID are a configured value. We assume that there is a fixed mappin
g between PPK_ID and PPK, which is
configured locally to both the initiator and the responder. The respo
nder can use the PPK_ID to look up the corresponding
PPK value. Not all implementations are able to configure arbitrary oct
et strings; to improve the potential interoperability,
it is recommended that, in the PPK_ID_FIXED case, both the PPK and the
PPK_ID strings be limited to the Base64 character set
<xref target="RFC4648"/>.</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Operational Considerations"> <name>Operational Considerations</name>
<t>The need to maintain several independent sets of security credentials <t>The need to maintain several independent sets of security credentials
can significantly complicate a security administrator's job, can significantly complicate a security administrator's job
and can potentially slow down widespread adoption of this specification. and can potentially slow down widespread adoption of this specification.
It is anticipated, that administrators will try to simplify their job It is anticipated that administrators will try to simplify their job
by decreasing the number of credentials they need to maintain. This sect ion describes some of the considerations for PPK management.</t> by decreasing the number of credentials they need to maintain. This sect ion describes some of the considerations for PPK management.</t>
<section title="PPK Distribution"> <section numbered="true" toc="default">
<name>PPK Distribution</name>
<t>PPK_IDs of the type PPK_ID_FIXED (and the corresponding PPKs) are a ssumed to be configured within the IKE device in an out-of-band fashion. <t>PPK_IDs of the type PPK_ID_FIXED (and the corresponding PPKs) are a ssumed to be configured within the IKE device in an out-of-band fashion.
While the method of distribution is a local matter and out of s While the method of distribution is a local matter and is out o
cope of this document or IKEv2, <xref target="RFC6030"/> describes a format for f scope of this document or IKEv2, <xref target="RFC6030" format="default"/> des
for the transport and provisioning of symmetric keys. That format coul cribes a format for the transport and provisioning of symmetric keys. That forma
d be reused using the PIN profile (defined in Section 10.2 of <xref target="RFC6 t
030"/>) could be reused using the PIN profile (defined in <xref target="RFC6030
with the "Id" attribute of the &lt;Key&gt; element being the PPK_ID (w " sectionFormat="of" section="10.2"/>)
ithout the PPK_ID Type octet for a PPK_ID_FIXED) and the &lt;Secret&gt; element with the "Id" attribute of the &lt;Key&gt; element being the PPK_ID (w
containing the PPK.</t> ithout the PPK_ID type octet for a PPK_ID_FIXED) and the &lt;Secret&gt; element
</section> containing the PPK.</t>
<section title="Group PPK"> </section>
<t>This document doesn't explicitly require that PPK is unique for eac <section numbered="true" toc="default">
h pair of peers. If it is the case, then this solution provides full <name>Group PPK</name>
peer authentication, but it also means that each host must have as man <t>This document doesn't explicitly require that the PPK be unique for
y independent PPKs as the peers it is going to communicate with. each pair of peers. If this is the case, then this solution provides full
As the number of peers grows the PPKs will not scale.</t> peer authentication, but it also means that each host must have as man
<t>It is possible to use a single PPK for a group of users. Since eac y independent PPKs as peers it is going to communicate with.
h peer uses classical public key cryptography in addition to PPK As the number of peers grows, the PPKs will not scale.</t>
for key exchange and authentication, members of the group can neither
impersonate each other nor read other's traffic, unless they use <t>It is possible to use a single PPK for a group of users. Since
quantum computers to break public key operations. However group member each peer uses classical public key cryptography in addition to a
s can record any traffic they have access to that comes PPK for key exchange and authentication, members of the group can
from other group members and decrypt it later, when they get access to neither impersonate each other nor read each other's traffic unless
a quantum computer.</t> they use quantum computers to break public key operations. However,
group members can record any traffic they have access to that comes
from other group members and decrypt it later, when they get access
to a quantum computer.</t>
<t>In addition, the fact that the PPK is known to a (potentially large ) group of users makes it more susceptible to theft. <t>In addition, the fact that the PPK is known to a (potentially large ) group of users makes it more susceptible to theft.
When an attacker equipped with a quantum computer gets access to a gro up PPK, all communications inside the group are revealed.</t> When an attacker equipped with a quantum computer gets access to a gro up PPK, all communications inside the group are revealed.</t>
<t>For these reasons using group PPK is NOT RECOMMENDED.</t> <t>For these reasons, using a group PPK is <bcp14>NOT RECOMMENDED</bcp
</section> 14>.</t>
<section title="PPK-only Authentication"> </section>
<section numbered="true" toc="default">
<name>PPK-Only Authentication</name>
<t>If quantum computers become a reality, classical public key cryptog raphy will provide little security, so administrators may find it attractive <t>If quantum computers become a reality, classical public key cryptog raphy will provide little security, so administrators may find it attractive
not to use it at all for authentication. This will reduce the number o not to use it at all for authentication.
f credentials they need to maintain to PPKs only. Combining group PPK and
PPK-only authentication is NOT RECOMMENDED, since in this case any mem This will reduce the number of credentials they need to maintain because they
ber of the group can impersonate any other member even without help only need to maintain PPK credentials. Combining group PPK and
PPK-only authentication is <bcp14>NOT RECOMMENDED</bcp14> since, in
this case, any member of the group can impersonate any other member,
even without the help
of quantum computers.</t> of quantum computers.</t>
<t>PPK-only authentication can be achieved in IKEv2 if the NULL Authen <t>PPK-only authentication can be achieved in IKEv2 if the NULL
tication method <xref target="RFC7619"/> is employed. Without PPK Authentication method <xref target="RFC7619" format="default"/> is
the NULL Authentication method provides no authentication of the peers employed. Without PPK, the NULL Authentication method provides no
, however since a PPK is stirred into the SK_pi and the SK_pr, authentication of the peers; however, since a PPK is stirred into
the peers become authenticated if a PPK is in use. Using PPKs MUST be the SK_pi and the SK_pr, the peers become authenticated if a PPK is
mandatory for the peers if they advertise support for PPK in use. Using PPKs <bcp14>MUST</bcp14> be mandatory for the peers if
in IKE_SA_INIT and use NULL Authentication. Additionally, since the pe they advertise support for PPKs in IKE_SA_INIT and use NULL
ers are authenticated via PPK, the ID Type in the IDi/IDr Authentication. Additionally, since the peers are authenticated via
payloads SHOULD NOT be ID_NULL, despite using the NULL Authentication PPKs, the ID Type in the IDi/IDr payloads <bcp14>SHOULD NOT</bcp14>
method.</t> be ID_NULL, despite using the NULL Authentication method.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<section anchor="Security" title="Security Considerations"> <t>A critical consideration is how to ensure the randomness of this
<t>Quantum computers are able to perform Grover's algorithm <xref target=" post-quantum preshared key. Quantum computers are able to perform Grover's
GROVER"/>; that algorithm <xref target="GROVER" format="default"/>; that effectively halves th
effectively halves the size of a symmetric key. Because of this, e size of
the user SHOULD ensure that the post-quantum preshared key used has a symmetric key. In addition, an adversary impersonating the server,
at least 256 bits of entropy, in order to provide 128 bits of post-quantum even with a conventional computer, can perform a dictionary search over
security. plausible post-quantum preshared key values. The strongest practice is
That provides security equivalent to Level 5 as defined to ensure that any post-quantum preshared key contains at least 256 bits of
in the NIST PQ Project Call For Proposals <xref target="NISTPQCFP"/>. entropy; this will provide 128 bits of post-quantum security, while
</t> providing security against conventional dictionary attacks. That provides the
security
equivalent to Category 5 as defined in the NIST Post-Quantum Cryptography
Call for Proposals <xref target="NISTPQCFP" format="default"/>. Deriving
a post-quantum preshared key from a password, name, or other low-entropy
source is not secure because of these known attacks.</t>
<t>With this protocol, the computed SK_d is a function of the PPK. Assumin <t>With this protocol, the computed SK_d is a function of the
g that the PPK has sufficient PPK. Assuming that the PPK has sufficient entropy (for example, at least
entropy (for example, at least 2^256 possible values), then even if an att 2<sup>256</sup> possible values), even if an attacker was able to recover
acker was able to recover the the
rest of the inputs to the PRF function, it would be infeasible to use Grov rest of the inputs to the PRF function, it would be infeasible to use
er's algorithm with a quantum Grover's algorithm with a quantum computer to recover the SK_d value.
computer to recover the SK_d value. Similarly, all keys that are a functi Similarly, all keys that are a function of SK_d, which include all Child
on of SK_d, which include SA keys and all keys for subsequent IKE SAs (created when the initial
all Child SAs keys and all keys for subsequent IKE SAs (created when the i IKE SA is rekeyed), are also quantum secure (assuming that the PPK was
nitial IKE SA is rekeyed), of high enough entropy and that all the subkeys are sufficiently long).
are also quantum-secure (assuming that the PPK was of high enough entropy,
and that all the subkeys are sufficiently long).
</t> </t>
<t>An attacker with a quantum computer that can decrypt the initial IKE
<t>An attacker with a quantum computer that can decrypt the initial IKE SA SA has access to all the information exchanged over it, such as
has access identities of the peers, configuration parameters, and all negotiated
to all the information exchanged over it, such as identities of the peers, IPsec SA information (including traffic selectors), with the exception
configuration parameters and all of the cryptographic keys used by the IPsec SAs, which are protected by
negotiated IPsec SAs information (including traffic selectors), with the e the PPK.
xception of the cryptographic keys
used by the IPsec SAs which are protected by the PPK.
</t> </t>
<t>Deployments that treat this information as sensitive or that send other sensitive data (like cryptographic keys) <t>Deployments that treat this information as sensitive or that send other sensitive data (like cryptographic keys)
over IKE SA MUST rekey the IKE SA before the sensitive information is sent over IKE SAs <bcp14>MUST</bcp14> rekey the IKE SA before the sensitive inf
to ensure this information is protected by the PPK. ormation is sent to ensure this information is protected by the PPK.
It is possible to create a childless IKE SA as specified in <xref target=" It is possible to create a childless IKE SA as specified in <xref target="
RFC6023"/>. This prevents Child SA RFC6023" format="default"/>. This prevents Child SA
configuration information from being transmitted in the original IKE SA th at is not protected by a PPK. configuration information from being transmitted in the original IKE SA th at is not protected by a PPK.
Some information related to IKE SA, that is sent in the IKE_AUTH exchange, Some information related to IKE SA that is sent in the IKE_AUTH exchange,
such as peer identities, feature notifications, such as peer identities, feature notifications,
Vendor ID's etc. cannot be hidden from the attack described above, even if vendor IDs, etc., cannot be hidden from the attack described above, even i
the additional IKE SA rekey is performed. f the additional IKE SA rekey is performed.
</t> </t>
<t>In addition, the policy <bcp14>SHOULD</bcp14> be set to negotiate only
<t>In addition, the policy SHOULD be set to negotiate only quantum-secure quantum-secure
symmetric algorithms; while this RFC doesn't claim to give symmetric algorithms; while this RFC doesn't claim to give
advice as to what algorithms are secure (as that may change advice as to what algorithms are secure (as that may change
based on future cryptographical results), below is a list of defined IKEv2 and based on future cryptographical results), below is a list of defined IKEv2 and
IPsec algorithms that should not be used, as they are known to provide les IPsec algorithms that should not be used, as they are known to provide les
s than 128 bits of post-quantum security s than 128 bits of post-quantum security:
<list style="symbols"> </t>
<t>Any IKEv2 Encryption algorithm, PRF or Integrity algorithm with key s <ul spacing="normal">
ize less than 256 bits.</t> <li>Any IKEv2 encryption algorithm, PRF, or integrity algorithm with a
<t>Any ESP Transform with key size less than 256 bits.</t> key size less than 256 bits.</li>
<t>PRF_AES128_XCBC and PRF_AES128_CBC; even though they are defined to b <li>Any ESP transform with a key size less than 256 bits.</li>
e able to use an arbitrary key size,
they convert it into a 128-bit key internally.</t>
</list></t>
<t><xref target="Exchanges" /> requires the initiator to abort the initial
exchange if using PPKs is mandatory for it,
but the responder does not include the USE_PPK notification in the respons
e. In this situation, when the initiator aborts
negotiation it leaves a half-open IKE SA on the responder (because IKE_SA_
INIT completes successfully from the responder's
point of view). This half-open SA will eventually expire and be deleted, b
ut if the initiator continues its attempts to create
IKE SA with a high enough rate, then the responder may consider it as a De
nial-of-Service (DoS) attack and take protection measures
(see <xref target="RFC8019" /> for more detail). In this situation, it is
RECOMMENDED that the initiator caches
the negative result of the negotiation and doesn't make attempts to create
it again for some time. This period of time may vary, but it is believed that w
aiting for at least few minutes will not cause the responder to treat it as DoS
attack. Note, that this situation would most likely be a result of misconfigurat
ion and some re-configuration of the peers would probably be needed.</t>
<li>PRF_AES128_XCBC and PRF_AES128_CBC: even though they can use as
input a key of arbitrary size, such input keys are converted into a 128-b
it key for internal use.</li>
</ul>
<t><xref target="Exchanges" format="default"/> requires the initiator to
abort the initial exchange if using PPKs is mandatory for it but the
responder does not include the USE_PPK notification in the response. In
this situation, when the initiator aborts the negotiation, it leaves a
half-open IKE SA on the responder (because IKE_SA_INIT completes
successfully from the responder's point of view). This half-open SA will
eventually expire and be deleted, but if the initiator continues its
attempts to create IKE SA with a high enough rate, then the responder may
consider it a denial-of-service (DoS) attack and take protective
measures (see <xref target="RFC8019" format="default"/> for more
details). In this situation, it is <bcp14>RECOMMENDED</bcp14> that the
initiator cache the negative result of the negotiation and not attempt
to create it again for some time. This period of time may vary, but it
is believed that waiting for at least few minutes will not cause the
responder to treat it as a DoS attack. Note that this situation would
most likely be a result of misconfiguration, and some reconfiguration of
the peers would probably be needed.</t>
<t>If using PPKs is optional for both peers and they authenticate themselv es using digital signatures, then <t>If using PPKs is optional for both peers and they authenticate themselv es using digital signatures, then
an attacker in between, equipped with a quantum computer capable of breaki ng public key operations an attacker in between, equipped with a quantum computer capable of breaki ng public key operations
in real time, is able to mount downgrade attack by removing USE_PPK notifi cation from the IKE_SA_INIT in real time, is able to mount a downgrade attack by removing the USE_PPK notification from the IKE_SA_INIT
and forging digital signatures in the subsequent exchange. If using PPKs i s mandatory for at least one of the peers and forging digital signatures in the subsequent exchange. If using PPKs i s mandatory for at least one of the peers
or PSK is used for authentication, then the attack will be detected and th or if a preshared key mode is used for authentication, then the attack wil
e SA won't be created.</t> l be detected
and the SA won't be created.</t>
<t>If using PPKs is mandatory for the initiator, then an attacker able to
eavesdrop and to inject packets into
the network can prevent creating an IKE SA by mounting the following attac
k. The attacker intercepts the
initial request containing the USE_PPK notification and injects a forged r
esponse containing no USE_PPK.
If the attacker manages to inject this packet before the responder sends a
genuine response, then the initiator would
abort the exchange. To thwart this kind of attack it is RECOMMENDED, that
if using PPKs is mandatory for the initiator and
the received response doesn't contain the USE_PPK notification, then the i
nitiator doesn't abort the exchange
immediately. Instead it waits for more response messages retransmitting th
e request as if no responses were received at all,
until either the received message contains the USE_PPK or the exchange tim
es out (see section 2.4 of <xref target="RFC7296"/>
for more details about retransmission timers in IKEv2). If neither of the
received responses contains USE_PPK, then the exchange is aborted.</t>
<t>If using PPK is optional for both peers, then in case of misconfigurati <t>If using PPKs is mandatory for the initiator, then an attacker able
on (e.g., mismatched PPK_ID) the IKE SA to eavesdrop and inject packets into the network can prevent creation of a
will be created without protection against quantum computers. It is advise n
d that if PPK was configured, but IKE SA by mounting the following attack. The attacker intercepts the
was not used for a particular IKE SA, then implementations SHOULD audit th initial request containing the USE_PPK notification and injects a forged
is event. response containing no USE_PPK. If the attacker manages to inject this
packet before the responder sends a genuine response, then the initiator
would abort the exchange. To thwart this kind of attack, it is
<bcp14>RECOMMENDED</bcp14> that, if using PPKs is mandatory for the
initiator and the received response doesn't contain the USE_PPK
notification, the initiator not abort the exchange
immediately. Instead, it waits for more response messages,
retransmitting the request as if no responses were received at all, until
either the received message contains the USE_PPK notification or the excha
nge times
out (see <xref target="RFC7296" format="default" sectionFormat="of"
section="2.4"/> for more details about retransmission timers in
IKEv2). If none of the received responses contains USE_PPK, then the
exchange is aborted.</t>
<t>If using a PPK is optional for both peers, then in case of misconfigura
tion (e.g., mismatched PPK_ID), the IKE SA
will be created without protection against quantum computers. It is
advised that if a PPK was configured but
was not used for a particular IKE SA, then implementations <bcp14>SHOULD</
bcp14> audit this event.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document defines three new Notify Message Types in the
"IKEv2 Notify Message Types - Status Types" subregistry under the
"Internet Key Exchange Version 2 (IKEv2) Parameters" registry
<xref target="IANA-IKEV2" format="default"/>:</t>
<section title="IANA Considerations"> <table anchor="table2" align="center">
<t>This document defines three new Notify Message Types in the "Notify Mes <tbody>
sage Types - Status Types" registry (https://www.iana.org/assignments/ikev2-para <tr>
meters/ikev2-parameters.xhtml#ikev2-parameters-16):</t> <th align="left">Value</th>
<figure align="center"> <th align="left">NOTIFY MESSAGES - STATUS TYPES</th>
<artwork align="left"><![CDATA[ <th align="left">Reference</th>
16435 USE_PPK [THIS RFC] </tr>
16436 PPK_IDENTITY [THIS RFC] <tr>
16437 NO_PPK_AUTH [THIS RFC] <td align="left">16435</td>
]]></artwork> <td align="left">USE_PPK</td>
</figure> <td align="left">RFC 8784</td>
</tr>
<t>This document also creates a new IANA registry "IKEv2 Post-quantum Pres <tr>
hared Key ID Types" in <td align="left">16436</td>
IKEv2 IANA registry (https://www.iana.org/assignments/ikev2-parameters/) f <td align="left">PPK_IDENTITY</td>
or the PPK_ID types used in the PPK_IDENTITY notification <td align="left">RFC 8784</td>
defined in this specification. The initial values of the new registry are: </tr>
</t> <tr>
<figure align="center"> <td align="left">16437</td>
<artwork align="left"><![CDATA[ <td align="left">NO_PPK_AUTH</td>
PPK_ID Type Value Reference <td align="left">RFC 8784</td>
Reserved 0 [THIS RFC] </tr>
PPK_ID_OPAQUE 1 [THIS RFC] </tbody>
PPK_ID_FIXED 2 [THIS RFC] </table>
Unassigned 3-127 [THIS RFC] <t>Per this document, IANA has created a new subregistry titled "IKEv2
Private Use 128-255 [THIS RFC] Post-quantum Preshared Key ID Types" under the "Internet Key Exchange
]]></artwork> Version 2 (IKEv2) Parameters" registry <xref target="IANA-IKEV2"
</figure> format="default"/>. This new subregistry is for the PPK_ID types used in
the PPK_IDENTITY notification defined in this specification. The initial
contents of the new subregistry are as follows:
</t>
<table anchor="table3" align="center">
<thead>
<tr>
<th align="left">Value</th>
<th align="left">PPK_ID Type</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0</td>
<td align="left">Reserved</td>
<td align="left">RFC 8784</td>
</tr>
<tr>
<td align="left">1</td>
<td align="left">PPK_ID_OPAQUE</td>
<td align="left">RFC 8784</td>
</tr>
<tr>
<td align="left">2</td>
<td align="left">PPK_ID_FIXED</td>
<td align="left">RFC 8784</td>
</tr>
<tr>
<td align="left">3-127</td>
<td align="left">Unassigned</td>
<td align="left">RFC 8784</td>
</tr>
<tr>
<td align="left">128-255</td>
<td align="left">Reserved for Private Use</td>
<td align="left">RFC 8784</td>
</tr>
</tbody>
</table>
<t>The PPK_ID type value 0 is reserved; values 3-127 are to be assigned by <t>The PPK_ID type value 0 is reserved; values 3-127 are to be assigned
IANA; values 128-255 are for private use among mutually consenting parties. To by IANA; and values 128-255 are for private use among mutually consenting
register new PPK_IDs in the unassigned range, a Type name, a Value between 3 and parties. To register new PPK_IDs in the Unassigned range, a type name, a
127 and a Reference specification need to be defined. Changes and additions to value between 3 and 127, and a reference specification need to be
the unassigned range of this registry are by the Expert Review Policy <xref targ defined. Changes and additions to the Unassigned range of this registry
et="RFC8126" />. Changes and additions to the private use range of this registry are made using the Expert Review policy <xref target="RFC8126"
are by the Private Use Policy <xref target="RFC8126" />.</t> format="default"/>. Changes and additions to the Reserved for Private Use
range of
this registry are made using the Private Use policy <xref target="RFC8126"
format="default"/>.</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative --> <displayreference target="I-D.hoffman-c2pq" to="C2PQ"/>
<references title="Normative References">
&RFC2119;
&RFC8174;
&RFC7296;
</references>
<references title="Informational References"> <references>
<reference anchor="GROVER"><front> <name>References</name>
<title>A Fast Quantum Mechanical Algorithm for Database Search</title> <references>
<author fullname="L. Grover" initials="L." surname="Grover"> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7296.xml"/>
</references>
<references>
<name>Informative References</name>
<reference anchor="GROVER">
<front>
<title>A Fast Quantum Mechanical Algorithm for Database
Search</title>
<seriesInfo name="DOI" value="10.1145/237814.237866"/>
<author fullname="L. Grover" initials="L." surname="Grove
r">
</author> </author>
<date year="1996"/> <date month="July" year="1996"/>
</front> </front>
<seriesInfo name="Proc." value="of the Twenty-Eighth Annual ACM Symposium <refcontent>STOC '96: Proceedings of the Twenty-Eighth Annual ACM Symposium
on the Theory of Computing (STOC 1996)"/> on the Theory of Computing, pp. 212-219"</refcontent>
</reference>
<reference anchor="NISTPQCFP" target="https://csrc.nist.gov/CSRC/media/Pro </reference>
jects/Post-Quantum-Cryptography/documents/call-for-proposals-final-dec-2016.pdf" <reference anchor="NISTPQCFP" target="https://csrc.nist.gov/CSRC/media/P
><front> rojects/Post-Quantum-Cryptography/documents/call-for-proposals-final-dec-2016.pd
<title>NIST Post-Quantum Cryptography Call for Proposals</title> f">
<author fullname="NIST" surname="NIST"> <front>
<title>Submission Requirements and Evaluation Criteria for the
Post-Quantum Cryptography Standardization Process</title>
<author><organization>NIST</organization>
</author> </author>
<date year="2016"/> <date month="December" year="2016"/>
</front> </front>
</reference> </reference>
&RFC2409; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC4648; FC.2409.xml"/>
&RFC6023; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC6030; FC.4648.xml"/>
&RFC7619; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC8019; FC.6023.xml"/>
&RFC8126; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I- FC.6030.xml"/>
D.hoffman-c2pq.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<reference anchor="IKEV2-IANA-PRFS" target="https://www.iana.org/assignmen FC.7619.xml"/>
ts/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-6"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.8019.xml"/>
<title>Internet Key Exchange Version 2 (IKEv2) Parameters, Transform T <xi:include
ype 2 - Pseudorandom Function Transform IDs</title> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.x
<author initials="" surname="" fullname=""> ml"/>
<organization /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
</author> I-D.hoffman-c2pq.xml"/>
<date /> <reference anchor="IANA-IKEV2" target="https://www.iana.org/assignments/
</front> ikev2-parameters/">
</reference> <front>
<title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
<author><organization>IANA
</organization>
</author>
</front>
</reference>
</references>
</references> </references>
<section anchor="app-additional" numbered="true" toc="default">
<name>Discussion and Rationale</name>
<section anchor="app-additional" title="Discussion and Rationale"> <t>The primary goal of this document is to augment the IKEv2 protocol to
<t>The idea behind this document is that while a quantum computer can easi provide protection against
ly quantum computers without requiring novel cryptographic algorithms. The id
reconstruct the shared secret of an (EC)DH exchange, they cannot as ea behind this document is that while a quantum computer can easily
reconstruct the shared secret of an (EC)DH exchange, it cannot as
easily recover a secret from a symmetric exchange. This document makes the easily recover a secret from a symmetric exchange. This document makes the
SK_d, and hence the IPsec KEYMAT and any child SA's SKEYSEED, depend SK_d (and thus also the IPsec KEYMAT and any subsequent IKE SA's SKEYSEED)
on both the symmetric PPK, and also the Diffie-Hellman exchange. depend
on both the symmetric PPK and the Diffie-Hellman exchange.
If we assume that the attacker knows everything except the If we assume that the attacker knows everything except the
PPK during the key exchange, and there are 2^n plausible PPKs, then PPK during the key exchange and there are 2<sup>n</sup> plausible PPKs, th
a quantum computer (using Grover's algorithm) would take O(2^(n/2)) en
a quantum computer (using Grover's algorithm) would take O(2<sup>n/2</sup>
)
time to recover the PPK. So, even if the (EC)DH can be trivially time to recover the PPK. So, even if the (EC)DH can be trivially
solved, the attacker still can't recover any key material solved, the attacker still can't recover any key material
(except for the SK_ei, SK_er, SK_ai and SK_ar values for the initial IKE e xchange) unless they (except for the SK_ei, SK_er, SK_ai, and SK_ar values for the initial IKE exchange) unless they
can find the PPK, which is too difficult if the PPK has enough can find the PPK, which is too difficult if the PPK has enough
entropy (for example, 256 bits). entropy (for example, 256 bits).
Note that we do allow an attacker with a quantum computer to Note that we do allow an attacker with a quantum computer to
rederive the keying material for the initial IKE SA; this was rederive the keying material for the initial IKE SA; this was
a compromise to allow the responder to select the correct PPK quickly. </t > a compromise to allow the responder to select the correct PPK quickly. </t >
<t>Another goal of this protocol is to minimize the number of changes <t>Another goal of this protocol is to minimize the number of changes
within the IKEv2 protocol, and in particular, within the cryptography within the IKEv2 protocol, in particular, within the cryptography
of IKEv2. By limiting our changes to notifications, and only adjusting th of IKEv2. By limiting our changes to notifications and only adjusting the
e SK_d, SK_pi, and SK_pr, it is hoped that this would be implementable, e
SK_d, SK_pi, SK_pr, it is hoped that this would be implementable, even ven
on systems that perform most of the IKEv2 processing in hardware.</t> on systems that perform most of the IKEv2 processing in hardware.</t>
<t>A third goal was to be friendly to incremental deployment in operationa <t>A third goal is to be friendly to incremental deployment in
l networks, for which operational networks for which we might not want to have a global
we might not want to have a global shared key, or quantum-secure IKEv2 is shared key or for which quantum-secure IKEv2 is rolled out incrementally.
rolled out This is
incrementally. This is why we specifically try to allow the why we specifically try to allow the PPK to be dependent on the peer and
PPK to be dependent on the peer, and why we allow the PPK to be why we allow the PPK to be configured as optional.</t>
configured as optional.</t> <t>A fourth goal is to avoid violating any of the security properties
provided by IKEv2.</t>
<t>A fourth goal was to avoid violating any of the security properties pro
vided by IKEv2.</t>
</section> </section>
<section anchor="Acknowledgements" numbered="false" toc="default">
<section anchor="Acknowledgements" title="Acknowledgements"> <name>Acknowledgements</name>
<t>We would like to thank Tero Kivinen, Paul Wouters, Graham Bartlett, Tom <t>We would like to thank <contact fullname="Tero Kivinen"/>, <contact
my Pauly, Quynh Dang fullname="Paul Wouters"/>, <contact fullname="Graham Bartlett"/>,
and the rest of the IPSecME Working Group for their feedback and suggestio <contact fullname="Tommy Pauly"/>, <contact fullname="Quynh Dang"/>, and
ns for the rest of the IPSECME Working Group for their feedback and suggestions
the scheme.</t> for the scheme.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 106 change blocks. 
817 lines changed or deleted 693 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/