--- 1/draft-ietf-ipsecme-ikev2bis-09.txt 2010-04-15 01:11:19.000000000 +0200 +++ 2/draft-ietf-ipsecme-ikev2bis-10.txt 2010-04-15 01:11:19.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 10, 2010 Check Point +Expires: October 16, 2010 Check Point P. Eronen Nokia - April 8, 2010 + April 14, 2010 Internet Key Exchange Protocol: IKEv2 - draft-ietf-ipsecme-ikev2bis-09 + draft-ietf-ipsecme-ikev2bis-10 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 10, 2010. + This Internet-Draft will expire on October 16, 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 @@ -194,20 +194,22 @@ D.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to draft-ietf-ipsecme-ikev2bis-05 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 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 @@ -528,24 +530,24 @@ <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} The responder asserts its identity with the IDr payload, optionally sends one or more certificates (again with the certificate containing the public key used to verify AUTH listed first), authenticates its identity and protects the integrity of the second message with the AUTH payload, and completes negotiation of a Child SA with the additional fields described below in the CREATE_CHILD_SA exchange. - Both parties in the IKE_SA_INIT exchange MUST verify that all - signatures and MACs are computed correctly. If either side uses a - shared secret for authentication, the names in the ID payload MUST - correspond to the key used to generate the AUTH payload. + Both parties in the IKE_AUTH exchange MUST verify that all signatures + and MACs are computed correctly. If either side uses a shared secret + for authentication, the names in the ID payload MUST correspond to + the key used to generate the AUTH payload. Because the initiator sends its Diffie-Hellman value in the IKE_SA_INIT, it must guess the Diffie-Hellman group that the responder will select from its list of supported groups. If the initiator guesses wrong, the responder will respond with a Notify payload of type INVALID_KE_PAYLOAD indicating the selected group. In this case, the initiator MUST retry the IKE_SA_INIT with the corrected Diffie-Hellman group. The initiator MUST again propose its full set of acceptable cryptographic suites because the rejection message was unauthenticated and otherwise an active attacker could @@ -1428,22 +1430,22 @@ not know the responder's SPI value and will therefore set that field to zero. When the IKE_SA_INIT exchange does not result in the creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, or COOKIE (see Section 2.6), the responder's SPI will be zero also in the response message. However, if the responder sends a non-zero responder SPI, the initiator should not reject the response for only that reason. Two expected attacks against IKE are state and CPU exhaustion, where the target is flooded with session initiation requests from forged IP - addresses. This attack can be made less effective a responder uses - minimal CPU and commits no state to an SA until it knows the + addresses. These attack can be made less effective if a responder + uses minimal CPU and commits no state to an SA until it knows the initiator can receive packets at the address from which it claims to be sending them. When a responder detects a large number of half-open IKE SAs, it SHOULD reply to IKE_SA_INIT requests with a response containing the COOKIE notification. The data associated with this notification MUST be between 1 and 64 octets in length (inclusive), and its generation is described later in this section. If the IKE_SA_INIT response includes the COOKIE notification, the initiator MUST then retry the IKE_SA_INIT request, and include the COOKIE notification containing @@ -2684,21 +2686,21 @@ this. The initiator MAY, of course, for reasons of policy later delete such an IKE SA. In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately following it (in case an error happened when processing a response to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and AUTHENTICATION_FAILED notifications are the only ones to cause the IKE SA to be deleted or not created, without a DELETE payload. Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer has been shown to - understand them using the Vendor ID payload. + understand them, such as by using the Vendor ID payload. 2.21.3. Error Handling after IKE SA is Authenticated After the IKE SA is authenticated all requests having errors MUST result in a response notifying about the error. In normal situations, there should not be cases where a valid response from one peer results in an error situation in the other peer, so there should not be any reason for a peer to send error messages to the other end except as a response. Because sending such @@ -2871,27 +2873,28 @@ Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec endpoint that discovers a NAT between it and its correspondent (as described below) MUST send all subsequent traffic from port 4500, which NATs should not treat specially (as they might with port 500). An initiator can use port 4500 for both IKE and ESP, regardless of whether or not there is a NAT, even at the beginning of IKE. When either side is using port 4500, sending ESP with UDP encapsulation is not required, but understanding received UDP encapsulated ESP packets - is required. If NAT-T is supported (that is, if NAT_DETECTION_*_IP - payloads were exchanged during IKE_SA_INIT), all devices MUST be able - to receive and process both UDP encapsulated ESP and non-UDP - encapsulated ESP packets at any time. Either side can decide whether - or not to use UDP encapsulation for ESP irrespective of the choice - made by the other side. However, if a NAT is detected, both devices - MUST use UDP encapsulation for ESP. + is required. UDP encapsulation MUST NOT be done on port 500. If + NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were + exchanged during IKE_SA_INIT), all devices MUST be able to receive + and process both UDP encapsulated ESP and non-UDP encapsulated ESP + packets at any time. Either side can decide whether or not to use + UDP encapsulation for ESP irrespective of the choice made by the + other side. However, if a NAT is detected, both devices MUST use UDP + encapsulation for ESP. The specific requirements for supporting NAT traversal [NATREQ] are listed below. Support for NAT traversal is optional. In this section only, requirements listed as MUST apply only to implementations supporting NAT traversal. o Both IKE initiator and responder MUST include in their IKE_SA_INIT packets Notify payloads of type NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP. Those payloads can be used to detect if there is NAT between the hosts, and which end is behind @@ -3071,21 +3074,21 @@ sent by the other end. This address substitution in transport mode is needed because the SPD is looked up using the addresses that will be seen by the local host. This also will make sure the SAD entries for the tunnel exit checks and return packets is added using the addresses as seen by the local operating system stack. The most common case is that the server's SPD will contain wildcard entries matching any addresses, but this allows also making different - SPD entries, for example, for different known NAT's outer addresses. + SPD entries, for example, for different known NATs' outer addresses. After the SPD lookup, the server will do traffic selector narrowing based on the SPD entry it found. It will again use the already- substituted traffic selectors, and it will thus send back traffic selectors having IPN1 and IP2 as their IP addresses; it can still narrow down the protocol number or port ranges used by the traffic selectors. The SAD entry created for the Child SA will have the addresses as seen by the server, namely IPN1 and IP2. When the client receives the server's response to the Child SA, it @@ -3194,21 +3197,21 @@ wait so that the sender may complete whatever operation caused the temporary condition. The recipient MAY retry the request one or more times over a period of several minutes. If a peer continues to receive TEMPORARY_FAILURE on the same IKE SA after several minutes, it SHOULD conclude that the state information is out-of-sync and close the IKE SA. A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist. The SA that the initiator attempted to rekey is indicated by the SPI field in the - Notify Payload, which is copied from the SPI field in the REYEY_SA + Notify Payload, which is copied from the SPI field in the REKEY_SA notification. A peer that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA (if it still exists) and send a request to create a new Child SA from scratch (if the Child SA does not yet exist). 2.25.1. Collisions While Rekeying or Closing Child SAs If a peer receives a request to rekey a Child SA that it is currently trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer receives a request to rekey a Child SA that it is currently rekeying, @@ -3667,24 +3670,24 @@ publication of this document. Readers should refer to [IKEV2IANA] for the latest values. Protocol Protocol ID ----------------------------------- IKE 1 AH 2 ESP 3 o SPI Size (1 octet) - For an initial IKE SA negotiation, this field - MUST be zero; the SPI is obtained from the outer IP header. - During subsequent negotiations, it is equal to the size, in - octets, of the SPI of the corresponding protocol (8 for IKE, 4 for - ESP and AH). + MUST be zero; the SPI is obtained from the outer header. During + subsequent negotiations, it is equal to the size, in octets, of + the SPI of the corresponding protocol (8 for IKE, 4 for ESP and + AH). o Num Transforms (1 octet) - Specifies the number of transforms in this proposal. o SPI (variable) - The sending entity's SPI. Even if the SPI Size is not a multiple of 4 octets, there is no padding applied to the payload. When the SPI Size field is zero, this field is not present in the Security Association payload. o Transforms (variable) - One or more transform substructures. @@ -5515,21 +5518,21 @@ interoperate, there are "MUST support" requirements in addition to those listed elsewhere. Of course, IKEv2 is a security protocol, and one of its major functions is to allow only authorized parties to successfully complete establishment of SAs. So a particular implementation may be configured with any of a number of restrictions concerning algorithms and trusted authorities that will prevent universal interoperability. IKEv2 is designed to permit minimal implementations that can interoperate with all compliant implementations. The following are - some of the features that can be omitted in a minimal implementation: + features that can be omitted in a minimal implementation: o Ability to negotiate SAs through a NAT and tunnel the resulting ESP SA over UDP. o Ability to request (and respond to a request for) a temporary IP address on the remote end of a tunnel. o Ability to support EAP-based authentication. o Ability to support window sizes greater than one. @@ -5806,21 +5809,21 @@ Types table: INTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRY. Two new additions to the IKEv2 parameters "NOTIFY MESSAGES - ERROR TYPES" registry are defined here that were not defined in [IKEV2]: {TBA1} TEMPORARY_FAILURE {TBA2} CHILD_SA_NOT_FOUND IANA should change the exiting IKEv2 Payload Types table from: - 46 Encrypted E [RFC4306] + 46 Encrypted E [IKEv2] to 46 Encrypted and Authenticated SK [This document] IANA should update all references to RFC 4306 to point to this document. 7. Acknowledgements @@ -7966,20 +7969,25 @@ some of the features that can be omitted in a minimal implementation:". In the references, moved [AEAD] from informative to normative. 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. + Authors' Addresses Charlie Kaufman Microsoft 1 Microsoft Way Redmond, WA 98052 US Phone: 1-425-707-3335 Email: charliek@microsoft.com