< draft-ietf-ipsecme-rfc4307bis-05.txt		draft-ietf-ipsecme-rfc4307bis-06.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		Obsoletes: 4307 (if approved) T. Kivinen
	Expires: October 7, 2016 INSIDE Secure		Updates: 7296 (if approved) INSIDE Secure
	P. Wouters		Intended status: Standards Track P. Wouters
	Red Hat		Expires: October 8, 2016 Red Hat
	D. Migault		D. Migault
	Ericsson		Ericsson
	April 5, 2016		April 6, 2016
	Algorithm Implementation Requirements and Usage Guidance for IKEv2		Algorithm Implementation Requirements and Usage Guidance for IKEv2
	draft-ietf-ipsecme-rfc4307bis-05		draft-ietf-ipsecme-rfc4307bis-06
	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 45 ¶		skipping to change at page 1, line 45 ¶
	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 October 7, 2016.		This Internet-Draft will expire on October 8, 2016.
	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 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	1. Introduction		1. Introduction
	The Internet Key Exchange (IKE) protocol [RFC7296] is used to		The Internet Key Exchange (IKE) protocol [RFC7296] is used to
	negotiate the parameters of the IPsec SA, such as the encryption and		negotiate the parameters of the IPsec SA, such as the encryption and
	authentication algorithms and the keys for the protected		authentication algorithms and the keys for the protected
	communications between the two endpoints. The IKE protocol itself is		communications between the two endpoints. The IKE protocol itself is
	also protected by cryptographic algorithms which are negotiated		also protected by cryptographic algorithms which are negotiated
	between the two endpoints using IKE. Different implementations of		between the two endpoints using IKE. Different implementations of
	IKE may negotiate different algorithms based on their individual		IKE may negotiate different algorithms based on their individual
	local policy. To ensure interoperability, a set of "mandatory-to-		local policy. To ensure interoperability, a set of "mandatory-to-
	implement" IKE cryptograhic algorithms is defined.		implement" IKE cryptographic algorithms is defined.
	This document describes the parameters of the IKE protocol. It does		This document describes the parameters of the IKE protocol and
			updates the IKEv2 specification because it changes the mandatory to
			implement authentication algorithms of the section 4 of the RFC7296
			by saying RSA key lengths of less than 2048 are SHOULD NOT. It does
	not describe the cryptographic parameters of the AH or ESP protocols.		not describe the cryptographic parameters of the AH or ESP protocols.
	1.1. Updating Algorithm Implementation Requirements and Usage Guidance		1.1. Updating Algorithm Implementation Requirements and Usage Guidance
	The field of cryptography evolves continuously. New stronger		The field of cryptography evolves continuously. New stronger
	algorithms appear and existing algorithms are found to be less secure		algorithms appear and existing algorithms are found to be less secure
	then originally thought. Therefore, algorithm implementation		then originally thought. Therefore, algorithm implementation
	requirements and usage guidance need to be updated from time to time		requirements and usage guidance need to be updated from time to time
	to reflect the new reality. The choices for algorithms must be		to reflect the new reality. The choices for algorithms must be
	conservative to minimize the risk of algorithm compromise.		conservative to minimize the risk of algorithm compromise.
	skipping to change at page 6, line 49 ¶		skipping to change at page 6, line 49 ¶
	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 pseudorandom values when needed.		generate pseudo-random values when needed.
	If an algorithm is selected as the integrity algorithm, it SHOULD		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		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.		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+ | |
	skipping to change at page 10, line 32 ¶		skipping to change at page 10, line 32 ¶
	mandatory to implement is provided by the PKIX Community. This		mandatory to implement is provided by the PKIX Community. This
	document is mostly concerned on signature verification and generation		document is mostly concerned on signature verification and generation
	for the authentication.		for the authentication.
	4.1. IKEv2 Authentication Method		4.1. IKEv2 Authentication Method
	+--------+---------------------------------------+------------+		+--------+---------------------------------------+------------+
	| Number | Description | Status |		| Number | Description | Status |
	+--------+---------------------------------------+------------+		+--------+---------------------------------------+------------+
	| 1 | RSA Digital Signature | MUST |		| 1 | RSA Digital Signature | MUST |
			| 2 | Shared Key Message Integrity Code | MUST |
	| 3 | DSS Digital Signature | SHOULD NOT |		| 3 | DSS Digital Signature | SHOULD NOT |
	| 9 | ECDSA with SHA-256 on the P-256 curve | SHOULD |		| 9 | ECDSA with SHA-256 on the P-256 curve | SHOULD |
	| 10 | ECDSA with SHA-384 on the P-384 curve | SHOULD |		| 10 | ECDSA with SHA-384 on the P-384 curve | SHOULD |
	| 11 | ECDSA with SHA-512 on the P-521 curve | SHOULD |		| 11 | ECDSA with SHA-512 on the P-521 curve | SHOULD |
	| 14 | Digital Signature | SHOULD |		| 14 | Digital Signature | SHOULD |
	+--------+---------------------------------------+------------+		+--------+---------------------------------------+------------+
	RSA Digital Signature is widely deployed and therefore kept for		RSA Digital Signature is widely deployed and therefore kept for
	interoperability. It is expected to be downgraded in the future as		interoperability. It is expected to be downgraded in the future as
	its signatures are based on the older RSASSA-PKCS1-v1.5 which is no		its signatures are based on the older RSASSA-PKCS1-v1.5 which is no
	longer recommended. RSA authentication, as well as other specific		longer recommended. RSA authentication, as well as other specific
	Authentication Methods, are expected to be replaced with the generic		Authentication Methods, are expected to be replaced with the generic
	Digital Signature method of [RFC7427]. RSA Digital Signature is not		Digital Signature method of [RFC7427]. RSA Digital Signature is not
	recommended for keys smaller then 2048, but since these signatures		recommended for keys smaller then 2048, but since these signatures
	only have value in real-time, and need no future protection, smaller		only have value in real-time, and need no future protection, smaller
	keys was kept at SHOULD NOT instead of MUST NOT.		keys was kept at SHOULD NOT instead of MUST NOT.
			Shared Key Message Integrity Code is widely deployed and mandatory to
			implement in the IKEv2 in the RFC7296.
	ECDSA based Authentication Methods are also expected to be downgraded		ECDSA based Authentication Methods are also expected to be downgraded
	as it does not provide hash function agility. Instead, ECDSA (like		as it does not provide hash function agility. Instead, ECDSA (like
	RSA) is expected to be performed using the generic Digital Signature		RSA) is expected to be performed using the generic Digital Signature
	method.		method.
	DSS Digital Signature is bound to SHA-1 and has the same level of		DSS Digital Signature is bound to SHA-1 and has the same level of
	security as 1024-bit RSA. It is expected to be downgraded to MUST		security as 1024-bit RSA. It is expected to be downgraded to MUST
	NOT in the future.		NOT in the future.
	Digital Signature [RFC7427] is expected to be promoted as it provides		Digital Signature [RFC7427] is expected to be promoted as it provides
	hash function, signature format and algorithm agility.		hash function, signature format and algorithm agility.
	4.1.1. Recommendations for RSA key length		4.1.1. Recommendations for RSA key length
	+-------------------------------------------+------------+		+-------------------------------------------+------------+
	| Description | Status |		| Description | Status |
	+-------------------------------------------+------------+		+-------------------------------------------+------------+
	| RSA with key length 2048 | MUST |		| RSA with key length 2048 | MUST |
	| RSA with key length 3072 and 4096 | SHOULD |		| RSA with key length 3072 and 4096 | SHOULD |
	| RSA with key length between 2049 and 4095 | MAY |		| RSA with key length between 2049 and 4095 | MAY |
	| RSA with key length smaler than 2048 | SHOULD NOT |		| RSA with key length smaller than 2048 | SHOULD NOT |
	+-------------------------------------------+------------+		+-------------------------------------------+------------+
			The IKEv2 RFC7296 mandates support for the RSA keys of size 1024 or
			2048 bits, but here we make key sizes less than 2048 SHOULD NOT as
			there is industry-wide trend to deprecate key lengths less than 2048
			bits.
	4.2. Digital Signature Recommendations		4.2. Digital Signature Recommendations
	Recommendations for when a hash function is involved in a signature:		Recommendations for when a hash function is involved in a signature:
	+--------+-------------+------------+---------+		+--------+-------------+------------+---------+
	| Number | Description | Status | Comment |		| Number | Description | Status | Comment |
	+--------+-------------+------------+---------+		+--------+-------------+------------+---------+
	| 1 | SHA1 | SHOULD NOT | |		| 1 | SHA1 | SHOULD NOT | |
	| 2 | SHA2-256 | MUST | |		| 2 | SHA2-256 | MUST | |
	| 3 | SHA2-384 | MAY | |		| 3 | SHA2-384 | MAY | |
	skipping to change at page 12, line 26 ¶		skipping to change at page 12, line 26 ¶
	| sha384WithRSAEncryption | MAY | |		| sha384WithRSAEncryption | MAY | |
	| sha512WithRSAEncryption | MAY | |		| sha512WithRSAEncryption | MAY | |
	| sha512WithRSAEncryption | MAY | |		| sha512WithRSAEncryption | MAY | |
	| dsa-with-sha256 | MAY | |		| dsa-with-sha256 | MAY | |
	| ecdsa-with-sha384 | MAY | |		| ecdsa-with-sha384 | MAY | |
	| ecdsa-with-sha512 | MAY | ?SHOULD |		| ecdsa-with-sha512 | MAY | ?SHOULD |
	+------------------------------------+------------+---------+		+------------------------------------+------------+---------+
	5. Algorithms for Internet of Things		5. Algorithms for Internet of Things
	Some algorithms in this document are marked for the Internet of		Some algorithms in this document are marked for use with the Internet
	Things (IoT). There are several reasons why the IoT devices want		of Things (IoT). There are several reasons why IoT devices prefer a
	have different set of algorithms than other users of IKEv2. Those		different set of algorithms from regular IKEv2 clients. IoT devices
	devices are usually very constrained, meaning the memory size and cpu		are usually very constrained, meaning the memory size and CPU power
	power is so limited, that they want to implement just minimal set of		is so limited, that these clients only have resources to implement
	algorithms. This means they quite often only implement one algorithm		and run one set of algorithms. For example, instead of implementing
	and pick it so that the same algorithm is already implemented in		AES and SHA, these devices typically use AES_XCBC as integrity
	software or hardware for other users.		algorithm so SHA does not need to be implemented.
	For example IEEE Std 802.15.4 [IEEE-802-15-4] devices has mandatory		For example, IEEE Std 802.15.4 [IEEE-802-15-4] devices have a
	to implement link level security using AES-CCM with 128 bit keys.		mandatory to implement link level security using AES-CCM with 128 bit
	The IEEE Recommended Practice for Transport of Key Management		keys. The IEEE Recommended Practice for Transport of Key Management
	Protocol (KMP) Datagrams [IEEE-802-15-9] already provides a way to		Protocol (KMP) Datagrams [IEEE-802-15-9] already provide a way to use
	use Minimal IKEv2 [RFC7815] over 802.15.4 to provide link keys for		Minimal IKEv2 [RFC7815] over 802.15.4 to provide link keys for the
	the 802.15.4.		802.15.4 layer.
	Those devices might want to use AES-CCM as their IKEv2 algorithm, so		These devices might want to use AES-CCM as their IKEv2 algorithm, so
	they can reuse the hardware implementing it. They cannot use the		they can reuse the hardware implementing it. They cannot use the
	AES-CBC, as the hardware quite often do not include support for AES		AES-CBC algorithm, as the hardware quite often do not include support
	decryption needed for it. So even when AES-CCM algorithm support		for AES decryption needed to support the CBC mode. So despite the
	requires support for the AEAD [RFC5282] support for IKEv2, the		AES-CCM algorithm requiring AEAD [RFC5282] support, the benefit of
	benefit of reusing crypto hardware makes it worthwhile.		reusing the crypto hardware makes AES-CCM the preferred algorithm.
	Other important aspects of the IoT devices, that their transfer rates		Another important aspect of IoT devices is that their transfer rates
	are usually quite low (in order of tens of kbits/s), and each bit		are usually quite low (in order of tens of kbits/s), and each bit
	they transmit costs a lot in energy consumption (shortening the		they transmit has an energy consumption cost associated with it and
	battery life). Because of this they usually want to use options		shortens their battery life. Therefore, shorter packets are
	which support shorter packets. I.e., using 8 octet ICV instead of		preferred. This is the reason for recommending the 8 octet ICV over
	16.		the 16 octet ICV.
	Also as each of those IoT devices have different constraints, we		Because different IoT devices will have different constraints, this
	cannot specify one exact profile for them. This document points out		document cannot specify the one mandatory profile for IoT. Instead,
	some algorithms commonly used in the IoT devices, but there might be		this document points out commonly used algorithms with IoT devices.
	devices using different set of algorithms, because of requirements
	for the environment.
	6. Security Considerations		6. 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.
End of changes. 18 change blocks.
	40 lines changed or deleted		50 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/