< draft-ietf-ipsecme-rfc4307bis-02.txt		draft-ietf-ipsecme-rfc4307bis-03.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: July 07, 2016 INSIDE Secure		Expires: August 13, 2016 INSIDE Secure
	P. Wouters		P. Wouters
	Red Hat		Red Hat
	D. Migault		D. Migault
	Ericsson		Ericsson
	January 04, 2016		February 10, 2016
	Algorithm Implementation Requirements and Usage Guidance for IKEv2		Algorithm Implementation Requirements and Usage Guidance for IKEv2
	draft-ietf-ipsecme-rfc4307bis-02		draft-ietf-ipsecme-rfc4307bis-03
	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 Security Association. To ensure		should be used in any given Security Association. To ensure
	interoperability between different implementations, it is necessary		interoperability between different implementations, it is necessary
	to specify a set of algorithm implementation requirements and Usage		to specify a set of algorithm implementation requirements and Usage
	guidance to ensure that there is at least one algorithm that all		guidance to ensure that there is at least one algorithm that all
	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 July 07, 2016.		This Internet-Draft will expire on August 13, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 33 ¶
	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 . . . . . . . . . . . . . . 4
	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 . . . . 6
	3.3. Type 3 - IKEv2 Integrity Algorithm Transforms . . . . . . 7		3.3. Type 3 - IKEv2 Integrity Algorithm Transforms . . . . . . 7
	3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms . . . . . 8		3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms . . . . . 8
	4. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 9		4. IKEv2 Authentication . . . . . . . . . . . . . . . . . . . . 10
	4.1. IKEv2 Authentication Method . . . . . . . . . . . . . . . 9		4.1. IKEv2 Authentication Method . . . . . . . . . . . . . . . 10
	4.2. Digital Signature Recommendation . . . . . . . . . . . . 10		4.2. Digital Signature Recommendation . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The Internet Key Exchange protocol [RFC7296] is used to negotiate the		The Internet Key Exchange protocol [RFC7296] is used to negotiate the
	IPsec parameters, such as encryption algorithms and keys, for		IPsec parameters, such as encryption algorithms and keys, for
	protected communications between two endpoints. The IKEv2 protocol		protected communications between two endpoints. The IKEv2 protocol
	itself is also protected by encryption, which is also negotiated		itself is also protected by encryption, which is also negotiated
	between the two endpoints. Negotiation is performed by IKEv2 itself.		between the two endpoints. Negotiation is performed by IKEv2 itself.
	This document describes the encryption parameters of the IKE		This document describes the encryption parameters of the IKE
	protocol, not the encryption parameters of the ESP (IPsec) protocol.		protocol, not the encryption parameters of the ESP (IPsec) protocol.
	Different implementations of IKEv2 may negotiate different encryption		Different implementations of IKEv2 may negotiate different encryption
	algorithms based on their individual local policy. To ensure		algorithms based on their individual local policy. To ensure
	interoperability, a set of "mandatory-to-implement" IKEv2 encryption		interoperability, a set of "mandatory-to-implement" IKEv2 encryption
	algorithms is defined.		algorithms is defined.
	1.1. Updating Algorithm Implementation Requirements and Usage Guidance		1.1. Updating Algorithm Implementation Requirements and Usage Guidance
	The field of cryptography evolves continiously. New stronger		The field of cryptography evolves continiously. 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
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 24 ¶
	The current trend toward Internet of Things and its adoption of IKEv2		The current trend toward Internet of Things and its adoption of IKEv2
	requires this specific use case to be taken into account as well.		requires this specific use case to be taken into account as well.
	IoT devices are resource constrainted devices and their choice of		IoT devices are resource constrainted devices and their choice of
	algorithms are motivated by minimizing the fooprint of the code, the		algorithms are motivated by minimizing the fooprint of the code, the
	computation effort and the size of the messages to send. This		computation effort and the size of the messages to send. This
	document indicates IoT when a specified algorithm is specifically		document indicates IoT when a specified algorithm is specifically
	listed for IoT devices.		listed for IoT devices.
	1.3. Document Audience		1.3. Document Audience
	The recommendations of this document target IKEv2 implementers. In		The recommendations of this document mostly target IKEv2 implementers
	other words, the recommendations should not be considered for IKEv2		as implementations needs to meet both high security expectations as
	configuration, as a preference for some algorithms. [PAUL: I don't		well as high interoperability between various vendors and with
	understand this. Clearly MTI are good default choices?]		different updates. Interoperability requires a smooth move to more
			secure cipher suites. This may differ from a user point of view that
			may deploy and configure IKEv2 with only the safest cipher suites.
			On the other hand, comments and recommendations are also expected to
			be useful for such users.
	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.		recommendations of this document must not be considered for IKEv1.
	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
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	We define some additional terms here:		We define some additional terms here:
	SHOULD+ This term means the same as SHOULD. However, it is likely		SHOULD+ This term means the same as SHOULD. However, it is likely
	that an algorithm marked as SHOULD+ will be promoted at some		that an algorithm marked as SHOULD+ will be promoted at
	future time to be a MUST.		some future time to be a MUST.
	SHOULD- This term means the same as SHOULD. However, an algorithm		SHOULD- This term means the same as SHOULD. However, an algorithm
	marked as SHOULD- may be deprecated to a MAY in a future		marked as SHOULD- may be deprecated to a MAY in a future
	version of this document.		version of this document.
	MUST- This term means the same as MUST. However, we expect at		MUST- This term means the same as MUST. However, we expect at
	some point that this algorithm will no longer be a MUST in a		some point that this algorithm will no longer be a MUST in
	future document. Although its status will be determined at		a future document. Although its status will be determined
	a later time, it is reasonable to expect that if a future		at a later time, it is reasonable to expect that if a
	revision of a document alters the status of a MUST-		future revision of a document alters the status of a MUST-
	algorithm, it will remain at least a SHOULD or a SHOULD-.		algorithm, it will remain at least a SHOULD or a SHOULD-.
	IoT stands for Internet of Things.		IoT stands for Internet of Things.
	Table 1
	3. Algorithm Selection		3. Algorithm Selection
	3.1. Type 1 - IKEv2 Encryption Algorithm Transforms		3.1. Type 1 - IKEv2 Encryption 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 in the ENCR payload. References to the specifications		and used in the Encrypted Payload. References to the specifications
	defining these algorithms and the ones in the following subsections		defining these algorithms and the ones in the following subsections
	are in the IANA registry [IKEV2-IANA]. Some of these algorithms are		are in the IANA registry [IKEV2-IANA]. Some of these algorithms are
	Authenticated Encryption with Associated Data (AEAD - [RFC5282]).		Authenticated Encryption with Associated Data (AEAD - [RFC5282]).
	Algorithms that are not AEAD MUST be used in conjunction with an		Algorithms that are not AEAD MUST be used in conjunction with an
	integrity algorithms in Section 3.3.		integrity algorithms in Section 3.3.
	+-----------------------------+----------+-------+----------+		+-----------------------------+----------+-------+----------+
	| Name | Status | AEAD? | Comment |		| Name | Status | AEAD? | Comment |
	+-----------------------------+----------+-------+----------+		+-----------------------------+----------+-------+----------+
	| ENCR_AES_CBC | MUST- | No | [1] |		| ENCR_AES_CBC | MUST- | No | [1] |
	skipping to change at page 5, line 42 ¶		skipping to change at page 5, line 46 ¶
	| 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][IoT] |		| ENCR_AES_CCM_8 | SHOULD | Yes | [1][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 keys. 256-bit keys are at		[1] - This requirement level is for 128-bit keys. 256-bit keys are at
	MAY. 192-bit keys can safely be ignored. [IoT] - This requirement is		MAY. 192-bit keys can safely be ignored. [IoT] - This requirement is
	for interoperability with IoT.		for interoperability with IoT.
	Table 2
	ENCR_AES_CBC is raised from SHOULD+ in RFC4307. It is the only		ENCR_AES_CBC is raised from SHOULD+ in RFC4307. It is the only
	shared mandatory-to-implement algorithm with RFC4307 and as a result		shared mandatory-to-implement algorithm with RFC4307 and as a result
	is necessary for interoperability with IKEv2 implementation		is necessary for interoperability with IKEv2 implementation
	compatible with RFC4307.		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 and others as an
	alternative to AES and AES-GCM. It is also being standarized for		alternative to AES and AES-GCM. It is also being standarized for
	IPsec for the same reasons. At the time of writing, there were not		IPsec for the same reasons. At the time of writing, there were not
	enough IKEv2 implementations of ENCR_CHACHA20_POLY1305 to be able to		enough IKEv2 implementations of ENCR_CHACHA20_POLY1305 to be able to
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 18 ¶
	| 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- | [1] |		| PRF_HMAC_SHA1 | MUST- | [1] |
	| PRF_AES128_CBC | SHOULD | [IoT] |		| PRF_AES128_CBC | SHOULD | [IoT] |
	+-------------------+---------+---------+		+-------------------+---------+---------+
	[IoT] - This requirement is for interoperability with IoT		[IoT] - This requirement is for interoperability with IoT
	Table 3
	PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based		PRF_HMAC_SHA2_256 was not mentioned in RFC4307, as no SHA2 based
	authentication was mentioned. PRF_HMAC_SHA2_256 MUST be implemented		authentication was mentioned. PRF_HMAC_SHA2_256 MUST be implemented
	in order to replace SHA1 and PRF_HMAC_SHA1.		in order to replace SHA1 and PRF_HMAC_SHA1.
	PRF_HMAC_SHA2_512 SHOULD be implemented as as a future replacement of		PRF_HMAC_SHA2_512 SHOULD be implemented as as a future replacement of
	SHA2_256 or when stronger security is required. PRF_HMAC_SHA2_512 is		SHA2_256 or when stronger security is required. PRF_HMAC_SHA2_512 is
	preferred over PRF_HMAC_SHA2_384, as the overhead of		preferred over PRF_HMAC_SHA2_384, as the overhead of
	PRF_HMAC_SHA2_512 is negligible.		PRF_HMAC_SHA2_512 is negligible.
	PRF_HMAC_SHA1_96 has been downgraded from MUST in RFC4307. There is		PRF_HMAC_SHA1_96 has been downgraded from MUST in RFC4307. There is
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 16 ¶
	| Name | Status | Comment |		| Name | Status | Comment |
	+------------------------+--------+---------+		+------------------------+--------+---------+
	| AUTH_HMAC_SHA2_256_128 | MUST | |		| AUTH_HMAC_SHA2_256_128 | MUST | |
	| AUTH_HMAC_SHA2_512_256 | SHOULD | |		| AUTH_HMAC_SHA2_512_256 | SHOULD | |
	| AUTH_HMAC_SHA1_96 | SHOULD | |		| AUTH_HMAC_SHA1_96 | SHOULD | |
	| AUTH_AES_XCBC_96 | SHOULD | [IoT] |		| AUTH_AES_XCBC_96 | SHOULD | [IoT] |
	+------------------------+--------+---------+		+------------------------+--------+---------+
	[IoT] - This requirement is for interoperability with IoT		[IoT] - This requirement is for interoperability with IoT
	Table 4
	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
	authentication was mentioned. AUTH_HMAC_SHA2_256_128 MUST be		authentication was 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 as a future		AUTH_HMAC_SHA2_512_256 SHOULD be implemented as as a future
	replacement of AUTH_HMAC_SHA2_256_128 or when stronger security is		replacement of AUTH_HMAC_SHA2_256_128 or when stronger security is
	required. This value has been preferred to AUTH_HMAC_SHA2_384, as		required. This value has been preferred to AUTH_HMAC_SHA2_384, as
	the overhead of AUTH_HMAC_SHA2_512 is negligible.		the overhead of AUTH_HMAC_SHA2_512 is negligible.
	AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307. There is		AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307. There is
	skipping to change at page 8, line 34 ¶		skipping to change at page 9, line 5 ¶
	it has not been widely adopted, it has been downgraded from SHOULD in		it has not been widely adopted, it has been downgraded from SHOULD in
	RFC4307 to MAY.		RFC4307 to MAY.
	3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms		3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms
	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 |
	| 5 | 1536-bit MODP Group | SHOULD NOT |		| 5 | 1536-bit MODP Group | SHOULD |
	| 2 | 1024-bit MODP Group | SHOULD NOT |		| | | NOT |
	| 1 | 768-bit MODP Group | MUST NOT |		| 2 | 1024-bit MODP Group | SHOULD |
	| TBD | Curve25519 | MAY |		| | | NOT |
	+--------+--------------------------+------------+		| 1 | 768-bit MODP Group | MUST NOT |
			| 22 | 1024-bit MODP Group with 160-bit Prime Order | MUST NOT |
	Table 5		| | Subgroup | |
			| 23 | 1024-bit MODP Group with 224-bit Prime Order | MUST NOT |
			| | Subgroup | |
			| 24 | 1024-bit MODP Group with 256-bit Prime Order | MUST NOT |
			| | 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.		Group 19 or 256-bit random ECP group was not specified in RFC4307.
	Group 19 is widely implemented and considered secure		Group 19 is widely implemented and considered secure
	Group 5 or 1536-bit MODP Group is downgrade from MUST- to SHOULD NOT.		Group 5 or 1536-bit MODP Group is downgrade from MUST- to SHOULD NOT.
	It was specified earlier, but now considered to be vulnerable to be		It was specified earlier, but now considered to be vulnerable to be
	broken within the next few years by a nation state level attack, so		broken within the next few years by a nation state level attack, so
	its security margin is considered too narrow.		its security margin is considered too narrow.
	Group 2 or 1024-bit MODP Group is downgrade from MUST- to SHOULD NOT.		Group 2 or 1024-bit MODP Group is downgrade from MUST- to SHOULD NOT.
	It was specified earlier, but now it is known to be weak against		It was specified earlier, but now it is known to be weak against
	sufficiently funded attackers using commercially available mass-		sufficiently funded attackers using commercially available mass-
	computing resources, so its security margin is considered too narrow.		computing resources, so its security margin is considered too narrow.
	It is expected in the near future to be downgraded to MUST NOT.		It is expected in the near future to be downgraded to MUST NOT.
	skipping to change at page 9, line 25 ¶		skipping to change at page 10, line 5 ¶
	Group 1 or 768-bit MODP Group can be broken within hours using cheap		Group 1 or 768-bit MODP Group can be broken within hours using cheap
	of-the-shelves hardware. It provides no security whatsoever.		of-the-shelves hardware. It provides no security whatsoever.
	Curve25519 has been designed with performance and security in mind		Curve25519 has been designed with performance and security in mind
	and have been recommended by CFRG. At the time of writing, the IKEv2		and have been recommended by CFRG. At the time of writing, the IKEv2
	specification is still at the draft status. This document specifies		specification is still at the draft status. This document specifies
	it as to encourage its implementation and deployment. If it gets		it as to encourage its implementation and deployment. If it gets
	widely implemented then it most likely will be upgraded to SHOULD or		widely implemented then it most likely will be upgraded to SHOULD or
	even MUST in the future.		even MUST in the future.
			Group 22-24 or 1024-bit MODP Group with 160-bit and 2048-bit MODP
			Group with 224-256-bit Prime Order Subgroup are exposed to
			synchronization or transcription attacks.
	4. IKEv2 Authentication		4. IKEv2 Authentication
	IKEv2 authentication may involve a signatures verification.		IKEv2 authentication may involve a signatures verification.
	Signatures may be used to validate a certificate or to check the		Signatures may be used to validate a certificate or to check the
	signature of the AUTH value. Cryptographic recommendations regarding		signature of the AUTH value. Cryptographic recommendations regarding
	certificate validation are out of scope of this document as what		certificate validation are out of scope of this document as what
	mandatory implementations are provided by the PKIX WG. This document		mandatory implementations are provided by the PKIX WG. This document
	is mostly concerned on signature verification and generation for the		is mostly concerned on signature verification and generation for the
	authentication.		authentication.
	4.1. IKEv2 Authentication Method		4.1. IKEv2 Authentication Method
	+----------+-----------------------+----------+---------------------+		+--------+-------------------------+--------+-----------------------+
	| Number | Description | Status | Comment |		| Number | Description | Status | Comment |
	+----------+-----------------------+----------+---------------------+		+--------+-------------------------+--------+-----------------------+
	| 1 | RSA Digital Signature | MUST | With keys length |		| 1 | RSA Digital Signature | MUST | With keys length 2048 |
	| | | | 2048 |		| 1 | RSA Digital Signature | SHOULD | With keys length |
	| 1 | RSA Digital Signature | SHOULD | With keys length |		| | | | 3072/4096 |
	| | | | 3072/4096 |		| 1 | RSA Digital Signature | MUST | With keys length |
	| 1 | RSA Digital Signature | MUST NOT | With keys length |		| | | NOT | lower than 2048 |
	| | | | lower than 2048 |		| 3 | DSS Digital Signature | MAY | |
	| 3 | DSS Digital Signature | MAY | |		| 9 | ECDSA with SHA-256 on | SHOULD | |
	| 9 | ECDSA with SHA-256 on | SHOULD | |		| | the P-256 curve | | |
	| | the P-256 curve | | |		| 10 | ECDSA with SHA-384 on | SHOULD | |
	| 10 | ECDSA with SHA-384 on | SHOULD | |		| | the P-384 curve | | |
	| | the P-384 curve | | |		| 11 | ECDSA with SHA-512 on | SHOULD | |
	| 11 | ECDSA with SHA-512 on | SHOULD | |		| | the P-521 curve | | |
	| | the P-521 curve | | |		| 14 | Digital Signature | SHOULD | |
	| 14 | Digital Signature | SHOULD | |		+--------+-------------------------+--------+-----------------------+
	+----------+-----------------------+----------+---------------------+
	Table 6
	RSA Digital Signature is mostly kept for interoperability. It is		RSA Digital Signature is mostly kept for interoperability. It is
	expected to be downgraded in the future as signatures are based on		expected to be downgraded in the future as signatures are based on
	RSASSA-PKCS1-v1.5, not any more recommemded. Instead, more robust		RSASSA-PKCS1-v1.5, not any more recommemded. Instead, more robust
	use of RSA is expected to be performed via the Digital Signature		use of RSA is expected to be performed via the Digital Signature
	method.		method.
	ECDSA family are also expected to be downgraded as it does not		ECDSA family are also expected to be downgraded as it does not
	provide hash function agility. Instead ECDSA is expected to be		provide hash function agility. Instead ECDSA is expected to be
	performed using the generic Digital Signature method.		performed using the generic Digital Signature method.
	skipping to change at page 10, line 31 ¶		skipping to change at page 11, line 13 ¶
	downgraded to MUST NOT in the future.		downgraded to MUST NOT in the future.
	Digital Signature is expected to be promoted as it provides hash		Digital Signature is expected to be promoted as it provides hash
	function, signature format and algorithm agility.		function, signature format and algorithm agility.
	[MGLT: Do we have any recommendation for the authentication based on		[MGLT: Do we have any recommendation for the authentication based on
	PSK?]		PSK?]
	4.2. Digital Signature Recommendation		4.2. Digital Signature Recommendation
	Recommended methods: RSA (MUST), ECDSA (SHOULD), Ed25519 (MAY),		Here are the recommendations for the authentication methods.
	Ed25519ph(MAY), Ed448(MAY), Ed448ph(MAY)?
			+--------+-------------+----------+---------------------------------+
			| Number | Description | Status | Comment |
			+--------+-------------+----------+---------------------------------+
			| OID | RSA | MUST | With keys length 2048 |
			| OID | RSA | SHOULD | With keys length 3072/4096 |
			| OID | RSA | MUST NOT | With keys length lower than |
			| | | | 2048 |
			| OID | ECDSA | SHOULD | |
			+--------+-------------+----------+---------------------------------+
	Here are the recommendations when a hash function is involved in a		Here are the recommendations when a hash function is involved in a
	signature.		signature.
	+--------+----------------------+----------+---------+		+--------+-------------+--------+---------+
	| Number | Description | Status | Comment |		| Number | Description | Status | Comment |
	+--------+----------------------+----------+---------+		+--------+-------------+--------+---------+
	| 1 | SHA1 | MUST | |		| 1 | SHA1 | MUST | |
	| 2 | SHA2-256 | MUST | |		| 2 | SHA2-256 | MUST | |
	| 3 | SHA2-384 | MAY | |		| 3 | SHA2-384 | MAY | |
	| 4 | SHA2-512 | SHOULD | |		| 4 | SHA2-512 | SHOULD | |
	| | Other hash functions | MUST NOT | |		+--------+-------------+--------+---------+
	+--------+----------------------+----------+---------+
	Table 7
	With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be		With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be
	implemented, and RSASSA-PSS MUST be implemented.		implemented, and RSASSA-PSS MUST be implemented.
	RSA keys MUST be greater or equal than 20148 bits.
	5. Security Considerations		5. 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.
	The Diffie-Hellman Groups parameter is the most important one to		The Diffie-Hellman Groups parameter is the most important one to
	skipping to change at page 11, line 44 ¶		skipping to change at page 12, line 28 ¶
	6. IANA Considerations		6. IANA Considerations
	This document makes no requests of IANA.		This document makes no requests of IANA.
	7. Acknowledgements		7. 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 original text has been copied verbatim.		the original text has been copied verbatim.
	We would like to thanks Paul Hoffman, Yaron Sheffer and Tommy Pauly		We would like to thanks Paul Hoffman, Yaron Sheffer John Mattsson and
	for their valuable feed backs.		Tommy Pauly for their valuable feed backs.
	8. References		8. References
	8.1. Normative References		8.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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode		[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
	(GCM) in IPsec Encapsulating Security Payload (ESP)", RFC		(GCM) in IPsec Encapsulating Security Payload (ESP)",
	4106, DOI 10.17487/RFC4106, June 2005,		RFC 4106, DOI 10.17487/RFC4106, June 2005,
	<http://www.rfc-editor.org/info/rfc4106>.		<http://www.rfc-editor.org/info/rfc4106>.
	[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the		[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
	Internet Key Exchange Version 2 (IKEv2)", RFC 4307, DOI		Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
	10.17487/RFC4307, December 2005,		DOI 10.17487/RFC4307, December 2005,
	<http://www.rfc-editor.org/info/rfc4307>.		<http://www.rfc-editor.org/info/rfc4307>.
	[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, DOI 10.17487/RFC7296, October		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <http://www.rfc-editor.org/info/rfc7296>.		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>.
	8.2. Informative References		8.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
	Yoav Nir		Yoav Nir
	Check Point Software Technologies Ltd.		Check Point Software Technologies Ltd.
	5 Hasolelim st.		5 Hasolelim st.
	Tel Aviv 6789735		Tel Aviv 6789735
	Israel		Israel
End of changes. 30 change blocks.
	89 lines changed or deleted		100 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/