< draft-ietf-ipsecme-dh-checks-00.txt		draft-ietf-ipsecme-dh-checks-01.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: August 2, 2013 January 29, 2013		Expires: October 4, 2013 April 2, 2013
	Additional Diffie-Hellman Tests for IKEv2		Additional Diffie-Hellman Tests for IKEv2
	draft-ietf-ipsecme-dh-checks-00		draft-ietf-ipsecme-dh-checks-01
	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 August 2, 2013.		This Internet-Draft will expire on October 4, 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 15 ¶		skipping to change at page 2, line 15 ¶
	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. Regular MODP Groups . . . . . . . . . . . . . . . . . . 3		2.1. Regular MODP Groups . . . . . . . . . . . . . . . . . . 3
	2.2. MODP Groups with Small Subgroups . . . . . . . . . . . 3		2.2. MODP Groups with Small Subgroups . . . . . . . . . . . 3
	2.3. Elliptic Curve Groups . . . . . . . . . . . . . . . . . 4		2.3. Elliptic Curve Groups . . . . . . . . . . . . . . . . . 4
	2.4. Transition . . . . . . . . . . . . . . . . . . . . . . 4		2.4. Transition . . . . . . . . . . . . . . . . . . . . . . 4
			2.5. Protocol Behavior . . . . . . . . . . . . . . . . . . . 5
	3. Security Considerations . . . . . . . . . . . . . . . . 5		3. Security Considerations . . . . . . . . . . . . . . . . 5
	3.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . . 5		3.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . . 5
	3.2. Groups not covered by this RFC . . . . . . . . . . . . 5		3.2. Groups not covered by this RFC . . . . . . . . . . . . 5
	4. IANA Considerations . . . . . . . . . . . . . . . . . . 5		3.3. Behavior Upon Test Failure . . . . . . . . . . . . . . 6
			4. IANA Considerations . . . . . . . . . . . . . . . . . . 6
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . 6		5. Acknowledgements . . . . . . . . . . . . . . . . . . . 6
	6. References . . . . . . . . . . . . . . . . . . . . . . 6		6. References . . . . . . . . . . . . . . . . . . . . . . 7
	6.1. Normative References . . . . . . . . . . . . . . . . . 6		6.1. Normative References . . . . . . . . . . . . . . . . . 7
	6.2. Informative References . . . . . . . . . . . . . . . . 6		6.2. Informative References . . . . . . . . . . . . . . . . 7
	Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 7		Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 7
	A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . 7		A.1. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . 7		A.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
			Authors' Addresses . . . . . . . . . . . . . . . . . . 8
	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 4, line 12 ¶		skipping to change at page 4, line 12 ¶
	these are modular exponential groups with comparatively small		these are modular exponential groups with comparatively small
	subgroups, and all have (p-1)/2 composite. Sec. 2.1 of [Menezes]		subgroups, and all have (p-1)/2 composite. Sec. 2.1 of [Menezes]
	describes some informational leakage from a small subgroup attack on		describes some informational leakage from a small subgroup attack on
	these groups, if the DH private value is reused.		these groups, if the DH private value is reused.
	This leakage can be prevented if the recipient performs a test on the		This leakage can be prevented if the recipient performs a test on the
	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 anyways.		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
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 8 ¶
	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, if they do not		include the tests described in the current document, if they do not
	reuse DH keys with multiple peers. The tests can be considered as		reuse DH keys with multiple peers. The tests can be considered as
	sanity checks, and will prevent the code having to handle inputs that		sanity checks, and will prevent the code having to handle inputs that
	it may not have been designed to handle.		it may not have 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
			The recipient of a DH public key that fails one of the above tests
			can assume that the sender either is truly malicious or else it has a
			bug in its implementation. The recipient MAY respond with an
			unauthenticated INVALID_SYNTAX notification, and MUST immediately
			drop the IKE SA.
	3. Security Considerations		3. Security Considerations
	This entire document is concerned with the IKEv2 security protocol		This entire document is concerned with the IKEv2 security protocol
	and the need to harden it in some cases.		and the need to harden it in some cases.
	3.1. DH Key Reuse and Multiple Peers		3.1. DH Key Reuse and Multiple Peers
	This section describes the attack prevented by the tests defined		This section describes the attack prevented by the tests defined
	here.		here.
	skipping to change at page 5, line 41 ¶		skipping to change at page 6, line 5 ¶
	One specific type of group would be an even-characteristic elliptic		One specific type of group would be an even-characteristic elliptic
	curve group. Now, these curves have cofactors greater than 1; this		curve group. Now, these curves have cofactors greater than 1; this
	leads to a possibility of some information leakage. There are		leads to a possibility of some information leakage. There are
	several ways to address this information leakage, such as performing		several ways to address this information leakage, such as performing
	a test analogous to the test in section 2.2, or adjusting the ECDH		a test analogous to the test in section 2.2, or adjusting the ECDH
	operation to avoid this leakage (such as "ECC CDH", where the shared		operation to avoid this leakage (such as "ECC CDH", where the shared
	secret really is hxyG). Because the appropriate test depends on how		secret really is hxyG). Because the appropriate test depends on how
	the group is defined, we cannot document it in advance.		the group is defined, we cannot document it in advance.
			3.3. Behavior Upon Test Failure
			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].
			The sender is not required to send back an error notification, and
			the recipient cannot depend on this notification because it is
			unauthenticated. Thus, the notification is only useful to debug
			implementation errors.
			On the other hand, the error notification is secure, in the sense
			that no secret information is leaked. All IKEv2 Diffie-Hellman
			groups are publicly known, and none of the tests defined here depend
			on any secret key. In fact the tests can all be performed by an
			eavesdropper.
	4. IANA Considerations		4. IANA Considerations
	This document requests that IANA should add a column named "Recipient		This document requests that IANA should add a column named "Recipient
	Tests" to the IKEv2 DH Group Transform IDs Registry		Tests" to the IKEv2 DH Group Transform IDs Registry
	[IANA-DH-Registry].		[IANA-DH-Registry].
	This column should initially be populated as per the following table.		This column should initially be populated as per the following table.
	+-----------------------------+---------------------+		+-----------------------------+---------------------+
	| Number | Recipient Tests |		| Number | Recipient Tests |
	skipping to change at page 6, line 23 ¶		skipping to change at page 6, line 46 ¶
	Note to RFC Editor: please replace [current] by the RFC number		Note to RFC Editor: please replace [current] by the RFC number
	assigned to this document.		assigned to this document.
	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.
	5. Acknowledgements		5. 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.		the ipsec mailing list. Thanks to Tero Kivinen and Rene Struik for
			their useful comments.
	The document was prepared using the lyx2rfc tool, created by Nico		The document was prepared using the lyx2rfc tool, created by Nico
	Williams.		Williams.
	6. References		6. References
	6.1. Normative References		6.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.
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 36 ¶
	[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.
	[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.
	[Menezes] Menezes, A. and B. Ostaoglu, "On Reusing Ephemeral Keys In		[Menezes] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In
	Diffie-Hellman Key Agreement Protocols", December 2008, <h		Diffie-Hellman Key Agreement Protocols", December 2008, <h
	ttp://www.cacr.math.uwaterloo.ca/techreports/2008/		ttp://www.cacr.math.uwaterloo.ca/techreports/2008/
	cacr2008-24.pdf>.		cacr2008-24.pdf>.
	[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. -00		A.1. -01
			o Corrected an author's name that was misspelled.
			o Added recipient behavior if a test fails, and the related security
			considerations.
			A.2. -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. 13 change blocks.
	13 lines changed or deleted		46 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/