Diff: rfc9242xml2.original.xml

	rfc9242xml2.original.xml	rfc9242.xml

	<?xml version="1.0" encoding="UTF-8"?>	<?xml version='1.0' encoding='UTF-8'?>
		<!DOCTYPE rfc [
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [	<!ENTITY nbsp " ">
	<!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen	<!ENTITY zwsp "">
	ce.RFC.2119.xml">	<!ENTITY nbhy "‑">
	<!ENTITY rfc5282 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen	<!ENTITY wj "⁠">
	ce.RFC.5282.xml">
	<!ENTITY rfc5723 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.5723.xml">
	<!ENTITY rfc6928 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.6928.xml">
	<!ENTITY rfc7296 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.7296.xml">
	<!ENTITY rfc7383 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.7383.xml">
	<!ENTITY rfc8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.8174.xml">
	<!ENTITY rfc8019 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.8019.xml">
	<!ENTITY rfc8229 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
	ce.RFC.8229.xml">
	]>	]>

		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902" docName="draft-ietf-ipsecme-ikev2-intermediate-10" obsoletes="" number="9242" u pdates="" submissionType="IETF" xml:lang="en" tocInclude="true" consensus="true" symRefs="true" sortRefs="true" version="3">


	<rfc category="std" ipr="trust200902" docName="draft-ietf-ipsecme-ikev2-intermed	<front>
	iate-10">	<title abbrev="Intermediate IKEv2 Exchange">Intermediate Exchange in the Int
		ernet Key Exchange Protocol Version 2 (IKEv2)</title>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>	<seriesInfo name="RFC" value="9242"/>
		<author initials="V" surname="Smyslov" fullname="Valery Smyslov">
	<?rfc toc="yes" ?>	<organization>ELVIS-PLUS</organization>
	<?rfc symrefs="yes" ?>	<address>
	<?rfc sortrefs="no"?>	<postal>
	<?rfc iprnotified="no" ?>	<street>PO Box 81</street>
	<?rfc strict="yes" ?>	<city>Moscow (Zelenograd)</city>
		<code>124460</code>
	<front>	<country>Russian Federation</country>
	<title abbrev="Intermediate IKEv2 Exchange">Intermediate Exchange in the	</postal>
	IKEv2 Protocol</title>	<phone>+7 495 276 0211</phone>
	<author initials='V.' surname="Smyslov" fullname='Valery Smyslov'>	<email>svan@elvis.ru</email>
	<organization>ELVIS-PLUS</organization>	</address>
	<address>	</author>
	<postal>	<date month="May" year="2022"/>
	<street>PO Box 81</street>	<area>sec</area>
	<city>Moscow (Zelenograd)</city>	<workgroup>ipsecme</workgroup>
	<code>124460</code>	<keyword>IKE_INTERMEDIATE</keyword>
	<country>RU</country>	<keyword>Quantum Computer resistant key exchange method</keyword>
	</postal>	<keyword>Post-quantum</keyword>
	<phone>+7 495 276 0211</phone>	<abstract>
	<email>svan@elvis.ru</email>	<t> This document defines a new exchange, called "Intermediate Exchange",
	</address>	for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be u
	</author>	sed for transferring large amounts of data in the process of IKEv2
	<date/>	Security Association (SA) establishment. An example of the need to do this
		is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA e
		stablishment.


	<keyword>IKE_INTERMEDIATE</keyword>	The Intermediate Exchange makes it possible to use the existing IKE
	<keyword>Quantum Computer resistant key exchange method</keyword>	fragmentation mechanism (which cannot be used in the initial IKEv2 exchange),
	<keyword>Post-quantum</keyword>	helping to avoid IP fragmentation of large IKE messages if they need to be
		sent before IKEv2 SA is established.


	<abstract>	</t>
	<t> This document defines a new exchange, called Intermediate Exchan
	ge, for the Internet Key Exchange protocol
	Version 2 (IKEv2). This exchange can be used for transferring large
	amounts of data in the process of IKEv2
	Security Association (SA) establishment. An example of the need to d
	o this is using Quantum Computer
	resistant key exchange methods for IKE SA establishment. Introducing
	the Intermediate Exchange
	allows re-using the existing IKE fragmentation mechanism, that helps
	to avoid IP fragmentation
	of large IKE messages, but cannot be used in the initial IKEv2 excha
	nge.
	</t>
	</abstract>
	</front>


	<middle>	</abstract>
	<section title="Introduction">	</front>
	<t> The Internet Key Exchange protocol version 2 (IKEv2) defined in	<middle>
	<xref target="RFC7296" />	<section numbered="true" toc="default">
	uses UDP as a transport for its messages. If the size of a message i	<name>Introduction</name>
	s larger than the PMTU, IP fragmentation	<t> The Internet Key Exchange Protocol
	takes place, which has been shown to cause operational challenge	Version 2 (IKEv2) defined in <xref target="RFC7296" format="default"/>
		uses UDP as a transport for its messages. If the size of a message i
		s larger than the Path MTU (PMTU), IP fragmentation
		takes place, which has been shown to cause operational challenges
	in certain network configurations and devices. The problem is descri bed	in certain network configurations and devices. The problem is descri bed

	in more detail in <xref target="RFC7383" />, which also defines an e xtension to IKEv2 called IKE fragmentation.	in more detail in <xref target="RFC7383" format="default"/>, which a lso defines an extension to IKEv2 called "IKE fragmentation".
	This extension allows IKE messages to be fragmented at the IKE level , eliminating possible issues	This extension allows IKE messages to be fragmented at the IKE level , eliminating possible issues
	caused by IP fragmentation. However, IKE fragmentation cannot be use d in the initial IKEv2 exchange	caused by IP fragmentation. However, IKE fragmentation cannot be use d in the initial IKEv2 exchange

	(IKE_SA_INIT). This limitation in most cases is not a problem, since the IKE_SA_INIT	(IKE_SA_INIT). In most cases, this limitation is not a problem, sinc e the IKE_SA_INIT
	messages are usually small enough not to cause IP fragmentation.	messages are usually small enough not to cause IP fragmentation.

	</t>	</t>
		<!-- [rfced] Would "has caused concern" or "has led to concern" (rather than
		"has brought a concern") be a better choice of words here?


	<t> However, the situation has been changing recently. One example o	Original:
	f the need to transfer large amount	Recent progress in Quantum Computing has brought a concern that
	of data before an IKE SA is created is using Quantum Computer resist	classical Diffie-Hellman key exchange methods will become insecure in
	ant key exchange methods in IKEv2.	a relatively near future and should be replaced with Quantum Computer
	Recent progress in Quantum Computing has brought a concern that clas	(QC) resistant ones.
	sical Diffie-Hellman key
	exchange methods will become insecure in a relatively near future an
	d should be replaced with
	Quantum Computer (QC) resistant ones. Currently, most QC-resistant k
	ey exchange methods have
	large public keys. If these keys are exchanged in the IKE_SA_INIT, t
	hen most probably
	IP fragmentation will take place, therefore all the problems caused
	by it will become inevitable.
	</t>


	<t> A possible solution to the problem would be to use TCP as a tran	double check on this. Do they mean they dont want any change?
	sport for IKEv2, as defined
	in <xref target="RFC8229" />. However, this approach has significant
	drawbacks and is
	intended to be a "last resort" when UDP transport is completely bloc
	ked by intermediate
	network devices.
	</t>


	<t> This specification describes a way to transfer a large amount of	-->
	data in IKEv2 using UDP transport.
	For this purpose the document defines a new exchange for the IKEv2 p	<t> However, the situation has been changing recently. One example of the
	rotocol, called Intermediate Exchange or IKE_INTERMEDIATE.	need to transfer large amounts
	One or more these exchanges may take place right after the IKE_SA_IN	of data before an IKE SA is created is using the QC-resistant key ex
	IT exchange and prior	change methods in IKEv2.

		Recent progress in quantum computing has led to concern that classica
		l Diffie-Hellman key
		exchange methods will become insecure in the relatively near future
		and should be replaced with
		QC-resistant ones.

		Currently, most QC-resistant key exchange methods have
		large public keys. If these keys are exchanged in the IKE_SA_INIT ex
		change, then
		IP fragmentation will probably take place; therefore, all the proble
		ms caused by it will become inevitable.
		</t>
		<t> A possible solution to this problem would be to use TCP as a transport
		for IKEv2, as defined
		in <xref target="RFC8229" format="default"/>. However, this approach
		has significant drawbacks and is
		intended to be a last resort when UDP transport is completely blocke
		d by intermediate
		network devices.
		</t>
		<t> This specification describes a way to transfer a large amount of data
		in IKEv2 using UDP transport.
		For this purpose, the document defines a new exchange for IKEv2 call
		ed "Intermediate Exchange" or "IKE_INTERMEDIATE".
		One or more of these exchanges may take place right after the IKE_SA
		_INIT exchange and prior
	to the IKE_AUTH exchange. The IKE_INTERMEDIATE exchange messages can be fragmented using the IKE fragmentation mechanism,	to the IKE_AUTH exchange. The IKE_INTERMEDIATE exchange messages can be fragmented using the IKE fragmentation mechanism,

	so these exchanges may be used to transfer large amounts of data whi ch don't fit into the IKE_SA_INIT exchange	so these exchanges may be used to transfer large amounts of data tha t don't fit into the IKE_SA_INIT exchange
	without causing IP fragmentation.	without causing IP fragmentation.

	</t>	</t>
		<t> The Intermediate Exchange can be used to transfer large public keys of
	<t> The Intermediate Exchange can be used to transfer large public k	QC-resistant key exchange methods,
	eys of QC-resistant key exchange methods,
	but its application is not limited to this use case. This exchange c an also be used	but its application is not limited to this use case. This exchange c an also be used

	whenever some data need to be transferred before the IKE_AUTH exchan ge and for some reason	whenever some data needs to be transferred before the IKE_AUTH excha nge and for some reason
	the IKE_SA_INIT exchange is not suited for this purpose. This docum ent defines the IKE_INTERMEDIATE	the IKE_SA_INIT exchange is not suited for this purpose. This docum ent defines the IKE_INTERMEDIATE
	exchange without tying it to any specific use case. It is expected t hat separate specifications will define	exchange without tying it to any specific use case. It is expected t hat separate specifications will define
	for which purposes and how the IKE_INTERMEDIATE exchange is used in IKEv2. Some considerations	for which purposes and how the IKE_INTERMEDIATE exchange is used in IKEv2. Some considerations
	must be taken into account when designing such specifications:	must be taken into account when designing such specifications:


	<list style="symbols">	</t>
	<t> The IKE_INTERMEDIATE exchange is not intended for	<ul spacing="normal">
		<li> The IKE_INTERMEDIATE exchange is not intended for
	bulk transfer. This document doesn't set a hard cap on	bulk transfer. This document doesn't set a hard cap on
	the amount of data that can be safely transferred using this mecha nism,	the amount of data that can be safely transferred using this mecha nism,

	as it depends on its application. But it is anticipated that in mo	as it depends on its application. However, in most cases, it is an
	st cases	ticipated that
	the amount of data will be limited to tens of Kbytes (few hundred	the amount of data will be limited to tens of kilobytes (a few hun
	Kbytes	dred kilobytes
	in extreme cases), which is believed to cause no network problems	in extreme cases), which is believed to cause no network problems

	(see <xref target="RFC6928" /> as an example of experiments with s ending	(see <xref target="RFC6928" format="default"/> as an example of ex periments with sending
	similar amounts of data in the first TCP flight). See also	similar amounts of data in the first TCP flight). See also

	<xref target="security" /> for the discussion of possible DoS atta	<xref target="security" format="default"/> for the discussion of p
	ck vectors	ossible DoS attack vectors
	when amount of data sent in IKE_INTERMEDIATE is too large.	when the amount of data sent in the IKE_INTERMEDIATE exchange is t
	</t>	oo large.
		</li>
	<t> It is expected that the IKE_INTERMEDIATE exchange will	<li> It is expected that the IKE_INTERMEDIATE exchange will
	only be used for transferring data that is needed to establish IKE SA	only be used for transferring data that is needed to establish IKE SA

	and not for data that can be send later when this SA is establishe	and not for data that can be sent later when this SA is establishe
	d.	d.
	</t>	</li>
	</list>	</ul>
	</t>	</section>
	</section>	<section anchor="mustshouldmay" numbered="true" toc="default">
		<name>Terminology and Notation</name>


	<section anchor="mustshouldmay" title="Terminology and Notation">	<t>
	<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NO	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	T", "SHOULD", "SHOULD NOT",	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this docu	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	ment are to be interpreted	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	as described in BCP 14 <xref target="RFC2119" /> <xref target="RFC81	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	74" /> when, and only when,	be interpreted as
	they appear in all capitals, as shown here.	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	</t>	when, and only when, they appear in all capitals, as shown here.
		</t>


	<t> It is expected that readers are familiar with the terms used in	<t> It is expected that readers are familiar with the terms used in the
	the IKEv2 specification <xref target="RFC7296" />.	IKEv2 specification <xref target="RFC7296" format="default"/>. Notation
	</t>	for the payloads contained in IKEv2 messages is defined in <xref target="R
	</section>	FC7296" sectionFormat="of" section="1.2" />.
		</t>


	<section title="Intermediate Exchange Details">	</section>
	<section title="Support for Intermediate Exchange Negotiation">
	<t> The initiator indicates its support for Intermediate Exchang	<section numbered="true" toc="default">
	e by including a	<name>Intermediate Exchange Details</name>
		<section numbered="true" toc="default">
		<name>Support for Intermediate Exchange Negotiation</name>

		<t> The initiator indicates its support for Intermediate Exchange by incl
		uding a
	notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in the IKE_ SA_INIT request message.	notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in the IKE_ SA_INIT request message.
	If the responder also supports this exchange, it includes this n otification	If the responder also supports this exchange, it includes this n otification
	in the response message.	in the response message.

	</t>	</t>
		<artwork align="left" name="" type="" alt=""><![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)] -->
	<-- HDR, SAr1, KEr, Nr, [CERTREQ],	<-- HDR, SAr1, KEr, Nr, [CERTREQ],
	[N(INTERMEDIATE_EXCHANGE_SUPPORTED)]	[N(INTERMEDIATE_EXCHANGE_SUPPORTED)]
	]]></artwork>	]]></artwork>

	</figure>	<t>
		The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2
		notification with Notify Message Type 16438. When it is sent, the Protocol ID
		and SPI Size fields in the Notify payload are both set to 0.


	<t> The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2 n
	otification. Its Notify Message Type
	is 16438, Protocol ID and SPI Size are both set to 0.
	This specification doesn't define any data that this notificatio n may contain,	This specification doesn't define any data that this notificatio n may contain,
	so the Notification Data is left empty. However, future enhancem ents to this specification may override this.	so the Notification Data is left empty. However, future enhancem ents to this specification may override this.

	Implementations MUST ignore non-empty Notification Data if they	Implementations <bcp14>MUST</bcp14> ignore non-empty Notificatio
	don't understand its purpose.	n Data if they don't understand its purpose.
	</t>	</t>
	</section>	</section>
		<section numbered="true" toc="default">
	<section title="Using Intermediate Exchange">	<name>Using Intermediate Exchange</name>
	<t> If both peers indicated their support for the Intermediate E	<t> If both peers indicated their support for the Intermediate Exchange,
	xchange, the initiator may	the initiator may
	use one or more these exchanges to transfer additional data. Usi ng the Intermediate Exchange is optional;	use one or more these exchanges to transfer additional data. Usi ng the Intermediate Exchange is optional;

	the initiator may find it unnecessary even when support for this	the initiator may find it unnecessary even when support for this
	exchanged has been negotiated.	exchange has been negotiated.
	</t>	</t>
		<t> The Intermediate Exchange is denoted as IKE_INTERMEDIATE; its Exchang
	<t> The Intermediate Exchange is denoted as IKE_INTERMEDIATE, it	e Type is 43.
	s Exchange Type is 43.	</t>
	</t>	<artwork align="left" name="" type="" alt=""><![CDATA[

	<figure align="center">
	<artwork align="left"><![CDATA[
	Initiator Responder	Initiator Responder
	----------- -----------	----------- -----------
	HDR, ..., SK {...} -->	HDR, ..., SK {...} -->
	<-- HDR, ..., SK {...}	<-- HDR, ..., SK {...}
	]]></artwork>	]]></artwork>

	</figure>	<t> The initiator may use several IKE_INTERMEDIATE exchanges if necessar
		y.
	<t> The initiator may use several IKE_INTERMEDIATE exchanges if	Since window size is initially set to 1 for both peers (<xref ta
	necessary.	rget="RFC7296" sectionFormat="of" section="2.3" format="default"/>), these exch
	Since window size is initially set to one for both peers (Sectio	anges <bcp14>MUST</bcp14> be sequential
	n 2.3 of	and <bcp14>MUST</bcp14> all be completed before the IKE_AUTH exc
	<xref target="RFC7296" />), these exchanges MUST be sequential	hange is initiated.
	and MUST all be completed before the IKE_AUTH exchange is initia	The IKE SA <bcp14>MUST NOT</bcp14> be considered as established
	ted.	until the IKE_AUTH
	The IKE SA MUST NOT be considered as established until the IKE_A
	UTH
	exchange is successfully completed.	exchange is successfully completed.

	</t>	</t>
		<t> The Message IDs for IKE_INTERMEDIATE exchanges <bcp14>MUST</bcp14> b
	<t> The Message IDs for IKE_INTERMEDIATE exchanges MUST be chose	e chosen according to the standard
	n according to the standard	IKEv2 rule, described in <xref target="RFC7296" sectionFormat="o
	IKEv2 rule, described in the Section 2.2. of <xref target="RFC72	f" section="2.2" format="default"/>, i.e.,
	96" />, i.e.	it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for th
	it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for th	e next (if any), and so on.
	e next (if any) and so on.	Implementations <bcp14>MUST</bcp14> verify that Message IDs in t
	Implementations MUST verify that Message IDs in the IKE_INTERMED	he IKE_INTERMEDIATE messages they receive actually follow this rule.
	IATE messages they receive actually follow this rule.	The Message ID for the first pair of IKE_AUTH messages is one mo
	The Message ID for the first pair of the IKE_AUTH messages is on	re
	e more
	than the value used in the last IKE_INTERMEDIATE exchange.	than the value used in the last IKE_INTERMEDIATE exchange.

	</t>	</t>
		<t> If the presence of NAT is detected in the IKE_SA_INIT exchange via N
	<t> If the presence of NAT is detected in the IKE_SA_INIT exchan	AT_DETECTION_SOURCE_IP and
	ge via NAT_DETECTION_SOURCE_IP and
	NAT_DETECTION_DESTINATION_IP notifications, then the peers switc h to port 4500 in the first IKE_INTERMEDIATE exchange	NAT_DETECTION_DESTINATION_IP notifications, then the peers switc h to port 4500 in the first IKE_INTERMEDIATE exchange

	and use this port for all subsequent exchanges, as described in	and use this port for all subsequent exchanges, as described in
	Section 2.23 of <xref target="RFC7296" />.	<xref target="RFC7296" sectionFormat="of" section="2.23" format="default"/>.
	</t>	</t>
		<t> The content of the IKE_INTERMEDIATE exchange messages depends on the
	<t> The content of the IKE_INTERMEDIATE exchange messages depend	data being transferred
	s on the data being transferred
	and will be defined by specifications utilizing this exchange.	and will be defined by specifications utilizing this exchange.
	However, since the main motivation for the IKE_INTERMEDIATE exch ange is to avoid	However, since the main motivation for the IKE_INTERMEDIATE exch ange is to avoid
	IP fragmentation when large amounts of data need to be transferr ed	IP fragmentation when large amounts of data need to be transferr ed

	prior to IKE_AUTH, the Encrypted payload MUST be present in the	prior to the IKE_AUTH exchange, the Encrypted payload <bcp14>MUS
	IKE_INTERMEDIATE exchange messages and payloads containing large	T</bcp14> be present in the
	data	IKE_INTERMEDIATE exchange messages, and payloads containing larg
	MUST be placed inside it. This will allow IKE fragmentation	e amounts of data
	<xref target="RFC7383" /> to take place, provided it is supporte	<bcp14>MUST</bcp14> be placed inside it. This will allow IKE fra
	d	gmentation
		<xref target="RFC7383" format="default"/> to take place, provide
		d it is supported
	by the peers and negotiated in the initial exchange.	by the peers and negotiated in the initial exchange.

	</t>	</t>
		<t> <xref target="example" format="default"/> contains an example of usi
	<t> <xref target="example" /> contains an example of using an IK	ng an IKE_INTERMEDIATE exchange
	E_INTERMEDIATE exchange
	in creating an IKE SA.	in creating an IKE SA.

	</t>	</t>
	</section>	</section>
		<section numbered="true" toc="default">
	<section title="The IKE_INTERMEDIATE Exchange Protection and Authent	<name>The IKE_INTERMEDIATE Exchange Protection and Authentication</name>
	ication">	<section anchor="protection" numbered="true" toc="default">
	<section anchor="protection" title="Protection of the IKE_INTERM	<name>Protection of IKE_INTERMEDIATE Messages</name>
	EDIATE Messages">	<t> The keys SK_e[i/r] and SK_a[i/r] for the protection of IKE_INTERME
	<t> The keys SK_e[i/r] and SK_a[i/r] for the IKE_INTERMEDIAT	DIATE exchanges
	E exchanges protection	are computed in the standard fashion, as defined in <xref ta
	are computed in the standard fashion, as defined in the Sect	rget="RFC7296" sectionFormat="of" section="2.14" format="default"/>.
	ion 2.14 of <xref target="RFC7296" />.	</t>
	</t>	<t> Every subsequent IKE_INTERMEDIATE exchange uses the most recently
		calculated IKE SA keys before
	<t> Every subsequent IKE_INTERMEDIATE exchange uses the most
	recently calculated IKE SA keys before
	this exchange is started. So, the first IKE_INTERMEDIATE exc hange always uses SK_e[i/r] and SK_a[i/r] keys	this exchange is started. So, the first IKE_INTERMEDIATE exc hange always uses SK_e[i/r] and SK_a[i/r] keys
	that were computed as a result of the IKE_SA_INIT exchange. If additional key exchange is performed	that were computed as a result of the IKE_SA_INIT exchange. If additional key exchange is performed
	in the first IKE_INTERMEDIATE exchange, resulting in the upd ate of SK_e[i/r] and SK_a[i/r],	in the first IKE_INTERMEDIATE exchange, resulting in the upd ate of SK_e[i/r] and SK_a[i/r],
	then these updated keys are used for protection of the secon d IKE_INTERMEDIATE exchange.	then these updated keys are used for protection of the secon d IKE_INTERMEDIATE exchange.
	Otherwise, the original SK_e[i/r] and SK_a[i/r] keys are use d again, and so on.	Otherwise, the original SK_e[i/r] and SK_a[i/r] keys are use d again, and so on.

	</t>	</t>
		<t> Once all the IKE_INTERMEDIATE exchanges are completed, the most re
	<t> Once all the IKE_INTERMEDIATE exchanges are completed, t	cently calculated
	he most recently calculated	SK_e[i/r] and SK_a[i/r] keys are used for protection of the
	SK_e[i/r] and SK_a[i/r] keys are used for protection of the	IKE_AUTH exchange and all subsequent exchanges.
	IKE_AUTH and all the	</t>
	subsequent exchanges.	</section>
	</t>	<section numbered="true" toc="default">
	</section>	<name>Authentication of IKE_INTERMEDIATE Exchanges</name>
		<t> The IKE_INTERMEDIATE messages must be authenticated in the IKE_AUT
	<section title="Authentication of the IKE_INTERMEDIATE Exchanges	H exchange,
	">	which is performed by adding their content into the AUTH pay
	<t> The IKE_INTERMEDIATE messages must be authenticated in t	load calculation. It is anticipated that in many use cases, IKE_INTERMEDIATE
	he IKE_AUTH exchange,	messages will be fragmented using the IKE fragmentation <xre
	which is performed by adding their content into the AUTH pay	f target="RFC7383" format="default"/> mechanism. According to <xref target="RFC7
	load calculation. It is anticipated that in many use cases IKE_INTERMEDIATE	383" format="default"/>,
	messages will be fragmented using IKE fragmentation <xref ta
	rget="RFC7383" /> mechanism. According to <xref target="RFC7383" />,
	when IKE fragmentation is negotiated, the initiator may firs t send a request message in unfragmented form,	when IKE fragmentation is negotiated, the initiator may firs t send a request message in unfragmented form,

	but later turn on IKE fragmentation and re-send it fragmente	but later turn on IKE fragmentation and resend it fragmented
	d if no response is received after a few retransmissions.	if no response is received after a few retransmissions.
	In addition, peers may re-send fragmented message using diff	In addition, peers may resend a fragmented message using dif
	erent fragment sizes to perform simple PMTU discovery.	ferent fragment sizes to perform simple PMTU discovery.
	</t>	</t>
		<t> The requirement to support this behavior makes authentication chal
	<t> The requirement to support this behavior makes authentic	lenging: it is not appropriate to add
	ation challenging: it is not appropriate to add
	on-the-wire content of the IKE_INTERMEDIATE messages into th e AUTH payload calculation,	on-the-wire content of the IKE_INTERMEDIATE messages into th e AUTH payload calculation,

	because implementations are generally unaware in which form	because implementations are generally unaware of which form
	these messages are received by peers.	these messages are received by peers.
	Instead, a more complex scheme is used -- authentication is	Instead, a more complex scheme is used; authentication is pe
	performed by adding content of these messages before	rformed by adding the content of these messages before
	their encryption and possible fragmentation, so that data to	their encryption and possible fragmentation, so that the dat
	be authenticated doesn't depend on the form	a to be authenticated doesn't depend on the form
	the messages are delivered in.	the messages are delivered in.

	</t>	</t>
		<t>
		If one or more IKE_INTERMEDIATE exchanges took place, the definition of the
		blob to be signed (or MACed) from <xref target="RFC7296" sectionFormat="of"
		section="2.15" format="default"/> is modified as follows:


	<t> If any IKE_INTERMEDIATE exchange took place, the definit	</t>
	ion of the blob to be signed (or MAC'ed) from the Section 2.15 of
	<xref target="RFC7296" /> is modified as follows:
	</t>


	<figure align="center">	<!-- [rfced] Please let us know if the <artwork> in Section 3.3.2 should be
	<artwork align="left"><![CDATA[	updated to the <sourcecode> element. If so, let us know what
		"type" attribute should be entered from the list of permissiable types
		here: https://www.rfc-editor.org/materials/sourcecode-types.txt

		Note that it is permissable to leave the "type" attribute empty.

		tell her that the type attribute can allow readers to strip code from documents,
		but if no type is allowed and the content itself is not strictly "code", it is
		fine to leave as artwork.

		we updated to sourcecode

		-->

		<sourcecode><![CDATA[
	InitiatorSignedOctets = RealMsg1 \| NonceRData \| MACedIDForI \| IntAuth	InitiatorSignedOctets = RealMsg1 \| NonceRData \| MACedIDForI \| IntAuth
	ResponderSignedOctets = RealMsg2 \| NonceIData \| MACedIDForR \| IntAuth	ResponderSignedOctets = RealMsg2 \| NonceIData \| MACedIDForR \| IntAuth

	IntAuth = IntAuth_iN \| IntAuth_rN \| IKE_AUTH_MID	IntAuth = IntAuth_iN \| IntAuth_rN \| IKE_AUTH_MID

	IntAuth_i1 = prf(SK_pi1, IntAuth_i1A [\| IntAuth_i1P])	IntAuth_i1 = prf(SK_pi1, IntAuth_i1A [\| IntAuth_i1P])
	IntAuth_i2 = prf(SK_pi2, IntAuth_i1 \| IntAuth_i2A [\| IntAuth_i2P])	IntAuth_i2 = prf(SK_pi2, IntAuth_i1 \| IntAuth_i2A [\| IntAuth_i2P])
	IntAuth_i3 = prf(SK_pi3, IntAuth_i2 \| IntAuth_i3A [\| IntAuth_i3P])	IntAuth_i3 = prf(SK_pi3, IntAuth_i2 \| IntAuth_i3A [\| IntAuth_i3P])
	...	...
	IntAuth_iN = prf(SK_piN, IntAuth_iN-1 \| IntAuth_iNA [\| IntAuth_iNP])	IntAuth_iN = prf(SK_piN, IntAuth_iN-1 \| IntAuth_iNA [\| IntAuth_iNP])

	IntAuth_r1 = prf(SK_pr1, IntAuth_r1A [\| IntAuth_r1P])	IntAuth_r1 = prf(SK_pr1, IntAuth_r1A [\| IntAuth_r1P])
	IntAuth_r2 = prf(SK_pr2, IntAuth_r1 \| IntAuth_r2A [\| IntAuth_r2P])	IntAuth_r2 = prf(SK_pr2, IntAuth_r1 \| IntAuth_r2A [\| IntAuth_r2P])
	IntAuth_r3 = prf(SK_pr3, IntAuth_r2 \| IntAuth_r3A [\| IntAuth_r3P])	IntAuth_r3 = prf(SK_pr3, IntAuth_r2 \| IntAuth_r3A [\| IntAuth_r3P])
	...	...
	IntAuth_rN = prf(SK_prN, IntAuth_rN-1 \| IntAuth_rNA [\| IntAuth_rNP])	IntAuth_rN = prf(SK_prN, IntAuth_rN-1 \| IntAuth_rNA [\| IntAuth_rNP])

	]]></artwork>	]]></sourcecode>
	</figure>	<t> The essence of this modification is that a new chunk called "IntAu
		th" is appended to the string of octets that is signed (or MACed) by the peers.
	<t> The essence of this modification is that a new chunk cal
	led IntAuth is appended to the string of octets that is signed (or MAC'ed) by th
	e peers.
	IntAuth consists of three parts: IntAuth_iN, IntAuth_rN, and IKE_AUTH_MID.	IntAuth consists of three parts: IntAuth_iN, IntAuth_rN, and IKE_AUTH_MID.

	</t>	</t>
		<t> The IKE_AUTH_MID chunk is a value of the Message ID field from the
	<t> The IKE_AUTH_MID chunk is a value of the Message ID fiel	IKE Header of the first round of the IKE_AUTH exchange.
	d from the IKE Header of the first round of the IKE_AUTH exchange.	It is represented as a four-octet integer in network byte or
	It is represented as a four octet integer in network byte or	der (in other words, exactly as it appears on the wire).
	der (in other words, exactly as it appears on the wire).	</t>
	</t>


	<t> The IntAuth_iN and IntAuth_rN chunks each represent the	<t> The IntAuth_iN and IntAuth_rN chunks represent the cumulative resu
	cumulative result of applying the negotiated prf	lt of applying the negotiated Pseudorandom Function (PRF)
	to all IKE_INTERMEDIATE exchange messages sent during IKE SA	to all IKE_INTERMEDIATE exchange messages sent during IKE SA
	establishment by the initiator and the responder respectively.	establishment by the initiator and the responder, respectively.
	After the first IKE_INTERMEDIATE exchange is completed peers	After the first IKE_INTERMEDIATE exchange is complete, peers
	calculate the IntAuth_i1 value	calculate the IntAuth_i1 value
	by applying the negotiated prf to the content of the request	by applying the negotiated PRF to the content of the request
	message from this exchange and	message from this exchange and
	calculate the IntAuth_r1 value by applying the negotiated pr	calculate the IntAuth_r1 value by applying the negotiated PR
	f to the content of the response message.	F to the content of the response message.
	For every following IKE_INTERMEDIATE exchange (if any) peers	For every subsequent IKE_INTERMEDIATE exchange (if any), pee
	re-calculate these values as follows.	rs recalculate these values as follows:
	After the n-th exchange is completed they compute IntAuth_[i	after the nth exchange is complete, they compute IntAuth_[i/
	/r]n by applying the negotiated	r]n by applying the negotiated
	prf to the concatenation of IntAuth_[i/r](n-1) (computed for	PRF to the concatenation of IntAuth_[i/r](n-1) (computed for
	the previous IKE_INTERMEDIATE exchange) and	the previous IKE_INTERMEDIATE exchange) and
	the content of the request (for IntAuth_in) or response (for IntAuth_rn) messages from this exchange. After all IKE_INTERMEDIATE exchanges	the content of the request (for IntAuth_in) or response (for IntAuth_rn) messages from this exchange. After all IKE_INTERMEDIATE exchanges

	are over the resulted IntAuth_[i/r]N values (assuming N exch	are over, the resulted IntAuth_[i/r]N values (assuming N exc
	anges took place) are used in the computing the AUTH payload.	hanges took place) are used in computing the AUTH payload.
	</t>	</t>
		<t> For the purpose of calculating the IntAuth_[i/r]* values, the cont
	<t> For the purpose of calculating the IntAuth_[i/r]* values	ent of the IKE_INTERMEDIATE messages
	the content of the IKE_INTERMEDIATE messages	is represented as two chunks of data: mandatory IntAuth_[i/r
	is represented as two chunks of data: mandatory IntAuth_[i/r	]A, optionally followed by IntAuth_[i/r]P.
	]A optionally followed by IntAuth_[i/r]P.	</t>
	</t>	<t> The IntAuth_[i/r]*A chunk consists of the sequence of octets from
		the first octet of the IKE Header (not including the prepended four octets of ze
	<t> The IntAuth_[i/r]*A chunk consists of the sequence of oc	ros,
	tets from the first octet of the IKE Header (not including prepended four octets
	of zeros,
	if UDP encapsulation or TCP encapsulation of ESP packets is used) to the last octet of the generic header of the Encrypted payload.	if UDP encapsulation or TCP encapsulation of ESP packets is used) to the last octet of the generic header of the Encrypted payload.

	The scope of IntAuth_[i/r]*A is identical to the scope of As	The scope of IntAuth_[i/r]*A is identical to the scope of As
	sociated Data defined for use of AEAD algorithms in IKEv2	sociated Data defined for the use of AEAD algorithms in IKEv2
	(see Section 5.1 of <xref target="RFC5282" />), which is str	(see <xref target="RFC5282" sectionFormat="of" section="5.1"
	essed by using "A" suffix in its name. Note, that calculation of IntAuth_[i/r]*A	format="default"/>), which is stressed by using the "A" suffix in its name. Not
		e that calculation of IntAuth_[i/r]*A
	doesn't depend on whether an AEAD algorithm or a plain ciphe r is used in IKE SA.	doesn't depend on whether an AEAD algorithm or a plain ciphe r is used in IKE SA.

	</t>	</t>
		<t> The IntAuth_[i/r]*P chunk is present if the Encrypted payload is n
	<t> The IntAuth_[i/r]*P chunk is present if the Encrypted pa	ot empty. It consists of the content of the Encrypted payload
	yload is not empty. It consists of the content of the Encrypted payload	that is fully formed but not yet encrypted. The Initializati
	that is fully formed, but not yet encrypted. The Initializat	on Vector, Padding, Pad Length, and Integrity Checksum Data fields
	ion Vector, the Padding, the Pad Length and the Integrity Checksum Data fields	(see <xref target="RFC7296" sectionFormat="of" section="3.14
	(see Section 3.14 of <xref target="RFC7296" />) are not incl	" format="default"/>) are not included into the calculation.
	uded into the calculation.
	In other words, the IntAuth_[i/r]*P chunk is the inner paylo ads of the Encrypted payload in plaintext form,	In other words, the IntAuth_[i/r]*P chunk is the inner paylo ads of the Encrypted payload in plaintext form,

	which is stressed by using "P" suffix in its name.	which is stressed by using the "P" suffix in its name.
	</t>	</t>
		<figure anchor="layout">
	<figure align="center" anchor="layout" title="Data to Authen	<name>Data to Authenticate in the IKE_INTERMEDIATE Exchange Messages
	ticate in the IKE_INTERMEDIATE Exchange Messages">	</name>
	<artwork align="left"><![CDATA[	<artwork align="left" name="" type="" alt=""><![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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^
	\| IKE SA Initiator's SPI \| \| \|	\| IKE SA Initiator's SPI \| \| \|
	\| \| \| \|	\| \| \| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I \|	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I \|
	\| IKE SA Responder's SPI \| K \|	\| IKE SA Responder's SPI \| K \|
	\| \| E \|	\| \| E \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	\| Next Payload \| MjVer \| MnVer \| Exchange Type \| Flags \| H \|	\| Next Payload \| MjVer \| MnVer \| Exchange Type \| Flags \| H \|

	skipping to change at line 353 ¶	skipping to change at line 357 ¶
	~ Inner payloads (not yet encrypted) ~ P	~ Inner payloads (not yet encrypted) ~ P
	\| \| P \|	\| \| P \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v
	\| Padding (0-255 octets) \| Pad Length \| d	\| Padding (0-255 octets) \| Pad Length \| d
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|
	\| \| \|	\| \| \|
	~ Integrity Checksum Data ~ \|	~ Integrity Checksum Data ~ \|
	\| \| \|	\| \| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<t> <xref target="layout" format="default"/> illustrates the layout of
	<t> <xref target="layout" /> illustrates the layout of the I	the IntAuth_[i/r]*A (denoted as A)
	ntAuth_[i/r]*A (denoted as A)
	and the IntAuth_[i/r]*P (denoted as P) chunks in case the En crypted payload is not empty.	and the IntAuth_[i/r]*P (denoted as P) chunks in case the En crypted payload is not empty.

	</t>	</t>
		<t> For the purpose of prf calculation, the Length field in the IKE He
	<t> For the purpose of prf calculation the Length field in t	ader and the Payload Length
	he IKE Header and the Payload Length
	field in the Encrypted payload header are adjusted so that t hey don't count the lengths	field in the Encrypted payload header are adjusted so that t hey don't count the lengths

	of Initialization Vector, Integrity Checksum Data, Padding a	of Initialization Vector, Integrity Checksum Data, Padding,
	nd Pad Length fields.	and Pad Length fields.
	In other words, the Length field in the IKE Header (denoted	In other words, the Length field in the IKE Header (denoted
	as Adjusted Length in <xref target="layout" />)	as Adjusted Length in <xref target="layout" format="default"/>)
	is set to the sum of the lengths of IntAuth_[i/r]A and IntA uth_[i/r]P, and the Payload Length	is set to the sum of the lengths of IntAuth_[i/r]A and IntA uth_[i/r]P, and the Payload Length

	field in the Encrypted payload header (denoted as Adjusted P ayload Length in <xref target="layout" />)	field in the Encrypted payload header (denoted as Adjusted P ayload Length in <xref target="layout" format="default"/>)
	is set to the length of IntAuth_[i/r]*P plus the size of the Encrypted payload header (four octets).	is set to the length of IntAuth_[i/r]*P plus the size of the Encrypted payload header (four octets).

	</t>	</t>
		<t> The prf calculations <bcp14>MUST</bcp14> be applied to whole messa
	<t> The prf calculations MUST be applied to whole messages o	ges only, before possible IKE fragmentation.
	nly, before possible IKE fragmentation.	This ensures that the IntAuth will be the same regardless of
	This ensures that the IntAuth will be the same regardless of	whether or not IKE fragmentation takes place.
	whether IKE fragmentation takes place or not.	If the message was received in fragmented form, it <bcp14>MU
	If the message was received in fragmented form, it MUST be r	ST</bcp14> be reconstructed before calculating the prf as if it were received un
	econstructed before calculating the prf as if it were received unfragmented.	fragmented.
	While reconstructing, the RESERVED field in the reconstructe	While reconstructing, the RESERVED field in the reconstructe
	d Encrypted payload header MUST be set to the value of the RESERVED	d Encrypted payload header <bcp14>MUST</bcp14> be set to the value of the RESERV
	field in the Encrypted Fragment payload header from the firs	ED
	t fragment (with Fragment Number field set to 1).	field in the Encrypted Fragment payload header from the firs
	</t>	t fragment (with the Fragment Number field set to 1).
		</t>
	<t> Note that it is possible to avoid actual reconstruction	<t> Note that it is possible to avoid actual reconstruction of the mes
	of the message by incrementally calculating prf on	sage by incrementally calculating prf on
	decrypted (or ready to be encrypted) fragments. However, car e must be taken to properly replace the content of the Next Header and the Lengt h fields	decrypted (or ready to be encrypted) fragments. However, car e must be taken to properly replace the content of the Next Header and the Lengt h fields
	so that the result of computing the prf is the same as if it were computed on the reconstructed message.	so that the result of computing the prf is the same as if it were computed on the reconstructed message.

	</t>	</t>
		<t> Each calculation of IntAuth_[i/r]* uses its own keys SK_p[i/r]*, w
	<t> Each calculation of IntAuth_[i/r]* uses its own keys SK_	hich are the most recently updated SK_p[i/r] keys
	p[i/r]*, which are the most recently updated SK_p[i/r] keys
	available before the corresponded IKE_INTERMEDIATE exchange is started. The first IKE_INTERMEDIATE exchange	available before the corresponded IKE_INTERMEDIATE exchange is started. The first IKE_INTERMEDIATE exchange

	always uses the SK_p[i/r] keys that were computed in the IKE	always uses the SK_p[i/r] keys that were computed in the IKE
	_SA_INIT as SK_p[i/r]1. If the first IKE_INTERMEDIATE exchange performs	_SA_INIT exchange as SK_p[i/r]1. If the first IKE_INTERMEDIATE exchange performs
	additional key exchange resulting in SK_p[i/r] update, then	additional key exchange resulting in an SK_p[i/r] update, th
	this updated SK_p[i/r] are used as SK_p[i/r]2, otherwise the original	en these updated SK_p[i/r] keys are used as SK_p[i/r]2; otherwise, the original
	SK_p[i/r] are used, and so on. Note that if keys are updated	SK_p[i/r] keys are used, and so on. Note that if keys are up
	, then for any given IKE_INTERMEDIATE exchange the keys SK_e[i/r] and SK_a[i/r]	dated, then for any given IKE_INTERMEDIATE exchange, the keys SK_e[i/r] and SK_a
	used for protection of its messages (see <xref target="prote	[i/r]
	ction" />) and the keys SK_p[i/r] for its authentication are always	used for protection of its messages (see <xref target="prote
		ction" format="default"/>) and the key SK_p[i/r] for its authentication are alwa
		ys
	from the same generation.	from the same generation.

	</t>	</t>
	</section>
	</section>


	<section title="Error Handling in the IKE_INTERMEDIATE Exchange">	</section>
	<t> Since messages of the IKE_INTERMEDIATE exchange are not auth	</section>
	enticated until the IKE_AUTH exchange successfully	<section numbered="true" toc="default">
		<name>Error Handling in the IKE_INTERMEDIATE Exchange</name>
		<t> Since messages of the IKE_INTERMEDIATE exchange are not authenticate
		d until the IKE_AUTH exchange successfully
	completes, possible errors need to be handled with care. There i s a trade-off between providing	completes, possible errors need to be handled with care. There i s a trade-off between providing

	better diagnostics of the problem and risk of becoming part of D	better diagnostics of the problem and risk of becoming part of a
	oS attack.	DoS attack.
	Section 2.21.1 and 2.21.2 of <xref target="RFC7296" /> describe	Sections <xref target="RFC7296" sectionFormat="bare" section="2.
	how errors are handled	21.1" /> and <xref target="RFC7296" sectionFormat="bare" section="2.21.2" /> of
		<xref target="RFC7296" format="default"/> describe how errors are handled
	in initial IKEv2 exchanges; these considerations are also applie d to the IKE_INTERMEDIATE exchange	in initial IKEv2 exchanges; these considerations are also applie d to the IKE_INTERMEDIATE exchange

	with a qualification, that not all error notifications may appea r in the IKE_INTERMEDIATE	with the qualification that not all error notifications may appe ar in the IKE_INTERMEDIATE
	exchange (for example, errors concerning authentication are gene rally only applicable to the IKE_AUTH exchange).	exchange (for example, errors concerning authentication are gene rally only applicable to the IKE_AUTH exchange).

	</t>	</t>
	</section>	</section>
	</section>	</section>
		<section anchor="interaction" numbered="true" toc="default">
	<section anchor="interaction" title="Interaction with other IKEv2 Extens	<name>Interaction with Other IKEv2 Extensions</name>
	ions">	<t> The IKE_INTERMEDIATE exchanges <bcp14>MAY</bcp14> be used during the I
	<t> The IKE_INTERMEDIATE exchanges MAY be used during the IKEv2 Sess	KEv2 Session Resumption <xref target="RFC5723" format="default"/>
	ion Resumption <xref target="RFC5723" />	between the IKE_SESSION_RESUME and the IKE_AUTH exchanges. To be abl
	between the IKE_SESSION_RESUME and the IKE_AUTH exchanges. To be abl	e to use it, peers <bcp14>MUST</bcp14> negotiate
	e to use it peers MUST negotiate	support for Intermediate Exchange by including INTERMEDIATE_EXCHANGE
	support for intermediate exchange by including INTERMEDIATE_EXCHANGE	_SUPPORTED notifications in the
	_SUPPORTED notifications in the	IKE_SESSION_RESUME messages. Note that a flag denoting whether peers
	IKE_SESSION_RESUME messages. Note, that a flag whether peers support	supported the IKE_INTERMEDIATE exchange
	ed the IKE_INTERMEDIATE exchange
	is not stored in the resumption ticket and is determined each time f rom the IKE_SESSION_RESUME exchange.	is not stored in the resumption ticket and is determined each time f rom the IKE_SESSION_RESUME exchange.

	</t>	</t>
	</section>	</section>
		<section anchor="security" numbered="true" toc="default">
	<section anchor="security" title="Security Considerations">	<name>Security Considerations</name>
	<t> The data that is transferred by means of the IKE_INTERMEDIATE ex	<t> The data that is transferred by means of the IKE_INTERMEDIATE exchange
	changes is not authenticated	s is not authenticated
	until the subsequent IKE_AUTH exchange is completed. However, if the	until the subsequent IKE_AUTH exchange is complete. However, if the
	data is placed inside	data is placed inside
	the Encrypted payload, then it is protected from passive eavesdroppe rs. In addition, the peers	the Encrypted payload, then it is protected from passive eavesdroppe rs. In addition, the peers

	can be certain that they receive messages from the party they perfor med the IKE_SA_INIT with	can be certain that they receive messages from the party they perfor med the IKE_SA_INIT exchange with
	if they can successfully verify the Integrity Checksum Data of the E ncrypted payload.	if they can successfully verify the Integrity Checksum Data of the E ncrypted payload.

	</t>	</t>
		<t> The main application for the Intermediate Exchange is to transfer
		large amounts of data before an IKE SA is set up, without causing IP
		fragmentation. For that reason, it is expected that IKE fragmentation
		will be employed in IKE_INTERMEDIATE exchanges in most cases. <xref
		target="RFC7383" sectionFormat="of" section="5" format="default"/>
		contains security considerations for IKE fragmentation.
		</t>


	<t> The main application for the Intermediate Exchange is to transfe	<t> Since authentication of peers occurs only in the IKE_AUTH exchange, a
	r large amounts of data before	malicious initiator
	an IKE SA is set up, without causing IP fragmentation. For that reas	may use the Intermediate Exchange to mount a DoS attack on the respo
	on it is expected that	nder. In this case, it
	in most cases IKE fragmentation will be employed in the IKE_INTERMED	starts creating an IKE SA, negotiates using the Intermediate Exchang
	IATE exchanges. Section 5 of	es, and transfers a lot
	<xref target="RFC7383" /> contains security considerations for IKE f	of data to the responder that may also require computationally expen
	ragmentation.	sive processing.
	</t>	Then, it aborts the SA establishment before the IKE_AUTH exchange.
		Specifications utilizing the Intermediate Exchange <bcp14>MUST
		NOT</bcp14> allow an unlimited number of these exchanges to take
		place at the initiator's discretion. It is recommended that these
		specifications be defined in such a way that the responder would
		know (possibly via negotiation with the initiator) the exact
		number of these exchanges that need to take place.


	<t> Since authentication of the peers occurs only in the IKE_AUTH ex	In other words, after the IKE_SA_INIT exchange is
	change, malicious initiator	complete, it is preferred that both the initiator and the responder
	may use the Intermediate Exchange to mount Denial of Service attack	know the exact number of IKE_INTERMEDIATE exchanges they have to
	on responder. In this case it	perform; it is possible that some IKE_INTERMEDIATE exchanges are
	starts creating IKE SA, negotiates using the Intermediate Exchanges	optional and are performed at the initiator's discretion, but if a specification
	and transfers a lot	defines optional use of IKE_INTERMEDIATE, then the maximum number
	of data to the responder that may also require some computationally	of these exchanges must be hard capped by the corresponding specification.
	expensive processing.
	Then it aborts the SA establishment before the IKE_AUTH exchange.
	Specifications utilizing the Intermediate Exchange MUST NOT allow un
	limited number
	of these exchanges to take place on initiator's discretion. It is re
	commended
	that these specifications are defined in such a way, that the respon
	der would know
	(possibly via negotiation with the initiator) the exact number of th
	ese exchanges that need to take place.
	In other words: it is preferred that both the initiator and the resp
	onder know after the IKE_SA_INIT is completed
	the exact number of the IKE_INTERMEDIATE exchanges they have to perf
	orm;
	it is allowed that some IKE_INTERMEDIATE exchanges are optional and
	are performed
	on the initiator's discretion, but in this case the maximum number o
	f optional exchanges
	must be hard capped by the corresponding specification.
	In addition, <xref target="RFC8019" /> provides guidelines for the r
	esponder of how to deal with DoS attacks during IKE SA establishment.
	</t>


	<t> Note that if an attacker was able to break the key exchange in r	In addition, <xref target="RFC8019"
	eal time	format="default"/> provides guidelines for the responder of how to
	(e.g. by means of a Quantum Computer), then the security of the IKE_	deal with DoS attacks during IKE SA establishment.
	INTERMEDIATE exchange would degrade.	</t>
	In particular, such an attacker would be able both to read data cont	<t> Note that if an attacker was able to break the key exchange in real ti
	ained in the	me
	Encrypted payload and to forge it. The forgery would become evident	(e.g., by means of a quantum computer), then the security of the IKE
	in the IKE_AUTH	_INTERMEDIATE exchange would degrade.
		In particular, such an attacker would be able to both read data cont
		ained in the
		Encrypted payload and forge it. The forgery would become evident in
		the IKE_AUTH
	exchange (provided the attacker cannot break the employed authentica tion mechanism),	exchange (provided the attacker cannot break the employed authentica tion mechanism),

	but the ability to inject forged IKE_INTERMEDIATE exchange messages	but the ability to inject forged IKE_INTERMEDIATE exchange messages
	with valid ICV would allow	with a valid Integrity Check Value (ICV) would allow
	the attacker to mount a Denial-of-Service attack. Moreover, if in th	the attacker to mount a DoS attack. Moreover, in this situation, if
	is situation the negotiated	the negotiated
	prf was not secure against second preimage attack with known key, th	PRF was not secure against a second preimage attack with known key,
	en the attacker could	then the attacker could
	forge the IKE_INTERMEDIATE exchange messages without later being det ected in the IKE_AUTH exchange.	forge the IKE_INTERMEDIATE exchange messages without later being det ected in the IKE_AUTH exchange.

	To do this the attacker would find the same IntAuth_[i/r]* value for	To do this, the attacker would find the same IntAuth_[i/r]* value fo
	the forged message as for original.	r the forged message as for the original.
	</t>	</t>
	</section>	</section>
		<section anchor="iana" numbered="true" toc="default">
		<name>IANA Considerations</name>
		<t>This document defines a new Exchange Type in the "IKEv2 Exchange Types"
		registry:</t>


	<section anchor="iana" title="IANA Considerations">	<table align="left" anchor="IKE_INTERMEDIATE">
	<t>This document defines a new Exchange Type in the "IKEv2 Exchange	<name>IKEv2 Exchange Types</name>
	Types" registry:</t>	<thead>
	<figure align="center">	<tr>
	<artwork align="left"><![CDATA[	<th>Value</th>
	43 IKE_INTERMEDIATE	<th>Exchange Type</th>
	]]></artwork>	<th>Reference</th>
	</figure>	</tr>
	<t>This document also defines a new Notify Message Type in the "IKEv	</thead>
	2 Notify Message Types - Status Types" registry:</t>	<tbody>
	<figure align="center">	<tr>
	<artwork align="left"><![CDATA[	<td>43</td>
	16438 INTERMEDIATE_EXCHANGE_SUPPORTED	<td>IKE_INTERMEDIATE</td>
	]]></artwork>	<td>RFC 9242</td>
	</figure>	</tr>
	</section>


	<section anchor="interop" title="Implementation Status">	</tbody>
	<t> [Note to RFC Editor: please, remove this section before publishing	</table>
	RFC.]
	</t>


	<t> At the time of writing the -05 version of the draft there were at	<t>This document also defines a new Notify Message Type in the "IKEv2 Notify Mes
	least three independent	sage Types - Status Types" registry:</t>
	interoperable implementations of this specification from the following
	vendors:
	<list style="symbols">
	<t>ELVIS-PLUS</t>
	<t>strongSwan</t>
	<t>libreswan (only one IKE_INTERMEDIATE exchange is supported)</t>
	</list>
	</t>
	</section>


	<section title="Acknowledgements">	<table align="left" anchor="INTERMEDIATE_EXCHANGE_SUPPORTED">
	<t> The idea to use an intermediate exchange between IKE_SA_INIT and	<name>IKEv2 Notify Message Types - Status Types</name>
	IKE_AUTH was first suggested by Tero Kivinen.	<thead>
	He also helped with writing an example of using IKE_INTERMEDIATE exc	<tr>
	hange (shown in <xref target="example" />).	<th>Value</th>
	Scott Fluhrer and Daniel Van Geest identified a possible problem wit	<th>NOTIFY MESSAGES - STATUS TYPES</th>
	h authentication of the IKE_INTERMEDIATE exchange and helped to resolve it.	<th>Reference</th>
	Author is grateful to Tobias Brunner who raised good questions conce	</tr>
	rning authentication of the IKE_INTERMEDIATE exchange	</thead>
	and proposed how to make the size of authentication chunk constant r	<tbody>
	egardless of the number of exchanges.	<tr>
	Author is also grateful to Paul Wouters and to Benjamin Kaduk who su	<td>16438</td>
	ggested a lot of text improvements for the document.	<td>INTERMEDIATE_EXCHANGE_SUPPORTED</td>
	</t>	<td>RFC 9242</td>
	</section>	</tr>
	</middle>


	<back>	</tbody>
	<references title='Normative References'>	</table>
	&rfc2119;
	&rfc8174;
	&rfc7296;
	&rfc7383;
	</references>


	<references title='Informative References'>	</section>
	&rfc5282;
	&rfc5723;
	&rfc6928;
	&rfc8019;
	&rfc8229;
	</references>


	<section anchor="example" title="Example of IKE_INTERMEDIATE exchange">	</middle>
	<t> This appendix contains an example of the messages using IKE_INTERM	<back>
	EDIATE exchanges.	<references>
		<name>References</name>
		<references>
		<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"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7383.xml"/>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5282.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5723.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6928.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8019.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8229.xml"/>
		</references>
		</references>
		<section anchor="example" numbered="true" toc="default">
		<name>Example of IKE_INTERMEDIATE Exchange</name>
		<t> This appendix contains an example of the messages using IKE_INTERMEDIA
		TE exchanges.
	This appendix is purely informative; if it disagrees with the body of this document,	This appendix is purely informative; if it disagrees with the body of this document,
	the other text is considered correct.	the other text is considered correct.

	</t>	</t>
		<t> In this example, there is one IKE_SA_INIT exchange and two IKE_INTERME
	<t> In this example there is one IKE_SA_INIT exchange and two IKE_INTE	DIATE exchanges,
	RMEDIATE exchanges,
	followed by the IKE_AUTH exchange to authenticate all initial exchange s. The xxx in the HDR(xxx,MID=yyy)	followed by the IKE_AUTH exchange to authenticate all initial exchange s. The xxx in the HDR(xxx,MID=yyy)

	indicates the exchange type, and yyy tells the message id used for tha t exchange.	indicates the Exchange Type, and yyy indicates the Message ID used for that exchange.
	The keys used for each SK {} payload are indicated in the parenthesis after the SK.	The keys used for each SK {} payload are indicated in the parenthesis after the SK.

	Otherwise, the payload notation is the same as is used in <xref target	Otherwise, the payload notation is the same as is used in <xref target
	="RFC7296" />.	="RFC7296" format="default"/>.
	</t>	</t>
		<artwork align="left" name="" type="" alt=""><![CDATA[
	<figure align="center">
	<artwork align="left"><![CDATA[
	Initiator Responder	Initiator Responder
	----------- -----------	----------- -----------
	HDR(IKE_SA_INIT,MID=0),	HDR(IKE_SA_INIT,MID=0),
	SAi1, KEi, Ni,	SAi1, KEi, Ni,
	N(INTERMEDIATE_EXCHANGE_SUPPORTED) -->	N(INTERMEDIATE_EXCHANGE_SUPPORTED) -->

	<-- HDR(IKE_SA_INIT,MID=0),	<-- HDR(IKE_SA_INIT,MID=0),
	SAr1, KEr, Nr, [CERTREQ],	SAr1, KEr, Nr, [CERTREQ],
	N(INTERMEDIATE_EXCHANGE_SUPPORTED)	N(INTERMEDIATE_EXCHANGE_SUPPORTED)
	]]></artwork>	]]></artwork>

	</figure>	<t> At this point, peers calculate SK_* and store them as SK_*1.
		SK_e[i/r]1 and SK_a[i/r]1 will be used to protect the first IKE_INTERM
	<t> At this point peers calculate SK_* and store them as SK_*1.	EDIATE exchange,
	SK_e[i/r]1 and SK_a[i/r]1 will be used to protect the first IKE_INTERM
	EDIATE exchange
	and SK_p[i/r]1 will be used for its authentication.	and SK_p[i/r]1 will be used for its authentication.

	</t>	</t>
		<artwork align="left" name="" type="" alt=""><![CDATA[
	<figure align="center">
	<artwork align="left"><![CDATA[
	Initiator Responder	Initiator Responder
	----------- -----------	----------- -----------
	HDR(IKE_INTERMEDIATE,MID=1),	HDR(IKE_INTERMEDIATE,MID=1),
	SK(SK_ei1,SK_ai1) {...} -->	SK(SK_ei1,SK_ai1) {...} -->

	<Calculate IntAuth_i1 = prf(SK_pi1, ...)>	<Calculate IntAuth_i1 = prf(SK_pi1, ...)>

	<-- HDR(IKE_INTERMEDIATE,MID=1),	<-- HDR(IKE_INTERMEDIATE,MID=1),
	SK(SK_er1,SK_ar1) {...}	SK(SK_er1,SK_ar1) {...}

	<Calculate IntAuth_r1 = prf(SK_pr1, ...)>	<Calculate IntAuth_r1 = prf(SK_pr1, ...)>
	]]></artwork>	]]></artwork>

	</figure>	<t> If the SK_*1 keys are updated (e.g., as a result of a new key exchange
		) after completing this IKE_INTERMEDIATE exchange,
	<t> If after completing this IKE_INTERMEDIATE exchange the SK_*1 keys	then the peers store the updated keys as SK_*2; otherwise, they use SK
	are updated (e.g., as a result of a new key exchange),	_1 as SK_2.
	then the peers store the updated keys as SK_*2, otherwise they use SK_	SK_e[i/r]2 and SK_a[i/r]2 will be used to protect the second IKE_INTER
	1 as SK_2.	MEDIATE exchange,
	SK_e[i/r]2 and SK_a[i/r]2 will be used to protect the second IKE_INTER
	MEDIATE exchange
	and SK_p[i/r]2 will be used for its authentication.	and SK_p[i/r]2 will be used for its authentication.

	</t>	</t>
		<artwork align="left" name="" type="" alt=""><![CDATA[
	<figure align="center">
	<artwork align="left"><![CDATA[
	Initiator Responder	Initiator Responder
	----------- -----------	----------- -----------
	HDR(IKE_INTERMEDIATE,MID=2),	HDR(IKE_INTERMEDIATE,MID=2),
	SK(SK_ei2,SK_ai2) {...} -->	SK(SK_ei2,SK_ai2) {...} -->

	<Calculate IntAuth_i2 = prf(SK_pi2, ...)>	<Calculate IntAuth_i2 = prf(SK_pi2, ...)>

	<-- HDR(IKE_INTERMEDIATE,MID=2),	<-- HDR(IKE_INTERMEDIATE,MID=2),
	SK(SK_er2,SK_ar2) {...}	SK(SK_er2,SK_ar2) {...}

	<Calculate IntAuth_r2 = prf(SK_pr2, ...)>	<Calculate IntAuth_r2 = prf(SK_pr2, ...)>
	]]></artwork>	]]></artwork>

	</figure>	<t> If the SK_*2 keys are updated (e.g., as a result of a new key exchange
		) after completing the second IKE_INTERMEDIATE exchange,
	<t> If after completing the second IKE_INTERMEDIATE exchange the SK_*2	then the peers store the updated keys as SK_*3; otherwise, they use SK
	keys are updated (e.g., as a result of a new key exchange),	_2 as SK_3.
	then the peers store the updated keys as SK_*3, otherwise they use SK_
	2 as SK_3.
	SK_e[i/r]3 and SK_a[i/r]3 will be used to protect the IKE_AUTH exchang e, SK_p[i/r]3 will be used for authentication, and	SK_e[i/r]3 and SK_a[i/r]3 will be used to protect the IKE_AUTH exchang e, SK_p[i/r]3 will be used for authentication, and

	SK_d3 will be used for derivation of other keys (e.g. for Child SAs).	SK_d3 will be used for derivation of other keys (e.g., for Child SAs).
	</t>	</t>
		<artwork align="left" name="" type="" alt=""><![CDATA[
	<figure align="center">
	<artwork align="left"><![CDATA[
	Initiator Responder	Initiator Responder
	----------- -----------	----------- -----------
	HDR(IKE_AUTH,MID=3),	HDR(IKE_AUTH,MID=3),
	SK(SK_ei3,SK_ai3)	SK(SK_ei3,SK_ai3)
	{IDi, [CERT,] [CERTREQ,]	{IDi, [CERT,] [CERTREQ,]
	[IDr,] AUTH, SAi2, TSi, TSr} -->	[IDr,] AUTH, SAi2, TSi, TSr} -->
	<-- HDR(IKE_AUTH,MID=3),	<-- HDR(IKE_AUTH,MID=3),
	SK(SK_er3,SK_ar3)	SK(SK_er3,SK_ar3)
	{IDr, [CERT,] AUTH, SAr2, TSi, TSr}	{IDr, [CERT,] AUTH, SAr2, TSi, TSr}
	]]></artwork>	]]></artwork>

	</figure>	<t> In this example, two IKE_INTERMEDIATE exchanges took place; therefore,
		SK_3 keys would be used as SK_ keys for
	<t> In this example two IKE_INTERMEDIATE exchanges took place, therefo	further cryptographic operations in the context of the created IKE SA,
	re SK_3 keys would be used as SK_ keys for	as defined in <xref target="RFC7296" format="default"/>.
	further cryptographic operations in the context of the created IKE SA,	</t>
	as defined in <xref target="RFC7296" />.	</section>
	</t>	<section numbered="false" toc="default">
		<name>Acknowledgements</name>
		<t> The idea to use an Intermediate Exchange between the IKE_SA_INIT and I
		KE_AUTH exchanges was first suggested by <contact fullname="Tero Kivinen"/>.
		He also helped to write the example IKE_INTERMEDIATE exchange shown
		in <xref target="example" format="default"/>.
		<contact fullname="Scott Fluhrer"/> and <contact fullname="Daniel Va
		n Geest"/> identified a possible problem with authentication of the IKE_INTERMED
		IATE exchange and helped to resolve it.
		The author is grateful to <contact fullname="Tobias Brunner"/>, who
		raised good questions concerning authentication of the IKE_INTERMEDIATE exchange
		and proposed how to make the size of authentication chunks constant
		regardless of the number of exchanges.
		The author is also grateful to <contact fullname="Paul Wouters"/> an
		d <contact fullname="Benjamin Kaduk"/>, who suggested a lot of text improvements
		for the document.
		</t>
		</section>


	</section>	</back>
	</back>
	</rfc>	</rfc>

End of changes. 86 change blocks.
	580 lines changed or deleted	578 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/