draft-ietf-ipsecme-ikev2bis-10.txt		draft-ietf-ipsecme-ikev2bis-11.txt
	Network Working Group C. Kaufman		Network Working Group C. Kaufman
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Obsoletes: 4306, 4718 P. Hoffman		Obsoletes: 4306, 4718 P. Hoffman
	(if approved) VPN Consortium		(if approved) VPN Consortium
	Intended status: Standards Track Y. Nir		Intended status: Standards Track Y. Nir
	Expires: October 16, 2010 Check Point		Expires: November 18, 2010 Check Point
	P. Eronen		P. Eronen
	Nokia		Nokia
	April 14, 2010		May 17, 2010
	Internet Key Exchange Protocol: IKEv2		Internet Key Exchange Protocol: IKEv2
	draft-ietf-ipsecme-ikev2bis-10		draft-ietf-ipsecme-ikev2bis-11
	Abstract		Abstract
	This document describes version 2 of the Internet Key Exchange (IKE)		This document describes version 2 of the Internet Key Exchange (IKE)
	protocol. IKE is a component of IPsec used for performing mutual		protocol. IKE is a component of IPsec used for performing mutual
	authentication and establishing and maintaining security associations		authentication and establishing and maintaining security associations
	(SAs). This document replaces and updates RFC 4306, and includes all		(SAs). This document replaces and updates RFC 4306, and includes all
	of the clarifications from RFC 4718.		of the clarifications from RFC 4718.
	Status of this Memo		Status of this Memo
	skipping to change at line 38		skipping to change at line 38
	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 16, 2010.		This Internet-Draft will expire on November 18, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 line 206		skipping to change at line 206
	D.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to		D.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to
	draft-ietf-ipsecme-ikev2bis-06		draft-ietf-ipsecme-ikev2bis-06
	D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to		D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to
	draft-ietf-ipsecme-ikev2bis-07		draft-ietf-ipsecme-ikev2bis-07
	D.15. Changes from draft-ietf-ipsecme-ikev2bis-07 to		D.15. Changes from draft-ietf-ipsecme-ikev2bis-07 to
	draft-ietf-ipsecme-ikev2bis-08		draft-ietf-ipsecme-ikev2bis-08
	D.16. Changes from draft-ietf-ipsecme-ikev2bis-08 to		D.16. Changes from draft-ietf-ipsecme-ikev2bis-08 to
	draft-ietf-ipsecme-ikev2bis-09		draft-ietf-ipsecme-ikev2bis-09
	D.17. Changes from draft-ietf-ipsecme-ikev2bis-09 to		D.17. Changes from draft-ietf-ipsecme-ikev2bis-09 to
	draft-ietf-ipsecme-ikev2bis-10		draft-ietf-ipsecme-ikev2bis-10
			D.18. Changes from draft-ietf-ipsecme-ikev2bis-10 to
			draft-ietf-ipsecme-ikev2bis-11
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	IP Security (IPsec) provides confidentiality, data integrity, access		IP Security (IPsec) provides confidentiality, data integrity, access
	control, and data source authentication to IP datagrams. These		control, and data source authentication to IP datagrams. These
	services are provided by maintaining shared state between the source		services are provided by maintaining shared state between the source
	and the sink of an IP datagram. This state defines, among other		and the sink of an IP datagram. This state defines, among other
	things, the specific services provided to the datagram, which		things, the specific services provided to the datagram, which
	cryptographic algorithms will be used to provide the services, and		cryptographic algorithms will be used to provide the services, and
	skipping to change at line 912		skipping to change at line 914
	that parts of IKEv2 rely on some of the processing rules in		that parts of IKEv2 rely on some of the processing rules in
	[IPSECARCH], as described in various sections of this document.		[IPSECARCH], as described in various sections of 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 [MUSTSHOULD].		document are to be interpreted as described in [MUSTSHOULD].
	1.7. Significant Differences Between RFC 4306 and This Document		1.7. Significant Differences Between RFC 4306 and This Document
	This document contains clarifications and amplifications to IKEv2		This document contains clarifications and amplifications to IKEv2
	[IKEV2]. The clarifications are mostly based on [Clarif]. The		[IKEV2]. Many of the clarifications are based on [Clarif]. The
	changes listed in that document were discussed in the IPsec Working		changes listed in that document were discussed in the IPsec Working
	Group and, after the Working Group was disbanded, on the IPsec		Group and, after the Working Group was disbanded, on the IPsec
	mailing list. That document contains detailed explanations of areas		mailing list. That document contains detailed explanations of areas
	that were unclear in IKEv2, and is thus useful to implementers of		that were unclear in IKEv2, and is thus useful to implementers of
	IKEv2.		IKEv2.
	The protocol described in this document retains the same major		The protocol described in this document retains the same major
	version number (2) and minor version number (0) as was used in RFC		version number (2) and minor version number (0) as was used in RFC
	4306. That is, the version number is *not* changed from RFC 4306.		4306. That is, the version number is *not* changed from RFC 4306.
			The small number of technical changes listed here are not expected to
			affect RFC 4306 implementations that have already been deployed at
			the time of publication of this document.
	This document makes the figures and references a bit more consistent		This document makes the figures and references a bit more consistent
	than they were in [IKEV2].		than they were in [IKEV2].
	IKEv2 developers have noted that the SHOULD-level requirements in RFC		IKEv2 developers have noted that the SHOULD-level requirements in RFC
	4306 are often unclear in that they don't say when it is OK to not		4306 are often unclear in that they don't say when it is OK to not
	obey the requirements. They also have noted that there are MUST-		obey the requirements. They also have noted that there are MUST-
	level requirements that are not related to interoperability. This		level requirements that are not related to interoperability. This
	document has more explanation of some of these requirements. All		document has more explanation of some of these requirements. All
	non-capitalized uses of the words SHOULD and MUST now mean their		non-capitalized uses of the words SHOULD and MUST now mean their
	skipping to change at line 3878		skipping to change at line 3883
	(*) Negotiating an integrity algorithm is mandatory for the		(*) Negotiating an integrity algorithm is mandatory for the
	Encrypted payload format specified in this document. For example,		Encrypted payload format specified in this document. For example,
	[AEAD] specifies additional formats based on authenticated		[AEAD] specifies additional formats based on authenticated
	encryption, in which a separate integrity algorithm is not		encryption, in which a separate integrity algorithm is not
	negotiated.		negotiated.
	3.3.4. Mandatory Transform IDs		3.3.4. Mandatory Transform IDs
	The specification of suites that MUST and SHOULD be supported for		The specification of suites that MUST and SHOULD be supported for
	interoperability has been removed from this document because they are		interoperability has been removed from this document because they are
	likely to change more rapidly than this document evolves.		likely to change more rapidly than this document evolves. At the
			time of publication of this document, [RFC4307] specifies these
			suites, but note that it might be updated in the future, and other
			RFCs might specify different sets of suites.
	An important lesson learned from IKEv1 is that no system should only		An important lesson learned from IKEv1 is that no system should only
	implement the mandatory algorithms and expect them to be the best		implement the mandatory algorithms and expect them to be the best
	choice for all customers.		choice for all customers.
	It is likely that IANA will add additional transforms in the future,		It is likely that IANA will add additional transforms in the future,
	and some users may want to use private suites, especially for IKE		and some users may want to use private suites, especially for IKE
	where implementations should be capable of supporting different		where implementations should be capable of supporting different
	parameters, up to certain size limits. In support of this goal, all		parameters, up to certain size limits. In support of this goal, all
	implementations of IKEv2 SHOULD include a management facility that		implementations of IKEv2 SHOULD include a management facility that
	skipping to change at line 4322		skipping to change at line 4330
	Implementations MUST be capable of being configured to send and		Implementations MUST be capable of being configured to send and
	accept up to four X.509 certificates in support of authentication,		accept up to four X.509 certificates in support of authentication,
	and also MUST be capable of being configured to send and accept the		and also MUST be capable of being configured to send and accept the
	Hash and URL format (with HTTP URLs). Implementations SHOULD be		Hash and URL format (with HTTP URLs). Implementations SHOULD be
	capable of being configured to send and accept Raw RSA keys. If		capable of being configured to send and accept Raw RSA keys. If
	multiple certificates are sent, the first certificate MUST contain		multiple certificates are sent, the first certificate MUST contain
	the public key used to sign the AUTH payload. The other certificates		the public key used to sign the AUTH payload. The other certificates
	may be sent in any order.		may be sent in any order.
	Implementations MUST support the HTTP method for hash-and-URL lookup.		Implementations MUST support the HTTP [HTTP] method for hash-and-URL
	The behavior of other URL methods is not currently specified, and		lookup. The behavior of other URL methods [URLS] is not currently
	such methods SHOULD NOT be used in the absence of a document		specified, and such methods SHOULD NOT be used in the absence of a
	specifying them.		document specifying them.
	3.7. Certificate Request Payload		3.7. Certificate Request Payload
	The Certificate Request Payload, denoted CERTREQ in this document,		The Certificate Request Payload, denoted CERTREQ in this document,
	provides a means to request preferred certificates via IKE and can		provides a means to request preferred certificates via IKE and can
	appear in the IKE_INIT_SA response and/or the IKE_AUTH request.		appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
	Certificate Request payloads MAY be included in an exchange when the		Certificate Request payloads MAY be included in an exchange when the
	sender needs to get the certificate of the receiver.		sender needs to get the certificate of the receiver.
	The Certificate Request Payload is defined as follows:		The Certificate Request Payload is defined as follows:
	skipping to change at line 5646		skipping to change at line 5654
	provide sufficient strength except for use with DES, which is also		provide sufficient strength except for use with DES, which is also
	for historic use only. Implementations should make note of these		for historic use only. Implementations should make note of these
	estimates when establishing policy and negotiating security		estimates when establishing policy and negotiating security
	parameters.		parameters.
	Note that these limitations are on the Diffie-Hellman groups		Note that these limitations are on the Diffie-Hellman groups
	themselves. There is nothing in IKE that prohibits using stronger		themselves. There is nothing in IKE that prohibits using stronger
	groups nor is there anything that will dilute the strength obtained		groups nor is there anything that will dilute the strength obtained
	from stronger groups (limited by the strength of the other algorithms		from stronger groups (limited by the strength of the other algorithms
	negotiated including the PRF). In fact, the extensible framework of		negotiated including the PRF). In fact, the extensible framework of
	IKE encourages the definition of more groups; use of elliptical curve		IKE encourages the definition of more groups; use of elliptic curve
	groups may greatly increase strength using much smaller numbers.		groups may greatly increase strength using much smaller numbers.
	It is assumed that all Diffie-Hellman exponents are erased from		It is assumed that all Diffie-Hellman exponents are erased from
	memory after use.		memory after use.
	The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator		The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator
	has been authenticated. As a result, an implementation of this		has been authenticated. As a result, an implementation of this
	protocol needs to be completely robust when deployed on any insecure		protocol needs to be completely robust when deployed on any insecure
	network. Implementation vulnerabilities, particularly DoS attacks,		network. Implementation vulnerabilities, particularly DoS attacks,
	can be exploited by unauthenticated peers. This issue is		can be exploited by unauthenticated peers. This issue is
	skipping to change at line 5896		skipping to change at line 5904
	Levkowetz, "Extensible Authentication Protocol (EAP)",		Levkowetz, "Extensible Authentication Protocol (EAP)",
	RFC 3748, June 2004.		RFC 3748, June 2004.
	[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, September 2001.		RFC 3168, September 2001.
	[ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher		[ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
	Algorithms", RFC 2451, November 1998.		Algorithms", RFC 2451, November 1998.
			[HTTP] Fielding, et. al., R., "Hypertext Transfer Protocol --
			HTTP/1.1", RFC 2616, June 1999.
	[IKEV2IANA]		[IKEV2IANA]
	"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>.
	[IPSECARCH]		[IPSECARCH]
	Kent, S. and K. Seo, "Security Architecture for the		Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
	[MUSTSHOULD]		[MUSTSHOULD]
	Bradner, S., "Key Words for use in RFCs to indicate		Bradner, S., "Key Words for use in RFCs to indicate
	skipping to change at line 5917		skipping to change at line 5928
	[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography		[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications		Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, February 2003.		Version 2.1", RFC 3447, February 2003.
	[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet		[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
	X.509 Public Key Infrastructure Certificate and		X.509 Public Key Infrastructure Certificate and
	Certificate Revocation List (CRL) Profile", RFC 5280,		Certificate Revocation List (CRL) Profile", RFC 5280,
	May 2008.		May 2008.
			[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in IKEv2",
			RFC 4307, December 2005.
	[UDPENCAPS]		[UDPENCAPS]
	Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.		Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
	Stenberg, "UDP Encapsulation of IPsec ESP Packets",		Stenberg, "UDP Encapsulation of IPsec ESP Packets",
	RFC 3948, January 2005.		RFC 3948, January 2005.
			[URLS] Fielding, et. al., R., "Uniform Resource Identifier (URI):
			Generic Syntax", RFC 3986, January 2005.
	8.2. Informative References		8.2. Informative References
	[AH] Kent, S., "IP Authentication Header", RFC 4302,		[AH] Kent, S., "IP Authentication Header", RFC 4302,
	December 2005.		December 2005.
	[ARCHGUIDEPHIL]		[ARCHGUIDEPHIL]
	Bush, R. and D. Meyer, "Some Internet Architectural		Bush, R. and D. Meyer, "Some Internet Architectural
	Guidelines and Philosophy", RFC 3439, December 2002.		Guidelines and Philosophy", RFC 3439, December 2002.
	[ARCHPRINC]		[ARCHPRINC]
	skipping to change at line 7984		skipping to change at line 8001
	In Appendix B, changed "The strength supplied by group one may not be		In Appendix B, changed "The strength supplied by group one may not be
	sufficient for the mandatory-to-implement encryption algorithm and is		sufficient for the mandatory-to-implement encryption algorithm and is
	here for historic reasons" to "The strength supplied by group 1 may		here for historic reasons" to "The strength supplied by group 1 may
	not be sufficient for typical uses and is here for historic reasons".		not be sufficient for typical uses and is here for historic reasons".
	D.17. Changes from draft-ietf-ipsecme-ikev2bis-09 to		D.17. Changes from draft-ietf-ipsecme-ikev2bis-09 to
	draft-ietf-ipsecme-ikev2bis-10		draft-ietf-ipsecme-ikev2bis-10
	Small editorial changes.		Small editorial changes.
			D.18. Changes from draft-ietf-ipsecme-ikev2bis-10 to
			draft-ietf-ipsecme-ikev2bis-11
			Changes made during IESG review.
			In 1.7, changed "The clarifications are mostly based on [Clarif]" to
			"Many of the clarifications are based on [Clarif]".
			Added to 1.7: The small number of technical changes listed here are
			not expected to affect RFC 4306 implementations that have already
			been deployed at the time of publication of this document.
			Added to 3.3.4: At the time of publication of this document,
			[RFC4307] specifies these suites, but note that it might be updated
			in the future, and other RFCs might specify different sets of suites.
			In 8.1, added normative references for [HTTP], [RFC4307], and [URLS].
			Editorial: changed "elliptical curve" to "elliptic curve".
	Authors' Addresses		Authors' Addresses
	Charlie Kaufman		Charlie Kaufman
	Microsoft		Microsoft
	1 Microsoft Way		1 Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	US		US
	Phone: 1-425-707-3335		Phone: 1-425-707-3335
	Email: charliek@microsoft.com		Email: charliek@microsoft.com
End of changes. 14 change blocks.
	11 lines changed or deleted		48 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/