--- 1/draft-ietf-ipsecme-ikev2bis-10.txt 2010-05-17 23:12:00.000000000 +0200 +++ 2/draft-ietf-ipsecme-ikev2bis-11.txt 2010-05-17 23:12:00.000000000 +0200 @@ -1,23 +1,23 @@ Network Working Group C. Kaufman Internet-Draft Microsoft Obsoletes: 4306, 4718 P. Hoffman (if approved) VPN Consortium Intended status: Standards Track Y. Nir -Expires: October 16, 2010 Check Point +Expires: November 18, 2010 Check Point P. Eronen Nokia - April 14, 2010 + May 17, 2010 Internet Key Exchange Protocol: IKEv2 - draft-ietf-ipsecme-ikev2bis-10 + draft-ietf-ipsecme-ikev2bis-11 Abstract This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. Status of this Memo @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -196,20 +196,22 @@ D.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to draft-ietf-ipsecme-ikev2bis-06 D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to draft-ietf-ipsecme-ikev2bis-07 D.15. Changes from draft-ietf-ipsecme-ikev2bis-07 to draft-ietf-ipsecme-ikev2bis-08 D.16. Changes from draft-ietf-ipsecme-ikev2bis-08 to draft-ietf-ipsecme-ikev2bis-09 D.17. Changes from draft-ietf-ipsecme-ikev2bis-09 to draft-ietf-ipsecme-ikev2bis-10 + D.18. Changes from draft-ietf-ipsecme-ikev2bis-10 to + draft-ietf-ipsecme-ikev2bis-11 Authors' Addresses 1. Introduction IP Security (IPsec) provides confidentiality, data integrity, access control, and data source authentication to IP datagrams. These services are provided by maintaining shared state between the source and the sink of an IP datagram. This state defines, among other things, the specific services provided to the datagram, which cryptographic algorithms will be used to provide the services, and @@ -902,30 +904,33 @@ that parts of IKEv2 rely on some of the processing rules in [IPSECARCH], as described in various sections of this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [MUSTSHOULD]. 1.7. Significant Differences Between RFC 4306 and This Document 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 Group and, after the Working Group was disbanded, on the IPsec mailing list. That document contains detailed explanations of areas that were unclear in IKEv2, and is thus useful to implementers of IKEv2. The protocol described in this document retains the same major 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. + 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 than they were in [IKEV2]. 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 obey the requirements. They also have noted that there are MUST- level requirements that are not related to interoperability. This document has more explanation of some of these requirements. All non-capitalized uses of the words SHOULD and MUST now mean their @@ -3868,21 +3873,24 @@ (*) Negotiating an integrity algorithm is mandatory for the Encrypted payload format specified in this document. For example, [AEAD] specifies additional formats based on authenticated encryption, in which a separate integrity algorithm is not negotiated. 3.3.4. Mandatory Transform IDs The specification of suites that MUST and SHOULD be supported for 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 implement the mandatory algorithms and expect them to be the best choice for all customers. It is likely that IANA will add additional transforms in the future, and some users may want to use private suites, especially for IKE where implementations should be capable of supporting different parameters, up to certain size limits. In support of this goal, all implementations of IKEv2 SHOULD include a management facility that @@ -4312,24 +4320,24 @@ Implementations MUST be capable of being configured to send and accept up to four X.509 certificates in support of authentication, and also MUST be capable of being configured to send and accept the Hash and URL format (with HTTP URLs). Implementations SHOULD be capable of being configured to send and accept Raw RSA keys. If multiple certificates are sent, the first certificate MUST contain the public key used to sign the AUTH payload. The other certificates may be sent in any order. - Implementations MUST support the HTTP method for hash-and-URL lookup. - The behavior of other URL methods is not currently specified, and - such methods SHOULD NOT be used in the absence of a document - specifying them. + Implementations MUST support the HTTP [HTTP] method for hash-and-URL + lookup. The behavior of other URL methods [URLS] is not currently + specified, and such methods SHOULD NOT be used in the absence of a + document specifying them. 3.7. Certificate Request Payload The Certificate Request Payload, denoted CERTREQ in this document, provides a means to request preferred certificates via IKE and can appear in the IKE_INIT_SA response and/or the IKE_AUTH request. Certificate Request payloads MAY be included in an exchange when the sender needs to get the certificate of the receiver. The Certificate Request Payload is defined as follows: @@ -5636,21 +5644,21 @@ provide sufficient strength except for use with DES, which is also for historic use only. Implementations should make note of these estimates when establishing policy and negotiating security parameters. Note that these limitations are on the Diffie-Hellman groups themselves. There is nothing in IKE that prohibits using stronger groups nor is there anything that will dilute the strength obtained from stronger groups (limited by the strength of the other algorithms 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. It is assumed that all Diffie-Hellman exponents are erased from memory after use. The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator has been authenticated. As a result, an implementation of this protocol needs to be completely robust when deployed on any insecure network. Implementation vulnerabilities, particularly DoS attacks, can be exploited by unauthenticated peers. This issue is @@ -5886,20 +5894,23 @@ Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. + [HTTP] Fielding, et. al., R., "Hypertext Transfer Protocol -- + HTTP/1.1", RFC 2616, June 1999. + [IKEV2IANA] "Internet Key Exchange Version 2 (IKEv2) Parameters", . [IPSECARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [MUSTSHOULD] Bradner, S., "Key Words for use in RFCs to indicate @@ -5907,25 +5918,31 @@ [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. + [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in IKEv2", + RFC 4307, December 2005. + [UDPENCAPS] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. + [URLS] Fielding, et. al., R., "Uniform Resource Identifier (URI): + Generic Syntax", RFC 3986, January 2005. + 8.2. Informative References [AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [ARCHGUIDEPHIL] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002. [ARCHPRINC] @@ -7974,20 +7991,40 @@ In Appendix B, changed "The strength supplied by group one may not be sufficient for the mandatory-to-implement encryption algorithm and is here for historic reasons" to "The strength supplied by group 1 may not be sufficient for typical uses and is here for historic reasons". D.17. Changes from draft-ietf-ipsecme-ikev2bis-09 to draft-ietf-ipsecme-ikev2bis-10 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 Charlie Kaufman Microsoft 1 Microsoft Way Redmond, WA 98052 US Phone: 1-425-707-3335 Email: charliek@microsoft.com