< draft-ietf-ipsecme-implicit-iv-01.txt		draft-ietf-ipsecme-implicit-iv-02.txt >
	IPSECME D. Migault, Ed.		IPSECME D. Migault
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track T. Guggemos, Ed.		Intended status: Standards Track T. Guggemos
	Expires: September 24, 2018 LMU Munich		Expires: September 27, 2018 LMU Munich
	Y. Nir		Y. Nir
	Dell EMC		Dell EMC
	March 23, 2018		March 26, 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-01		draft-ietf-ipsecme-implicit-iv-02
	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 September 24, 2018.		This Internet-Draft will expire on September 27, 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 23 ¶		skipping to change at page 2, line 23 ¶
	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 . . . . . . . . . . . . . . . . . . . . . 4
	7. Security Consideration . . . . . . . . . . . . . . . . . . . 4		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 . . . . . . . . . . . . . . . . . . 5
	10.2. Informational References . . . . . . . . . . . . . . . . 6		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
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 25 ¶
	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 SPI 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 SPI.
	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] explains how		one secret and thus one SPI. Section 3.5 of [RFC6407] provides a
	repetition MAY BE prevented by using a prefix for each group member,		mechanism that MAY be used to prevent IV collisions when the same key
	which could be prefixed to the Sequence Number. Otherwise, Implicit		is used by multiple users. The mechanism consists in partitioning
	IV MUST NOT be used in multicast scenarios.		the IV space between users by assigning the most significant byte to
			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
			Sequence Number. A similar mechanism could be used by associating
			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
			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.
			Unless some mechanism are provided to avoid collision between
			Sequence Number, ( and so IV ), Implicit IV MUST NOT be used.
	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 Implicit IV (IIV). This may require extra		algorithms without Implicit IV (IIV). This may require extra
	transforms.		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 transform 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. 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-CTR, AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to		AES-CCM, AES-GCM and ChaCha20-Poly1305 are likely to implement the
	implement the implicit IV described in this document. This section		implicit IV described in this document. This section limits
	limits assignment of new code points to the recommended suites		assignment of new code points to the recommended suites provided in
	provided in [RFC8221], thus the new Transform Type 1 - Encryption		[RFC8221], thus the new Transform Type 1 - Encryption Algorithm
	Algorithm Transform IDs [IANA] are as defined below:		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.
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 22 ¶
	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-13 (work in progress),		using IKEv2", draft-yeung-g-ikev2-13 (work in progress),
	March 2018.		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
	Ericsson		Ericsson
	8400 boulevard Decarie		8275 Trans Canada Route
	Montreal, QC H4P 2N2		Saint Laurent, QC H4S 0B6
	Canada		Canada
	Email: daniel.migault@ericsson.com		Email: daniel.migault@ericsson.com
	Tobias Guggemos (editor)		Tobias Guggemos
	LMU Munich		LMU Munich
	Oettingenstr. 67		Oettingenstr. 67
	80538 Munich, Bavaria		80538 Munich, Bavaria
	Germany		Germany
	Email: guggemos@mnm-team.org		Email: guggemos@mnm-team.org
	URI: http://mnm-team.org/~guggemos		URI: http://mnm-team.org/~guggemos
	Yoav Nir		Yoav Nir
	Dell EMC		Dell EMC
End of changes. 13 change blocks.
	22 lines changed or deleted		32 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/