< draft-ietf-ipsecme-ikev2-intermediate-08.txt		draft-ietf-ipsecme-ikev2-intermediate-09.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track February 2, 2022		Intended status: Standards Track 24 February 2022
	Expires: August 6, 2022		Expires: 28 August 2022
	Intermediate Exchange in the IKEv2 Protocol		Intermediate Exchange in the IKEv2 Protocol
	draft-ietf-ipsecme-ikev2-intermediate-08		draft-ietf-ipsecme-ikev2-intermediate-09
	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 amounts of data in the		exchange can be used for transferring large amounts of data in the
	process of IKEv2 Security Association (SA) establishment.		process of IKEv2 Security Association (SA) establishment.
	Introducing the Intermediate Exchange allows re-using the existing		Introducing the Intermediate Exchange allows re-using the existing
	IKE fragmentation mechanism, that helps to avoid IP fragmentation of		IKE 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 August 6, 2022.		This Internet-Draft will expire on 28 August 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised 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. Intermediate Exchange Details . . . . . . . . . . . . . . . . 3		3. Intermediate Exchange Details . . . . . . . . . . . . . . . . 4
	3.1. Support for Intermediate Exchange Negotiation . . . . . . 3		3.1. Support for Intermediate Exchange Negotiation . . . . . . 4
	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 . . 6
	3.4. Error Handling in the IKE_INTERMEDIATE Exchange . . . . . 9		3.4. Error Handling in the IKE_INTERMEDIATE Exchange . . . . . 10
	4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 10		4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7. Implementation Status . . . . . . . . . . . . . . . . . . . . 11		7. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 12		9.2. Informative References . . . . . . . . . . . . . . . . . 12
	Appendix A. Example of IKE_INTERMEDIATE exchange . . . . . . . . 13		Appendix A. Example of IKE_INTERMEDIATE exchange . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
	skipping to change at page 6, line 39 ¶		skipping to change at page 7, line 4 ¶
	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])
	The essence of this modification is that a new chunk called IntAuth		The essence of this modification is that a new chunk called IntAuth
	is appended to the string of octets that is signed (or MAC'ed) by the		is appended to the string of octets that is signed (or MAC'ed) by the
	peers. IntAuth consists of three parts: IntAuth_iN, IntAuth_rN, and		peers. IntAuth consists of three parts: IntAuth_iN, IntAuth_rN, and
	IKE_AUTH_MID.		IKE_AUTH_MID.
	The IKE_AUTH_MID chunk is a value of the Message ID field from the		The IKE_AUTH_MID chunk is a value of the Message ID field from the
	IKE Header of the first round of the IKE_AUTH exchange. It is		IKE Header of the first round of the IKE_AUTH exchange. It is
	represented as a four octet integer in network byte order (in other		represented as a four octet integer in network byte order (in other
	words, exactly as it appears on the wire).		words, exactly as it appears on the wire).
	The IntAuth_iN and IntAuth_rN chunks each represent the cumulative		The IntAuth_iN and IntAuth_rN chunks each represent the cumulative
	result of applying the negotiated prf to all IKE_INTERMEDIATE		result of applying the negotiated prf to all IKE_INTERMEDIATE
	exchange messages sent during IKE SA establishing by the initiator		exchange messages sent during IKE SA establishment by the initiator
	and the responder respectively. After the first IKE_INTERMEDIATE		and the responder respectively. After the first IKE_INTERMEDIATE
	exchange is completed peers calculate the IntAuth_i1 value by		exchange is completed peers calculate the IntAuth_i1 value by
	applying the negotiated prf to the content of the request message		applying the negotiated prf to the content of the request message
	from this exchange and calculate the IntAuth_r1 value by applying the		from this exchange and calculate the IntAuth_r1 value by applying the
	negotiated prf to the content of the response message. For every		negotiated prf to the content of the response message. For every
	following IKE_INTERMEDIATE exchange (if any) peers re-calculate these		following IKE_INTERMEDIATE exchange (if any) peers re-calculate these
	values as follows. After n-th exchange is completed they compute		values as follows. After n-th exchange is completed they compute
	IntAuth_[i/r]n by applying the negotiated prf to the concatenation of		IntAuth_[i/r]n by applying the negotiated prf to the concatenation of
	IntAuth_[i/r](n-1) (computed for the previous IKE_INTERMEDIATE		IntAuth_[i/r](n-1) (computed for the previous IKE_INTERMEDIATE
	exchange) and the content of the request (for IntAuth_in) or response		exchange) and the content of the request (for IntAuth_in) or response
	skipping to change at page 8, line 42 ¶		skipping to change at page 8, line 45 ¶
	| | 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]*A (denoted as A)		Figure 1 illustrates the layout of the IntAuth_[i/r]*A (denoted as A)
	and the IntAuth_[i/r]*P (denoted as P) chunks in case the Encrypted		and the IntAuth_[i/r]*P (denoted as P) chunks in case the Encrypted
	payload is not empty.		payload is not empty.
	For the purpose of prf calculation the Length field in the IKE Header		For the purpose of prf calculation the Length field in the IKE Header
	and the Payload Length field in the Encrypted payload header are		and the Payload Length field in the Encrypted payload header are
	adjusted so that they don't count the lengths of Initialization		adjusted so that they don't count the lengths of Initialization
	Vector, Integrity Checksum Data, Padding and Pad Length fields. In		Vector, Integrity Checksum Data, Padding and Pad Length fields. In
	other words, the Length field in the IKE Header (denoted as Adjusted		other words, the Length field in the IKE Header (denoted as Adjusted
	skipping to change at page 11, line 38 ¶		skipping to change at page 12, line 4 ¶
	This document also defines a new Notify Message Type 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. Implementation Status		7. Implementation Status
	[Note to RFC Editor: please, remove this section before publishing		[Note to RFC Editor: please, remove this section before publishing
	RFC.]		RFC.]
	At the time of writing the -05 version of the draft there were at		At the time of writing the -05 version of the draft there were at
	least three independent interoperable implementations of this		least three independent interoperable implementations of this
	specifications from the following vendors:		specifications from the following vendors:
	o ELVIS-PLUS		* ELVIS-PLUS
	o strongSwan		* strongSwan
	o libreswan (only one IKE_INTERMEDIATE exchange is supported)		* libreswan (only one IKE_INTERMEDIATE exchange is supported)
	8. Acknowledgements		8. 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. He also helped with		IKE_AUTH was first suggested by Tero Kivinen. He also helped with
	writing an example of using IKE_INTERMEDIATE exchange (shown in		writing an example of using IKE_INTERMEDIATE exchange (shown in
	Appendix A). Scott Fluhrer and Daniel Van Geest identified a		Appendix A). Scott Fluhrer and Daniel Van Geest identified a
	possible problem with authentication of the IKE_INTERMEDIATE exchange		possible problem with authentication of the IKE_INTERMEDIATE exchange
	and helped to resolve it. Author is grateful to Tobias Brunner who		and helped to resolve it. Author is grateful to Tobias Brunner who
	raised good questions concerning authentication of the		raised good questions concerning authentication of the
	skipping to change at page 15, line 15 ¶		skipping to change at page 15, line 25 ¶
	In this example two IKE_INTERMEDIATE exchanges took place, therefore		In this example two IKE_INTERMEDIATE exchanges took place, therefore
	SK_*3 keys would be used as SK_* keys for further cryptographic		SK_*3 keys would be used as SK_* keys for further cryptographic
	operations in the context of the created IKE SA, as defined in		operations in the context of the created IKE SA, as defined in
	[RFC7296].		[RFC7296].
	Author's Address		Author's Address
	Valery Smyslov		Valery Smyslov
	ELVIS-PLUS		ELVIS-PLUS
	PO Box 81		PO Box 81
	Moscow (Zelenograd) 124460		Moscow (Zelenograd)
	RU		124460
			Russian Federation
	Phone: +7 495 276 0211		Phone: +7 495 276 0211
	Email: svan@elvis.ru		Email: svan@elvis.ru
End of changes. 14 change blocks.
	26 lines changed or deleted		23 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/