< draft-ietf-ipsecme-implicit-iv-08.txt		draft-ietf-ipsecme-implicit-iv-09.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: April 18, 2020 LMU Munich		Expires: April 20, 2020 LMU Munich
	Y. Nir		Y. Nir
	Dell EMC		Dell EMC
	October 16, 2019		October 18, 2019
	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-08		draft-ietf-ipsecme-implicit-iv-09
	Abstract		Abstract
	Encapsulating Security Payload (ESP) sends an initialization vector		Encapsulating Security Payload (ESP) sends an initialization vector
	(IV) in each packet. The size of IV depends on the applied		(IV) 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 and ChaCha20-Poly1305 when used with IPsec, take the IV to		AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to
	generate a nonce that is used as an input parameter for encrypting		generate a nonce that is used as an input parameter for encrypting
	and decrypting. These algorithms require a unique IV but do not		and decrypting. This IV must be unique but can be predictable. As a
	require an unpredictable IV. As a result, the value provided in the		result, the value provided in the ESP Sequence Number (SN) can be
	ESP Sequence Number (SN) can be used instead to generate the nonce.		used instead to generate the nonce. This avoids sending the IV
	This avoids sending the IV itself, and saves in the case of AES-GCM,		itself, and saves in the case of AES-GCM, AES-CCM and
	AES-CCM and ChaCha20-Poly1305 8 octets per packet. This document		ChaCha20-Poly1305 8 octets per packet. This document describes how
	describes how to do this.		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 April 18, 2020.		This Internet-Draft will expire on April 20, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 49 ¶		skipping to change at page 2, line 49 ¶
	"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 BCP 14		"OPTIONAL" in this document are to be interpreted as described BCP 14
	[RFC2119], [RFC8174] when, and only when, they appear in all		[RFC2119], [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Introduction		2. Introduction
	Counter-based AES modes of operation such as AES-CCM ([RFC4309]), and		Counter-based AES modes of operation such as AES-CCM ([RFC4309]), and
	AES-GCM ([RFC4106]) require the specification of an nonce for each		AES-GCM ([RFC4106]) require the specification of an nonce for each
	ESP packet. The same applies for ChaCha20-Poly1305 ([RFC7634]).		ESP packet. The same applies for ChaCha20-Poly1305 ([RFC7634]).
	Currently this nonce is generated thanks to the Initialize Vector		Currently this nonce is generated thanks to the Initialization Vector
	(IV) provided in each ESP packet ([RFC4303]). This practice is		(IV) provided in each ESP packet ([RFC4303]). This practice is
	designated in this document as "explicit IV".		designated in this document as "explicit IV".
	In some contexts, such as IoT, it may be preferable to avoid carrying		In some contexts, 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 IV is designated in this		on each peer. The local generation of the IV is designated in this
	document as "implicit IV".		document as "implicit IV".
	The size of this IV depends on the specific algorithm, but all of the		The size of this IV depends on the specific algorithm, but all of the
	algorithms mentioned above take an 8-octet IV.		algorithms mentioned above take an 8-octet IV.
	This document defines how to compute the IV locally when it is		This document defines how to compute the IV locally when it is
	implicit. It also specifies how peers agree with the Internet Key		implicit. It also specifies how peers agree with the Internet Key
	Exchange version 2 (IKEv2 - [RFC7296]) on using an implicit IV versus		Exchange version 2 (IKEv2 - [RFC7296]) on using an implicit IV versus
	an explicit IV.		an explicit IV.
	This document limits its scope to the algorithms mentioned above.		This document limits its scope to the algorithms mentioned above.
	Other algorithms with similar properties may later be defined to use		Other algorithms with similar properties may later be defined to use
	similar mechanism.		similar mechanisms.
	This document does not consider AES-CBC ([RFC3602]) as AES-CBC		This document does not consider AES-CBC ([RFC3602]) as AES-CBC
	requires the IV to be unpredictable. Deriving it directly from the		requires the IV to be unpredictable. Deriving it directly from the
	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].
	This document does not consider AES-CTR [RFC3686] as it focuses on		This document does not consider AES-CTR [RFC3686] as it focuses on
	the recommended AEAD suites provided in [RFC8221].		the recommended AEAD suites provided in [RFC8221].
End of changes. 7 change blocks.
	12 lines changed or deleted		12 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/