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