< draft-smyslov-ipsecme-ikev2-cookie-revised-00.txt		draft-smyslov-ipsecme-ikev2-cookie-revised-01.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Standards Track October 28, 2020		Intended status: Standards Track April 27, 2021
	Expires: May 1, 2021		Expires: October 29, 2021
	Revised Cookie Processing in the IKEv2 Protocol		Revised Cookie Processing in the IKEv2 Protocol
	draft-smyslov-ipsecme-ikev2-cookie-revised-00		draft-smyslov-ipsecme-ikev2-cookie-revised-01
	Abstract		Abstract
	This document defines a revised processing of cookies in the Internet		This document defines a revised processing of cookies in the Internet
	Key Exchange protocol Version 2 (IKEv2). It is intended to solve a		Key Exchange protocol Version 2 (IKEv2). It is intended to solve a
	problem in IKEv2 when due to packets loss and reordering peers may		problem in IKEv2 when due to packets loss and reordering peers may
	erroneously fail to authenticate each other when cookies are used in		erroneously fail to authenticate each other when cookies are used in
	the initial IKEv2 exchange.		the initial IKEv2 exchange.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 May 1, 2021.		This Internet-Draft will expire on October 29, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	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 . . . . . . . . . . . . . . . . . . 2		2. Terminology and Notation . . . . . . . . . . . . . . . . . . 2
	3. Using Cookie in IKEv2 . . . . . . . . . . . . . . . . . . . . 3		3. Using Cookies in IKEv2 . . . . . . . . . . . . . . . . . . . 3
	4. Problem Description . . . . . . . . . . . . . . . . . . . . . 3		4. Problem Description . . . . . . . . . . . . . . . . . . . . . 3
	5. Revised Cookie Processing . . . . . . . . . . . . . . . . . . 6		5. Revised Cookie Processing . . . . . . . . . . . . . . . . . . 6
	5.1. Negotiation of Revised Cookie Processing . . . . . . . . 6		5.1. Negotiation of Revised Cookie Processing . . . . . . . . 6
	5.2. Processing of REVISED_COOKIE Notification . . . . . . . . 7		5.2. Processing of REVISED_COOKIE Notification . . . . . . . . 7
	5.3. Changes in AUTH Payload Calculation . . . . . . . . . . . 7		5.3. Changes in AUTH Payload Calculation . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	9. Normative References . . . . . . . . . . . . . . . . . . . . 9		9. Normative References . . . . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	the situation described above.		the situation described above.
	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. Using Cookie in IKEv2		3. Using Cookies in IKEv2
	Section 2.6 of [RFC7296] specifies that when a responder detects a		Section 2.6 of [RFC7296] specifies that when a responder detects a
	large number of half-open IKE SAs, it SHOULD reply to an IKE_SA_INIT		large number of half-open IKE SAs, it SHOULD reply to an IKE_SA_INIT
	request with a response containing the COOKIE notification and If an		request with a response containing the COOKIE notification and If an
	IKE_SA_INIT response includes the COOKIE notification, the initiator		IKE_SA_INIT response includes the COOKIE notification, the initiator
	MUST then retry the IKE_SA_INIT request, and include the COOKIE		MUST then retry the IKE_SA_INIT request, and include the COOKIE
	notification containing the received data as the very first payload		notification containing the received data as the very first payload
	in it, retaining all other payloads intact. This is illustrated in		in it, retaining all other payloads intact. This process is
	the Figure 1.		illustrated in Figure 1.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	send req1:		send req1:
	HDR, SAi1, KEi, Ni --> recv req1, send resp1:		HDR, SAi1, KEi, Ni --> recv req1, send resp1:
	<-- HDR, N(COOKIE,c)		<-- HDR, N(COOKIE,c)
	recv resp1, send req2:		recv resp1, send req2:
	HDR, N(COOKIE,c),		HDR, N(COOKIE,c),
	SAi1, KEi, Ni --> recv req2, send resp2:		SAi1, KEi, Ni --> recv req2, send resp2:
	<-- HDR, SAr1, KEr, Nr		<-- HDR, SAr1, KEr, Nr
	recv resp2		recv resp2
	Figure 1		Figure 1
	Note, that the responder saves no state when it sends message resp1.		Note, that the responder saves no state when it sends message resp1.
	This is achieved by the way cookies are generated. A good way to		This is achieved due to the way cookies are generated. A good way to
	generate a cookie is described in Section 2.6 of [RFC7296]:		generate a cookie is described in Section 2.6 of [RFC7296]:
	Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)		Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
	where <secret> is a randomly generated secret known only to the		where <secret> is a randomly generated secret known only to the
	responder and periodically changed. [RFC7296] advises the responder		responder which is periodically changed. [RFC7296] advises the
	to change the value of <secret> frequently, especially if under		responder to change the value of <secret> frequently, especially if
	attack.		under attack.
	Later in the IKE_AUTH exchange the IKE_SA_INIT messages are		Later in the IKE_AUTH exchange the IKE_SA_INIT messages are
	authenticated by including their content intact into the data that is		authenticated by including their content intact into the data that is
	signed (or MAC'ed) using peers' credentials (see Section 2.15 of		signed (or MAC'ed) using peers' credentials (see Section 2.15 of
	[RFC7296] for details).		[RFC7296] for details).
	4. Problem Description		4. Problem Description
	To successfully complete authentication it is important that both		To successfully complete authentication it is important that both
	peers use the same content of the IKE_SA_INIT messages when		peers use the same content of the IKE_SA_INIT messages when
	calculating authentication data. However, when cookie is employed,		calculating authentication data. However, when cookies are employed,
	the IKE_SA_INIT request is sent at least twice with different		the IKE_SA_INIT request is sent at least twice with different
	content. Section 2.15. of [RFC7296] states that if the first message		content. Section 2.15. of [RFC7296] states that if the first message
	of the IKE_SA_INIT exchange is sent multiple times with different		of the IKE_SA_INIT exchange is sent multiple times with different
	content (such as with a cookie), it is the latest version of the		content (e.g. with a cookie), it is the latest version of the message
	message that is used for authentication. However, in situations when		that is used for authentication. However, in situations when network
	network packets can be lost and reordered peers may end up with		packets can be lost and reordered peers may end up with different
	different views on what is "the latest version of the message". Two		views on what is "the latest version of the message". Two examples
	examples of such situations are shown below.		of such situations are shown below.
	Consider a situation when at the time the initiator starts creating		Consider a situation when at the time the initiator starts creating
	IKE SA by sending req1 message the responder thinks it's under attack		IKE SA by sending req1 message the responder thinks it's under attack
	and responds with a resp2 message containing cookie request.		and responds with a resp2 message containing cookie request.
	However, this message is delayed in the network.		However, this message is delayed in the network.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	send req1:		send req1:
	HDR, SAi1, KEi, Ni --> recv req1, send resp1:		HDR, SAi1, KEi, Ni --> recv req1, send resp1:
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	the network.		the network.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	re-send req1:		re-send req1:
	HDR, SAi1, KEi, Ni --> recv req1, send resp2:		HDR, SAi1, KEi, Ni --> recv req1, send resp2:
	(delayed) <-- HDR, SAr1, KEr, Nr		(delayed) <-- HDR, SAr1, KEr, Nr
	After some time the initiator eventually receives the first		After some time the initiator eventually receives the first
	initiator's response resp1, which contains cookie request. It is the		initiator's response resp1, which contains cookie request. It is the
	first response the initiator receives, so it re-sends the request		first response the initiator receives from the responder, so it re-
	adding the received cookie into it (req2). However, this message is		sends the request adding the received cookie into it (req2).
	lost and never reaches the responder. Shortly after sending req2 the		However, this message is lost and never reaches the responder.
	initiator receives resp2 message.		Shortly after sending req2 the initiator receives resp2 message.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	recv resp1, send req2:		recv resp1, send req2:
	HDR, N(COOKIE,c),		HDR, N(COOKIE,c),
	SAi1, KEi, Ni --> (lost)		SAi1, KEi, Ni --> (lost)
	recv resp2		recv resp2
	At this point both peers have completed the IKE_SA_INIT exchange and		At this point both peers have completed the IKE_SA_INIT exchange and
	the KE_AUTH exchange is ready to start. However, the peers have		the KE_AUTH exchange is ready to start. However, the peers have
	skipping to change at page 8, line 39 ¶		skipping to change at page 8, line 39 ¶
	InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload		InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload
	RestOfInitIDPayload = IDType | RESERVED | InitIDData		RestOfInitIDPayload = IDType | RESERVED | InitIDData
	MACedIDForI = prf(SK_pi, RestOfInitIDPayload)		MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
	Figure 4		Figure 4
	In brief, if RealMessage1 doesn't contain the REVISED_COOKIE		In brief, if RealMessage1 doesn't contain the REVISED_COOKIE
	notification then it is used in the authentication as is (Figure 3).		notification then it is used in the authentication as is (Figure 3).
	Otherwise a new pseudo message PseudoMessage1 is used which is		Otherwise a new pseudo message PseudoMessage1 is used which is
	constructed from RealMessage1 as if it doesn't contain the		constructed from RealMessage1 as if it doesn't contain the
	REVISED_COOKIE notification (Figure 4>).		REVISED_COOKIE notification (Figure 4).
	This modification excludes Notify payload containing cookie from the		This modification excludes Notify payload containing cookie from the
	input to the AUTH payload calculation, thus solving the problem		input to the AUTH payload calculation, thus solving the problem
	described in Section 4.		described in Section 4.
	6. Security Considerations		6. Security Considerations
	This extension modifies the way IKE initiator is authenticated to the		This extension modifies the way IKE initiator is authenticated to the
	IKE responder. In particular, the cookie, created by the responder		IKE responder. In particular, the cookie, created by the responder
	and returned by the initiator in the IKE_SA_INIT request is excluded		and returned by the initiator in the IKE_SA_INIT request is excluded
End of changes. 13 change blocks.
	24 lines changed or deleted		24 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/