< draft-ietf-ipsecme-implicit-iv-02.txt		draft-ietf-ipsecme-implicit-iv-03.txt >
	IPSECME D. Migault		IPSECME D. Migault
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track T. Guggemos		Intended status: Standards Track T. Guggemos
	Expires: September 27, 2018 LMU Munich		Expires: November 10, 2018 LMU Munich
	Y. Nir		Y. Nir
	Dell EMC		Dell EMC
	March 26, 2018		May 9, 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-02		draft-ietf-ipsecme-implicit-iv-03
	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
	sending the nonce itself, and savec in the case of AES-GCM, AES-CCM,		sending the nonce itself, and saves in the case of AES-GCM, AES-CCM,
	AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document		AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document
	describes how to do this.		describes how to do this.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 27, 2018.		This Internet-Draft will expire on November 10, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	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. Requirements notation . . . . . . . . . . . . . . . . . . . . 2		1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Implicit IV . . . . . . . . . . . . . . . . . . . . . . . . . 3		4. Implicit IV . . . . . . . . . . . . . . . . . . . . . . . . . 3
	5. Initiator Behavior . . . . . . . . . . . . . . . . . . . . . 4		5. Initiator Behavior . . . . . . . . . . . . . . . . . . . . . 4
	6. Responder Behavior . . . . . . . . . . . . . . . . . . . . . 4		6. Responder Behavior . . . . . . . . . . . . . . . . . . . . . 5
	7. Security Consideration . . . . . . . . . . . . . . . . . . . 5		7. Security Consideration . . . . . . . . . . . . . . . . . . . 5
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	10.1. Normative References . . . . . . . . . . . . . . . . . . 5		10.1. Normative References . . . . . . . . . . . . . . . . . . 6
	10.2. Informational References . . . . . . . . . . . . . . . . 7		10.2. Informational References . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Requirements notation		1. Requirements 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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	Counter-based AES modes of operation such as AES-CTR ([RFC3686]),		Counter-based AES modes of operation such as AES-CTR ([RFC3686]),
	AES-CCM ([RFC4309]), and AES-GCM ([RFC4106]) require the		AES-CCM ([RFC4309]), and AES-GCM ([RFC4106]) require the
	specification of an nonce for each ESP packet. The same applies for		specification of an nonce for each ESP packet. The same applies for
	ChaCha20-Poly1305 ([RFC7634]. Currently this nonce is sent in each		ChaCha20-Poly1305 ([RFC7634]). Currently this nonce is sent in each
	ESP packet ([RFC4303]). This practice is designated in this document		ESP packet ([RFC4303]). This practice is designated in this document
	as "explicit nonce".		as "explicit nonce".
	In some context, such as IoT, it may be preferable to avoid carrying		In some context, such as IoT, it may be preferable to avoid carrying
	the extra bytes associated to the IV and instead generate it locally		the extra bytes associated to the IV and instead generate it locally
	on each peer. The local generation of the nonce is designated in		on each peer. The local generation of the nonce is designated in
	this document as "implicit IV".		this document as "implicit IV".
	The size of this nonce depends on the specific algorithm, but all of		The size of this nonce depends on the specific algorithm, but all of
	the algorithms mentioned above take an 8-octet nonce.		the algorithms mentioned above take an 8-octet nonce.
	skipping to change at page 4, line 20 ¶		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		As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are
	used, Implicit IV as described in this document MUST NOT be used in		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.		setups with the chance that the Sequence Number overlaps for one SA.
	Multicast as described in [RFC5374], [RFC6407] and		Multicast as described in [RFC5374], [RFC6407] and
	[I-D.yeung-g-ikev2] is a prominent example, where many senders share		[I-D.yeung-g-ikev2] is a prominent example, where many senders share
	one secret and thus one SPI. Section 3.5 of [RFC6407] provides a		one secret and thus one SA. Section 3.5 of [RFC6407] provides a
	mechanism that MAY be used to prevent IV collisions when the same key		mechanism that MAY be used to prevent IV collisions when the same key
	is used by multiple users. The mechanism consists in partitioning		is used by multiple users. The mechanism consists in partitioning
	the IV space between users by assigning the most significant byte to		the IV space between users by assigning the most significant byte to
	a user. When implicit IV transforms are used, such mechanism cannot		a user. When implicit IV transforms are used, such mechanism cannot
	be applied as the IV is not sent, but instead it is derived from the		be applied as the IV is not sent, but instead it is derived from the
	Sequence Number. A similar mechanism could be used by associating		Sequence Number. A similar mechanism could be used by associating
	the most significant byte of the Sequence Number to a sender, while		the most significant byte of the Sequence Number to a sender, while
	the 3 remaining bytes will be used to carry the counter value. Such		the 3 remaining bytes will be used to carry the counter value. Such
	mechanism prevents the use of Extended Sequence Number and limits the		mechanism prevents the use of Extended Sequence Number and limits the
	number of packet to be sent to 2** 24 = 16777216, that is 16 M.		number of packet to be sent to 2** 24 = 16777216, that is 16 M. Note
			that associating instead the least significant byte of the Sequence
			Number to the sender, would enable the system to use Extended
			Sequence Number and as such extend the limit of packet to be sent to
			2 ** ( 24 + 32 ) = 72057594037927936, that is 72 P. Note also that
			in both cases the Sequence Number are not interpreted as numeric
			values which impacts the replay window processing defined in
			[RFC4302] and [RFC4302].
	Unless some mechanism are provided to avoid collision between		Unless some mechanism are provided to avoid collision between
	Sequence Number, ( and so IV ), Implicit IV MUST NOT be used.		Sequence Number, ( and so IV ), Implicit IV MUST NOT be used. As
			such, it is NOT RECOMMENDED to use Implicit IV with Multicast.
	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
	all relevant algorithms. To facilitate backward compatibility with		algorithms in the Transform Type 1 (Encryption Algorithm)
	non-supporting peers the initiator SHOULD also include those same		Substructure of the Proposal Substructure inside the SA Payload. To
	algorithms without Implicit IV (IIV). This may require extra		facilitate backward compatibility with non-supporting peers the
	transforms.		initiator SHOULD also include those same algorithms without Implicit
			IV (IIV) as separate transforms.
	6. Responder Behavior		6. Responder Behavior
	The rules of SA payload processing ensure that the responder will		The rules of SA Payload processing require that responder picks its
	never send an SA payload containing the IIV transform to an initiator		algorithms from the proposal sent by the initiator, thus this will
	that does not support IIV.		ensure that the responder will never send an SA payload containing
			the IIV transform to an initiator that did not propose it.
	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. Typically, for AES-GCM, AES-CCM, AES-		security requirements are met. Typically, for AES-GCM, AES-CCM, AES-
	CTR and ChaCha20-Poly1305, the IV is not allowed being repeated for		CTR and ChaCha20-Poly1305, the IV is not allowed being repeated for
	one particular key. This document provides an explicit and normative		one particular key. This document provides an explicit and normative
	way to generate IVs. The mechanism described in this document meets		way to generate IVs. The mechanism described in this document meets
	the IV security requirements of all relevant algorithms.		the IV security requirements of all relevant algorithms.
	8. IANA Considerations		8. IANA Considerations
	AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to implement the		This section assigns new code points to the recommended AEAD suites
	implicit IV described in this document. This section limits		provided in [RFC8221], thus the new Transform Type 1 - Encryption
	assignment of new code points to the recommended suites provided in		Algorithm Transform IDs [IANA] are as defined below:
	[RFC8221], thus the new Transform Type 1 - Encryption Algorithm
	Transform IDs [IANA] are as defined below:
	- ENCR_AES_CCM_8_IIV		- ENCR_AES_CCM_8_IIV: 29
	- ENCR_AES_GCM_16_IIV		- ENCR_AES_GCM_16_IIV: 30
	- ENCR_CHACHA20_POLY1305_IIV		- ENCR_CHACHA20_POLY1305_IIV: 31
	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 would like to thanks people Valery Smyslov for their valuable		We would like to thanks people Valery Smyslov for their valuable
	comments, David Schinazi for its implementation, as well as the		comments, David Schinazi for its implementation, as well as the
	ipseceme chairs Tero Kivinen and David Waltermire for moving this		ipseceme chairs Tero Kivinen and David Waltermire for moving this
	work forward.		work forward.
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 26 ¶
	[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)		[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
	Counter Mode With IPsec Encapsulating Security Payload		Counter Mode With IPsec Encapsulating Security Payload
	(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,		(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,
	<https://www.rfc-editor.org/info/rfc3686>.		<https://www.rfc-editor.org/info/rfc3686>.
	[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode		[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
	(GCM) in IPsec Encapsulating Security Payload (ESP)",		(GCM) in IPsec Encapsulating Security Payload (ESP)",
	RFC 4106, DOI 10.17487/RFC4106, June 2005,		RFC 4106, DOI 10.17487/RFC4106, June 2005,
	<https://www.rfc-editor.org/info/rfc4106>.		<https://www.rfc-editor.org/info/rfc4106>.
			[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
			DOI 10.17487/RFC4302, December 2005,
			<https://www.rfc-editor.org/info/rfc4302>.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, DOI 10.17487/RFC4303, December 2005,		RFC 4303, DOI 10.17487/RFC4303, December 2005,
	<https://www.rfc-editor.org/info/rfc4303>.		<https://www.rfc-editor.org/info/rfc4303>.
	[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM		[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
	Mode with IPsec Encapsulating Security Payload (ESP)",		Mode with IPsec Encapsulating Security Payload (ESP)",
	RFC 4309, DOI 10.17487/RFC4309, December 2005,		RFC 4309, DOI 10.17487/RFC4309, December 2005,
	<https://www.rfc-editor.org/info/rfc4309>.		<https://www.rfc-editor.org/info/rfc4309>.
	[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast		[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
End of changes. 20 change blocks.
	29 lines changed or deleted		41 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/