draft-ietf-ipsecme-rfc7321bis-02.txt		draft-ietf-ipsecme-rfc7321bis-03.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: August 03, 2017 Red Hat		Expires: August 06, 2017 Red Hat
	Y. Nir		Y. Nir
	Check Point		Check Point
	T. Kivinen		T. Kivinen
	INSIDE Secure		INSIDE Secure
	January 30, 2017		February 02, 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-02		draft-ietf-ipsecme-rfc7321bis-03
	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 August 03, 2017.		This Internet-Draft will expire on August 06, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		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 . . . . . . . . . . . . . . . . . . . . 5
	3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5		4. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5
	5. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7		5. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7
	6. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9		6. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 9
	7. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9		7. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 10		10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	11.1. Normative References . . . . . . . . . . . . . . . . . . 10		11.1. Normative References . . . . . . . . . . . . . . . . . . 10
	skipping to change at page 3, line 36 ¶		skipping to change at page 3, line 36 ¶
	mandatory. This document attempts to identify and introduce those		mandatory. This document attempts to identify and introduce those
	algorithms for future mandatory-to-implement status. There is no		algorithms for future mandatory-to-implement status. There is no
	guarantee that the algorithms in use today may become mandatory in		guarantee that the algorithms in use today may become mandatory in
	the future. Published algorithms are continuously subjected to		the future. Published algorithms are continuously subjected to
	cryptographic attack and may become too weak or could become		cryptographic attack and may become too weak or could become
	completely broken before this document is updated.		completely broken before this document is updated.
	This document only provides recommendations for the mandatory-to-		This document only provides recommendations for the mandatory-to-
	implement algorithms and algorithms too weak that are recommended not		implement algorithms and algorithms too weak that are recommended not
	to be implemented. As a result, any algorithm listed at the IPsec		to be implemented. As a result, any algorithm listed at the IPsec
	IANA registry not mentioned in this document MAY be implemented. As		IANA registry not mentioned in this document MAY be implemented. It
	[RFC7321] omitted most of the algorithms mentioned by the IPsec IANA		is expected that this document will be updated over time and next
	repository, which makes it difficult to define whether non mentioned		versions will only mention algorithms which status has evolved. For
	algorithms are optional to implement or must not be implemented as		clarification when an algorithm has been mentioned in [RFC7321], this
	they are too weak. This document provides explicit guidance for all		document states explicitly the update of the status.
	of them. It is expected that this document will be updated over time
	and next versions will only mention algorithms which status has
	evolved. For clarification when an algorithm has been mentioned in
	[RFC7321], this document states explicitly the update of the status.
	Although this document updates the algorithms to keep the AH/ESP		Although this document updates the algorithms to keep the AH/ESP
	communication secure over time, it also aims at providing		communication secure over time, it also aims at providing
	recommendations so that AH/ESP implementations remain interoperable.		recommendations so that AH/ESP implementations remain interoperable.
	AH/ESP interoperability is addressed by an incremental introduction		AH/ESP interoperability is addressed by an incremental introduction
	or deprecation of algorithms. In addition, this document also		or deprecation of algorithms. In addition, this document also
	considers the new use cases for AH/ESP deployment, such as Internet		considers the new use cases for AH/ESP deployment, such as Internet
	of Things (IoT).		of Things (IoT).
	It is expected that deprecation of an algorithm is performed		It is expected that deprecation of an algorithm is performed
	skipping to change at page 4, line 19 ¶		skipping to change at page 4, line 15 ¶
	downgraded from MUST to MUST- or SHOULD, instead of MUST NOT.		downgraded from MUST to MUST- or SHOULD, instead of MUST NOT.
	Similarly, an algorithm that has not been mentioned as mandatory-to-		Similarly, an algorithm that has not been mentioned as mandatory-to-
	implement is expected to be introduced with a SHOULD instead of a		implement is expected to be introduced with a SHOULD instead of a
	MUST.		MUST.
	The current trend toward Internet of Things and its adoption of AH/		The current trend toward Internet of Things and its adoption of AH/
	ESP requires this specific use case to be taken into account as well.		ESP requires this specific use case to be taken into account as well.
	IoT devices are resource constrained devices and their choice of		IoT devices are resource constrained devices and their choice of
	algorithms are motivated by minimizing the footprint of the code, the		algorithms are motivated by minimizing the footprint of the code, the
	computation effort and the size of the messages to send. This		computation effort and the size of the messages to send. This
	document indicates "[IoT]" when a specified algorithm is specifically		document indicates "(IoT)" when a specified algorithm is specifically
	listed for IoT devices. Requirement levels that are marked as "IoT"		listed for IoT devices. Requirement levels that are marked as "IoT"
	apply to IoT devices and to server-side implementations that might		apply to IoT devices and to server-side implementations that might
	presumably need to interoperate with them, including any general-		presumably need to interoperate with them, including any general-
	purpose VPN gateways.		purpose VPN gateways.
	1.3. Document Audience		1.3. Document Audience
	The recommendations of this document mostly target AH/ESP		The recommendations of this document mostly target AH/ESP
	implementers as implementations need to meet both high security		implementers as implementations need to meet both high security
	expectations as well as high interoperability between various vendors		expectations as well as high interoperability between various vendors
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 6 ¶
	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:		We define some additional terms here:
	MUST- This term means the same as MUST. However, we expect that at		SHOULD+ This term means the same as SHOULD. However, it is likely
	some point in the future this algorithm will no longer be a MUST.		that an algorithm marked as SHOULD+ will be promoted at some
	SHOULD+ This term means the same as SHOULD. However, it is likely		future time to be a MUST.
	that an algorithm marked as SHOULD+ will be promoted at some		SHOULD- This term means the same as SHOULD. However, an algorithm
	future time to be a MUST.		marked as SHOULD- may be deprecated to a MAY in a future
			version of this document.
			MUST- This term means the same as MUST. However, we expect at some
			point that this algorithm will no longer be a MUST in a
			future document. Although its status will be determined at a
			later time, it is reasonable to expect that if a future
			revision of a document alters the status of a MUST-
			algorithm, it will remain at least a SHOULD or a SHOULD-
			level.
			IoT stands for Internet of Things.
			Table 1
	3. Manual Keying		3. Manual Keying
	Manual Keying is not to be used as it is inherently dangerous.		Manual Keying is not to be used as it is inherently dangerous.
	Without any keying protocol, it does not offer Perfect Forward		Without any keying protocol, it does not offer Perfect Forward
	Secrecy ("PFS") protection. Deployments tend to never be		Secrecy ("PFS") protection. Deployments tend to never be
	reconfigured with fresh session keys. It also fails to scale and		reconfigured with fresh session keys. It also fails to scale and
	keeping SPI's unique amongst many servers is impractical. This		keeping SPI's unique amongst many servers is impractical. This
	document was written for deploying ESP/AH using IKE (RFC7298) and		document was written for deploying ESP/AH using IKE ([RFC7296]) and
	assumes that keying happens using IKEv2.		assumes that keying happens using IKEv2.
	If manual keying is used anyway, ENCR_AES_CBC MUST be used, and		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		ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be
	used as these algorithms require IKE.		used as these algorithms require IKE.
	4. ESP Encryption Algorithms		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 |
	| ENCR_NULL | MUST | No | [RFC2410] |		| ENCR_NULL | MUST | No | [RFC2410] |
	| ENCR_AES_CBC | MUST | No | [RFC3602][1] |		| ENCR_AES_CBC | MUST | No | [RFC3602][1] |
	| ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309]IoT] |		| ENCR_AES_CCM_8 | SHOULD(IoT) | Yes | [RFC4309] |
	| 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 the given level.
	192-bit and 256-bit keys are at the MAY level.
	Table 1		Table 2
	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 to 256-bit keys in the long term.		packets, so there is a need to move to 256-bit keys in the long term.
	For that purpose the requirement level for 128 bit keys and 256 bit		For that purpose the requirement level for 128 bit keys and 256 bit
	keys are at MUST (when applicable). In that sense 256 bit keys		keys are at MUST (when applicable). In that sense 256 bit keys
	status has been raised from MAY in RFC7321 to MUST.		status has been raised from MAY in RFC7321 to MUST.
	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
	skipping to change at page 7, line 20 ¶		skipping to change at page 7, line 29 ¶
	devices. As this case is not a general use case for VPNs, its status		devices. As this case is not a general use case for VPNs, its status
	is expected to remain as SHOULD.		is expected to remain as SHOULD.
	ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order		ENCR_AES_GCM_16 status has been updated from SHOULD+ to MUST in order
	to favor the use of authenticated encryption and AEAD algorithms.		to favor the use of authenticated encryption and AEAD algorithms.
	ENCR_AES_GCM_16 has been widely implemented for ESP due to its		ENCR_AES_GCM_16 has been widely implemented for ESP due to its
	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 AES-CBC and AES-GCM. It is also being standardized
	standardized for ESP for the same reasons. At the time of writing,		for ESP for the same reasons. At the time of writing, there are not
	there are not enough ESP implementations of ENCR_CHACHA20_POLY1305 to		enough ESP implementations of ENCR_CHACHA20_POLY1305 to be able to
	be able to introduce it at the SHOULD+ level. Its status has been		introduce it at the SHOULD+ level. Its status has been set to SHOULD
	set to SHOULD and is expected to become MUST in the long term.		and is expected to become MUST in the long term.
	5. 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
	skipping to change at page 7, line 47 ¶		skipping to change at page 8, line 7 ¶
	+----------------------------+-------------+------------------------+		+----------------------------+-------------+------------------------+
	| Name | Status | Comment |		| Name | Status | Comment |
	+----------------------------+-------------+------------------------+		+----------------------------+-------------+------------------------+
	| AUTH_NONE | MUST / MUST | [RFC7296] AEAD |		| AUTH_NONE | MUST / MUST | [RFC7296] AEAD |
	| | NOT | |		| | NOT | |
	| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |		| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |
	| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |		| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |
	| AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] |		| AUTH_DES_MAC | MUST NOT | [UNSPECIFIED] |
	| AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] |		| AUTH_KPDK_MD5 | MUST NOT | [UNSPECIFIED] |
	| AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] |		| AUTH_AES_XCBC_96 | SHOULD | [RFC3566][RFC7296] |
	| | | [IoT] |		| | | (IoT) |
	| AUTH_AES_128_GMAC | MAY | [RFC4543] |		| AUTH_AES_128_GMAC | MAY | [RFC4543] |
	| AUTH_AES_256_GMAC | MAY | [RFC4543] |		| AUTH_AES_256_GMAC | MAY | [RFC4543] |
	| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |		| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |
	| AUTH_HMAC_SHA2_512_256 | SHOULD | [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		Table 3
	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 4. In all other cases, NULL		algorithms are selected from Section 4. In all other cases, NULL
	MUST NOT be selected. As ESP and AH both provides authentication,		MUST NOT be selected. As ESP and AH both provides authentication,
	one may be tempted to combine these protocols to provide		one may be tempted to combine these protocols to provide
	authentication. As mentioned by RFC7321, it is NOT RECOMMENDED to		authentication. As mentioned by RFC7321, it is NOT RECOMMENDED to
	use ESP with NULL authentication - with non authenticated encryption		use ESP with NULL authentication - with non authenticated encryption
	- in conjunction with AH; some configurations of this combination of		- in conjunction with AH; some configurations of this combination of
	services have been shown to be insecure [PD10]. In addition, NULL		services have been shown to be insecure [PD10]. In addition, NULL
	skipping to change at page 9, line 21 ¶		skipping to change at page 9, line 29 ¶
	+----------------+----------+-------------+		+----------------+----------+-------------+
	| 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		Table 4
	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.
	7. 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
	skipping to change at page 9, line 50 ¶		skipping to change at page 10, line 9 ¶
	| 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.
	Table 4		Table 5
	8. Acknowledgements		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.
	9. IANA Considerations		9. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
End of changes. 21 change blocks.
	52 lines changed or deleted		59 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/