draft-ietf-ipsecme-dh-checks-01.txt		draft-ietf-ipsecme-dh-checks-02.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 4, 2013 April 2, 2013		Expires: October 22, 2013 April 20, 2013
	Additional Diffie-Hellman Tests for IKEv2		Additional Diffie-Hellman Tests for IKEv2
	draft-ietf-ipsecme-dh-checks-01		draft-ietf-ipsecme-dh-checks-02
	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 4, 2013.		This Internet-Draft will expire on October 22, 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
	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
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . 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. Sophie Germain Prime MODP Groups . . . . . . . . . . . 3
	2.2. MODP Groups with Small Subgroups . . . . . . . . . . . 3		2.2. MODP Groups with Small Subgroups . . . . . . . . . . . 4
	2.3. Elliptic Curve Groups . . . . . . . . . . . . . . . . . 4		2.3. Elliptic Curve Groups . . . . . . . . . . . . . . . . 4
	2.4. Transition . . . . . . . . . . . . . . . . . . . . . . 4		2.4. Transition . . . . . . . . . . . . . . . . . . . . . . 5
	2.5. Protocol Behavior . . . . . . . . . . . . . . . . . . . 5		2.5. Protocol Behavior . . . . . . . . . . . . . . . . . . 5
	3. Security Considerations . . . . . . . . . . . . . . . . 5		3. Side-Channel Attacks . . . . . . . . . . . . . . . . . 5
	3.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . 6
	3.2. Groups not covered by this RFC . . . . . . . . . . . . 5		4.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . 6
	3.3. Behavior Upon Test Failure . . . . . . . . . . . . . . 6		4.2. DH Key Reuse: Variants . . . . . . . . . . . . . . . . 7
	4. IANA Considerations . . . . . . . . . . . . . . . . . . 6		4.3. Groups not covered by this RFC . . . . . . . . . . . . 7
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . 6		4.4. Behavior Upon Test Failure . . . . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . 8
	6.1. Normative References . . . . . . . . . . . . . . . . . 7		6. Acknowledgements . . . . . . . . . . . . . . . . . . . 8
	6.2. Informative References . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . 9
	Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 7		7.1. Normative References . . . . . . . . . . . . . . . . . 9
	A.1. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . 8		7.2. Informative References . . . . . . . . . . . . . . . . 9
	A.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . 8		Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . 8		A.1. -02 . . . . . . . . . . . . . . . . . . . . . . . . . 10
			A.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . 10
			A.3. -00 . . . . . . . . . . . . . . . . . . . . . . . . . 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 3.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 groups whose use is becoming ever more popular. This
	document defines such tests for several types of DH groups.		document defines such tests for several types of DH groups.
			In addition, this document describes another potential attack related
			to reuse of DH keys: a timing attack. This additional material is
			taken from [RFC2412].
	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
	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 secret keys (as defined in [RFC5996], Sec. 2.12). The tests
	are listed here according to the DH group being used.		apply to the recipient of a KE payload, and describe how it should
			check the received payload. They are listed here according to the DH
			group being used.
	2.1. Regular 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.
	See Section 4 for the specific groups covered by this section.		See Section 5 for the specific groups covered by this section.
	2.2. MODP Groups with Small Subgroups		2.2. MODP Groups with Small Subgroups
	[RFC5114] defines modular exponential groups with small subgroups;		[RFC5114] defines modular exponential groups with small subgroups;
	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
	skipping to change at page 4, line 29		skipping to change at page 4, line 35
	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 4 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, it is not the point-
	at-infinity, and that the x and y parameters from the peer's public		at-infinity, and that the x and y parameters from the peer's public
	value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod p		value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod p
	(where for groups 19, 20, 21, a=-3, and all other values of a, b and		(where for groups 19, 20, 21, a=-3 (mod p), and all other values of
	p for the group are listed in the RFC).		a, b and p for the group are listed in the RFC).
	See Section 4 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, if they do not		include the tests described in the current document, even if they do
	reuse DH keys with multiple peers. The tests can be considered as		not reuse DH keys. The tests can be considered as sanity checks, and
	sanity checks, and will prevent the code having to handle inputs that		will prevent the code having to handle inputs that it may not have
	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 either is truly malicious or else it has a		can assume that the sender is either truly malicious or else it has a
	bug in its implementation. The recipient MAY respond with an		bug in its implementation.
	unauthenticated INVALID_SYNTAX notification, and MUST immediately
	drop the IKE SA.
	3. Security Considerations		If this error happens during the IKE_SA_INIT exchange, then the
			recipient MUST drop the message that contains an invalid KE payload,
			and MUST NOT use that message when creating the IKE SA.
			If the implementation implements the DoS-resistant behavior proposed
			in Sec. 2.4 of [RFC5996], it may simply ignore the erroneous request
			or response message, and continue waiting for a later message
			containing a legitimate KE payload.
			If DoS-resistant behavior is not implemented, and the invalid KE
			payload was in the IKE_SA_INIT request, the implementation MAY send
			an INVALID_SYNTAX error notification back, and remove the in-progress
			IKE SA; if the invalid KE payload was in the IKE_SA_INIT response,
			then the implementation MAY simply delete the half created IKE SA,
			and re-initiate the exchange.
			If the invalid KE payload is received during the CREATE_CHILD_SA
			exchange (or any other exchange after the IKE SA has been
			established) and the invalid KE payload is in the request message,
			the Responder MUST reply with an INVALID_SYNTAX error notification
			and drop the IKE SA. If the invalid KE payload is in a response, the
			Initiator getting this reply MUST immediately delete the IKE SA by
			sending an IKE SA Delete notification as a new exchange. In this
			case the sender evidently has an implementation bug, and dropping the
			IKE SA makes it easier to detect.
			3. Side-Channel Attacks
			In addition to the small-subgroup attack, there is also a potential
			timing attack on IKE peers when they are reusing Diffie-Hellman
			secret values. This is a side-channel attack, which means that it
			may or may not be a vulnerability in certain cases, depending on
			implementation details and the threat model.
			The remainder of this section is quoted from [RFC2412], Sec. 5, with
			a few minor clarifications. This attack still applies to IKEv2
			implementations, and both to MODP groups and ECDH groups. We also
			note that more efficient countermeasures are available for ECC groups
			represented in projective form, but these are outside the scope of
			the current document.
			Timing attacks that are capable of recovering the exponent value used
			in Diffie-Hellman calculations have been described by Paul Kocher
			[Kocher]. In order to nullify the attack, implementors must take
			pains to obscure the sequence of operations involved in carrying out
			modular exponentiations.
			One potential method to foil these timing attacks is to use a
			"blinding factor". In this method, a group element, r, is chosen at
			random, and its multiplicative inverse modulo p is computed, which
			we'll call r_inv. r_inv can be computed by the Extended Euclidean
			Method, using r and p as inputs. When an exponent x is chosen, the
			value r_inv^x is also calculated. Then, when calculating (g^y)^x,
			the implementation will calculate this sequence:
			A = r*g^y
			B = A^x = (r*g^y)^x = (r^x)(g^(xy))
			C = B*r_inv^x = (r^x)(r^(-1*x))(g^(xy)) = g^(xy)
			The blinding factor is only necessary if the exponent x is used more
			than 100 times (estimate by Richard Schroeppel).
			4. 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		4.1. DH Key Reuse and Multiple Peers
	This section describes the attack prevented by the tests defined		This section describes one variant of the attack prevented by the
	here.		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 secret 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.
	3.2. Groups not covered by this RFC		4.2. DH Key Reuse: Variants
			Private DH keys can be reused in different ways, with subtly
			different security implications. For example:
			1. DH keys are reused for multiple connections (IKE SAs) to the same
			peer, and for connections to different peers.
			2. DH keys are reused for multiple connections to the same peer
			(e.g. when the peer is identified by its IP address) but not for
			different peers.
			3. DH keys are reused only when they had not been used to complete
			an exchange, e.g. when the peer replies with an
			INVALID_KE_PAYLOAD notification.
			Both the small subgroup attack and the timing attack described in
			this document apply at least to options #1 and #2.
			4.3. Groups not covered by this RFC
	There are a number of group types that are not specifically addressed		There are a number of group types that are not specifically addressed
	by this RFC. A document that defines such a group MUST describe the		by this RFC. A document that defines such a group MUST describe the
	tests required by that group.		tests required by that group.
	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		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. Thus, the notification is only useful to debug		unauthenticated, and may in fact have been sent by an attacker trying
	implementation errors.		to DoS the connection. Thus, the notification is only useful to
			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 no secret information is leaked. All IKEv2 Diffie-Hellman		that no secret information is leaked. All IKEv2 Diffie-Hellman
	groups are publicly known, and none of the tests defined here depend		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		on any secret key. In fact the tests can all be performed by an
	eavesdropper.		eavesdropper.
	4. IANA Considerations		The situation when the failure occurs in the Create Child SA exchange
			is different, since everything is protected by an IKE SA. The peers
			are authenticated, and error notifications can be relied on. See
			Sec. 2.21.3 of [RFC5996] for more details on error handling in this
			case.
			5. 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 43		skipping to change at page 8, line 36
	| 19, 20, 21, 25, 26 | [current], Sec. 2.3 |		| 19, 20, 21, 25, 26 | [current], Sec. 2.3 |
	+-----------------------------+---------------------+		+-----------------------------+---------------------+
	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		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.
	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		7. References
			7.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.
	[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.
	6.2. Informative References		7.2. Informative References
			[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
			RFC 2412, November 1998.
	[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)		[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
	Diffie-Hellman groups for Internet Key Exchange (IKE)",		Diffie-Hellman groups for Internet Key Exchange (IKE)",
	RFC 3526, May 2003.		RFC 3526, May 2003.
	[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman		[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman
	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.
	[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-
			Hellman, RSA, DSS, and Other Systems", December 1996,
			<http://www.cryptography.com/timingattack/paper.html>.
	[Menezes] Menezes, A. and B. Ustaoglu, "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. -01		A.1. -02
			o Based on Tero's review: Improved the protocol behavior, and
			mentioned that these checks apply to Create Child SA. Added a
			discussion of DH timing attacks, stolen from RFC 2412.
			A.2. -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.2. -00		A.3. -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. 27 change blocks.
	56 lines changed or deleted		161 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/