< draft-ietf-ipsecme-rfc7321bis-00.txt		draft-ietf-ipsecme-rfc7321bis-01.txt >
	Network Working Group D. Migault		Network Working Group D. Migault
	Internet-Draft J. Mattsson		Internet-Draft J. Mattsson
	Obsoletes: 7321 (if approved) Ericsson		Obsoletes: 7321 (if approved) Ericsson
	Intended status: Standards Track P. Wouters		Intended status: Standards Track P. Wouters
	Expires: April 9, 2017 Red Hat		Expires: July 12, 2017 Red Hat
	Y. Nir		Y. Nir
	Check Point		Check Point
	T. Kivinen		T. Kivinen
	INSIDE Secure		INSIDE Secure
	October 6, 2016		January 08, 2017
	Cryptographic Algorithm Implementation Requirements and Usage Guidance		Cryptographic Algorithm Implementation Requirements and Usage Guidance
	for Encapsulating Security Payload (ESP) and Authentication Header (AH)		for Encapsulating Security Payload (ESP) and Authentication Header (AH)
	draft-ietf-ipsecme-rfc7321bis-00		draft-ietf-ipsecme-rfc7321bis-01
	Abstract		Abstract
	This document updates the Cryptographic Algorithm Implementation		This document updates the Cryptographic Algorithm Implementation
	Requirements for ESP and AH. The goal of these document is to enable		Requirements for ESP and AH. The goal of these document is to enable
	ESP and AH to benefit from cryptography that is up to date while		ESP and AH to benefit from cryptography that is up to date while
	making IPsec interoperable.		making IPsec interoperable.
	This document obsoletes RFC 7321 on the cryptographic recommendations		This document obsoletes RFC 7321 on the cryptographic recommendations
	only.		only.
	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 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 April 9, 2017.		This Internet-Draft will expire on July 12, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Updating Algorithm Implementation Requirements and Usage		1.1. Updating Algorithm Implementation Requirements and Usage
	Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2		Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3		1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
	1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4		1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
	3. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5		3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7		4. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5
	5. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 8		5. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7
	6. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9		6. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		7. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 9		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . 10		11.1. Normative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		11.2. Informative References . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The Encapsulating Security Payload (ESP) [RFC4303] and the		The Encapsulating Security Payload (ESP) [RFC4303] and the
	Authentication Header (AH) [RFC4302] are the mechanisms for applying		Authentication Header (AH) [RFC4302] are the mechanisms for applying
	cryptographic protection to data being sent over an IPsec Security		cryptographic protection to data being sent over an IPsec Security
	Association (SA) [RFC4301].		Association (SA) [RFC4301].
	This document provides guidance and recommendations so that ESP and		This document provides guidance and recommendations so that ESP and
	AH can be used with a cryptographic algorithms that are up to date.		AH can be used with a cryptographic algorithms that are up to date.
	skipping to change at page 4, line 47 ¶		skipping to change at page 5, line 4 ¶
	IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is		IKEv2 parameters. IKEv1 is out of scope of this document. IKEv1 is
	deprecated and the recommendations of this document must not be		deprecated and the recommendations of this document must not be
	considered for IKEv1, nor IKEv1 parameters be considered by this		considered for IKEv1, nor IKEv1 parameters be considered by this
	document.		document.
	The IANA registry for Internet Key Exchange Version 2 (IKEv2)		The IANA registry for Internet Key Exchange Version 2 (IKEv2)
	Parameters contains some entries that are not for use with ESP or AH.		Parameters contains some entries that are not for use with ESP or AH.
	This document does not modify the status of those algorithms.		This document does not modify the status of those algorithms.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"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 in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	Following [RFC4835], we define some additional key words:		Following [RFC4835], we define some additional key words:
	MUST- This term means the same as MUST. However, we expect that at		MUST- This term means the same as MUST. However, we expect that at
	some point in the future this algorithm will no longer be a MUST.		some point in the future this algorithm will no longer be a MUST.
	SHOULD+ This term means the same as SHOULD. However, it is likely		SHOULD+ This term means the same as SHOULD. However, it is likely
	that an algorithm marked as SHOULD+ will be promoted at some		that an algorithm marked as SHOULD+ will be promoted at some
	future time to be a MUST.		future time to be a MUST.
	3. ESP Encryption Algorithms		3. Manual Keying
			Manual Keying is not be used as it is inherently dangerous. Without
			any keying protocol, it does not offer Perfect Forward Secrecy
			("PFS") protection. Deployments tend to never be reconfigured with
			fresh session keys. It also fails to scale and keeping SPI's unique
			amongst many servers is impractical. This document was written for
			deploying ESP/AH using IKE (RFC7298) and assumes that keying happens
			using IKEv2.
			If manual keying is used anyway, ENCR_AES_CBC MUST be used, and
			ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be
			used as these algorithms require IKE.
			4. ESP Encryption Algorithms
	+-------------------------+------------+---------+---------------+		+-------------------------+------------+---------+---------------+
	| Name | Status | AEAD | Comment |		| Name | Status | AEAD | Comment |
	+-------------------------+------------+---------+---------------+		+-------------------------+------------+---------+---------------+
	| ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED |		| ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED |
	| ENCR_DES | MUST NOT | No | [RFC2405] |		| ENCR_DES | MUST NOT | No | [RFC2405] |
	| ENCR_3DES | SHOULD NOT | No | [RFC2451] |		| ENCR_3DES | SHOULD NOT | No | [RFC2451] |
	| ENCR_BLOWFISH | MUST NOT | No | [RFC2451] |		| ENCR_BLOWFISH | MUST NOT | No | [RFC2451] |
	| ENCR_3IDEA | MUST NOT | No | UNSPECIFIED |		| ENCR_3IDEA | MUST NOT | No | UNSPECIFIED |
	| ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED |		| ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED |
	skipping to change at page 5, line 36 ¶		skipping to change at page 6, line 10 ¶
	| ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309]IoT] |		| ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309]IoT] |
	| ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] |		| ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] |
	| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] |		| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] |
	+-------------------------+------------+---------+---------------+		+-------------------------+------------+---------+---------------+
	[1] - This requirement level is for 128-bit and 256-bit keys.		[1] - This requirement level is for 128-bit and 256-bit keys.
	192-bit keys remain at MAY level. [IoT] - This requirement is for		192-bit keys remain at MAY level. [IoT] - This requirement is for
	interoperability with IoT. Only 128-bit keys are at MUST level.		interoperability with IoT. Only 128-bit keys are at MUST level.
	192-bit and 256-bit keys are at the MAY level.		192-bit and 256-bit keys are at the MAY level.
			Table 1
	IPsec sessions may have very long life time, and carry multiple		IPsec sessions may have very long life time, and carry multiple
	packets, so there is a need to move 256-bit keys in the long term.		packets, so there is a need to move 256-bit keys in the long term.
	For that purpose requirement level is for 128 bit keys and 256 bit		For that purpose requirement level is for 128 bit keys and 256 bit
	keys are at SHOULD (when applicable). In that sense 256 bit keys		keys are at SHOULD (when applicable). In that sense 256 bit keys
	status has been raised from MAY in RFC7321 to SHOULD.		status has been raised from MAY in RFC7321 to SHOULD.
	IANA has allocated codes for cryptographic algorithms that have not		IANA has allocated codes for cryptographic algorithms that have not
	been specified by the IETF. Such algorithms are noted as		been specified by the IETF. Such algorithms are noted as
	UNSPECIFIED. Usually, the use of theses algorithms is limited to		UNSPECIFIED. Usually, the use of theses algorithms is limited to
	specific cases, and the absence of specification makes		specific cases, and the absence of specification makes
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 26 ¶
	increased performance and key longevity compared to ENCR_AES_CBC.		increased performance and key longevity compared to ENCR_AES_CBC.
	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
	RFC7321. It has been recommended by the CRFG and others as an		RFC7321. It has been recommended by the CRFG and others as an
	alternative to ENCR_AES_XCBC and ENCR_AES_GCM_*. It is also being		alternative to ENCR_AES_XCBC and ENCR_AES_GCM_*. It is also being
	standardized for ESP for the same reasons. At the time of writing,		standardized for ESP for the same reasons. At the time of writing,
	there are not enough ESP implementations of ENCR_CHACHA20_POLY1305 to		there are not enough ESP implementations of ENCR_CHACHA20_POLY1305 to
	be able to introduce it at the SHOULD+ level. Its status has been		be able to introduce it at the SHOULD+ level. Its status has been
	set to SHOULD and is expected to become MUST in the long term.		set to SHOULD and is expected to become MUST in the long term.
	4. ESP and AH Authentication Algorithms		5. ESP and AH Authentication Algorithms
	Encryption without authentication MUST NOT be used. As a result,		Encryption without authentication MUST NOT be used. As a result,
	authentication algorithm recommendations in this section are		authentication algorithm recommendations in this section are
	targeting two types of communications: Firstly authenticated only		targeting two types of communications: Firstly authenticated only
	communications without encryption. Such communications can be ESP		communications without encryption. Such communications can be ESP
	with NULL encryption or AH communications. Secondly, communications		with NULL encryption or AH communications. Secondly, communications
	that are encrypted with non AEAD encryption algorithms mentioned		that are encrypted with non AEAD encryption algorithms mentioned
	above. In this case, they MUST be combined with an authentication		above. In this case, they MUST be combined with an authentication
	algorithm.		algorithm.
	+------------------------+------------------+-----------------------+		+----------------------------+-------------+------------------------+
	| Name | Status | Comment |		| Name | Status | Comment |
	+------------------------+------------------+-----------------------+		+----------------------------+-------------+------------------------+
	| AUTH_NONE | MUST / MUST NOT | [RFC7296] AEAD |		| AUTH_NONE | MUST / MUST | [RFC7296] AEAD |
	| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |		| | NOT | |
	| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |		| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |
	| AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] |		| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |
	| AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] |		| AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] |
	| AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] |		| AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] |
	| | | [IoT] |		| AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] |
	| AUTH_AES_128_GMAC | MAY | [RFC4543] |		| | | [IoT] |
	| AUTH_AES_256_GMAC | MAY | [RFC4543] |		| AUTH_AES_128_GMAC | MAY | [RFC4543] |
	| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |		| AUTH_AES_256_GMAC | MAY | [RFC4543] |
	| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] |		| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |
	+------------------------+------------------+-----------------------+		| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] |
			+----------------------------+-------------+------------------------+
	[IoT] - This requirement is for interoperability with IoT		[IoT] - This requirement is for interoperability with IoT
			Table 2
	AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The		AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The
	only reason NULL is acceptable is when authenticated encryption		only reason NULL is acceptable is when authenticated encryption
	algorithms are selected from Section 3. In all other case, NULL MUST		algorithms are selected from Section 4. In all other case, NULL MUST
	NOT be selected. As ESP and AH provides both authentication, one may		NOT be selected. As ESP and AH provides both authentication, one may
	be tempted to combine these protocol to provide authentication. As		be tempted to combine these protocol to provide authentication. As
	mentioned by RFC7321, it is NOT RECOMMENDED to use ESP with NULL		mentioned by RFC7321, it is NOT RECOMMENDED to use ESP with NULL
	authentication - with non authenticated encryption - in conjunction		authentication - with non authenticated encryption - in conjunction
	with AH; some configurations of this combination of services have		with AH; some configurations of this combination of services have
	been shown to be insecure [PD10]. In addition, NULL authentication		been shown to be insecure [PD10]. In addition, NULL authentication
	cannot be combined with ESP NULL encryption.		cannot be combined with ESP NULL encryption.
	AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in RFC7321. As		AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 were not mentioned in RFC7321. As
	MD5 is known to be vulnerable to collisions, these algorithms MUST		MD5 is known to be vulnerable to collisions, these algorithms MUST
	skipping to change at page 8, line 34 ¶		skipping to change at page 9, line 10 ¶
	a long standing common implementation bug of this algorithm that		a long standing common implementation bug of this algorithm that
	truncates the hash at 96-bits instead of 128-bits, it is recommended		truncates the hash at 96-bits instead of 128-bits, it is recommended
	that implementations prefer AUTH_HMAC_SHA2_512_256 over		that implementations prefer AUTH_HMAC_SHA2_512_256 over
	AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256.		AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256.
	AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement		AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement
	of AUTH_HMAC_SHA2_256_128 or when stronger security is required.		of AUTH_HMAC_SHA2_256_128 or when stronger security is required.
	This value has been preferred to AUTH_HMAC_SHA2_384, as the		This value has been preferred to AUTH_HMAC_SHA2_384, as the
	additional overhead of AUTH_HMAC_SHA2_512 is negligible.		additional overhead of AUTH_HMAC_SHA2_512 is negligible.
	5. ESP and AH Compression Algorithms		6. ESP and AH Compression Algorithms
	+----------------+----------+-------------+		+----------------+----------+-------------+
	| Name | Status | Comment |		| Name | Status | Comment |
	+----------------+----------+-------------+		+----------------+----------+-------------+
	| IPCOMP_OUI | MUST NOT | UNSPECIFIED |		| IPCOMP_OUI | MUST NOT | UNSPECIFIED |
	| IPCOMP_DEFLATE | MAY | [RFC2393] |		| IPCOMP_DEFLATE | MAY | [RFC2393] |
	| IPCOMP_LZS | MAY | [RFC2395] |		| IPCOMP_LZS | MAY | [RFC2395] |
	| IPCOMP_LZJH | MAY | [RFC3051] |		| IPCOMP_LZJH | MAY | [RFC3051] |
	+----------------+----------+-------------+		+----------------+----------+-------------+
	[IoT] - This requirement is for interoperability with IoT		[IoT] - This requirement is for interoperability with IoT
			Table 3
	Compression was not mentioned in RFC7321. As it is not widely		Compression was not mentioned in RFC7321. As it is not widely
	deployed, it remains optional and at the MAY-level.		deployed, it remains optional and at the MAY-level.
	6. Summary of Changes from RFC 7321		7. Summary of Changes from RFC 7321
	The following table summarizes the changes from RFC 7321.		The following table summarizes the changes from RFC 7321.
	RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE		RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE
	TABLE BELOW WITH THE NUMBER OF THIS RFC		TABLE BELOW WITH THE NUMBER OF THIS RFC
	+-------------------+----------+-----------------+		+-------------------+----------+-----------------+
	| Algorithm | RFC 7321 | RFC XXXX |		| Algorithm | RFC 7321 | RFC XXXX |
	+-------------------+----------+-----------------+		+-------------------+----------+-----------------+
	| ENCR_AES_GCM_16 | SHOULD+ | MUST |		| ENCR_AES_GCM_16 | SHOULD+ | MUST |
	skipping to change at page 9, line 27 ¶		skipping to change at page 9, line 50 ¶
	| ENCR_AES_CTR | MAY | (*) |		| ENCR_AES_CTR | MAY | (*) |
	| ENCR_3DES | MAY | SHOULD NOT |		| ENCR_3DES | MAY | SHOULD NOT |
	| AUTH_HMAC_SHA1_96 | MUST | MUST- |		| AUTH_HMAC_SHA1_96 | MUST | MUST- |
	| AUTH_AES_128_GMAC | SHOULD+ | MAY |		| AUTH_AES_128_GMAC | SHOULD+ | MAY |
	| AUTH_NONE | MAY | MUST / MUST NOT |		| AUTH_NONE | MAY | MUST / MUST NOT |
	+-------------------+----------+-----------------+		+-------------------+----------+-----------------+
	(*) This algorithm is not mentioned in the above sections, so it		(*) This algorithm is not mentioned in the above sections, so it
	defaults to MAY.		defaults to MAY.
	7. Acknowledgements		Table 4
			8. Acknowledgements
	Some of the wording in this document was adapted from [RFC7321], the		Some of the wording in this document was adapted from [RFC7321], the
	document that this one obsoletes, which was written by D. McGrew and		document that this one obsoletes, which was written by D. McGrew and
	P. Hoffman.		P. Hoffman.
	8. IANA Considerations		9. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	9. Security Considerations		10. Security Considerations
	The security of a system that uses cryptography depends on both the		The security of a system that uses cryptography depends on both the
	strength of the cryptographic algorithms chosen and the strength of		strength of the cryptographic algorithms chosen and the strength of
	the keys used with those algorithms. The security also depends on		the keys used with those algorithms. The security also depends on
	the engineering and administration of the protocol used by the system		the engineering and administration of the protocol used by the system
	to ensure that there are no non-cryptographic ways to bypass the		to ensure that there are no non-cryptographic ways to bypass the
	security of the overall system.		security of the overall system.
	This document concerns itself with the selection of cryptographic		This document concerns itself with the selection of cryptographic
	algorithms for the use of ESP and AH, specifically with the selection		algorithms for the use of ESP and AH, specifically with the selection
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 31 ¶
	to ensure that there are no non-cryptographic ways to bypass the		to ensure that there are no non-cryptographic ways to bypass the
	security of the overall system.		security of the overall system.
	This document concerns itself with the selection of cryptographic		This document concerns itself with the selection of cryptographic
	algorithms for the use of ESP and AH, specifically with the selection		algorithms for the use of ESP and AH, specifically with the selection
	of mandatory-to-implement algorithms. The algorithms identified in		of mandatory-to-implement algorithms. The algorithms identified in
	this document as "MUST implement" or "SHOULD implement" are not known		this document as "MUST implement" or "SHOULD implement" are not known
	to be broken at the current time, and cryptographic research to date		to be broken at the current time, and cryptographic research to date
	leads us to believe that they will likely remain secure into the		leads us to believe that they will likely remain secure into the
	foreseeable future. However, this is not necessarily forever.		foreseeable future. However, this is not necessarily forever.
	Therefore, we expect that revisions of that document will be issued		Therefore, we expect that revisions of that document will be issued
	from time to time to reflect the current best practice in this area.		from time to time to reflect the current best practice in this area.
	10. References		11. References
	10.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	DOI 10.17487/RFC2119, March 1997,		RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <http://www.rfc-editor.org/info/rfc4301>.		December 2005, <http://www.rfc-editor.org/info/rfc4301>.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI
	DOI 10.17487/RFC4302, December 2005,		10.17487/RFC4302, December 2005,
	<http://www.rfc-editor.org/info/rfc4302>.		<http://www.rfc-editor.org/info/rfc4302>.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
	RFC 4303, DOI 10.17487/RFC4303, December 2005,		4303, DOI 10.17487/RFC4303, December 2005,
	<http://www.rfc-editor.org/info/rfc4303>.		<http://www.rfc-editor.org/info/rfc4303>.
	[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm		[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm
	Implementation Requirements and Usage Guidance for		Implementation Requirements and Usage Guidance for
	Encapsulating Security Payload (ESP) and Authentication		Encapsulating Security Payload (ESP) and Authentication
	Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014,		Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014,
	<http://www.rfc-editor.org/info/rfc7321>.		<http://www.rfc-editor.org/info/rfc7321>.
	[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,
	<http://www.rfc-editor.org/info/rfc7634>.		<http://www.rfc-editor.org/info/rfc7634>.
	10.2. Informative References		11.2. Informative References
	[PD10] Paterson, K. and J. Degabriele, "On the (in)security of		[PD10] Paterson, K. and J. Degabriele, "On the (in)security of
	IPsec in MAC-then-encrypt configurations (ACM Conference		IPsec in MAC-then-encrypt configurations (ACM Conference
	on Computer and Communications Security, ACM CCS)", 2010.		on Computer and Communications Security, ACM CCS)", 2010.
	[RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP		[RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
	Payload Compression Protocol (IPComp)", RFC 2393,		Payload Compression Protocol (IPComp)", RFC 2393, DOI
	DOI 10.17487/RFC2393, December 1998,		10.17487/RFC2393, December 1998,
	<http://www.rfc-editor.org/info/rfc2393>.		<http://www.rfc-editor.org/info/rfc2393>.
	[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using		[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using
	LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998,		LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998,
	<http://www.rfc-editor.org/info/rfc2395>.		<http://www.rfc-editor.org/info/rfc2395>.
	[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within		[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
	ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November		ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November
	1998, <http://www.rfc-editor.org/info/rfc2403>.		1998, <http://www.rfc-editor.org/info/rfc2403>.
	[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within		[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
	ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November		ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
	1998, <http://www.rfc-editor.org/info/rfc2404>.		1998, <http://www.rfc-editor.org/info/rfc2404>.
	[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher		[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
	Algorithm With Explicit IV", RFC 2405,		Algorithm With Explicit IV", RFC 2405, DOI 10.17487/
	DOI 10.17487/RFC2405, November 1998,		RFC2405, November 1998,
	<http://www.rfc-editor.org/info/rfc2405>.		<http://www.rfc-editor.org/info/rfc2405>.
	[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and		[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
	Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410,		Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410,
	November 1998, <http://www.rfc-editor.org/info/rfc2410>.		November 1998, <http://www.rfc-editor.org/info/rfc2410>.
	[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher		[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
	Algorithms", RFC 2451, DOI 10.17487/RFC2451, November		Algorithms", RFC 2451, DOI 10.17487/RFC2451, November
	1998, <http://www.rfc-editor.org/info/rfc2451>.		1998, <http://www.rfc-editor.org/info/rfc2451>.
	[RFC3051] Heath, J. and J. Border, "IP Payload Compression Using		[RFC3051] Heath, J. and J. Border, "IP Payload Compression Using
	ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051,		ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051,
	January 2001, <http://www.rfc-editor.org/info/rfc3051>.		January 2001, <http://www.rfc-editor.org/info/rfc3051>.
	[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm		[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
	and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566,		and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566,
	September 2003, <http://www.rfc-editor.org/info/rfc3566>.		September 2003, <http://www.rfc-editor.org/info/rfc3566>.
	[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher		[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
	Algorithm and Its Use with IPsec", RFC 3602,		Algorithm and Its Use with IPsec", RFC 3602, DOI 10.17487/
	DOI 10.17487/RFC3602, September 2003,		RFC3602, September 2003,
	<http://www.rfc-editor.org/info/rfc3602>.		<http://www.rfc-editor.org/info/rfc3602>.
	[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
	RFC 4106, DOI 10.17487/RFC4106, June 2005,		4106, DOI 10.17487/RFC4106, June 2005,
	<http://www.rfc-editor.org/info/rfc4106>.		<http://www.rfc-editor.org/info/rfc4106>.
	[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
	RFC 4309, DOI 10.17487/RFC4309, December 2005,		4309, DOI 10.17487/RFC4309, December 2005,
	<http://www.rfc-editor.org/info/rfc4309>.		<http://www.rfc-editor.org/info/rfc4309>.
	[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message		[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
	Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,		Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
	DOI 10.17487/RFC4543, May 2006,		DOI 10.17487/RFC4543, May 2006,
	<http://www.rfc-editor.org/info/rfc4543>.		<http://www.rfc-editor.org/info/rfc4543>.
	[RFC4835] Manral, V., "Cryptographic Algorithm Implementation		[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
	Requirements for Encapsulating Security Payload (ESP) and		Requirements for Encapsulating Security Payload (ESP) and
	Authentication Header (AH)", RFC 4835,		Authentication Header (AH)", RFC 4835, DOI 10.17487/
	DOI 10.17487/RFC4835, April 2007,		RFC4835, April 2007,
	<http://www.rfc-editor.org/info/rfc4835>.		<http://www.rfc-editor.org/info/rfc4835>.
	[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-		[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-
	384, and HMAC-SHA-512 with IPsec", RFC 4868,		SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI
	DOI 10.17487/RFC4868, May 2007,		10.17487/RFC4868, May 2007,
	<http://www.rfc-editor.org/info/rfc4868>.		<http://www.rfc-editor.org/info/rfc4868>.
	[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, <http://www.rfc-editor.org/info/rfc7296>.		2014, <http://www.rfc-editor.org/info/rfc7296>.
	Authors' Addresses		Authors' Addresses
	Daniel Migault		Daniel Migault
End of changes. 35 change blocks.
	68 lines changed or deleted		90 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/