< draft-ietf-ipsecme-rfc4307bis-08.txt		draft-ietf-ipsecme-rfc4307bis-09.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: November 12, 2016 Red Hat		Expires: November 14, 2016 Red Hat
	D. Migault		D. Migault
	Ericsson		Ericsson
	May 11, 2016		May 13, 2016
	Algorithm Implementation Requirements and Usage Guidance for IKEv2		Algorithm Implementation Requirements and Usage Guidance for IKEv2
	draft-ietf-ipsecme-rfc4307bis-08		draft-ietf-ipsecme-rfc4307bis-09
	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 November 12, 2016.		This Internet-Draft will expire on November 14, 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 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. Conventions Used in This Document . . . . . . . . . . . . . . 4		2. Conventions Used in This Document . . . . . . . . . . . . . . 5
	3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 5		3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Type 1 - IKEv2 Encryption Algorithm Transforms . . . . . 5		3.1. Type 1 - IKEv2 Encryption Algorithm Transforms . . . . . 5
	3.2. Type 2 - IKEv2 Pseudo-random Function Transforms . . . . 6		3.2. Type 2 - IKEv2 Pseudo-random Function Transforms . . . . 7
	3.3. Type 3 - IKEv2 Integrity Algorithm Transforms . . . . . . 7		3.3. Type 3 - IKEv2 Integrity Algorithm Transforms . . . . . . 8
	3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms . . . . . 8		3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms . . . . . 9
	4. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 10		4. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 10
	4.1. IKEv2 Authentication Method . . . . . . . . . . . . . . . 10		4.1. IKEv2 Authentication Method . . . . . . . . . . . . . . . 10
	4.1.1. Recommendations for RSA key length . . . . . . . . . 11		4.1.1. Recommendations for RSA key length . . . . . . . . . 11
	4.2. Digital Signature Recommendations . . . . . . . . . . . . 11		4.2. Digital Signature Recommendations . . . . . . . . . . . . 12
	5. Algorithms for Internet of Things . . . . . . . . . . . . . . 12		5. Algorithms for Internet of Things . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	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
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 37 ¶
	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 IKEv2 implementers		The recommendations of this document mostly target IKEv2 implementers
	as implementations need to meet both high security expectations as		as implementations need to meet both high security expectations as
	well as high interoperability between various vendors and with		well as high interoperability between various vendors and with
	different versions. Interoperability requires a smooth move to more		different versions. Interoperability requires a smooth move to more
	secure cipher suites. This may differ from a user point of view that		secure cipher suites. This may differ from a user point of view that
	may deploy and configure IKEv2 with only the safest cipher suite. On		may deploy and configure IKEv2 with only the safest cipher suite.
	the other hand, comments from this document are also expected to be
	useful for such users.		This document does not give any recommendations for the use of
			algorithms, it only gives implementation recommendations for
			implementations. The use of algorithms by users is dictated by the
			security policy requirements for that specific user, and are outside
			the scope of this document.
	IKEv1 is out of scope of this document. IKEv1 is deprecated and the		IKEv1 is out of scope of this document. IKEv1 is deprecated and the
	recommendations of this document must not be considered for IKEv1, as		recommendations of this document must not be considered for IKEv1, as
	most IKEv1 implementations have been "frozen" and will not be able to		most IKEv1 implementations have been "frozen" and will not be able to
	update the list of mandatory-to-implement algorithms.		update the list of mandatory-to-implement algorithms.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	skipping to change at page 11, line 38 ¶		skipping to change at page 12, line 15 ¶
	The IKEv2 RFC7296 mandates support for the RSA keys of size 1024 or		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		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		there is industry-wide trend to deprecate key lengths less than 2048
	bits.		bits.
	4.2. Digital Signature Recommendations		4.2. Digital Signature Recommendations
	When Digital Signature authentication method is implemented, then the		When Digital Signature authentication method is implemented, then the
	following recommendations are applied for hash functions:		following recommendations are applied for hash functions:
	+--------+-------------+------------+---------+		+--------+-------------+----------+---------+
	| Number | Description | Status | Comment |		| Number | Description | Status | Comment |
	+--------+-------------+------------+---------+		+--------+-------------+----------+---------+
	| 1 | SHA1 | SHOULD NOT | |		| 1 | SHA1 | MUST NOT | |
	| 2 | SHA2-256 | MUST | |		| 2 | SHA2-256 | MUST | |
	| 3 | SHA2-384 | MAY | |		| 3 | SHA2-384 | MAY | |
	| 4 | SHA2-512 | SHOULD | |		| 4 | SHA2-512 | SHOULD | |
	+--------+-------------+------------+---------+		+--------+-------------+----------+---------+
	When Digital Signature authentication method is used with RSA		When Digital Signature authentication method is used with RSA
	signature algorithm, then RSASSA-PSS MUST be supported and RSASSA-		signature algorithm, then RSASSA-PSS MUST be supported and RSASSA-
	PKCS1-v1.5 MAY be supported.		PKCS1-v1.5 MAY be supported.
	The following table lists recommendations for authentication methods		The following table lists recommendations for authentication methods
	in RFC7427 [RFC7427] notation. These recommendations are applied		in RFC7427 [RFC7427] notation. These recommendations are applied
	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 | SHOULD NOT | |		| sha1WithRSAEncryption | MUST NOT | |
	| dsa-with-sha1 | SHOULD NOT | |		| dsa-with-sha1 | MUST NOT | |
	| ecdsa-with-sha1 | SHOULD NOT | |		| ecdsa-with-sha1 | MUST NOT | |
	| RSASSA-PSS with Empty Parameters | SHOULD NOT | |		| RSASSA-PSS with Empty Parameters | MUST NOT | |
	| RSASSA-PSS with Default Parameters | SHOULD NOT | |		| RSASSA-PSS with Default Parameters | 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
End of changes. 12 change blocks.
	34 lines changed or deleted		38 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/