< draft-ietf-ipsecme-rfc4307bis-13.txt		draft-ietf-ipsecme-rfc4307bis-14.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: March 16, 2017 Red Hat		Expires: March 26, 2017 Red Hat
	D. Migault		D. Migault
	Ericsson		Ericsson
	September 12, 2016		September 22, 2016
	Algorithm Implementation Requirements and Usage Guidance for IKEv2		Algorithm Implementation Requirements and Usage Guidance for IKEv2
	draft-ietf-ipsecme-rfc4307bis-13		draft-ietf-ipsecme-rfc4307bis-14
	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 47 ¶		skipping to change at page 1, line 47 ¶
	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 16, 2017.		This Internet-Draft will expire on March 26, 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 18 ¶		skipping to change at page 6, line 18 ¶
	| 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 | (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 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 SHOULD level.
	192-bit and 256-bit keys are at the MAY level.		192-bit and 256-bit remain 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+ for 128-bit keys and MAY for
	only shared mandatory-to-implement algorithm with RFC4307 and as a		256-bit keys in [RFC4307] to MUST. 192-bit keys remain at the MAY
	result it is necessary for interoperability with IKEv2 implementation		level. ENCR_AES_CBC is the only shared mandatory-to-implement
	compatible with RFC4307.		algorithm with RFC4307 and as a result it is necessary for
			interoperability with IKEv2 implementation 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 as an alternative to
	alternative to AES-CBC and AES-GCM. It is also being standardized		AES-CBC and AES-GCM. It is also being standardized for IPsec for the
	for IPsec for the same reasons. At the time of writing, there were		same reasons. At the time of writing, there were not enough IKEv2
	not enough IKEv2 implementations supporting ENCR_CHACHA20_POLY1305 to		implementations supporting ENCR_CHACHA20_POLY1305 to be able to
	be able to introduce it at the SHOULD+ level.		introduce it at the SHOULD+ level.
	ENCR_AES_GCM_16 was not considered in RFC4307. At the time RFC4307		ENCR_AES_GCM_16 was not considered in RFC4307. At the time RFC4307
	was written, AES-GCM was not defined in an IETF document. AES-GCM		was written, AES-GCM was not defined in an IETF document. AES-GCM
	was defined for ESP in [RFC4106] and later for IKEv2 in [RFC5282].		was defined for ESP in [RFC4106] and later for IKEv2 in [RFC5282].
	The main motivation for adopting AES-GCM for ESP is encryption		The main motivation for adopting AES-GCM for ESP is encryption
	performance and key longevity compared to AES-CBC. This resulted in		performance and key longevity compared to AES-CBC. This resulted in
	AES-GCM being widely implemented for ESP. As the computation load of		AES-GCM being widely implemented for ESP. As the computation load of
	IKEv2 is relatively small compared to ESP, many IKEv2 implementations		IKEv2 is relatively small compared to ESP, many IKEv2 implementations
	have not implemented AES-GCM. For this reason, AES-GCM is not		have not implemented AES-GCM. For this reason, AES-GCM is not
	promoted to a greater status than SHOULD. The reason for promotion		promoted to a greater status than SHOULD. The reason for promotion
	skipping to change at page 6, line 52 ¶		skipping to change at page 7, line 4 ¶
	from MAY to SHOULD is to promote the slightly more secure AEAD method		from MAY to SHOULD is to promote the slightly more secure AEAD method
	over the traditional encrypt+auth method. Its status is expected to		over the traditional encrypt+auth method. Its status is expected to
	be raised once widely implemented. As the advantage of the shorter		be raised once widely implemented. As the advantage of the shorter
	(and weaker) ICVs is minimal, the 8 and 12 octet ICV's remain at the		(and weaker) ICVs is minimal, the 8 and 12 octet ICV's remain at the
	MAY level.		MAY level.
	ENCR_AES_CCM_8 was not considered in RFC4307. This document		ENCR_AES_CCM_8 was not considered in RFC4307. This document
	considers it as SHOULD be implemented in order to be able to interact		considers it as SHOULD be implemented in order to be able to interact
	with Internet of Things devices. As this case is not a general use		with Internet of Things devices. As this case is not a general use
	case for non-IoT VPNs, its status is expected to remain as SHOULD.		case for non-IoT VPNs, its status is expected to remain as SHOULD.
	The 8 octet size of the ICV is expected to be sufficient for most use		The 8 octet size of the ICV is expected to be sufficient for most use
	cases of IKEv2, as far less packets are exchanged on those cases, and		cases of IKEv2, as far less packets are exchanged on those cases, and
	IoT devices want to make packets as small as possible. When		IoT devices want to make packets as small as possible. The SHOULD
	implemented, ENCR_AES_CCM_8 MUST be implemented for key length 128		level is for 128-bit keys, 256-bit keys remains at MAY level.
	and MAY be implemented for key length 256.
	ENCR_3DES has been downgraded from RFC4307 MUST- to SHOULD NOT. All		ENCR_3DES has been downgraded from RFC4307 MUST- to SHOULD NOT. All
	IKEv2 implementation already implement ENCR_AES_CBC, so there is no		IKEv2 implementation already implement ENCR_AES_CBC, so there is no
	need to keep support for the much slower ENCR_3DES. In addition,		need to keep support for the much slower ENCR_3DES. In addition,
	ENCR_CHACHA20_POLY1305 provides a more modern alternative to AES.		ENCR_CHACHA20_POLY1305 provides a more modern alternative to AES.
	ENCR_DES can be brute-forced using of-the-shelves hardware. It		ENCR_DES can be brute-forced using of-the-shelves hardware. It
	provides no meaningful security whatsoever and therefor MUST NOT be		provides no meaningful security whatsoever and therefor MUST NOT be
	implemented.		implemented.
	3.2. Type 2 - IKEv2 Pseudo-random Function Transforms		3.2. Type 2 - IKEv2 Pseudo-random Function Transforms
	Transform Type 2 algorithms are pseudo-random functions used to		Transform Type 2 algorithms are pseudo-random functions used to
	generate pseudo-random values when needed.		generate pseudo-random values when needed.
	If an algorithm is selected as the integrity algorithm, it SHOULD
	also be used as the PRF. When using an AEAD cipher, a choice of PRF
	needs to be made. The table below lists the recommended algorithms.
	+-------------------+----------+---------+		+-------------------+----------+---------+
	| Name | Status | Comment |		| Name | Status | Comment |
	+-------------------+----------+---------+		+-------------------+----------+---------+
	| PRF_HMAC_SHA2_256 | MUST | |		| PRF_HMAC_SHA2_256 | MUST | |
	| PRF_HMAC_SHA2_512 | SHOULD+ | |		| PRF_HMAC_SHA2_512 | SHOULD+ | |
	| PRF_HMAC_SHA1 | MUST- | |		| PRF_HMAC_SHA1 | MUST- | |
	| PRF_AES128_XCBC | SHOULD | (IoT) |		| PRF_AES128_XCBC | SHOULD | (IoT) |
	| PRF_HMAC_MD5 | MUST NOT | |		| PRF_HMAC_MD5 | MUST NOT | |
	+-------------------+----------+---------+		+-------------------+----------+---------+
	(IoT) - This requirement is for interoperability with IoT		(IoT) - This requirement is for interoperability with IoT
	PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based		As no SHA2 based transforms were referenced in RFC4307,
	transforms were mentioned. PRF_HMAC_SHA2_256 MUST be implemented in		PRF_HMAC_SHA2_256 was not mentioned in RFC4307. PRF_HMAC_SHA2_256
	order to replace SHA1 and PRF_HMAC_SHA1.		MUST be implemented in order to replace SHA1 and PRF_HMAC_SHA1.
	PRF_HMAC_SHA2_512 SHOULD be implemented as a future replacement for		PRF_HMAC_SHA2_512 SHOULD be implemented as a future replacement for
	PRF_HMAC_SHA2_256 or when stronger security is required.		PRF_HMAC_SHA2_256 or when stronger security is required.
	PRF_HMAC_SHA2_512 is preferred over PRF_HMAC_SHA2_384, as the		PRF_HMAC_SHA2_512 is preferred over PRF_HMAC_SHA2_384, as the
	additional overhead of PRF_HMAC_SHA2_512 is negligible.		additional overhead of PRF_HMAC_SHA2_512 is negligible.
	PRF_HMAC_SHA1 has been downgraded from MUST in RFC4307 to MUST- as		PRF_HMAC_SHA1 has been downgraded from MUST in RFC4307 to MUST- as
	their is an industry-wide trend to deprecate its usage.		cryptographic attacks against SHA1 are increasing, resulting in an
			industry-wide trend to deprecate its usage
	PRF_AES128_XCBC is only recommended in the scope of IoT, as Internet		PRF_AES128_XCBC is only recommended in the scope of IoT, as Internet
	of Things deployments tend to prefer AES based pseudo-random		of Things deployments tend to prefer AES based pseudo-random
	functions in order to avoid implementing SHA2. For the non-IoT VPN		functions in order to avoid implementing SHA2. For the non-IoT VPN
	deployment it has been downgraded from SHOULD in RFC4307 to MAY as it		deployment it has been downgraded from SHOULD in RFC4307 to MAY as it
	has not seen wide adoption.		has not seen wide adoption.
	PRF_HMAC_MD5 has been downgraded from MAY in RFC4307 to MUST NOT.		PRF_HMAC_MD5 has been downgraded from MAY in RFC4307 to MUST NOT.
	There is an industry-wide trend to deprecate its usage as MD5 support		Cryptographic attacks against MD5, such as collision attacks
	is being removed from cryptographic libraries in general because its		mentioned in [TRANSCRIPTION], are resulting in an industry-wide trend
	non-HMAC use is known to be subject to collision attacks, for example		to deprecate and remove MD5 (and thus HMAC-MD5) from cryptographic
	as mentioned in [TRANSCRIPTION].		libraries.
	3.3. Type 3 - IKEv2 Integrity Algorithm Transforms		3.3. Type 3 - IKEv2 Integrity 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 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 proposed, this algorithm transform		algorithm (see Section 3.1) is proposed, this algorithm transform
	type is not in use.		type is not in use.
	+------------------------+----------+---------+		+------------------------+----------+---------+
	skipping to change at page 8, line 49 ¶		skipping to change at page 8, line 45 ¶
	AUTH_HMAC_SHA2_256_128 was not mentioned in RFC4307, as no SHA2 based		AUTH_HMAC_SHA2_256_128 was not mentioned in RFC4307, as no SHA2 based
	transforms were mentioned. AUTH_HMAC_SHA2_256_128 MUST be		transforms were mentioned. AUTH_HMAC_SHA2_256_128 MUST be
	implemented in order to replace AUTH_HMAC_SHA1_96.		implemented in order to replace AUTH_HMAC_SHA1_96.
	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 over AUTH_HMAC_SHA2_384, as the		This value has been preferred over AUTH_HMAC_SHA2_384, as the
	additional overhead of AUTH_HMAC_SHA2_512 is negligible.		additional overhead of AUTH_HMAC_SHA2_512 is negligible.
	AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307 to MUST-		AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307 to MUST-
	as there is an industry-wide trend to deprecate its usage.		as cryptographic attacks against SHA1 are increasing, resulting in an
			industry-wide trend to deprecate its usage
	AUTH_AES-XCBC is only recommended in the scope of IoT, as Internet of		AUTH_AES_XCBC_96 is only recommended in the scope of IoT, as Internet
	Things deployments tend to prefer AES based pseudo-random functions		of Things deployments tend to prefer AES based pseudo-random
	in order to avoid implementing SHA2. For the non-IoT VPN deployment,		functions in order to avoid implementing SHA2. For the non-IoT VPN
	it has been downgraded from SHOULD in RFC4307 to MAY as it has not		deployment, it has been downgraded from SHOULD in RFC4307 to MAY as
	been widely adopted.		it has not been widely adopted.
	AUTH_DES_MAC, AUTH_HMAC_MD5_96, and AUTH_KPDK_MD5 were not mentioned		AUTH_DES_MAC, AUTH_HMAC_MD5_96, and AUTH_KPDK_MD5 were not mentioned
	in RFC4307 so their default status ware MAY. They have been		in RFC4307 so their default status ware MAY. They have been
	downgraded to MUST NOT. There is an industry-wide trend to deprecate		downgraded to MUST NOT. There is an industry-wide trend to deprecate
	DES and MD5. MD5 support is being removed from cryptographic		DES and MD5. MD5 support is being removed from cryptographic
	libraries in general because its non-HMAC use is known to be subject		libraries in general because its non-HMAC use is known to be subject
	to collision attacks, for example as mentioned in [TRANSCRIPTION].		to collision attacks, for example as mentioned in [TRANSCRIPTION].
	3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms		3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms
	skipping to change at page 10, line 6 ¶		skipping to change at page 10, line 6 ¶
	| | Order Subgroup | |		| | Order Subgroup | |
	| 24 | 2048-bit MODP Group with 256-bit Prime | SHOULD NOT |		| 24 | 2048-bit MODP Group with 256-bit Prime | SHOULD NOT |
	| | Order Subgroup | |		| | Order Subgroup | |
	+--------+---------------------------------------------+------------+		+--------+---------------------------------------------+------------+
	Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 as		Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 as
	a replacement for 1024-bit MODP Group. Group 14 is widely		a replacement for 1024-bit MODP Group. Group 14 is widely
	implemented and considered secure.		implemented and considered secure.
	Group 19 or 256-bit random ECP group was not specified in RFC4307, as		Group 19 or 256-bit random ECP group was not specified in RFC4307, as
	this group were not specified at that time. Group 19 is widely		this group were not defined at that time. Group 19 is widely
	implemented and considered secure.		implemented and considered secure.
	Group 5 or 1536-bit MODP Group has been downgraded from MAY in		Group 5 or 1536-bit MODP Group has been downgraded from MAY in
	RFC4307 to SHOULD NOT. It was specified earlier, but is now		RFC4307 to SHOULD NOT. It was specified earlier, but is now
	considered to be vulnerable to be broken within the next few years by		considered to be vulnerable to be broken within the next few years by
	a nation state level attack, so its security margin is considered too		a nation state level attack, so its security margin is considered too
	narrow.		narrow.
	Group 2 or 1024-bit MODP Group has been downgraded from MUST- in		Group 2 or 1024-bit MODP Group has been downgraded from MUST- in
	RFC4307 to SHOULD NOT. It is known to be weak against sufficiently		RFC4307 to SHOULD NOT. It is known to be weak against sufficiently
	skipping to change at page 13, line 30 ¶		skipping to change at page 13, line 30 ¶
	only if Digital Signature authentication method is implemented.		only if Digital Signature authentication method is implemented.
	+------------------------------------+----------+---------+		+------------------------------------+----------+---------+
	| Description | Status | Comment |		| Description | Status | Comment |
	+------------------------------------+----------+---------+		+------------------------------------+----------+---------+
	| RSASSA-PSS with SHA-256 | MUST | |		| RSASSA-PSS with SHA-256 | MUST | |
	| ecdsa-with-sha256 | SHOULD | |		| ecdsa-with-sha256 | SHOULD | |
	| sha1WithRSAEncryption | MUST NOT | |		| sha1WithRSAEncryption | MUST NOT | |
	| dsa-with-sha1 | MUST NOT | |		| dsa-with-sha1 | MUST NOT | |
	| ecdsa-with-sha1 | MUST NOT | |		| ecdsa-with-sha1 | MUST NOT | |
	| RSASSA-PSS with Empty Parameters | MUST NOT | |		| RSASSA-PSS with Empty Parameters | MUST NOT | (*) |
	| RSASSA-PSS with Default Parameters | MUST NOT | |		| RSASSA-PSS with Default Parameters | MUST NOT | (*) |
	+------------------------------------+----------+---------+		+------------------------------------+----------+---------+
			(*) Empty or Default parameters means it is using SHA1, which is at
			level MUST NOT.
	5. Algorithms for Internet of Things		5. Algorithms for Internet of Things
	Some algorithms in this document are marked for use with the Internet		Some algorithms in this document are marked for use with the Internet
	of Things (IoT). There are several reasons why IoT devices prefer a		of Things (IoT). There are several reasons why IoT devices prefer a
	different set of algorithms from regular IKEv2 clients. IoT devices		different set of algorithms from regular IKEv2 clients. IoT devices
	are usually very constrained, meaning the memory size and CPU power		are usually very constrained, meaning the memory size and CPU power
	is so limited, that these clients only have resources to implement		is so limited, that these clients only have resources to implement
	and run one set of algorithms. For example, instead of implementing		and run one set of algorithms. For example, instead of implementing
	AES and SHA, these devices typically use AES_XCBC as integrity		AES and SHA, these devices typically use AES_XCBC as integrity
	algorithm so SHA does not need to be implemented.		algorithm so SHA does not need to be implemented.
End of changes. 18 change blocks.
	39 lines changed or deleted		41 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/