< draft-ietf-ipsecme-implicit-iv-04.txt		draft-ietf-ipsecme-implicit-iv-05.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: November 10, 2018 LMU Munich		Expires: December 28, 2018 LMU Munich
	Y. Nir		Y. Nir
	Dell EMC		Dell EMC
	May 9, 2018		June 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-04		draft-ietf-ipsecme-implicit-iv-05
	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 November 10, 2018.		This Internet-Draft will expire on December 28, 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 28 ¶		skipping to change at page 2, line 28 ¶
	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 . . . . . . . . . . . . . . . . . . . 4
	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 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 SA 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 SA.
	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 SA. 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		An initiator supporting this feature SHOULD propose implicit IV
	algorithms in the Transform Type 1 (Encryption Algorithm)		algorithms in the Transform Type 1 (Encryption Algorithm)
	Substructure of the Proposal Substructure inside the SA Payload. To		Substructure of the Proposal Substructure inside the SA Payload. To
	facilitate backward compatibility with non-supporting peers the		facilitate backward compatibility with non-supporting peers the
	initiator SHOULD also include those same algorithms without Implicit		initiator SHOULD also include those same algorithms without Implicit
	IV (IIV) as separate transforms.		IV (IIV) as separate transforms.
	6. Responder Behavior		6. Responder Behavior
	skipping to change at page 5, line 5 ¶		skipping to change at page 4, line 46 ¶
	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.
			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
			setups with the chance that the Sequence Number overlaps for one SA.
			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 SA. As such, Implicit IV may only be used
			with Multicast if some mechanisms are employed that prevent Sequence
			Number to overlap for one SA, otherwise Implicit IV MUST NOT be used
			with Multicast.
			This document defines three new encryption transforms that use
			implicit IV. Unlike most encryption transforms defined to date,
			which can be used for both ESP and IKEv2, these transforms are
			defined for ESP only and cannot be used in IKEv2. The reason is that
			IKEv2 messages don't contain unique per-message value, that can be
			used for IV generation. The Message-ID field in IKEv2 header is
			somewhat counterpart of SN field in ESP header, but recent IKEv2
			extensions ([RFC6311], [RFC7383]) do allow it to repeat, so there is
			no an easy way to derive unique IV from IKEv2 header fields.
	8. IANA Considerations		8. IANA Considerations
	This section assigns new code points to the recommended AEAD suites		This section assigns new code points to the recommended AEAD 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: 29		- ENCR_AES_CCM_8_IIV: 29
	- ENCR_AES_GCM_16_IIV: 30		- ENCR_AES_GCM_16_IIV: 30
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 29 ¶
	[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
	Extensions to the Security Architecture for the Internet		Extensions to the Security Architecture for the Internet
	Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008,		Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008,
	<https://www.rfc-editor.org/info/rfc5374>.		<https://www.rfc-editor.org/info/rfc5374>.
			[RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D.
			Zhang, "Protocol Support for High Availability of IKEv2/
			IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011,
			<https://www.rfc-editor.org/info/rfc6311>.
	[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain		[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
	of Interpretation", RFC 6407, DOI 10.17487/RFC6407,		of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
	October 2011, <https://www.rfc-editor.org/info/rfc6407>.		October 2011, <https://www.rfc-editor.org/info/rfc6407>.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <https://www.rfc-editor.org/info/rfc7296>.		2014, <https://www.rfc-editor.org/info/rfc7296>.
			[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
			(IKEv2) Message Fragmentation", RFC 7383,
			DOI 10.17487/RFC7383, November 2014,
			<https://www.rfc-editor.org/info/rfc7383>.
	[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the		[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the
	Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634,		Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634,
	DOI 10.17487/RFC7634, August 2015,		DOI 10.17487/RFC7634, August 2015,
	<https://www.rfc-editor.org/info/rfc7634>.		<https://www.rfc-editor.org/info/rfc7634>.
	[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.		[RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.
	Kivinen, "Cryptographic Algorithm Implementation		Kivinen, "Cryptographic Algorithm Implementation
	Requirements and Usage Guidance for Encapsulating Security		Requirements and Usage Guidance for Encapsulating Security
	Payload (ESP) and Authentication Header (AH)", RFC 8221,		Payload (ESP) and Authentication Header (AH)", RFC 8221,
	DOI 10.17487/RFC8221, October 2017,		DOI 10.17487/RFC8221, October 2017,
End of changes. 9 change blocks.
	13 lines changed or deleted		35 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/