< draft-ietf-ipsecme-dh-checks-03.txt		draft-ietf-ipsecme-dh-checks-04.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: October 24, 2013 April 22, 2013		Expires: November 5, 2013 May 4, 2013
	Additional Diffie-Hellman Tests for IKEv2		Additional Diffie-Hellman Tests for IKEv2
	draft-ietf-ipsecme-dh-checks-03		draft-ietf-ipsecme-dh-checks-04
	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 October 24, 2013.		This Internet-Draft will expire on November 5, 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 16 ¶		skipping to change at page 2, line 16 ¶
	Table of Contents		Table of Contents
	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 . . . . . . . . . . . . . . . . . 5		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 . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . 8
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgements . . . . . . . . . . . . . . . . . . . 8
	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. -03 . . . . . . . . . . . . . . . . . . . . . . . . . 10		A.1. -04 . . . . . . . . . . . . . . . . . . . . . . . . . 10
	A.2. -02 . . . . . . . . . . . . . . . . . . . . . . . . . 10		A.2. -03 . . . . . . . . . . . . . . . . . . . . . . . . . 10
	A.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . 10		A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . 10
	A.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . 10		A.4. -01 . . . . . . . . . . . . . . . . . . . . . . . . . 10
			A.5. -00 . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . 10
	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
	fine for the common case of MODP groups. For other DH groups, when		fine for the common case of MODP groups. For other DH groups, when
	peers reuse DH values across multiple IKE sessions, the lack of tests		peers reuse DH values across multiple IKE sessions, the lack of tests
	by the recipient results in a potential vulnerability (see		by the recipient results in a potential vulnerability (see
	Section 4.1 for more details). In particular, this is true for		Section 4.1 for more details). In particular, this is true for
	elliptic curve groups whose use is becoming ever more popular. This		Elliptic Curve (EC) groups whose use is becoming ever more popular.
	document defines such tests for several types of DH groups.		This document defines such tests for several types of DH groups.
	In addition, this document describes another potential attack related		In addition, this document describes another potential attack related
	to reuse of DH keys: a timing attack. This additional material is		to reuse of DH keys: a timing attack. This additional material is
	taken from [RFC2412].		taken from [RFC2412].
			This document updates [RFC5996] by adding security requirements that
			apply to many of the protocol's implementations.
	1.1. Conventions used in this document		1.1. 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].
	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
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 27 ¶
	peer's public value, however this test is expensive (approximately as		peer's public value, however this test is expensive (approximately as
	expensive as what reusing DH private values saves). In addition, the		expensive as what reusing DH private values saves). In addition, the
	NIST standard [NIST-800-56A] requires that test (see section		NIST standard [NIST-800-56A] requires that test (see section
	5.6.2.4), hence anyone needing to conform to that standard will need		5.6.2.4), hence anyone needing to conform to that standard will need
	to implement the test anyway.		to implement the test anyway.
	Because of the above, the IKE implementation MUST choose between one		Because of the above, the IKE implementation MUST choose between one
	of the following two options:		of the following two options:
	o It MUST check both that the peer's public value is in range (1 < r		o It MUST check both that the peer's public value is in range (1 < r
	< p-1) and that r**q = 1 mod p (where q is the size of the		< p-1) and that r^q = 1 mod p (where q is the size of the
	subgroup, as listed in the RFC). DH private values MAY then be		subgroup, as listed in the RFC). DH private values MAY then be
	reused. This option is appropriate if conformance to		reused. This option is appropriate if conformance to
	[NIST-800-56A] is required.		[NIST-800-56A] is required.
	o It MUST NOT reuse DH private values (that is, the DH private value		o It MUST NOT reuse DH private values (that is, the DH private value
	for each DH exchange MUST be generated from a fresh output of a		for each DH exchange MUST be generated from a fresh output of a
	cryptographically secure random number generator), and it MUST		cryptographically secure random number generator), and it MUST
	check that the peer's public value is in range (1 < r < p-1).		check that the peer's public value is in range (1 < r < p-1).
	This option is more appropriate if conformance to [NIST-800-56A]		This option is more appropriate if conformance to [NIST-800-56A]
	is not required.		is not required.
	See Section 5 for the specific groups covered by this section.		See Section 5 for the specific groups covered by this section.
	2.3. Elliptic Curve Groups		2.3. Elliptic Curve Groups
	IKEv2 can be used with elliptic curve groups defined over a field		IKEv2 can be used with elliptic curve groups defined over a field
	GF(p) [RFC5903] [RFC5114]. According to [Menezes], Sec. 2.3, there		GF(p) [RFC5903] [RFC5114]. According to [Menezes], Sec. 2.3, there
	is some informational leakage possible. A receiving peer MUST check		is some informational leakage possible. A receiving peer MUST check
	that its peer's public value is valid; that is, it is not the point-		that its peer's public value is valid; that is, the x and y
	at-infinity, and that the x and y parameters from the peer's public		parameters from the peer's public value satisfy the curve equation,
	value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod p		y^2 = x^3 + ax + b mod p (where for groups 19, 20, 21, a=-3 (mod p),
	(where for groups 19, 20, 21, a=-3 (mod p), and all other values of		and all other values of a, b and p for the group are listed in the
	a, b and p for the group are listed in the RFC).		RFC).
			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
			[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.
	skipping to change at page 6, line 11 ¶		skipping to change at page 6, line 16 ¶
	In addition to the small-subgroup attack, there is also a potential		In addition to the small-subgroup attack, there is also a potential
	timing attack on IKE peers when they are reusing Diffie-Hellman		timing attack on IKE peers when they are reusing Diffie-Hellman
	secret values. This is a side-channel attack, which means that it		secret values. This is a side-channel attack, which means that it
	may or may not be a vulnerability in certain cases, depending on		may or may not be a vulnerability in certain cases, depending on
	implementation details and the threat model.		implementation details and the threat model.
	The remainder of this section is quoted from [RFC2412], Sec. 5, with		The remainder of this section is quoted from [RFC2412], Sec. 5, with
	a few minor clarifications. This attack still applies to IKEv2		a few minor clarifications. This attack still applies to IKEv2
	implementations, and both to MODP groups and ECDH groups. We also		implementations, and both to MODP groups and ECDH groups. We also
	note that more efficient countermeasures are available for ECC groups		note that more efficient countermeasures are available for EC groups
	represented in projective form, but these are outside the scope of		represented in projective form, but these are outside the scope of
	the current document.		the current document.
	Timing attacks that are capable of recovering the exponent value used		Timing attacks that are capable of recovering the exponent value used
	in Diffie-Hellman calculations have been described by Paul Kocher		in Diffie-Hellman calculations have been described by Paul Kocher
	[Kocher]. In order to nullify the attack, implementors must take		[Kocher]. In order to nullify the attack, implementors must take
	pains to obscure the sequence of operations involved in carrying out		pains to obscure the sequence of operations involved in carrying out
	modular exponentiations.		modular exponentiations.
	One potential method to foil these timing attacks is to use a		One potential method to foil these timing attacks is to use a
	skipping to change at page 8, line 43 ¶		skipping to change at page 8, line 47 ¶
	[I-D.merkle-ikev2-ke-brainpool].		[I-D.merkle-ikev2-ke-brainpool].
	Future documents that define new DH groups for IKEv2 are REQUIRED to		Future documents that define new DH groups for IKEv2 are REQUIRED to
	provide this information for each new group, possibly by referring to		provide this information for each new group, possibly by referring to
	the current document.		the current document.
	6. Acknowledgements		6. Acknowledgements
	We would like to thank Dan Harkins who initially raised this issue on		We would like to thank Dan Harkins who initially raised this issue on
	the ipsec mailing list. Thanks to Tero Kivinen and Rene Struik for		the ipsec mailing list. Thanks to Tero Kivinen and Rene Struik for
	their useful comments.		their useful comments. Much of the text in Section 3 is taken from
			[RFC2412] and we would like to thank its author, Hilarie Orman.
	The document was prepared using the lyx2rfc tool, created by Nico		The document was prepared using the lyx2rfc tool, created by Nico
	Williams.		Williams.
	7. References		7. References
	7.1. Normative References		7.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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,		[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
	"Internet Key Exchange Protocol Version 2 (IKEv2)",		"Internet Key Exchange Protocol Version 2 (IKEv2)",
	RFC 5996, September 2010.		RFC 5996, September 2010.
	7.2. Informative References		7.2. Informative References
	skipping to change at page 9, line 33 ¶		skipping to change at page 9, line 37 ¶
	Groups for Use with IETF Standards", RFC 5114,		Groups for Use with IETF Standards", RFC 5114,
	January 2008.		January 2008.
	[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a		[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
	Prime (ECP Groups) for IKE and IKEv2", RFC 5903,		Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
	June 2010.		June 2010.
	[I-D.merkle-ikev2-ke-brainpool]		[I-D.merkle-ikev2-ke-brainpool]
	Merkle, J. and M. Lochter, "Using the ECC Brainpool Curves		Merkle, J. and M. Lochter, "Using the ECC Brainpool Curves
	for IKEv2 Key Exchange",		for IKEv2 Key Exchange",
	draft-merkle-ikev2-ke-brainpool-04 (work in progress),		draft-merkle-ikev2-ke-brainpool-06 (work in progress),
	April 2013.		April 2013.
	[NIST-800-56A]		[NIST-800-56A]
	National Institute of Standards and Technology (NIST),		National Institute of Standards and Technology (NIST),
	"Recommendation for Pair-Wise Key Establishment Schemes		"Recommendation for Pair-Wise Key Establishment Schemes
	Using Discrete Logarithm Cryptography (Revised)", NIST PUB		Using Discrete Logarithm Cryptography (Revised)", NIST PUB
	800-56A, March 2007.		800-56A, March 2007.
	[Kocher] Kocher, P., "Timing Attacks on Implementations of Diffie-		[Kocher] Kocher, P., "Timing Attacks on Implementations of Diffie-
	Hellman, RSA, DSS, and Other Systems", December 1996,		Hellman, RSA, DSS, and Other Systems", December 1996,
	skipping to change at page 10, line 13 ¶		skipping to change at page 10, line 18 ¶
	[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. -03		A.1. -04
			o Implemented Sean's AD review, and removed the inapplicable
			requirement on the point at infinity.
			A.2. -03
	o Added the Brainpool curves to the IANA registration table.		o Added the Brainpool curves to the IANA registration table.
	A.2. -02		A.3. -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.3. -01		A.4. -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.4. -00		A.5. -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.
	23 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/