< draft-ietf-ipsecme-ikev2-intermediate-03.txt		draft-ietf-ipsecme-ikev2-intermediate-04.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track December 16, 2019		Intended status: Standards Track June 15, 2020
	Expires: June 18, 2020		Expires: December 17, 2020
	Intermediate Exchange in the IKEv2 Protocol		Intermediate Exchange in the IKEv2 Protocol
	draft-ietf-ipsecme-ikev2-intermediate-03		draft-ietf-ipsecme-ikev2-intermediate-04
	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 June 18, 2020.		This Internet-Draft will expire on December 17, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	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
	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,		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)]
	The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2		The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2
	notification. Its Notify Message Type is 16438. Protocol ID and SPI		notification. Its Notify Message Type is 16438. Protocol ID and SPI
	Size are both set to 0. This specification doesn't define any data		Size are both set to 0. This specification doesn't define any data
	this notification may contain, so the Notification Data is left		this notification may contain, so the Notification Data is left
	empty. However, future enhancements of this specification may		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 31 ¶		skipping to change at page 5, line 31 ¶
	IKE_INTERMEDIATE exchange performs additional key exchange resulting		IKE_INTERMEDIATE exchange performs additional key exchange resulting
	in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are		in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are
	used for encryption and authentication of the next IKE_INTERMEDIATE		used for encryption and authentication of the next IKE_INTERMEDIATE
	exchange, otherwise the current keys are used, and so on.		exchange, otherwise the current keys are used, and so on.
	3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges		3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges
	The content of the IKE_INTERMEDIATE exchanges must be authenticated		The content of the IKE_INTERMEDIATE exchanges must be authenticated
	in the IKE_AUTH exchange. For this purpose the definition of the		in the IKE_AUTH exchange. For this purpose the definition of the
	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 in case INTERMEDIATE exchange(s) took place:
	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_A [| IntAuth_1_I_P])		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_A [| IntAuth_2_I_P])		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_A [| IntAuth_3_I_P])		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_A [| IntAuth_1_R_P])		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_A [| IntAuth_2_R_P])		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_A [| IntAuth_3_R_P])		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: mandatory IntAuth_*_[I/R]_A and optional		two chunks of data: mandatory IntAuth_*_[I/R]_A and optional
	IntAuth_*_[I/R]_P. 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 the Initialization
	Padding, Pad Length and Integrity Checksum Data fields (see 3.14 of		Vector, the Padding, the Pad Length and the Integrity Checksum Data
	[RFC7296] for description of the Encrypted payload). In other words,		fields (see 3.14 of [RFC7296] for description of the Encrypted
	the IntAuth_*_[I/R]_P chunk is the inner payloads of the Encrypted		payload). In other words, the IntAuth_*_[I/R]_P chunk is the inner
	payload in plaintext form.		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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	skipping to change at page 10, line 12 ¶		skipping to change at page 10, line 12 ¶
	exchange. To do this the attacker should find the same		exchange. To do this the attacker should find the same
	IntAuth_*_[I|R] value for the forged message as for original.		IntAuth_*_[I|R] value for the 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:
	43 IKE_INTERMEDIATE		43 IKE_INTERMEDIATE
	This document also defines a new Notify Message Types in the "Notify		This document also defines a new Notify Message Type in the "Notify
	Message Types - Status Types" registry:		Message Types - Status Types" registry:
	16438 INTERMEDIATE_EXCHANGE_SUPPORTED		16438 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. Author is		the IKE_INTERMEDIATE exchange and helped to resolve it. Author is
End of changes. 13 change blocks.
	30 lines changed or deleted		31 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/