< draft-ietf-ipsecme-rfc4307bis-00.txt		draft-ietf-ipsecme-rfc4307bis-01.txt >
	Network Working Group Y. Nir		Network Working Group Y. Nir
	Internet-Draft Check Point		Internet-Draft Check Point
	Intended status: Standards Track T. Kivinen		Intended status: Standards Track T. Kivinen
	Expires: April 20, 2016 INSIDE Secure		Expires: May 12, 2016 INSIDE Secure
	P. Wouters		P. Wouters
	Red Hat		Red Hat
	D. Migault		D. Migault
	Ericsson		Ericsson
	October 18, 2015		November 9, 2015
	Cryptographic Algorithms for Use in the Internet Key Exchange Version 2		Cryptographic Algorithms for Use in the Internet Key Exchange Version 2
	(IKEv2)		(IKEv2)
	draft-ietf-ipsecme-rfc4307bis-00		draft-ietf-ipsecme-rfc4307bis-01
	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 protocol provides a mechanism to negotiate which algorithms		Exchange protocol provides a mechanism to negotiate which algorithms
	should be used in any given association. However, to ensure		should be used in any given association. However, to ensure
	interoperability between disparate implementations, it is necessary		interoperability between disparate implementations, it is necessary
	to specify a set of mandatory-to-implement algorithms to ensure that		to specify a set of mandatory-to-implement algorithms to ensure that
	there is at least one algorithm that all implementations will have		there is at least one algorithm that all implementations will have
	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 April 20, 2016.		This Internet-Draft will expire on May 12, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	2. Conventions Used in This Document . . . . . . . . . . . . . . 3		2. Conventions Used in This Document . . . . . . . . . . . . . . 3
	3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 3		3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 3
	3.1. IKEv2 Transform Type 1 Algorithms . . . . . . . . . . . . 3		3.1. IKEv2 Transform Type 1 Algorithms . . . . . . . . . . . . 3
	3.2. IKEv2 Transform Type 3 Algorithms . . . . . . . . . . . . 4		3.2. IKEv2 Transform Type 3 Algorithms . . . . . . . . . . . . 4
	3.3. IKEv2 Transform Type 2 Algorithms . . . . . . . . . . . . 4		3.3. IKEv2 Transform Type 2 Algorithms . . . . . . . . . . . . 5
	3.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 5		3.4. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 5
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7.1. Normative References . . . . . . . . . . . . . . . . . . 6		7.1. Normative References . . . . . . . . . . . . . . . . . . 6
	7.2. Informative References . . . . . . . . . . . . . . . . . 6		7.2. Informative References . . . . . . . . . . . . . . . . . 7
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	The Internet Key Exchange protocol [RFC7296] provides for the		The Internet Key Exchange protocol [RFC7296] provides for the
	negotiation of cryptographic algorithms between both endpoints of a		negotiation of cryptographic algorithms between both endpoints of a
	cryptographic association. Different implementations of IPsec and		cryptographic association. Different implementations of IPsec and
	IKE may provide different algorithms. However, the IETF desires that		IKE may provide different algorithms. However, the IETF desires that
	all implementations should have some way to interoperate. In		all implementations should have some way to interoperate. In
	particular, this requires that IKE define a set of mandatory-to-		particular, this requires that IKE define a set of mandatory-to-
	implement algorithms because IKE itself uses such algorithms as part		implement algorithms because IKE itself uses such algorithms as part
	skipping to change at page 4, line 19 ¶		skipping to change at page 4, line 20 ¶
	| 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 | |
	| AES-GCM with a 16 octet ICV | SHOULD | Yes | [1] |		| AES-GCM with a 16 octet ICV | SHOULD | Yes | [1] |
	| ENCR_AES_CCM_8 | SHOULD | Yes | [1] |		| ENCR_AES_CCM_8 | SHOULD | Yes | [1] |
	| ENCR_3DES | MAY | No | |		| ENCR_3DES | MAY | No | |
	| ENCR_DES | MUST NOT | No | |		| ENCR_DES | MUST NOT | No | |
	+-----------------------------+----------+-------+---------+		+-----------------------------+----------+-------+---------+
	[1] - Both 256-bit and 128-bit keys should be supported at the same		[1] - This requirement level is for 128-bit keys. 256-bit keys are at
	level of requirement.		MAY. 192-bit keys can safely be ignored.
			Explanation about AES-CBC is TBD.
			Explanation about ChaCha20 is TBD.
			Explanation about AES-GCM is TBD.
			Explanation about AES-CCM is TBD.
			Explanation about 3DES is TBD.
			Explanation about DES is TBD.
	3.2. IKEv2 Transform Type 3 Algorithms		3.2. IKEv2 Transform Type 3 Algorithms
	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 in the ENCR payload. References to the specifications		and used in the ENCR payload. References to the specifications
	defining these algorithms are in the IANA registry. When an AEAD		defining these algorithms are in the IANA registry. When an AEAD
	algorithm (see Section 3.1) is used, no algorithm from this table		algorithm (see Section 3.1) is used, no algorithm from this table
	needs to be used.		needs to be used.
	+------------------------+---------+		+------------------------+---------+
	| Name | Status |		| Name | Status |
	+------------------------+---------+		+------------------------+---------+
	| AUTH_HMAC_SHA2_256_128 | MUST |		| AUTH_HMAC_SHA2_256_128 | MUST |
	| AUTH_HMAC_SHA2_384_192 | SHOULD+ |		| AUTH_HMAC_SHA2_512_256 | SHOULD+ |
	| AUTH_HMAC_SHA1_96 | MUST- |		| AUTH_HMAC_SHA1_96 | MUST- |
	| AUTH_AES_128_GMAC | MAY |
	| AUTH_AES_XCBC_96 | MAY |		| AUTH_AES_XCBC_96 | MAY |
	| AUTH_HMAC_MD5_96 | MAY |
	+------------------------+---------+		+------------------------+---------+
			Explanation about SHA-256 is TBD.
			Explanation about SHA-512 is TBD.
			Explanation about SHA-1 is TBD.
			Explanation about AES-XCBC is TBD.
	3.3. IKEv2 Transform Type 2 Algorithms		3.3. IKEv2 Transform Type 2 Algorithms
	Transform Type 2 Algorithms are pseudo-random functions used to		Transform Type 2 Algorithms are pseudo-random functions used to
	generate random values when needed.		generate random values when needed.
	+-------------------+---------+		+-------------------+---------+
	| Name | Status |		| Name | Status |
	+-------------------+---------+		+-------------------+---------+
	| PRF_HMAC_SHA2_256 | MUST |		| PRF_HMAC_SHA2_256 | MUST |
	| PRF_HMAC_SHA2_384 | SHOULD+ |		| PRF_HMAC_SHA2_512 | SHOULD+ |
	| PRF_HMAC_SHA1 | MUST- |		| PRF_HMAC_SHA1 | MUST- |
	| PRF_AES128_CBC | MAY |		| PRF_AES128_CBC | MAY |
	| PRF_HMAC_MD5 | MAY |
	+-------------------+---------+		+-------------------+---------+
			Explanation about SHA-256 is TBD.
			Explanation about SHA-512 is TBD.
			Explanation about SHA-1 is TBD.
			Explanation about AES-XCBC is TBD.
	3.4. Diffie-Hellman Groups		3.4. Diffie-Hellman Groups
	There are several Modular Exponential (MODP) groups and several		There are several Modular Exponential (MODP) groups and several
	Elliptic Curve groups (ECC) that are defined for use in IKEv2. They		Elliptic Curve groups (ECC) that are defined for use in IKEv2. They
	are defined in both the [IKEv2] base document and in extensions		are defined in both the [IKEv2] base document and in extensions
	documents. They are identified by group number.		documents. They are identified by group number.
	+--------+--------------------------+------------+		+--------+--------------------------+------------+
	| Number | Description | Status |		| Number | Description | Status |
	+--------+--------------------------+------------+		+--------+--------------------------+------------+
	| 14 | 2048-bit MODP Group | MUST |		| 14 | 2048-bit MODP Group | MUST |
	| 19 | 256-bit random ECP group | SHOULD |		| 19 | 256-bit random ECP group | SHOULD |
	| 20 | 384-bit random ECP group | MAY |
	| 2 | 1024-bit MODP Group | SHOULD NOT |		| 2 | 1024-bit MODP Group | SHOULD NOT |
			| 1 | 768-bit MODP Group | MUST NOT |
	+--------+--------------------------+------------+		+--------+--------------------------+------------+
			Explanation about Group 14 is TBD.
			Explanation about Group 19 is TBD.
			Explanation about Group 2 is TBD.
			Explanation about Group 1 is TBD.
	4. Security Considerations		4. Security Considerations
	The security of cryptographic-based systems depends on both the		The security of cryptographic-based systems 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 of the protocol used by the system to ensure that		the engineering of the protocol used by the system to ensure that
	there are no non-cryptographic ways to bypass the security of the		there are no non-cryptographic ways to bypass the security of the
	overall system.		overall system.
	This document concerns itself with the selection of cryptographic		This document concerns itself with the selection of cryptographic
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 39 ¶
	this area.		this area.
	5. IANA Considerations		5. IANA Considerations
	This document makes no requests of IANA.		This document makes no requests of IANA.
	6. Acknowledgements		6. Acknowledgements
	The first version of this document was RFC 4307 by Jeffrey I.		The first version of this document was RFC 4307 by Jeffrey I.
	Schiller of the Massachusetts Institute of Technology (MIT). Much of		Schiller of the Massachusetts Institute of Technology (MIT). Much of
	the text has been copied verbatim.		the original text has been copied verbatim.
	7. References		7. References
	7.1. Normative References		7.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, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[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, October 2014.		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
			2014, <http://www.rfc-editor.org/info/rfc7296>.
	[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption		[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
	Algorithms with the Encrypted Payload of the Internet Key		Algorithms with the Encrypted Payload of the Internet Key
	Exchange version 2 (IKEv2) Protocol", RFC 5282, DOI		Exchange version 2 (IKEv2) Protocol", RFC 5282,
	10.17487/RFC5282, August 2008,		DOI 10.17487/RFC5282, August 2008,
	<http://www.rfc-editor.org/info/rfc5282>.		<http://www.rfc-editor.org/info/rfc5282>.
	7.2. Informative References		7.2. Informative References
	[IKEV2-IANA]		[IKEV2-IANA]
	"Internet Key Exchange Version 2 (IKEv2) Parameters",		"Internet Key Exchange Version 2 (IKEv2) Parameters",
	<http://www.iana.org/assignments/ikev2-parameters>.		<http://www.iana.org/assignments/ikev2-parameters>.
	Authors' Addresses		Authors' Addresses
End of changes. 22 change blocks.
	20 lines changed or deleted		57 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/