< draft-ietf-ipsecme-ikev2-intermediate-06.txt		draft-ietf-ipsecme-ikev2-intermediate-07.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track March 9, 2021		Intended status: Standards Track August 3, 2021
	Expires: September 10, 2021		Expires: February 4, 2022
	Intermediate Exchange in the IKEv2 Protocol		Intermediate Exchange in the IKEv2 Protocol
	draft-ietf-ipsecme-ikev2-intermediate-06		draft-ietf-ipsecme-ikev2-intermediate-07
	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 September 10, 2021.		This Internet-Draft will expire on February 4, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 18 ¶		skipping to change at page 2, line 18 ¶
	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 . . . . . 9
	4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 9		4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Implementation Status . . . . . . . . . . . . . . . . . . . . 10		7. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 10		9.1. Normative References . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . 11		9.2. Informative References . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11		Appendix A. Example of IKE_INTERMEDIATE exchange . . . . . . . . 11
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
	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 a		[RFC7296] uses UDP as a transport for its messages. If size of a
	message is large enough, IP fragmentation takes place, that may		message 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 5, line 17 ¶		skipping to change at page 5, line 17 ¶
	The content of the IKE_INTERMEDIATE exchange messages depends on the		The content of the IKE_INTERMEDIATE exchange messages depends on the
	data being transferred and will be defined by specifications		data being transferred and will be defined by specifications
	utilizing this exchange. However, since the main motivation for the		utilizing this exchange. However, since the main motivation for the
	IKE_INTERMEDIATE exchange is to avoid IP fragmentation when large		IKE_INTERMEDIATE exchange is to avoid IP fragmentation when large
	amount of data need to be transferred prior to IKE_AUTH, the		amount of data need to be transferred prior to IKE_AUTH, the
	Encrypted payload MUST be present in the IKE_INTERMEDIATE exchange		Encrypted payload MUST be present in the IKE_INTERMEDIATE exchange
	messages and payloads containing large data MUST be placed inside it.		messages and payloads containing large data MUST be placed inside it.
	This will allow IKE fragmentation [RFC7383] to take place, provided		This will allow IKE fragmentation [RFC7383] to take place, provided
	it is supported by the peers and negotiated in the initial exchange.		it is supported by the peers and negotiated in the initial exchange.
			Appendix A contains an example of using IKE_INTERMEDIATE exchange in
			creating IKE SA.
	3.3. The IKE_INTERMEDIATE Exchange Protection and Authentication		3.3. The IKE_INTERMEDIATE Exchange Protection and Authentication
	3.3.1. Protection of the IKE_INTERMEDIATE Messages		3.3.1. Protection of the IKE_INTERMEDIATE Messages
	The keys SK_e[i/r] and SK_a[i/r] for the IKE_INTERMEDIATE exchanges		The keys SK_e[i/r] and SK_a[i/r] for the IKE_INTERMEDIATE exchanges
	protection are computed in a standard fashion, as defined in the		protection are computed in a standard fashion, as defined in the
	Section 2.14 of [RFC7296].		Section 2.14 of [RFC7296].
	Every subsequent IKE_INTERMEDIATE exchange uses the most recently		Every subsequent IKE_INTERMEDIATE exchange uses the most recently
	calculated IKE SA keys before this exchange is started. So, the		calculated IKE SA keys before this exchange is started. So, the
	first IKE_INTERMEDIATE exchange always uses SK_e[i/r] and SK_a[i/r]		first IKE_INTERMEDIATE exchange 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		keys that were computed as a result of the IKE_SA_INIT exchange. If
	additional key exchange is performed in the first IKE_INTERMEDIATE		additional key exchange is performed in the first IKE_INTERMEDIATE
	exchange resulting in the update of SK_e[i/r] and SK_a[i/r], then		exchange resulting in the update of SK_e[i/r] and SK_a[i/r], then
	these updated keys are used for protection of the second		these updated keys are used for protection of the second
	IKE_INTERMEDIATE exchange, otherwise the original SK_e[i/r] and		IKE_INTERMEDIATE exchange, otherwise the original SK_e[i/r] and
	SK_a[i/r] keys are used again, and so on.		SK_a[i/r] keys are used again, and so on.
			Once all the IKE_INTERMEDIATE exchanges are completed, the most
			recently calculated SK_e[i/r] and SK_a[i/r] keys are used for
			protection of the IKE_AUTH and all the subsequent exchanges.
	3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges		3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges
	The IKE_INTERMEDIATE messages must be authenticated in the IKE_AUTH		The IKE_INTERMEDIATE messages must be authenticated in the IKE_AUTH
	exchange, which is performed by adding their content into the AUTH		exchange, which is performed by adding their content into the AUTH
	payload calculation. It is anticipated that in many use cases		payload calculation. It is anticipated that in many use cases
	IKE_INTERMEDIATE messages will be fragmented using IKE fragmentation		IKE_INTERMEDIATE messages will be fragmented using IKE fragmentation
	[RFC7383] mechanism. According to [RFC7383], when IKE fragmentation		[RFC7383] mechanism. According to [RFC7383], when IKE fragmentation
	is negotiated, initiator may first send request message in		is negotiated, initiator may first send request message in
	unfragmented form, but later turn IKE fragmentation on and re-send it		unfragmented form, but later turn IKE fragmentation on and re-send it
	fragmented if no response is received after few retransmissions. In		fragmented if no response is received after few retransmissions. In
	skipping to change at page 10, line 35 ¶		skipping to change at page 10, line 40 ¶
	o ELVIS-PLUS		o ELVIS-PLUS
	o strongSwan		o strongSwan
	o libreswan (only one IKE_INTERMEDIATE exchange is supported)		o 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. Scott Fluhrer and		IKE_AUTH was first suggested by Tero Kivinen. He also helped with
	Daniel Van Geest identified a possible problem with authentication of		writing an example of using IKE_INTERMEDIATE exchange (shown in
	the IKE_INTERMEDIATE exchange and helped to resolve it. Author is		Appendix A). Scott Fluhrer and Daniel Van Geest identified a
	also grateful to Tobias Brunner for raising good points concerning		possible problem with authentication of the IKE_INTERMEDIATE exchange
	authentication of the IKE_INTERMEDIATE exchange and to Paul Wouters		and helped to resolve it. Author is also grateful to Tobias Brunner
	who suggested text improvements for the document.		for raising good points concerning authentication of the
			IKE_INTERMEDIATE exchange and to Paul Wouters who suggested text
			improvements for the document.
	9. References		9. References
	9.1. Normative References		9.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>.
	skipping to change at page 11, line 30 ¶		skipping to change at page 11, line 39 ¶
	[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation		[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
	of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,		of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
	August 2017, <https://www.rfc-editor.org/info/rfc8229>.		August 2017, <https://www.rfc-editor.org/info/rfc8229>.
	[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange		[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
	Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,		Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
	DOI 10.17487/RFC5723, January 2010,		DOI 10.17487/RFC5723, January 2010,
	<https://www.rfc-editor.org/info/rfc5723>.		<https://www.rfc-editor.org/info/rfc5723>.
			Appendix A. Example of IKE_INTERMEDIATE exchange
			This appendix contains an example of the messages using
			IKE_INTERMEDIATE exchange. This appendix is purely informative; if
			it disagrees with the body of this document, the other text is
			considered correct.
			In this example there is one IKE_SA_INIT exchange, two
			IKE_INTERMEDIATE exchanges followed by the IKE_AUTH exchange to
			authenticate all initial exchanges. The xxx in the HDR(xxx,MID=yyy)
			indicates the exchange type, and yyy tells the message id used for
			that exchange. The keys used for each SK {} payload are indicated in
			the parenthesis after the SK. Otherwise payload notation is same as
			is used in [RFC7296].
			Initiator Responder
			----------- -----------
			HDR(IKE_SA_INIT,MID=0),
			SAi1, KEi, Ni,
			N(INTERMEDIATE_EXCHANGE_SUPPORTED) -->
			<-- HDR(IKE_SA_INIT,MID=0),
			SAr1, KEr, Nr, [CERTREQ],
			N(INTERMEDIATE_EXCHANGE_SUPPORTED)
			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_INTERMEDIATE exchange and SK_p[i/r]_1 will be used for its
			authentication.
			Initiator Responder
			----------- -----------
			HDR(IKE_INTERMEDIATE,MID=1),
			SK(SK_ei_1,SK_ai_1) {...} -->
			<Calculate IntAuth_1_I = prf(SK_pi_1, ...)>
			<-- HDR(IKE_INTERMEDIATE,MID=1),
			SK(SK_er_1,SK_ar_1) {...}
			<Calculate IntAuth_1_R = prf(SK_pr_1, ...)>
			If after completing this IKE_INTERMEDIATE exchange SK_*_1 keys are
			updated (e.g., as a result of a new key exchange), then peers store
			updated keys as SK_*_2, otherwise they use SK_*_1 as SK_*_2. SK_e[i/
			r]_2 and SK_a[i/r]_2 will be used to protect the second
			IKE_INTERMEDIATE exchange and SK_p[i/r]_2 will be used for its
			authentication.
			Initiator Responder
			----------- -----------
			HDR(IKE_INTERMEDIATE,MID=2),
			SK(SK_ei_2,SK_ai_2) {...} -->
			<Calculate IntAuth_2_I = prf(SK_pi_2, ...)>
			<-- HDR(IKE_INTERMEDIATE,MID=2),
			SK(SK_er_2,SK_ar_2) {...}
			<Calculate IntAuth_2_R = prf(SK_pr_2, ...)>
			If after completing the second IKE_INTERMEDIATE exchange SK_*_2 keys
			are updated (e.g., as a result of a new key exchange), then peers
			store 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
			exchange, SK_p[i/r]_3 will be used for authentication and SK_d_3 will
			be used for derivation of other keys (e.g. for Child SAs).
			Initiator Responder
			----------- -----------
			HDR(IKE_AUTH,MID=3),
			SK(SK_ei_3,SK_ai_3)
			{IDi, [CERT,] [CERTREQ,]
			[IDr,] AUTH, SAi2, TSi, TSr} -->
			<-- HDR(IKE_AUTH,MID=3),
			SK(SK_er_3,SK_ar_3)
			{IDr, [CERT,] AUTH, SAr2, TSi, TSr}
			In this example two IKE_INTERMEDIATE exchanges took place, therefore
			SK_*_3 keys would be used as SK_* keys for further cryptographic
			operations in the context of the created IKE SA, as defined in
			[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) 124460
	RU		RU
	Phone: +7 495 276 0211		Phone: +7 495 276 0211
	Email: svan@elvis.ru		Email: svan@elvis.ru
End of changes. 10 change blocks.
	14 lines changed or deleted		107 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/