< draft-ietf-ipsecme-implicit-iv-00.txt		draft-ietf-ipsecme-implicit-iv-01.txt >
	IPSECME D. Migault, Ed.		IPSECME D. Migault, Ed.
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track T. Guggemos, Ed.		Intended status: Standards Track T. Guggemos, Ed.
	Expires: May 22, 2018 LMU Munich		Expires: September 24, 2018 LMU Munich
	Y. Nir		Y. Nir
	Dell EMC		Dell EMC
	November 18, 2017		March 23, 2018
	Implicit IV for Counter-based Ciphers in Encapsulating Security Payload		Implicit IV for Counter-based Ciphers in Encapsulating Security Payload
	(ESP)		(ESP)
	draft-ietf-ipsecme-implicit-iv-00		draft-ietf-ipsecme-implicit-iv-01
	Abstract		Abstract
	Encapsulating Security Payload (ESP) sends an initialization vector		Encapsulating Security Payload (ESP) sends an initialization vector
	(IV) or nonce in each packet. The size of IV depends on the applied		(IV) or nonce in each packet. The size of IV depends on the applied
	transform, being usually 8 or 16 octets for the transforms defined by		transform, being usually 8 or 16 octets for the transforms defined by
	the time this document is written. Some algorithms such as AES-GCM,		the time this document is written. Some algorithms such as AES-GCM,
	AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do		AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do
	not require an unpredictable nonce. When using such algorithms the		not require an unpredictable nonce. When using such algorithms the
	packet counter value can be used to generate a nonce. This avoids		packet counter value can be used to generate a nonce. This avoids
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 22, 2018.		This Internet-Draft will expire on September 24, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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 26 ¶		skipping to change at page 3, line 26 ¶
	packet counter as described below is insecure as mentioned in		packet counter as described below is insecure as mentioned in
	Security Consideration of [RFC3602] and has led to real world chosen		Security Consideration of [RFC3602] and has led to real world chosen
	plain-text attack such as BEAST [BEAST].		plain-text attack such as BEAST [BEAST].
	3. Terminology		3. Terminology
	o IoT: Internet of Things.		o IoT: Internet of Things.
	o IV: Initialization Vector.		o IV: Initialization Vector.
			o IIV: Implicit Initialization Vector.
	o Nonce: a fixed-size octet string used only once. This is similar		o Nonce: a fixed-size octet string used only once. This is similar
	to IV, except that in common usage there is no implication of non-		to IV, except that in common usage there is no implication of non-
	predictability.		predictability.
	4. Implicit IV		4. Implicit IV
	With the algorithms listed in Section 2, the 8 byte nonce MUST NOT		With the algorithms listed in Section 2, the 8 byte nonce MUST NOT
	repeat. The binding between a ESP packet and its nonce is provided		repeat. The binding between a ESP packet and its nonce is provided
	using the Sequence Number or the Extended Sequence Number. Figure 1		using the Sequence Number or the Extended Sequence Number. Figure 1
	and Figure 2 represent the IV with a regular 4-byte Sequence Number		and Figure 2 represent the IV with a regular 4-byte Sequence Number
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 20 ¶
	| Extended |		| Extended |
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Implicit IV with an 8 byte Extended Sequence Number		Figure 2: Implicit IV with an 8 byte Extended Sequence Number
	o Extended Sequence Number: the 8 byte Extended Sequence Number of		o Extended Sequence Number: the 8 byte Extended Sequence Number of
	the Security Association. The 4 byte low order bytes are carried		the Security Association. The 4 byte low order bytes are carried
	in the ESP packet.		in the ESP packet.
			As the IV MUST NOT repeat for one SPI when Counter-Mode ciphers are
			used, Implicit IV as described in this document MUST NOT be used in
			setups with the chance that the Sequence Number overlaps for one SPI.
			Multicast as described in [RFC5374], [RFC6407] and
			[I-D.yeung-g-ikev2] is a prominent example, where many senders share
			one secret and thus one SPI. Section 3.5 of [RFC6407] explains how
			repetition MAY BE prevented by using a prefix for each group member,
			which could be prefixed to the Sequence Number. Otherwise, Implicit
			IV MUST NOT be used in multicast scenarios.
	5. Initiator Behavior		5. Initiator Behavior
	An initiator supporting this feature SHOULD propose implicit IV for		An initiator supporting this feature SHOULD propose implicit IV for
	all relevant algorithms. To facilitate backward compatibility with		all relevant algorithms. To facilitate backward compatibility with
	non-supporting peers the initiator SHOULD also include those same		non-supporting peers the initiator SHOULD also include those same
	algorithms without IIV. This may require extra transforms.		algorithms without Implicit IV (IIV). This may require extra
			transforms.
	6. Responder Behavior		6. Responder Behavior
	The rules of SA payload processing ensure that the responder will		The rules of SA payload processing ensure that the responder will
	never send an SA payload containing the IIV indicator to an initiator		never send an SA payload containing the IIV indicator to an initiator
	that does not support IIV.		that does not support IIV.
	7. Security Consideration		7. Security Consideration
	Nonce generation for these algorithms has not been explicitly		Nonce generation for these algorithms has not been explicitly
	defined. It has been left to the implementation as long as certain		defined. It has been left to the implementation as long as certain
	security requirements are met. This document provides an explicit		security requirements are met. Typically, for AES-GCM, AES-CCM, AES-
	and normative way to generate IVs. The mechanism described in this		CTR and ChaCha20-Poly1305, the IV is not allowed being repeated for
	document meets the IV security requirements of all relevant		one particular key. This document provides an explicit and normative
	algorithms.		way to generate IVs. The mechanism described in this document meets
			the IV security requirements of all relevant algorithms.
	As the IV MUST NOT repeat for one SPI when Counter-Mode ciphers are
	used, Implicit IV as described in this document MUST NOT be used in
	setups with the chance that the Sequence Number overlaps for one SPI.
	Multicast as described in [RFC5374], [RFC6407] and
	[I-D.yeung-g-ikev2] is a prominent example, where many senders share
	one secret and thus one SPI. Section 3.5 of [RFC6407] explains how
	repetition MAY BE prevented by using a prefix for each group member,
	which could be prefixed to the Sequence Number. Otherwise, Implicit
	IV MUST NOT be used in multicast scenarios.
	8. IANA Considerations		8. IANA Considerations
	AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to		AES-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to
	implement the implicit IV described in this document. This section		implement the implicit IV described in this document. This section
	limits assignment of new code points to the recommended suites		limits assignment of new code points to the recommended suites
	provided in [RFC8221], thus the new Transform Type 1 - Encryption		provided in [RFC8221], thus the new Transform Type 1 - Encryption
	Algorithm Transform IDs [IANA] are as defined below:		Algorithm Transform IDs [IANA] are as defined below:
	- ENCR_AES_CCM_8_IIV		- ENCR_AES_CCM_8_IIV
	- ENCR_AES_GCM_16_IIV		- ENCR_AES_GCM_16_IIV
	- ENCR_CHACHA20_POLY1305_IIV		- ENCR_CHACHA20_POLY1305_IIV
	These algorithms should be added with this document as ESP Reference		These algorithms should be added with this document as ESP Reference
	and "Not Allowed" for IKEv2 Reference.		and "Not Allowed" for IKEv2 Reference.
	9. Acknowledgements		9. Acknowledgements
	We woudl like to thanks people Valery Smyslov for their valuable		We would like to thanks people Valery Smyslov for their valuable
	comments as well as the ipseceme chairs Tero Kivinen and David		comments, David Schinazi for its implementation, as well as the
	Waltermire for moving this work forward.		ipseceme chairs Tero Kivinen and David Waltermire for moving this
			work forward.
	10. References		10. References
	10.1. Normative References		10.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 6, line 48 ¶		skipping to change at page 6, line 48 ¶
	<https://www.rfc-editor.org/info/rfc8221>.		<https://www.rfc-editor.org/info/rfc8221>.
	10.2. Informational References		10.2. Informational References
	[BEAST] Thai, T. and J. Juliano, "Here Come The xor Ninjas", ,		[BEAST] Thai, T. and J. Juliano, "Here Come The xor Ninjas", ,
	May 2011, <https://www.researchgate.net/		May 2011, <https://www.researchgate.net/
	publication/266529975_Here_Come_The_Ninjas>.		publication/266529975_Here_Come_The_Ninjas>.
	[I-D.yeung-g-ikev2]		[I-D.yeung-g-ikev2]
	Weis, B., Nir, Y., and V. Smyslov, "Group Key Management		Weis, B., Nir, Y., and V. Smyslov, "Group Key Management
	using IKEv2", draft-yeung-g-ikev2-12 (work in progress),		using IKEv2", draft-yeung-g-ikev2-13 (work in progress),
	October 2017.		March 2018.
	[IANA] "IANA IKEv2 Parameter - Type 1 - Encryption Algorithm		[IANA] "IANA IKEv2 Parameter - Type 1 - Encryption Algorithm
	Transform IDs", <https://www.iana.org/assignments/ikev2-		Transform IDs", <https://www.iana.org/assignments/ikev2-
	parameters/ikev2-parameters.xhtml#ikev2-parameters-5>.		parameters/ikev2-parameters.xhtml#ikev2-parameters-5>.
	Authors' Addresses		Authors' Addresses
	Daniel Migault (editor)		Daniel Migault (editor)
	Ericsson		Ericsson
	8400 boulevard Decarie		8400 boulevard Decarie
End of changes. 11 change blocks.
	25 lines changed or deleted		30 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/