< draft-smyslov-ipsecme-ikev2-aux-01.txt		draft-smyslov-ipsecme-ikev2-aux-02.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track July 27, 2018		Intended status: Standards Track December 3, 2018
	Expires: January 28, 2019		Expires: June 6, 2019
	Auxiliary Exchange in the IKEv2 Protocol		Intermediate Exchange in the IKEv2 Protocol
	draft-smyslov-ipsecme-ikev2-aux-01		draft-smyslov-ipsecme-ikev2-aux-02
	Abstract		Abstract
	This documents defines a new exchange, called Auxiliary Exchange, for		This documents defines a new exchange, called Intermediate Exchange,
	the Internet Key Exchange protocol Version 2 (IKEv2). This exchange		for the Internet Key Exchange protocol Version 2 (IKEv2). This
	can be used for transferring large amount of data in the process of		exchange can be used for transferring large amount of data in the
	IKEv2 Security Association (SA) establishment. Introducing Auxiliary		process of IKEv2 Security Association (SA) establishment.
	Exchange allows to re-use existing IKE Fragmentation mechanism, that		Introducing Intermediate Exchange allows re-using existing IKE
	helps to avoid IP fragmentation of large IKE messages, but cannot be		Fragmentation mechanism, that helps to avoid IP fragmentation of
	used in the initial IKEv2 exchange.		large IKE messages, but cannot be used in the initial IKEv2 exchange.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 28, 2019.		This Internet-Draft will expire on June 6, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3		2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
	3. Auxiliary Exchange Details . . . . . . . . . . . . . . . . . 3		3. Intermediate Exchange Details . . . . . . . . . . . . . . . . 3
	3.1. Support for Auxiliary Exchange Negotiation . . . . . . . 3		3.1. Support for Intermediate Exchange Negotiation . . . . . . 3
	3.2. Using Auxiliary Exchange . . . . . . . . . . . . . . . . 4		3.2. Using Intermediate Exchange . . . . . . . . . . . . . . . 4
	3.3. IKE_AUX Protection and Authentication . . . . . . . . . . 4		3.3. The INTERMEDIATE Exchange Protection and Authentication . 5
	3.3.1. Protection of IKE_AUX Messages . . . . . . . . . . . 4		3.3.1. Protection of the INTERMEDIATE Messages . . . . . . . 5
	3.3.2. Authentication of IKE_AUX Exchanges . . . . . . . . . 5		3.3.2. Authentication of the INTERMEDIATE Exchanges . . . . 5
	3.4. Error Handling in IKE_AUX . . . . . . . . . . . . . . . . 7		3.4. Error Handling in the INTERMEDIATE Exchange . . . . . . . 8
	4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 7		4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The Internet Key Exchange protocol version 2 (IKEv2) defined in		The Internet Key Exchange protocol version 2 (IKEv2) defined in
	[RFC7296] uses UDP as a transport for its messages. If size of the		[RFC7296] uses UDP as a transport for its messages. If size of the
	messages is large enough, IP fragmentation takes place that may		messages is large enough, IP fragmentation takes place, that may
	interfere badly with some network devices. The problem is described		interfere badly with some network devices. The problem is described
	in more detail in [RFC7383], which also defines an extension to the		in more detail in [RFC7383], which also defines an extension to the
	IKEv2 called IKE Fragmentation. This extension allows IKE messages		IKEv2 called IKE Fragmentation. This extension allows IKE messages
	to be fragmented at IKE level, eliminating possible issues caused by		to be fragmented at IKE level, eliminating possible issues caused by
	IP fragmentation. However, the IKE Fragmentation cannot be used in		IP fragmentation. However, the IKE Fragmentation cannot be used in
	the initial IKEv2 exchange, IKE_SA_INIT. This limitation in most		the initial IKEv2 exchange, IKE_SA_INIT. This limitation in most
	cases is not a problem, since the IKE_SA_INIT messages used to be		cases is not a problem, since the IKE_SA_INIT messages used to be
	small enough to not cause IP fragmentation.		small enough not to cause IP fragmentation.
	Recent progress in Quantum Computing has brought a concern that		Recent progress in Quantum Computing has brought a concern that
	classical Diffie-Hellman key exchange methods will become insecure in		classical Diffie-Hellman key exchange methods will become insecure in
	a relatively near future and should be replaced with Quantum Computer		a relatively near future and should be replaced with Quantum Computer
	(QC) resistant ones. Currently most of QC-resistant key exchange		(QC) resistant ones. Currently most of QC-resistant key exchange
	methods have large public keys. If these keys are exchanged in the		methods have large public keys. If these keys are exchanged in the
	IKE_SA_INIT, then most probably IP fragmentation would take place,		IKE_SA_INIT, then most probably IP fragmentation will take place,
	therefore all the problems caused by it would become inevitable.		therefore all the problems caused by it will become inevitable.
	A possible solution to the problem would be to use TCP as a transport		A possible solution to the problem would be to use TCP as a transport
	for IKEv2, as described in [RFC8229]. However this approach has		for IKEv2, as defined in [RFC8229]. However this approach has
	significant drawbacks and is intended to be a "last resort" when UDP		significant drawbacks and is intended to be a "last resort" when UDP
	transport is blocked by intermediate network devices.		transport is completely blocked by intermediate network devices.
	This document defines a new exchange for the IKEv2 protocol, called		This document defines a new exchange for the IKEv2 protocol, called
	Auxiliary Exchange or IKE_AUX. One or more these exchanges may take		Intermediate Exchange or INTERMEDIATE. One or more these exchanges
	place right after the IKE_SA_INIT exchange and prior to the IKE_AUTH		may take place right after the IKE_SA_INIT exchange and prior to the
	exchange. These exchanges may be used to exchange large amounts of		IKE_AUTH exchange. The INTERMEDIATE exchange messages can be
	data, which don't fit into the IKE_SA_INIT exchange without causing		fragmented using IKE Fragmentation mechanism, so these exchanges may
	IP fragmentation. The IKE_AUX messages can be fragmented using IKE		be used to transfer large amounts of data which don't fit into the
	Fragmentation mechanism.		IKE_SA_INIT exchange without causing IP fragmentation.
	While ability to transfer large public keys of QC-resistant key		While ability to transfer large public keys of QC-resistant key
	exchange methods was a primary motivation for the Auxiliary Exchange,		exchange methods is a primary motivation for introducing of the
	its application is not limited to this use case. This exchange may		Intermediate Exchange, its application is not limited to this use
	be used whenever some data need to be transferred before the IKE_AUTH		case. This exchange may be used whenever some data need to be
	exchange and for some reason the IKE_SA_INIT exchange is not suited		transferred before the IKE_AUTH exchange and for some reason the
	for this purpose. It is expected that separate specifications will		IKE_SA_INIT exchange is not suited for this purpose. This document
	define how and when the IKE_AUX exchange is used in the IKEv2.		defines the INTERMEDIATE exchange without tying it to any specific
			use case. It is expected that separate specifications will define
			for which purposes and how the INTERMEDIATE exchange is used in the
			IKEv2.
	2. Terminology and Notation		2. Terminology and Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Auxiliary Exchange Details		3. Intermediate Exchange Details
	3.1. Support for Auxiliary Exchange Negotiation		3.1. Support for Intermediate Exchange Negotiation
	The initiator indicates its support for Auxiliary Exchange by		The initiator indicates its support for Intermediate Exchange by
	including a notification of type AUX_EXCHANGE_SUPPORTED in the		including a notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in
	IKE_SA_INIT request message. If the responder also supports this		the IKE_SA_INIT request message. If the responder also supports this
	exchange, it includes this notification in the response message.		exchange, it includes this notification in the response message.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	HDR, SAi1, KEi, Ni,		HDR, SAi1, KEi, Ni,
	[N(AUX_EXCHANGE_SUPPORTED)] -->		[N(INTERMEDIATE_EXCHANGE_SUPPORTED)] -->
	<-- HDR, SAr1, KEr, Nr, [CERTREQ],		<-- HDR, SAr1, KEr, Nr, [CERTREQ],
	[N(AUX_EXCHANGE_SUPPORTED)]		[N(INTERMEDIATE_EXCHANGE_SUPPORTED)]
	The AUX_EXCHANGE_SUPPORTED is a Status Type IKEv2 notification. Its
	Notify Message Type is <TBA by IANA>. Protocol ID and SPI Size are
	both set to 0. This specification doesn't define any data this
	notification may contain, so the Notification Data is left empty.
	However, future enhancements of this specification may override this.
	Implementations MUST ignore the non-empty Notification Data if they		The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2
	don't understand its purpose.		notification. Its Notify Message Type is <TBA by IANA>. Protocol ID
			and SPI Size are both set to 0. This specification doesn't define
			any data this notification may contain, so the Notification Data is
			left empty. However, future enhancements of this specification may
			override this. Implementations MUST ignore the non-empty
			Notification Data if they don't understand its purpose.
	3.2. Using Auxiliary Exchange		3.2. Using Intermediate Exchange
	If both peers indicated their support for the Auxiliary Exchange, the		If both peers indicated their support for the Intermediate Exchange,
	initiator may use one or more these exchanges to transfer additional		the initiator may use one or more these exchanges to transfer
	data. Using the IKE_AUX exchange is optional, the initiator may find		additional data. Using the INTERMEDIATE exchange is optional, the
	it unnecessary after completing the IKE_SA_INIT exchange.		initiator may find it unnecessary after completing the IKE_SA_INIT
			exchange.
	The Auxiliary Exchange is denoted as IKE_AUX, its Exchange Type is		The Intermediate Exchange is denoted as INTERMEDIATE, its Exchange
	<TBA by IANA>.		Type is <TBA by IANA>.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	HDR, ..., SK {...} -->		HDR, ..., SK {...} -->
	<-- HDR, ..., SK {...}		<-- HDR, ..., SK {...}
	The initiator may use several IKE_AUX exchanges if necessary. Since		The initiator may use several INTERMEDIATE exchanges if necessary.
	initiator's Window Size is initially set to one (Section 2.3 of		Since initiator's Window Size is initially set to one (Section 2.3 of
	[RFC7296]), these exchanges MUST follow each other and MUST all be		[RFC7296]), these exchanges MUST follow each other and MUST all be
	completed before the IKE_AUTH exchange is initiated. The IKE SA MUST		completed before the IKE_AUTH exchange is initiated. The IKE SA MUST
	NOT be considered as established until the IKE_AUTH exchange is		NOT be considered as established until the IKE_AUTH exchange is
	successfully completed.		successfully completed.
	The Message IDs for the IKE_AUX exchanges MUST be chosen according to		The Message IDs for the INTERMEDIATE exchanges MUST be chosen
	the standard IKEv2 rule, described in the Section 2.2. of [RFC7296],		according to the standard IKEv2 rule, described in the Section 2.2.
	i.e. it is set to 1 for the first IKE_AUX exchange, 2 for the next		of [RFC7296], i.e. it is set to 1 for the first INTERMEDIATE
	(if any) and so on. The message ID for the first pair of the		exchange, 2 for the next (if any) and so on. The message ID for the
	IKE_AUTH messages is one more than the last IKE_AUX Message ID.		first pair of the IKE_AUTH messages is one more than the one that was
			used in the last INTERMEDIATE exchange.
	The content of the IKE_AUX messages depends on the data being		If the presence of NAT is detected in the IKE_SA_INIT exchange via
	transferred and will be defined by specifications utilizing this		NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
	exchange. However, since the main motivation for IKE_AUX is to avoid		notifications, then the peers MUST switch to port 4500 immediately
	IP fragmentation when large amount of data need to be transferred		once this exchange is completed, i.e. in the first INTERMEDIATE
	prior to IKE_AUTH, the Encrypted payload SHOULD be present in the
	IKE_AUX messages and payloads containing large data SHOULD be placed
	inside. This will allow IKE Fragmentation [RFC7383] to take place,
	provided it is supported by the peers and negotiated in the initial
	exchange.		exchange.
	3.3. IKE_AUX Protection and Authentication		The content of the INTERMEDIATE exchange messages depends on the data
			being transferred and will be defined by specifications utilizing
			this exchange. However, since the main motivation for the
			INTERMEDIATE exchange is to avoid IP fragmentation when large amount
			of data need to be transferred prior to IKE_AUTH, the Encrypted
			payload MUST be present in the INTERMEDIATE exchange messages and
			payloads containing large data MUST be placed inside. This will
			allow IKE Fragmentation [RFC7383] to take place, provided it is
			supported by the peers and negotiated in the initial exchange.
	3.3.1. Protection of IKE_AUX Messages		3.3. The INTERMEDIATE Exchange Protection and Authentication
			3.3.1. Protection of the INTERMEDIATE Messages
	The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the		The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the
	IKE_AUX exchanges are computed in a standard fashion, as defined in		INTERMEDIATE exchanges are computed in a standard fashion, as defined
	the Section 2.14 of [RFC7296]. Every subsequent IKE_AUX exchange		in the Section 2.14 of [RFC7296]. Every subsequent INTERMEDIATE
	uses the most recently calculated keys before this exchange is		exchange uses the most recently calculated keys before this exchange
	started. The first IKE_AUX exchange always uses SK_e[i/r] and		is started. The first INTERMEDIATE exchange always uses SK_e[i/r]
	SK_a[i/r] keys that were computed as result the IKE_SA_INIT exchange.		and SK_a[i/r] keys that were computed as result the IKE_SA_INIT
	If this IKE_AUX exchange performs additional key exchange resulting		exchange. If this INTERMEDIATE exchange performs additional key
	in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are		exchange resulting in the update of SK_e[i/r] and SK_a[i/r], then
	used for encryption and authentication of next IKE_AUX exchange,		these updated keys are used for encryption and authentication of next
	otherwise the current keys are used, and so on.		INTERMEDIATE exchange, otherwise the current keys are used, and so
			on.
	3.3.2. Authentication of IKE_AUX Exchanges		3.3.2. Authentication of the INTERMEDIATE Exchanges
	The data transferred in the IKE_AUX exchanges must be authenticated		The data transferred in the INTERMEDIATE exchanges must be
	in the IKE_AUTH exchange. For this purpose the definition of the		authenticated in the IKE_AUTH exchange. For this purpose the
	blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is		definition of the blob to be signed (or MAC'ed) from the Section 2.15
	modified as follows:		of [RFC7296] is modified as follows:
	InitiatorSignedOctets = RealMessage1 | AUX_I | NonceRData | MACedIDForI		InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI [| IntAuth]
	AUX_I = [AUX_PRF_I_1 [| AUX_PRF_I_2 [| AUX_PRF_I_3]]] ...		ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR [| IntAuth]
	AUX_PRF_I_1 = prf(SK_pi_1, IKE_AUX_I_1_H [| IKE_AUX_I_1_E])
	AUX_PRF_I_2 = prf(SK_pi_2, IKE_AUX_I_2_H [| IKE_AUX_I_2_E])		IntAuth = IntAuth_1 | [| IntAuth_2 [| IntAuth_3]] ...
	AUX_PRF_I_3 = prf(SK_pi_3, IKE_AUX_I_3_H [| IKE_AUX_I_3_E])
			IntAuth_1 = IntAuth_1_I | IntAuth_1_R
			IntAuth_2 = IntAuth_2_I | IntAuth_2_R
			IntAuth_3 = IntAuth_3_I | IntAuth_3_R
	...		...
	ResponderSignedOctets = RealMessage2 | AUX_R | NonceIData | MACedIDForR		IntAuth_1_I = prf(SK_pi_1, [IntAuth_1_I_P |] IntAuth_1_I_A)
	AUX_R = [AUX_PRF_R_1 [| AUX_PRF_R_2 [| AUX_PRF_R_3]]] ...		IntAuth_2_I = prf(SK_pi_2, [IntAuth_2_I_P |] IntAuth_2_I_A)
	AUX_PRF_R_1 = prf(SK_pr_1, IKE_AUX_R_1_H [| IKE_AUX_R_1_E])		IntAuth_3_I = prf(SK_pi_3, [IntAuth_3_I_P |] IntAuth_3_I_A)
	AUX_PRF_R_2 = prf(SK_pr_2, IKE_AUX_R_2_H [| IKE_AUX_R_2_E])
	AUX_PRF_R_3 = prf(SK_pr_3, IKE_AUX_R_3_H [| IKE_AUX_R_3_E])
	...		...
	AUX_PRF_I_1/AUX_PRF_R_1, AUX_PRF_I_2/AUX_PRF_R_2, AUX_PRF_I_3/		IntAuth_1_R = prf(SK_pr_1, [IntAuth_1_R_P |] IntAuth_1_R_A)
	AUX_PRF_R_1, etc. represent the results of applying the negotiated		IntAuth_2_R = prf(SK_pr_2, [IntAuth_2_R_P |] IntAuth_2_R_A)
	prf to the content of the IKE_AUX messages sent by the initiator		IntAuth_3_R = prf(SK_pr_3, [IntAuth_3_R_P |] IntAuth_3_R_A)
	(AUX_PRF_I_*) by the responder (AUX_PRF_R_*) in an order of		...
	increasing MessageIDs (i.e. in an order the IKE_AUX exchanges took
	place). The prf is applied to the two chunks of data: IKE_AUX_[I/		IntAuth_1_I/IntAuth_1_R, IntAuth_2_I/IntAuth_2_R, IntAuth_3_I/
	R]_*_H and optionally IKE_AUX_[I/R]_*_E. The IKE_AUX_[I/R]_*_H chunk		IntAuth_3_R, etc. represent the results of applying the negotiated
	lasts from the first octet of the IKE Header (not including prepended		prf to the content of the INTERMEDIATE messages sent by the initiator
	four octets of zeros, if any) to the last octet of the Encrypted		(IntAuth_*_I) and by the responder (IntAuth_*_R) in an order of
	Payload header (or to the end of the message in case the Encrypted		increasing Message IDs (i.e. in an order the INTERMEDIATE exchanges
	payload is not present). The IKE_AUX_[I/R]_*_E chunk is computed if		took place). The prf is applied to the two chunks of data: optional
	the Encrypted payload is present and consists of the not yet		IntAuth_*_[I/R]_P and mandatory IntAuth_*_[I/R]_A. The IntAuth_*_[I/
	encrypted content of the Encrypted payload, excluding Initialization		R]_A chunk lasts from the first octet of the IKE Header (not
	Vector, Padding, Pad Length and Integrity Checksum Data fields (see		including prepended four octets of zeros, if port 4500 is used) to
	3.14 of [RFC7296] for description of the Encrypted payload). In		the last octet of the Encrypted Payload header. The IntAuth_*_[I/
	other words, the IKE_AUX_[I/R]_*_E chunk is the inner payloads of the		R]_P chunk is present if the Encrypted payload is not empty. It
	Encrypted payload in plaintext form.		consists of the not yet encrypted content of the Encrypted payload,
			excluding Initialization Vector, Padding, Pad Length and Integrity
			Checksum Data fields (see 3.14 of [RFC7296] for description of the
			Encrypted payload). In other words, the IntAuth_*_[I/R]_P chunk is
			the inner payloads of the Encrypted payload in plaintext form.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d |
	| Message ID | r H		| Message ID | r A
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
	| Length | | |		| Length | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v |
	| | |		| | |
	~ Unencrypted payloads (if any) ~ |		~ Unencrypted payloads (if any) ~ |
	| | |		| | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |
	| Next Payload |C| RESERVED | Payload Length | | |		| Next Payload |C| RESERVED | Payload Length | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v
	| Initialization Vector | n		| Initialization Vector | n
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^
	| | r |		| | r |
	~ Inner payloads (not yet encrypted) ~ E		~ 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
	Figure 1: Data to Authenticate in IKE_AUX Exchange		Figure 1: Data to Authenticate in the INTERMEDIATE Exchange Messages
	Figure 1 illustrates the layout of the IKE_AUX_*_*_H (denoted as H)		Figure 1 illustrates the layout of the IntAuth_*_[I/R]_P (denoted as
	and the IKE_AUX_*_*_E (denoted as E) chunks in case the Encrypted		P) and the IntAuth_*_[I/R]_A (denoted as A) chunks in case the
	payload is present in the message. Note, that while the Encrypted		Encrypted payload is not empty.
	payload is not required to be present in the IKE_AUX messages, the
	intended purpose of this exchange is to allow transferring large
	amount of data utilizing IKE fragmentation, so in most cases the
	Encrypted payload will be present.
	The calculations are applied to whole messages only, before possible		The calculations are applied to whole messages only, before possible
	fragmentation. This ensures that the AUX_I/AUX_R will be the same		fragmentation. This ensures that the IntAuth will be the same
	regardless of whether fragmentation takes place or not ([RFC7383]		regardless of whether fragmentation takes place or not ([RFC7383]
	allows sending first unfragmented message and then trying		allows sending first unfragmented message and then trying
	fragmentation in case of no reply).		fragmentation in case of no reply).
	Each calculation of AUX_PRF_[I/R]_* uses its own key SK_p[i/r]_*,		Each calculation of IntAuth_*_[I/R] uses its own key SK_p[i/r]_*,
	which is the most recently updated SK_p[i/r] key available before the		which is the most recently updated SK_p[i/r] key available before the
	corresponded IKE_AUX exchange is started. The first IKE_AUX exchange		corresponded INTERMEDIATE exchange is started. The first
	always uses SK_p[i/r] key that was computed in the IKE_SA_INIT as		INTERMEDIATE exchange always uses SK_p[i/r] key that was computed in
	SK_p[i/r]_1. If the first IKE_AUX exchange performs additional key		the IKE_SA_INIT as SK_p[i/r]_1. If the first INTERMEDIATE exchange
	exchange resulting in SK_p[i/r] update, then this updated SK_p[i/r]		performs additional key exchange resulting in SK_p[i/r] update, then
	is used as SK_p[i/r]_2, otherwise the original SK_p[i/r] is used, and		this updated SK_p[i/r] is used as SK_p[i/r]_2, otherwise the original
	so on. Note, that if keys are updated then for any given IKE_AUX		SK_p[i/r] is used, and so on. Note, that if keys are updated then
	exchange the keys SK_e[i/r] and SK_a[i/r] used for IKE_AUX messages		for any given INTERMEDIATE exchange the keys SK_e[i/r] and SK_a[i/r]
	protection (see Section 3.3.1) and the keys SK_p[i/r] for their		used for its messages protection (see Section 3.3.1) and the keys
	authentication are always from the same generation.		SK_p[i/r] for its authentication are always from the same generation.
	3.4. Error Handling in IKE_AUX		3.4. Error Handling in the INTERMEDIATE Exchange
	Since IKE_AUX messages are not authenticated until the IKE_AUTH		Since messages of the INTERMEDIATE exchange are not authenticated
	exchange successfully completes, possible errors need to be handled		until the IKE_AUTH exchange successfully completes, possible errors
	carefully. There is a trade-off between providing a better		need to be handled carefully. There is a trade-off between providing
	diagnostics of the problem and a risk to become a part of DoS attack.		a better diagnostics of the problem and a risk to become a part of
	See Section 2.21.1 and 2.21.2 of [RFC7296] describe how errors are		DoS attack. See Section 2.21.1 and 2.21.2 of [RFC7296] describe how
	handled in initial IKEv2 exchanges, these considerations are applied		errors are handled in initial IKEv2 exchanges, these considerations
	to an IKE_AUX exchange too.		are applied to the INTERMEDIATE exchange too.
	4. Interaction with other IKEv2 Extensions		4. Interaction with other IKEv2 Extensions
	The IKE_AUTH exchanges may be used in the IKEv2 Session Resumption		The INTERMEDIATE exchanges MAY be used in the IKEv2 Session
	[RFC5723] between the IKE_SESSION_RESUME and the IKE_AUTH exchanges.		Resumption [RFC5723] between the IKE_SESSION_RESUME and the IKE_AUTH
			exchanges.
	5. Security Considerations		5. Security Considerations
	The data that is transferred by means of the IKE_AUX exchanges is not		The data that is transferred by means of the INTERMEDIATE exchanges
	authenticated until the subsequent IKE_AUTH exchange is completed.		is not authenticated until the subsequent IKE_AUTH exchange is
	However, if the data is placed inside the Encrypted payload, then it		completed. However, if the data is placed inside the Encrypted
	is protected from passive eavesdroppers. In addition the peers can		payload, then it is protected from passive eavesdroppers. In
	be certain that they receives messages from the party he/she		addition the peers can be certain that they receives messages from
	performed the IKE_SA_INIT with if they can successfully verify the		the party he/she performed the IKE_SA_INIT with if they can
	Integrity Checksum Data of the Encrypted payload.		successfully verify the Integrity Checksum Data of the Encrypted
			payload.
	The main application for Auxiliary Exchange is to transfer large		The main application for Intermediate Exchange is to transfer large
	amount of data before IKE SA is set up without causing IP		amount of data before IKE SA is set up without causing IP
	fragmentation. For that reason it is expected that in most cases IKE		fragmentation. For that reason it is expected that in most cases IKE
	Fragmentation will be employed in the IKE_AUX exchanges. Section 5		Fragmentation will be employed in the INTERMEDIATE exchanges.
	of [RFC7383] contains security considerations for IKE Fragmentation.		Section 5 of [RFC7383] contains security considerations for IKE
			Fragmentation.
	Note, that if an attacker was able to break key exchange in real time		Note, that if an attacker was able to break key exchange in real time
	(e.g. by means of Quantum Computer), then the security of IKE_AUX		(e.g. by means of Quantum Computer), then the security of the
	would degrade. In particular, such an attacker would be able both to		INTERMEDIATE exchange would degrade. In particular, such an attacker
	read data contained in the Encrypted payload and to forge it. The		would be able both to read data contained in the Encrypted payload
	forgery would become evident in the IKE_AUTH exchange (provided the		and to forge it. The forgery would become evident in the IKE_AUTH
	attacker cannot break employed authentication mechanism), but the		exchange (provided the attacker cannot break employed authentication
	ability to inject forged IKE_AUX messages with valid ICV would allow		mechanism), but the ability to inject forged the INTERMEDIATE
	the attacker to mount Denial-of-Service attack. Moreover, if in this		exchange messages with valid ICV would allow the attacker to mount
	situation the negotiated prf was not secure against preimage attack		Denial-of-Service attack. Moreover, if in this situation the
	with known key, then the attacker could forge IKE_AUX messages		negotiated prf was not secure against preimage attack with known key,
			then the attacker could forge the INTERMEDIATE exchange messages
	without later being detected in the IKE_AUTH exchange. To do this		without later being detected in the IKE_AUTH exchange. To do this
	the attacker should find the same AUX_PRF_*_* value for the forged		the attacker should find the same IntAuth_*_[I|R] value for the
	message as for original.		forged message as for original.
	6. IANA Considerations		6. IANA Considerations
	This document defines a new Exchange Type in the "IKEv2 Exchange		This document defines a new Exchange Type in the "IKEv2 Exchange
	Types" registry:		Types" registry:
	<TBA> IKE_AUX		<TBA> INTERMEDIATE
	This document also defines a new Notify Message Types in the "Notify		This document also defines a new Notify Message Types in the "Notify
	Message Types - Status Types" registry:		Message Types - Status Types" registry:
	<TBA> AUX_EXCHANGE_SUPPORTED		<TBA> INTERMEDIATE_EXCHANGE_SUPPORTED
	7. Acknowledgements		7. Acknowledgements
	The idea to use an intermediate exchange between IKE_SA_INIT and		The idea to use an intermediate exchange between IKE_SA_INIT and
	IKE_AUTH was first suggested by Tero Kivinen. Scott Fluhrer and		IKE_AUTH was first suggested by Tero Kivinen. Scott Fluhrer and
	Daniel Van Geest identified a possible problem with authentication of		Daniel Van Geest identified a possible problem with authentication of
	IKE_AUX exchange and helped to resolve it.		the INTERMEDIATE exchange and helped to resolve it.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
End of changes. 52 change blocks.
	186 lines changed or deleted		202 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/