< draft-ietf-ipsecme-rfc4307bis-10.txt		draft-ietf-ipsecme-rfc4307bis-11.txt >
	Network Working Group Y. Nir		Network Working Group Y. Nir
	Internet-Draft Check Point		Internet-Draft Check Point
	Obsoletes: 4307 (if approved) T. Kivinen		Obsoletes: 4307 (if approved) T. Kivinen
	Updates: 7296 (if approved) INSIDE Secure		Updates: 7296 (if approved) INSIDE Secure
	Intended status: Standards Track P. Wouters		Intended status: Standards Track P. Wouters
	Expires: January 21, 2017 Red Hat		Expires: March 5, 2017 Red Hat
	D. Migault		D. Migault
	Ericsson		Ericsson
	July 20, 2016		September 1, 2016
	Algorithm Implementation Requirements and Usage Guidance for IKEv2		Algorithm Implementation Requirements and Usage Guidance for IKEv2
	draft-ietf-ipsecme-rfc4307bis-10		draft-ietf-ipsecme-rfc4307bis-11
	Abstract		Abstract
	The IPsec series of protocols makes use of various cryptographic		The IPsec series of protocols makes use of various cryptographic
	algorithms in order to provide security services. The Internet Key		algorithms in order to provide security services. The Internet Key
	Exchange (IKE) protocol is used to negotiate the IPsec Security		Exchange (IKE) protocol is used to negotiate the IPsec Security
	Association (IPsec SA) parameters, such as which algorithms should be		Association (IPsec SA) parameters, such as which algorithms should be
	used. To ensure interoperability between different implementations,		used. To ensure interoperability between different implementations,
	it is necessary to specify a set of algorithm implementation		it is necessary to specify a set of algorithm implementation
	requirements and usage guidance to ensure that there is at least one		requirements and usage guidance to ensure that there is at least one
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 January 21, 2017.		This Internet-Draft will expire on March 5, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	3.1. Type 1 - IKEv2 Encryption Algorithm Transforms		3.1. Type 1 - IKEv2 Encryption Algorithm Transforms
	The algorithms in the below table are negotiated in the SA payload		The algorithms in the below table are negotiated in the SA payload
	and used for the Encrypted Payload. References to the specification		and used for the Encrypted Payload. References to the specification
	defining these algorithms and the ones in the following subsections		defining these algorithms and the ones in the following subsections
	are in the IANA registry [IKEV2-IANA]. Some of these algorithms are		are in the IANA registry [IKEV2-IANA]. Some of these algorithms are
	Authenticated Encryption with Associated Data (AEAD - [RFC5282]).		Authenticated Encryption with Associated Data (AEAD - [RFC5282]).
	Algorithms that are not AEAD MUST be used in conjunction with an		Algorithms that are not AEAD MUST be used in conjunction with an
	integrity algorithms in Section 3.3.		integrity algorithms in Section 3.3.
	+------------------------+----------+-------+----------+		+------------------------+----------+-------+---------+
	| Name | Status | AEAD? | Comment |		| Name | Status | AEAD? | Comment |
	+------------------------+----------+-------+----------+		+------------------------+----------+-------+---------+
	| ENCR_AES_CBC | MUST | No | [1] |		| ENCR_AES_CBC | MUST | No | [1] |
	| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | |		| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | |
	| ENCR_AES_GCM_16 | SHOULD | Yes | [1] |		| ENCR_AES_GCM_16 | SHOULD | Yes | [1] |
	| ENCR_AES_CCM_8 | SHOULD | Yes | [1][IoT] |		| ENCR_AES_CCM_8 | SHOULD | Yes | [IoT] |
	| ENCR_3DES | MAY | No | |		| ENCR_3DES | MAY | No | |
	| ENCR_DES | MUST NOT | No | |		| ENCR_DES | MUST NOT | No | |
	+------------------------+----------+-------+----------+		+------------------------+----------+-------+---------+
	[1] - This requirement level is for 128-bit keys. 256-bit keys are at		[1] - This requirement level is for 128-bit and 256-bit keys.
	SHOULD. 192-bit keys can safely be ignored. [IoT] - This requirement		192-bit keys remain at MAY level. [IoT] - This requirement is for
	is for interoperability with IoT.		interoperability with IoT. Only 128-bit keys are at MUST level.
			192-bit and 256-bit keys are at the MAY level.
	ENCR_AES_CBC is raised from SHOULD+ in [RFC4307] to MUST. It is the		ENCR_AES_CBC is raised from SHOULD+ in [RFC4307] to MUST. It is the
	only shared mandatory-to-implement algorithm with RFC4307 and as a		only shared mandatory-to-implement algorithm with RFC4307 and as a
	result it is necessary for interoperability with IKEv2 implementation		result it is necessary for interoperability with IKEv2 implementation
	compatible with RFC4307.		compatible with RFC4307.
	ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of		ENCR_CHACHA20_POLY1305 was not ready to be considered at the time of
	RFC4307. It has been recommended by the CRFG and others as an		RFC4307. It has been recommended by the CRFG and others as an
	alternative to AES-CBC and AES-GCM. It is also being standardized		alternative to AES-CBC and AES-GCM. It is also being standardized
	for IPsec for the same reasons. At the time of writing, there were		for IPsec for the same reasons. At the time of writing, there were
End of changes. 6 change blocks.
	17 lines changed or deleted		18 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/