< draft-ietf-ipsecme-ikev2-intermediate-01.txt		draft-ietf-ipsecme-ikev2-intermediate-02.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track June 27, 2019		Intended status: Standards Track July 24, 2019
	Expires: December 29, 2019		Expires: January 25, 2020
	Intermediate Exchange in the IKEv2 Protocol		Intermediate Exchange in the IKEv2 Protocol
	draft-ietf-ipsecme-ikev2-intermediate-01		draft-ietf-ipsecme-ikev2-intermediate-02
	Abstract		Abstract
	This documents defines a new exchange, called Intermediate Exchange,		This documents defines a new exchange, called Intermediate Exchange,
	for the Internet Key Exchange protocol Version 2 (IKEv2). This		for the Internet Key Exchange protocol Version 2 (IKEv2). This
	exchange can be used for transferring large amount of data in the		exchange can be used for transferring large amount of data in the
	process of IKEv2 Security Association (SA) establishment.		process of IKEv2 Security Association (SA) establishment.
	Introducing Intermediate Exchange allows re-using existing IKE		Introducing Intermediate Exchange allows re-using existing IKE
	Fragmentation mechanism, that helps to avoid IP fragmentation of		Fragmentation mechanism, that helps to avoid IP fragmentation of
	large IKE messages, but cannot be used in the initial IKEv2 exchange.		large IKE messages, but cannot be used in the initial IKEv2 exchange.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 December 29, 2019.		This Internet-Draft will expire on January 25, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3		2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
	3. Intermediate Exchange Details . . . . . . . . . . . . . . . . 3		3. Intermediate Exchange Details . . . . . . . . . . . . . . . . 3
	3.1. Support for Intermediate Exchange Negotiation . . . . . . 3		3.1. Support for Intermediate Exchange Negotiation . . . . . . 3
	3.2. Using Intermediate Exchange . . . . . . . . . . . . . . . 4		3.2. Using Intermediate Exchange . . . . . . . . . . . . . . . 4
	3.3. The IKE_INTERMEDIATE Exchange Protection and		3.3. The IKE_INTERMEDIATE Exchange Protection and
	Authentication . . . . . . . . . . . . . . . . . . . . . 5		Authentication . . . . . . . . . . . . . . . . . . . . . 5
	3.3.1. Protection of the IKE_INTERMEDIATE Messages . . . . . 5		3.3.1. Protection of the IKE_INTERMEDIATE Messages . . . . . 5
	3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges . . 5		3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges . . 5
	3.4. Error Handling in the IKE_INTERMEDIATE Exchange . . . . . 8		3.4. Error Handling in the IKE_INTERMEDIATE Exchange . . . . . 8
	4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 8		4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
	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
	skipping to change at page 3, line 47 ¶		skipping to change at page 3, line 47 ¶
	3. Intermediate Exchange Details		3. Intermediate Exchange Details
	3.1. Support for Intermediate Exchange Negotiation		3.1. Support for Intermediate Exchange Negotiation
	The initiator indicates its support for Intermediate Exchange by		The initiator indicates its support for Intermediate Exchange by
	including a notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in		including a notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in
	the 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,		----------- -----------
	[N(INTERMEDIATE_EXCHANGE_SUPPORTED)] -->		HDR, SAi1, KEi, Ni,
	<-- HDR, SAr1, KEr, Nr, [CERTREQ],		[N(INTERMEDIATE_EXCHANGE_SUPPORTED)] -->
			<-- HDR, SAr1, KEr, Nr, [CERTREQ],
	[N(INTERMEDIATE_EXCHANGE_SUPPORTED)]		[N(INTERMEDIATE_EXCHANGE_SUPPORTED)]
	The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2		The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2
	notification. Its Notify Message Type is <TBA by IANA>. Protocol ID		notification. Its Notify Message Type is <TBA by IANA>. Protocol ID
	and SPI Size are both set to 0. This specification doesn't define		and SPI Size are both set to 0. This specification doesn't define
	any data this notification may contain, so the Notification Data is		any data this notification may contain, so the Notification Data is
	left empty. However, future enhancements of this specification may		left empty. However, future enhancements of this specification may
	override this. Implementations MUST ignore the non-empty		override this. Implementations MUST ignore the non-empty
	Notification Data if they don't understand its purpose.		Notification Data if they don't understand its purpose.
	skipping to change at page 5, line 40 ¶		skipping to change at page 5, line 40 ¶
	blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is		blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is
	modified as follows:		modified as follows:
	InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI [| IntAuth]		InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI [| IntAuth]
	ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR [| IntAuth]		ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR [| IntAuth]
	IntAuth = IntAuth_1 | [| IntAuth_2 [| IntAuth_3]] ...		IntAuth = IntAuth_1 | [| IntAuth_2 [| IntAuth_3]] ...
	IntAuth_1 = IntAuth_1_I | IntAuth_1_R		IntAuth_1 = IntAuth_1_I | IntAuth_1_R
	IntAuth_2 = IntAuth_2_I | IntAuth_2_R		IntAuth_2 = IntAuth_2_I | IntAuth_2_R
	IntAuth_3 = IntAuth_3_I | IntAuth_3_R		IntAuth_3 = IntAuth_3_I | IntAuth_3_R...
	...
	IntAuth_1_I = prf(SK_pi_1, [IntAuth_1_I_P |] IntAuth_1_I_A)		IntAuth_1_I = prf(SK_pi_1, IntAuth_1_I_A [| IntAuth_1_I_P])
	IntAuth_2_I = prf(SK_pi_2, [IntAuth_2_I_P |] IntAuth_2_I_A)		IntAuth_2_I = prf(SK_pi_2, IntAuth_2_I_A [| IntAuth_2_I_P])
	IntAuth_3_I = prf(SK_pi_3, [IntAuth_3_I_P |] IntAuth_3_I_A)		IntAuth_3_I = prf(SK_pi_3, IntAuth_3_I_A [| IntAuth_3_I_P])
	...		...
	IntAuth_1_R = prf(SK_pr_1, [IntAuth_1_R_P |] IntAuth_1_R_A)		IntAuth_1_R = prf(SK_pr_1, IntAuth_1_R_A [| IntAuth_1_R_P])
	IntAuth_2_R = prf(SK_pr_2, [IntAuth_2_R_P |] IntAuth_2_R_A)		IntAuth_2_R = prf(SK_pr_2, IntAuth_2_R_A [| IntAuth_2_R_P])
	IntAuth_3_R = prf(SK_pr_3, [IntAuth_3_R_P |] IntAuth_3_R_A)		IntAuth_3_R = prf(SK_pr_3, IntAuth_3_R_A [| IntAuth_3_R_P])
	...		...
	IntAuth_1_I/IntAuth_1_R, IntAuth_2_I/IntAuth_2_R, IntAuth_3_I/		IntAuth_1_I/IntAuth_1_R, IntAuth_2_I/IntAuth_2_R, IntAuth_3_I/
	IntAuth_3_R, etc. represent the results of applying the negotiated		IntAuth_3_R, etc. represent the results of applying the negotiated
	prf to the content of the IKE_INTERMEDIATE messages sent by the		prf to the content of the IKE_INTERMEDIATE messages sent by the
	initiator (IntAuth_*_I) and by the responder (IntAuth_*_R) in an		initiator (IntAuth_*_I) and by the responder (IntAuth_*_R) in an
	order of increasing Message IDs (i.e. in an order the		order of increasing Message IDs (i.e. in an order the
	IKE_INTERMEDIATE exchanges took place). The prf is applied to the		IKE_INTERMEDIATE exchanges took place). The prf is applied to the
	two chunks of data: optional IntAuth_*_[I/R]_P and mandatory		two chunks of data: mandatory IntAuth_*_[I/R]_A and optional
	IntAuth_*_[I/R]_A. The IntAuth_*_[I/R]_A chunk lasts from the first		IntAuth_*_[I/R]_P. The IntAuth_*_[I/R]_A chunk lasts from the first
	octet of the IKE Header (not including prepended four octets of		octet of the IKE Header (not including prepended four octets of
	zeros, if port 4500 is used) to the last octet of the Encrypted		zeros, if port 4500 is used) to the last octet of the Encrypted
	Payload header. The IntAuth_*_[I/R]_P chunk is present if the		Payload header. The IntAuth_*_[I/R]_P chunk is present if the
	Encrypted payload is not empty. It consists of the not yet encrypted		Encrypted payload is not empty. It consists of the not yet encrypted
	content of the Encrypted payload, excluding Initialization Vector,		content of the Encrypted payload, excluding Initialization Vector,
	Padding, Pad Length and Integrity Checksum Data fields (see 3.14 of		Padding, Pad Length and Integrity Checksum Data fields (see 3.14 of
	[RFC7296] for description of the Encrypted payload). In other words,		[RFC7296] for description of the Encrypted payload). In other words,
	the IntAuth_*_[I/R]_P chunk is the inner payloads of the Encrypted		the IntAuth_*_[I/R]_P chunk is the inner payloads of the Encrypted
	payload in plaintext form.		payload in plaintext form.
	skipping to change at page 7, line 18 ¶		skipping to change at page 7, line 18 ¶
	| 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 A		| Message ID | r A
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
	| Length | | |		| Adjusted Length | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v |
	| | |		| | |
	~ Unencrypted payloads (if any) ~ |		~ Unencrypted payloads (if any) ~ |
	| | |		| | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |
	| Next Payload |C| RESERVED | Payload Length | | |		| Next Payload |C| RESERVED | Adjusted Payload Length | | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v
	| Initialization Vector | n		| Initialization Vector | n
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^
	| | r |		| | r |
	~ 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
	Figure 1: Data to Authenticate in the IKE_INTERMEDIATE Exchange		Figure 1: Data to Authenticate in the IKE_INTERMEDIATE Exchange
	Messages		Messages
	Figure 1 illustrates the layout of the IntAuth_*_[I/R]_P (denoted as		Figure 1 illustrates the layout of the IntAuth_*_[I/R]_P (denoted as
	P) and the IntAuth_*_[I/R]_A (denoted as A) chunks in case the		P) and the IntAuth_*_[I/R]_A (denoted as A) chunks in case the
	Encrypted payload is not empty.		Encrypted payload is not empty.
	The calculations are applied to whole messages only, before possible		For the purpose of prf calculation the Length field in the IKE header
	IKE Fragmentation. This ensures that the IntAuth will be the same		and the Payload Length field in the Encrypted Payload header are
	regardless of whether IKE Fragmentation takes place or not. This is		adjusted so that they don't count the lengths of Initialization
	important since [RFC7383] allows sending first unfragmented message		Vector, Integrity Checksum Data and Padding (along with Pad Length
	and then resending it in fragmented form in case of no reply is		field). In other words, the Length field in the IKE header (denoted
	received.		as Adjusted Length in Figure 1) is set to the sum of the lengths of
			IntAuth_*_[I/R]_A and IntAuth_*_[I/R]_P, and the Payload Length field
			in the Encrypted Payload header (denoted as Adjusted Payload Length
			in Figure 1) is set to the length of IntAuth_*_[I/R]_P plus the size
			of the Payload header (four octets).
			The prf calculations MUST be applied to whole messages only, before
			possible IKE Fragmentation. This ensures that the IntAuth will be
			the same regardless of whether IKE Fragmentation takes place or not.
			This is important since [RFC7383] allows sending first unfragmented
			message and then resending it in fragmented form in case of no reply
			is received. If the message was received in fragmented form, it
			should be reconstructed before calculating prf as if it were received
			unfragmented. The RESERVED field in the recontructed Encrypted
			Payload header MUST be set to the value of the RESERVED field in the
			Encrypted Fragment payload header from the first fragment (that with
			Fragment Number equal to 1).
			Note that it is possible to avoid actual reconstruction of the
			message by incrementally calculating prf on decrypted fragments.
			However care must be taken to properly replace the content of the
			Next Header and the Length fields so that the result of computing prf
			is the same as if it were computed on reconstructed message.
	Each calculation of IntAuth_*_[I/R] uses its own keys SK_p[i/r]_*,		Each calculation of IntAuth_*_[I/R] uses its own keys SK_p[i/r]_*,
	which are the most recently updated SK_p[i/r] keys available before		which are the most recently updated SK_p[i/r] keys available before
	the corresponded IKE_INTERMEDIATE exchange is started. The first		the corresponded IKE_INTERMEDIATE exchange is started. The first
	IKE_INTERMEDIATE exchange always uses SK_p[i/r] keys that were		IKE_INTERMEDIATE exchange always uses SK_p[i/r] keys that were
	computed in the IKE_SA_INIT as SK_p[i/r]_1. If the first		computed in the IKE_SA_INIT as SK_p[i/r]_1. If the first
	IKE_INTERMEDIATE exchange performs additional key exchange resulting		IKE_INTERMEDIATE exchange performs additional key exchange resulting
	in SK_p[i/r] update, then this updated SK_p[i/r] are used as SK_p[i/		in SK_p[i/r] update, then this updated SK_p[i/r] are used as SK_p[i/
	r]_2, otherwise the original SK_p[i/r] are used, and so on. Note,		r]_2, otherwise the original SK_p[i/r] are used, and so on. Note,
	that if keys are updated then for any given IKE_INTERMEDIATE exchange		that if keys are updated then for any given IKE_INTERMEDIATE exchange
	skipping to change at page 9, line 40 ¶		skipping to change at page 10, line 22 ¶
	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> INTERMEDIATE_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
	the IKE_INTERMEDIATE exchange and helped to resolve it.		the IKE_INTERMEDIATE exchange and helped to resolve it. Author is
			also grateful to Tobias Brunner for raising good points concerning
			authentication of the IKE_INTERMEDIATE exchange.
	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,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
End of changes. 13 change blocks.
	35 lines changed or deleted		59 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/