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/