draft-mglt-ipsecme-rfc7321bis-03.txt		draft-mglt-ipsecme-rfc7321bis-04.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: March 5, 2017 Red Hat		Expires: March 13, 2017 Red Hat
	Y. Nir		Y. Nir
	Check Point		Check Point
	T. Kivinen		T. Kivinen
	INSIDE Secure		INSIDE Secure
	September 1, 2016		September 9, 2016
	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-mglt-ipsecme-rfc7321bis-03		draft-mglt-ipsecme-rfc7321bis-04
	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 March 5, 2017.		This Internet-Draft will expire on March 13, 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 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	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. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 5
	4. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7		4. ESP and AH Authentication Algorithms . . . . . . . . . . . . 7
	5. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 8		5. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 8
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		6. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
			10.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	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
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 5 ¶
	| 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
	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. Acknowledgements		6. Summary of Changes from RFC 7321
			The following table summarizes the changes from RFC 7321.
			RFC EDITOR: PLEASE REMOVE THIS PARAGRAPH AND REPLACE XXXX IN THE
			TABLE BELOW WITH THE NUMBER OF THIS RFC
			+-------------------+----------+-----------------+
			| Algorithm | RFC 7321 | RFC XXXX |
			+-------------------+----------+-----------------+
			| ENCR_AES_GCM_16 | SHOULD+ | MUST |
			| ENCR_AES_CCM_8 | MAY | SHOULD |
			| ENCR_AES_CTR | MAY | (*) |
			| ENCR_3DES | MAY | SHOULD NOT |
			| AUTH_HMAC_SHA1_96 | MUST | MUST- |
			| AUTH_AES_128_GMAC | SHOULD+ | MAY |
			| AUTH_NONE | MAY | MUST / MUST NOT |
			+-------------------+----------+-----------------+
			(*) This algorithm is not mentioned in the above sections, so it
			defaults to MAY.
			7. 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.
	7. IANA Considerations		8. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	8. Security Considerations		9. 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 9, line 31 ¶		skipping to change at page 10, line 4 ¶
	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.
	9. References		10. References
	9.1. Normative References		10.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/RFC2119, March 1997,		DOI 10.17487/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>.
	skipping to change at page 10, line 20 ¶		skipping to change at page 10, line 40 ¶
	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>.
	9.2. Informative References		10.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 10.17487/RFC2393, December 1998,		DOI 10.17487/RFC2393, December 1998,
	<http://www.rfc-editor.org/info/rfc2393>.		<http://www.rfc-editor.org/info/rfc2393>.
End of changes. 12 change blocks.
	16 lines changed or deleted		40 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/