draft-ietf-ipsecme-dh-checks-04.txt		draft-ietf-ipsecme-dh-checks-05.txt
	ipsecme Y. Sheffer		ipsecme Y. Sheffer
	Internet-Draft Porticor		Internet-Draft Porticor
	Updates: 5996 (if approved) S. Fluhrer		Updates: 5996 (if approved) S. Fluhrer
	Intended status: Standards Track Cisco		Intended status: Standards Track Cisco
	Expires: November 5, 2013 May 4, 2013		Expires: December 6, 2013 June 4, 2013
	Additional Diffie-Hellman Tests for IKEv2		Additional Diffie-Hellman Tests for IKEv2
	draft-ietf-ipsecme-dh-checks-04		draft-ietf-ipsecme-dh-checks-05
	Abstract		Abstract
	This document adds a small number of mandatory tests required for the		This document adds a small number of mandatory tests required for the
	secure operation of IKEv2 with elliptic curve groups. No change is		secure operation of IKEv2 with elliptic curve groups. No change is
	required to IKE implementations that use modular exponential groups,		required to IKE implementations that use modular exponential groups,
	other than a few rarely used so-called DSA groups. This document		other than a few rarely used so-called DSA groups. This document
	updates the IKEv2 protocol, RFC 5996.		updates the IKEv2 protocol, RFC 5996.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 5, 2013.		This Internet-Draft will expire on December 6, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 18		skipping to change at page 2, line 18
	1. Introduction . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Conventions used in this document . . . . . . . . . . 3		1.1. Conventions used in this document . . . . . . . . . . 3
	2. Group Membership Tests . . . . . . . . . . . . . . . . 3		2. Group Membership Tests . . . . . . . . . . . . . . . . 3
	2.1. Sophie Germain Prime MODP Groups . . . . . . . . . . . 3		2.1. Sophie Germain Prime MODP Groups . . . . . . . . . . . 3
	2.2. MODP Groups with Small Subgroups . . . . . . . . . . . 4		2.2. MODP Groups with Small Subgroups . . . . . . . . . . . 4
	2.3. Elliptic Curve Groups . . . . . . . . . . . . . . . . 4		2.3. Elliptic Curve Groups . . . . . . . . . . . . . . . . 4
	2.4. Transition . . . . . . . . . . . . . . . . . . . . . . 5		2.4. Transition . . . . . . . . . . . . . . . . . . . . . . 5
	2.5. Protocol Behavior . . . . . . . . . . . . . . . . . . 5		2.5. Protocol Behavior . . . . . . . . . . . . . . . . . . 5
	3. Side-Channel Attacks . . . . . . . . . . . . . . . . . 6		3. Side-Channel Attacks . . . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . 6
	4.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . 6		4.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . 7
	4.2. DH Key Reuse: Variants . . . . . . . . . . . . . . . . 7		4.2. DH Key Reuse: Variants . . . . . . . . . . . . . . . . 7
	4.3. Groups not covered by this RFC . . . . . . . . . . . . 7		4.3. Groups not covered by this RFC . . . . . . . . . . . . 7
	4.4. Behavior Upon Test Failure . . . . . . . . . . . . . . 7		4.4. Behavior Upon Test Failure . . . . . . . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . 8
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgements . . . . . . . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Normative References . . . . . . . . . . . . . . . . . 9		7.1. Normative References . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . 9		7.2. Informative References . . . . . . . . . . . . . . . . 9
	Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 10		Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 10
	A.1. -04 . . . . . . . . . . . . . . . . . . . . . . . . . 10		A.1. -05 . . . . . . . . . . . . . . . . . . . . . . . . . 10
	A.2. -03 . . . . . . . . . . . . . . . . . . . . . . . . . 10		A.2. -04 . . . . . . . . . . . . . . . . . . . . . . . . . 10
	A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . 10		A.3. -03 . . . . . . . . . . . . . . . . . . . . . . . . . 10
	A.4. -01 . . . . . . . . . . . . . . . . . . . . . . . . . 10		A.4. -02 . . . . . . . . . . . . . . . . . . . . . . . . . 10
	A.5. -00 . . . . . . . . . . . . . . . . . . . . . . . . . 10		A.5. -01 . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . 10		A.6. -00 . . . . . . . . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	IKEv2 [RFC5996] consists of the establishment of a shared secret		IKEv2 [RFC5996] consists of the establishment of a shared secret
	using the Diffie-Hellman (DH) protocol, followed by authentication of		using the Diffie-Hellman (DH) protocol, followed by authentication of
	the two peers. Existing implementations typically use modular		the two peers. Existing implementations typically use modular
	exponential (MODP) DH groups, such as those defined in [RFC3526].		exponential (MODP) DH groups, such as those defined in [RFC3526].
	IKEv2 does not require that any tests be performed by a peer		IKEv2 does not require that any tests be performed by a peer
	receiving a public Diffie-Hellman key from the other peer. This is		receiving a public Diffie-Hellman key from the other peer. This is
	skipping to change at page 3, line 39		skipping to change at page 3, line 39
	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].
	2. Group Membership Tests		2. Group Membership Tests
	This section describes the tests that need to be performed by IKE		This section describes the tests that need to be performed by IKE
	peers receiving a Key Exchange (KE) payload. The tests are		peers receiving a Key Exchange (KE) payload. The tests are
	RECOMMENDED for all implementations, but only REQUIRED for those that		RECOMMENDED for all implementations, but only REQUIRED for those that
	reuse DH secret keys (as defined in [RFC5996], Sec. 2.12). The tests		reuse DH private keys (as defined in [RFC5996], Sec. 2.12). The
	apply to the recipient of a KE payload, and describe how it should		tests apply to the recipient of a KE payload, and describe how it
	check the received payload. They are listed here according to the DH		should check the received payload. They are listed here according to
	group being used.		the DH group being used.
	2.1. Sophie Germain Prime MODP Groups		2.1. Sophie Germain Prime MODP Groups
	These are currently the most commonly used groups; all these groups		These are currently the most commonly used groups; all these groups
	have the property that (p-1)/2 is also prime; this section applies to		have the property that (p-1)/2 is also prime; this section applies to
	any such MODP group. Each recipient MUST verify that the peer's		any such MODP group. Each recipient MUST verify that the peer's
	public value r is in the legal range (1 < r < p-1). According to		public value r is in the legal range (1 < r < p-1). According to
	[Menezes], Sec 2.2, even with this check there remains the		[Menezes], Sec 2.2, even with this check there remains the
	possibility of leaking a single bit of the secret exponent when DH		possibility of leaking a single bit of the secret exponent when DH
	keys are reused; this amount of leakage is insignificant.		keys are reused; this amount of leakage is insignificant.
	skipping to change at page 5, line 11		skipping to change at page 5, line 11
	RFC).		RFC).
	We note that an additional check to ensure that the public value is		We note that an additional check to ensure that the public value is
	not the point at infinity is not needed, because IKE (in Sec. 7 of		not the point at infinity is not needed, because IKE (in Sec. 7 of
	[RFC5903]) does not allow for encoding this value.		[RFC5903]) does not allow for encoding this value.
	See Section 5 for the specific groups covered by this section.		See Section 5 for the specific groups covered by this section.
	2.4. Transition		2.4. Transition
	Existing implementations of IKEv2 with ECDH groups MAY be modified to		Existing implementations of IKEv2 with ECDH groups may be modified to
	include the tests described in the current document, even if they do		include the tests described in the current document, even if they do
	not reuse DH keys. The tests can be considered as sanity checks, and		not reuse DH keys. The tests can be considered as sanity checks, and
	will prevent the code having to handle inputs that it may not have		will prevent the code having to handle inputs that it may not have
	been designed to handle.		been designed to handle.
	ECDH implementations that do reuse DH keys MUST be enhanced to		ECDH implementations that do reuse DH keys MUST be enhanced to
	include the above tests.		include the above tests.
	2.5. Protocol Behavior		2.5. Protocol Behavior
	The recipient of a DH public key that fails one of the above tests		The recipient of a DH public key that fails one of the above tests
	can assume that the sender is either truly malicious or else it has a		must assume that the sender is either truly malicious or else it has
	bug in its implementation.		a bug in its implementation. The behavior defined below attempts to
			balance resistance to attackers that are trying to disrupt the IKE
			exchange, against the need to help a badly implemented peer by
			providing useful error indications.
	If this error happens during the IKE_SA_INIT exchange, then the		If this error happens during the IKE_SA_INIT exchange, then the
	recipient MUST drop the message that contains an invalid KE payload,		recipient MUST drop the message that contains an invalid KE payload,
	and MUST NOT use that message when creating the IKE SA.		and MUST NOT use that message when creating the IKE SA.
	If the implementation implements the DoS-resistant behavior proposed		If the implementation implements the DoS-resistant behavior proposed
	in Sec. 2.4 of [RFC5996], it may simply ignore the erroneous request		in Sec. 2.4 of [RFC5996], it may simply ignore the erroneous request
	or response message, and continue waiting for a later message		or response message, and continue waiting for a later message
	containing a legitimate KE payload.		containing a legitimate KE payload.
	skipping to change at page 7, line 7		skipping to change at page 7, line 14
	4.1. DH Key Reuse and Multiple Peers		4.1. DH Key Reuse and Multiple Peers
	This section describes one variant of the attack prevented by the		This section describes one variant of the attack prevented by the
	tests defined above.		tests defined above.
	Suppose that IKE peer Alice maintains IKE security associations with		Suppose that IKE peer Alice maintains IKE security associations with
	peers Bob and Eve. Alice uses the same secret ECDH key for both SAs,		peers Bob and Eve. Alice uses the same secret ECDH key for both SAs,
	which is allowed with some restrictions. If Alice does not implement		which is allowed with some restrictions. If Alice does not implement
	these tests, Eve will be able to send a malformed public key, which		these tests, Eve will be able to send a malformed public key, which
	would allow her to efficiently determine Alice's secret key (as		would allow her to efficiently determine Alice's private key (as
	described in Sec. 2 of [Menezes]). Since the key is shared, Eve will		described in Sec. 2 of [Menezes]). Since the key is shared, Eve will
	be able to obtain Alice's shared IKE SA key with Bob.		be able to obtain Alice's shared IKE SA key with Bob.
	4.2. DH Key Reuse: Variants		4.2. DH Key Reuse: Variants
	Private DH keys can be reused in different ways, with subtly		Private DH keys can be reused in different ways, with subtly
	different security implications. For example:		different security implications. For example:
	1. DH keys are reused for multiple connections (IKE SAs) to the same		1. DH keys are reused for multiple connections (IKE SAs) to the same
	peer, and for connections to different peers.		peer, and for connections to different peers.
	skipping to change at page 8, line 5		skipping to change at page 8, line 15
	4.4. Behavior Upon Test Failure		4.4. Behavior Upon Test Failure
	The behavior recommended in Section 2.5 is in line with generic error		The behavior recommended in Section 2.5 is in line with generic error
	treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of [RFC5996].		treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of [RFC5996].
	The sender is not required to send back an error notification, and		The sender is not required to send back an error notification, and
	the recipient cannot depend on this notification because it is		the recipient cannot depend on this notification because it is
	unauthenticated, and may in fact have been sent by an attacker trying		unauthenticated, and may in fact have been sent by an attacker trying
	to DoS the connection. Thus, the notification is only useful to		to DoS the connection. Thus, the notification is only useful to
	debug implementation errors.		debug implementation errors.
	On the other hand, the error notification is secure, in the sense		On the other hand, the error notification is secure in the sense that
	that no secret information is leaked. All IKEv2 Diffie-Hellman		no secret information is leaked. All IKEv2 Diffie-Hellman groups are
	groups are publicly known, and none of the tests defined here depend		publicly known, and none of the tests defined here depend on any
	on any secret key. In fact the tests can all be performed by an		private key. In fact the tests can all be performed by an
	eavesdropper.		eavesdropper.
	The situation when the failure occurs in the Create Child SA exchange		The situation when the failure occurs in the Create Child SA exchange
	is different, since everything is protected by an IKE SA. The peers		is different, since everything is protected by an IKE SA. The peers
	are authenticated, and error notifications can be relied on. See		are authenticated, and error notifications can be relied on. See
	Sec. 2.21.3 of [RFC5996] for more details on error handling in this		Sec. 2.21.3 of [RFC5996] for more details on error handling in this
	case.		case.
	5. IANA Considerations		5. IANA Considerations
	skipping to change at page 10, line 18		skipping to change at page 10, line 26
	[IANA-DH-Registry]		[IANA-DH-Registry]
	IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters,		IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters,
	Transform Type 4 - Diffie-Hellman Group Transform IDs",		Transform Type 4 - Diffie-Hellman Group Transform IDs",
	Jan. 2005, <http://www.iana.org/assignments/		Jan. 2005, <http://www.iana.org/assignments/
	ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-8>.		ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-8>.
	Appendix A. Appendix: Change Log		Appendix A. Appendix: Change Log
	Note to RFC Editor: please remove this section before publication.		Note to RFC Editor: please remove this section before publication.
	A.1. -04		A.1. -05
			o Resolved IESG members' comments.
			A.2. -04
	o Implemented Sean's AD review, and removed the inapplicable		o Implemented Sean's AD review, and removed the inapplicable
	requirement on the point at infinity.		requirement on the point at infinity.
	A.2. -03		A.3. -03
	o Added the Brainpool curves to the IANA registration table.		o Added the Brainpool curves to the IANA registration table.
	A.3. -02		A.4. -02
	o Based on Tero's review: Improved the protocol behavior, and		o Based on Tero's review: Improved the protocol behavior, and
	mentioned that these checks apply to Create Child SA. Added a		mentioned that these checks apply to Create Child SA. Added a
	discussion of DH timing attacks, stolen from RFC 2412.		discussion of DH timing attacks, stolen from RFC 2412.
	A.4. -01		A.5. -01
	o Corrected an author's name that was misspelled.		o Corrected an author's name that was misspelled.
	o Added recipient behavior if a test fails, and the related security		o Added recipient behavior if a test fails, and the related security
	considerations.		considerations.
	A.5. -00		A.6. -00
	o First WG document.		o First WG document.
	o Clarified IANA actions.		o Clarified IANA actions.
	o Discussion of potential future groups not covered here.		o Discussion of potential future groups not covered here.
	o Clarification re: practicality of recipient tests for DSA groups.		o Clarification re: practicality of recipient tests for DSA groups.
	Authors' Addresses		Authors' Addresses
	Yaron Sheffer		Yaron Sheffer
	Porticor		Porticor
End of changes. 17 change blocks.
	29 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/