draft-ietf-ipsecme-ikev2bis-08.txt   draft-ietf-ipsecme-ikev2bis-09.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: August 30, 2010 Check Point Expires: October 10, 2010 Check Point
P. Eronen P. Eronen
Nokia Nokia
February 26, 2010 April 8, 2010
Internet Key Exchange Protocol: IKEv2 Internet Key Exchange Protocol: IKEv2
draft-ietf-ipsecme-ikev2bis-08 draft-ietf-ipsecme-ikev2bis-09
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
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 10, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
skipping to change at line 208 skipping to change at line 202
D.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to D.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to
draft-ietf-ipsecme-ikev2bis-04 draft-ietf-ipsecme-ikev2bis-04
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
draft-ietf-ipsecme-ikev2bis-09
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 248 skipping to change at line 244
to protect the traffic that they carry. In this document, the term to protect the traffic that they carry. In this document, the term
"suite" or "cryptographic suite" refers to a complete set of "suite" or "cryptographic suite" refers to a complete set of
algorithms used to protect an SA. An initiator proposes one or more algorithms used to protect an SA. An initiator proposes one or more
suites by listing supported algorithms that can be combined into suites by listing supported algorithms that can be combined into
suites in a mix-and-match fashion. IKE can also negotiate use of IP suites in a mix-and-match fashion. IKE can also negotiate use of IP
Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA. Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA.
The SAs for ESP or AH that get set up through that IKE SA we call The SAs for ESP or AH that get set up through that IKE SA we call
"Child SAs". "Child SAs".
All IKE communications consist of pairs of messages: a request and a All IKE communications consist of pairs of messages: a request and a
response. The pair is called an "exchange". We call the first response. The pair is called an "exchange", and is sometimes called
messages establishing an IKE SA IKE_SA_INIT and IKE_AUTH exchanges "request/response pair". The first exchange of messages establishing
and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL an IKE SA are called the IKE_SA_INIT and IKE_AUTH exchanges;
exchanges. In the common case, there is a single IKE_SA_INIT subsequent IKE exchanges are called the CREATE_CHILD_SA or
exchange and a single IKE_AUTH exchange (a total of four messages) to INFORMATIONAL exchanges. In the common case, there is a single
establish the IKE SA and the first Child SA. In exceptional cases, IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four
there may be more than one of each of these exchanges. In all cases, messages) to establish the IKE SA and the first Child SA. In
all IKE_SA_INIT exchanges MUST complete before any other exchange exceptional cases, there may be more than one of each of these
type, then all IKE_AUTH exchanges MUST complete, and following that exchanges. In all cases, all IKE_SA_INIT exchanges MUST complete
any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur before any other exchange type, then all IKE_AUTH exchanges MUST
in any order. In some scenarios, only a single Child SA is needed complete, and following that any number of CREATE_CHILD_SA and
between the IPsec endpoints, and therefore there would be no INFORMATIONAL exchanges may occur in any order. In some scenarios,
additional exchanges. Subsequent exchanges MAY be used to establish only a single Child SA is needed between the IPsec endpoints, and
additional Child SAs between the same authenticated pair of endpoints therefore there would be no additional exchanges. Subsequent
and to perform housekeeping functions. exchanges MAY be used to establish additional Child SAs between the
same authenticated pair of endpoints and to perform housekeeping
functions.
An IKE message flow always consists of a request followed by a An IKE message flow always consists of a request followed by a
response. It is the responsibility of the requester to ensure response. It is the responsibility of the requester to ensure
reliability. If the response is not received within a timeout reliability. If the response is not received within a timeout
interval, the requester needs to retransmit the request (or abandon interval, the requester needs to retransmit the request (or abandon
the connection). the connection).
The first request/response of an IKE session (IKE_SA_INIT) negotiates The first exchange of an IKE session, IKE_SA_INIT, negotiates
security parameters for the IKE SA, sends nonces, and sends Diffie- security parameters for the IKE SA, sends nonces, and sends Diffie-
Hellman values. Hellman values.
The second request/response (IKE_AUTH) transmits identities, proves The second exchange, IKE_AUTH, transmits identities, proves knowledge
knowledge of the secrets corresponding to the two identities, and of the secrets corresponding to the two identities, and sets up an SA
sets up an SA for the first (and often only) AH or ESP Child SA for the first (and often only) AH or ESP Child SA (unless there is
(unless there is failure setting up the AH or ESP Child SA, in which failure setting up the AH or ESP Child SA, in which case the IKE SA
case the IKE SA is still established without the Child SA). is still established without the Child SA).
The types of subsequent exchanges are CREATE_CHILD_SA (which creates The types of subsequent exchanges are CREATE_CHILD_SA (which creates
a Child SA) and INFORMATIONAL (which deletes an SA, reports error a Child SA) and INFORMATIONAL (which deletes an SA, reports error
conditions, or does other housekeeping). Every request requires a conditions, or does other housekeeping). Every request requires a
response. An INFORMATIONAL request with no payloads (other than the response. An INFORMATIONAL request with no payloads (other than the
empty Encrypted payload required by the syntax) is commonly used as a empty Encrypted payload required by the syntax) is commonly used as a
check for liveness. These subsequent exchanges cannot be used until check for liveness. These subsequent exchanges cannot be used until
the initial exchanges have completed. the initial exchanges have completed.
In the description that follows, we assume that no errors occur. In the description that follows, we assume that no errors occur.
Modifications to the flow should errors occur are described in Modifications to the flow when errors occur are described in
Section 2.21. Section 2.21.
1.1. Usage Scenarios 1.1. Usage Scenarios
IKE is expected to be used to negotiate ESP or AH SAs in a number of IKE is used to negotiate ESP or AH SAs in a number of different
different scenarios, each with its own special requirements. scenarios, each with its own special requirements.
1.1.1. Security Gateway to Security Gateway Tunnel Mode 1.1.1. Security Gateway to Security Gateway Tunnel Mode
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | IPsec | | | | IPsec | |
Protected |Tunnel | tunnel |Tunnel | Protected Protected |Tunnel | tunnel |Tunnel | Protected
Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
skipping to change at line 389 skipping to change at line 387
security gateway (i.e., the address that will get traffic routed to security gateway (i.e., the address that will get traffic routed to
the security gateway for forwarding to the endpoint). The outer the security gateway for forwarding to the endpoint). The outer
destination address will always be that of the security gateway, destination address will always be that of the security gateway,
while the inner destination address will be the ultimate destination while the inner destination address will be the ultimate destination
for the packet. for the packet.
In this scenario, it is possible that the protected endpoint will be In this scenario, it is possible that the protected endpoint will be
behind a NAT. In that case, the IP address as seen by the security behind a NAT. In that case, the IP address as seen by the security
gateway will not be the same as the IP address sent by the protected gateway will not be the same as the IP address sent by the protected
endpoint, and packets will have to be UDP encapsulated in order to be endpoint, and packets will have to be UDP encapsulated in order to be
routed properly. routed properly. Interaction with NATs is covered in detail in
Section 2.23.
1.1.4. Other Scenarios 1.1.4. Other Scenarios
Other scenarios are possible, as are nested combinations of the Other scenarios are possible, as are nested combinations of the
above. One notable example combines aspects of 1.1.1 and 1.1.3. A above. One notable example combines aspects of 1.1.1 and 1.1.3. A
subnet may make all external accesses through a remote security subnet may make all external accesses through a remote security
gateway using an IPsec tunnel, where the addresses on the subnet are gateway using an IPsec tunnel, where the addresses on the subnet are
routed to the security gateway by the rest of the Internet. An routed to the security gateway by the rest of the Internet. An
example would be someone's home network being virtually on the example would be someone's home network being virtually on the
Internet with static IP addresses even though connectivity is Internet with static IP addresses even though connectivity is
skipping to change at line 436 skipping to change at line 435
protected using the cryptographic algorithms and keys negotiated in protected using the cryptographic algorithms and keys negotiated in
the IKE_SA_INIT exchange. These subsequent messages use the syntax the IKE_SA_INIT exchange. These subsequent messages use the syntax
of the Encrypted Payload described in Section 3.14, encrypted with of the Encrypted Payload described in Section 3.14, encrypted with
keys that are derived as described in Section 2.14. All subsequent keys that are derived as described in Section 2.14. All subsequent
messages include an Encrypted Payload, even if they are referred to messages include an Encrypted Payload, even if they are referred to
in the text as "empty". For the CREATE_CHILD_SA, IKE_AUTH, or in the text as "empty". For the CREATE_CHILD_SA, IKE_AUTH, or
INFORMATIONAL exchanges, the message following the header is INFORMATIONAL exchanges, the message following the header is
encrypted and the message including the header is integrity protected encrypted and the message including the header is integrity protected
using the cryptographic algorithms negotiated for the IKE SA. using the cryptographic algorithms negotiated for the IKE SA.
Every IKE message contains a Message ID as part of its fixed header.
This Message ID is used to match up requests and responses, and to
identify retransmissions of messages.
In the following descriptions, the payloads contained in the message In the following descriptions, the payloads contained in the message
are indicated by names as listed below. are indicated by names as listed below.
Notation Payload Notation Payload
----------------------------------------- -----------------------------------------
AUTH Authentication AUTH Authentication
CERT Certificate CERT Certificate
CERTREQ Certificate Request CERTREQ Certificate Request
CP Configuration CP Configuration
D Delete D Delete
skipping to change at line 489 skipping to change at line 492
offered choices and expresses that choice in the SAr1 payload, offered choices and expresses that choice in the SAr1 payload,
completes the Diffie-Hellman exchange with the KEr payload, and sends completes the Diffie-Hellman exchange with the KEr payload, and sends
its nonce in the Nr payload. its nonce in the Nr payload.
At this point in the negotiation, each party can generate SKEYSEED, At this point in the negotiation, each party can generate SKEYSEED,
from which all keys are derived for that IKE SA. The messages that from which all keys are derived for that IKE SA. The messages that
follow are encrypted and integrity protected in their entirety, with follow are encrypted and integrity protected in their entirety, with
the exception of the message headers. The keys used for the the exception of the message headers. The keys used for the
encryption and integrity protection are derived from SKEYSEED and are encryption and integrity protection are derived from SKEYSEED and are
known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity
protection). A separate SK_e and SK_a is computed for each protection); see Section 2.13 and Section 2.14 for details on the key
direction. In addition to the keys SK_e and SK_a derived from the DH derivation. A separate SK_e and SK_a is computed for each direction.
In addition to the keys SK_e and SK_a derived from the Diffie-Hellman
value for protection of the IKE SA, another quantity SK_d is derived value for protection of the IKE SA, another quantity SK_d is derived
and used for derivation of further keying material for Child SAs. and used for derivation of further keying material for Child SAs.
The notation SK { ... } indicates that these payloads are encrypted The notation SK { ... } indicates that these payloads are encrypted
and integrity protected using that direction's SK_e and SK_a. and integrity protected using that direction's SK_e and SK_a.
HDR, SK {IDi, [CERT,] [CERTREQ,] HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, [IDr,] AUTH, SAi2,
TSi, TSr} --> TSi, TSr} -->
The initiator asserts its identity with the IDi payload, proves The initiator asserts its identity with the IDi payload, proves
skipping to change at line 518 skipping to change at line 522
The optional payload IDr enables the initiator to specify which of The optional payload IDr enables the initiator to specify which of
the responder's identities it wants to talk to. This is useful when the responder's identities it wants to talk to. This is useful when
the machine on which the responder is running is hosting multiple the machine on which the responder is running is hosting multiple
identities at the same IP address. If the IDr proposed by the identities at the same IP address. If the IDr proposed by the
initiator is not acceptable to the responder, the responder might use initiator is not acceptable to the responder, the responder might use
some other IDr to finish the exchange. If the initiator then does some other IDr to finish the exchange. If the initiator then does
not accept the fact that responder used an IDr different than the one not accept the fact that responder used an IDr different than the one
that was requested, the initiator can close the SA after noticing the that was requested, the initiator can close the SA after noticing the
fact. fact.
The traffic selectors (TSi and TSr) are discussed in Section 2.9.
The initiator begins negotiation of a Child SA using the SAi2 The initiator begins negotiation of a Child SA using the SAi2
payload. The final fields (starting with SAi2) are described in the payload. The final fields (starting with SAi2) are described in the
description of the CREATE_CHILD_SA exchange. description of the CREATE_CHILD_SA exchange.
<-- 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.
The recipients of messages 3 and 4 MUST verify that all signatures Both parties in the IKE_SA_INIT exchange MUST verify that all
and MACs are computed correctly. If either side uses a shared secret signatures and MACs are computed correctly. If either side uses a
for authentication, the names in the ID payload MUST correspond to shared secret for authentication, the names in the ID payload MUST
the key used to generate the AUTH payload. correspond to 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
trick the endpoints into negotiating a weaker suite than a stronger trick the endpoints into negotiating a weaker suite than a stronger
one that they both prefer. one that they both prefer.
If creating the Child SA during the IKE_AUTH exchange fails for some If creating the Child SA during the IKE_AUTH exchange fails for some
reason, the IKE SA is still created as usual. The list of responses reason, the IKE SA is still created as usual. The list of Notify
in the IKE_AUTH exchange that do not prevent an IKE SA from being set message types in the IKE_AUTH exchange that do not prevent an IKE SA
up include at least the following: NO_PROPOSAL_CHOSEN, from being set up include at least the following: NO_PROPOSAL_CHOSEN,
TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and
FAILED_CP_REQUIRED. FAILED_CP_REQUIRED.
If the failure is related to creating the IKE SA (for example, If the failure is related to creating the IKE SA (for example, an
AUTHENTICATION_FAILED), the IKE SA is not created. Note that AUTHENTICATION_FAILED Notify error message is returned), the IKE SA
although the IKE_AUTH messages are encrypted and integrity protected, is not created. Note that although the IKE_AUTH messages are
if the peer receiving this notification has not yet authenticated the encrypted and integrity protected, if the peer receiving this Notify
other end (or if the peer fails to authenticate the other end for error message has not yet authenticated the other end (or if the peer
some reason), the information needs to be treated with caution. More fails to authenticate the other end for some reason), the information
precisely, assuming that the MAC verifies correctly, the sender of needs to be treated with caution. More precisely, assuming that the
the error indication is known to be the responder of the IKE_SA_INIT MAC verifies correctly, the sender of the error Notify message is
exchange, but the sender's identity cannot be assured. known to be the responder of the IKE_SA_INIT exchange, but the
sender's identity cannot be assured.
Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
Thus, the SA payloads in the IKE_AUTH exchange cannot contain Thus, the SA payloads in the IKE_AUTH exchange cannot contain
Transform Type 4 (Diffie-Hellman Group) with any value other than Transform Type 4 (Diffie-Hellman Group) with any value other than
NONE. Implementations SHOULD omit the whole transform substructure NONE. Implementations SHOULD omit the whole transform substructure
instead of sending value NONE. instead of sending value NONE.
1.3. The CREATE_CHILD_SA Exchange 1.3. The CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA exchange is used to create new Child SAs and to The CREATE_CHILD_SA exchange is used to create new Child SAs and to
rekey both IKE SAs and Child SAs. This exchange consists of a single rekey both IKE SAs and Child SAs. This exchange consists of a single
request/response pair, and some of its function was referred to as a request/response pair, and some of its function was referred to as a
phase 2 exchange in IKEv1. It MAY be initiated by either end of the phase 2 exchange in IKEv1. It MAY be initiated by either end of the
IKE SA after the initial exchanges are completed. IKE SA after the initial exchanges are completed.
All messages following the initial exchange are cryptographically
protected using the cryptographic algorithms and keys negotiated in
the first two messages of the IKE exchange. These subsequent
messages use the syntax of the Encrypted Payload described in
Section 3.14, encrypted with keys that are derived as described in
Section 2.14. All subsequent messages include an Encrypted Payload,
even if they are referred to in the text as "empty". For both
messages in the CREATE_CHILD_SA, the message following the header is
encrypted and the message including the header is integrity protected
using the cryptographic algorithms negotiated for the IKE SA.
The CREATE_CHILD_SA is also used for rekeying IKE SAs and Child SAs.
An SA is rekeyed by creating a new SA and then deleting the old one. An SA is rekeyed by creating a new SA and then deleting the old one.
This section describes the first part of rekeying, the creation of This section describes the first part of rekeying, the creation of
new SAs; Section 2.8 covers the mechanics of rekeying, including new SAs; Section 2.8 covers the mechanics of rekeying, including
moving traffic from old to new SAs and the deletion of the old SAs. moving traffic from old to new SAs and the deletion of the old SAs.
The two sections must be read together to understand the entire The two sections must be read together to understand the entire
process of rekeying. process of rekeying.
Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
section the term initiator refers to the endpoint initiating this section the term initiator refers to the endpoint initiating this
exchange. An implementation MAY refuse all CREATE_CHILD_SA requests exchange. An implementation MAY refuse all CREATE_CHILD_SA requests
skipping to change at line 620 skipping to change at line 615
in the CREATE_CHILD_SA exchange). in the CREATE_CHILD_SA exchange).
If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
the SA offers MUST include the Diffie-Hellman group of the KEi. The the SA offers MUST include the Diffie-Hellman group of the KEi. The
Diffie-Hellman group of the KEi MUST be an element of the group the Diffie-Hellman group of the KEi MUST be an element of the group the
initiator expects the responder to accept (additional Diffie-Hellman initiator expects the responder to accept (additional Diffie-Hellman
groups can be proposed). If the responder selects a proposal using a groups can be proposed). If the responder selects a proposal using a
different Diffie-Hellman group (other than NONE), the responder MUST different Diffie-Hellman group (other than NONE), the responder MUST
reject the request and indicate its preferred Diffie-Hellman group in reject the request and indicate its preferred Diffie-Hellman group in
the INVALID_KE_PAYLOAD Notify payload. There are two octets of data the INVALID_KE_PAYLOAD Notify payload. There are two octets of data
associated with this notification: the accepted D-H Group number in associated with this notification: the accepted Diffie-Hellman Group
big endian order. In the case of such a rejection, the number in big endian order. In the case of such a rejection, the
CREATE_CHILD_SA exchange fails, and the initiator will probably retry CREATE_CHILD_SA exchange fails, and the initiator will probably retry
the exchange with a Diffie-Hellman proposal and KEi in the group that the exchange with a Diffie-Hellman proposal and KEi in the group that
the responder gave in the INVALID_KE_PAYLOAD. the responder gave in the INVALID_KE_PAYLOAD Notify payload.
The responder sends a NO_ADDITIONAL_SAS notification to indicate that The responder sends a NO_ADDITIONAL_SAS notification to indicate that
a CREATE_CHILD_SA request is unacceptable because the responder is a CREATE_CHILD_SA request is unacceptable because the responder is
unwilling to accept any more Child SAs on this IKE SA. This notify unwilling to accept any more Child SAs on this IKE SA. This
can also be used to reject IKE SA rekey. Some minimal notification can also be used to reject IKE SA rekey. Some minimal
implementations may only accept a single Child SA setup in the implementations may only accept a single Child SA setup in the
context of an initial IKE exchange and reject any subsequent attempts context of an initial IKE exchange and reject any subsequent attempts
to add more. to add more.
1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange
A Child SA may be created by sending a CREATE_CHILD_SA request. The A Child SA may be created by sending a CREATE_CHILD_SA request. The
CREATE_CHILD_SA request for creating a new Child SA is: CREATE_CHILD_SA request for creating a new Child SA is:
Initiator Responder Initiator Responder
skipping to change at line 674 skipping to change at line 669
message that also includes an SA payload requesting a Child SA. It message that also includes an SA payload requesting a Child SA. It
requests that the Child SA use transport mode rather than tunnel mode requests that the Child SA use transport mode rather than tunnel mode
for the SA created. If the request is accepted, the response MUST for the SA created. If the request is accepted, the response MUST
also include a notification of type USE_TRANSPORT_MODE. If the also include a notification of type USE_TRANSPORT_MODE. If the
responder declines the request, the Child SA will be established in responder declines the request, the Child SA will be established in
tunnel mode. If this is unacceptable to the initiator, the initiator tunnel mode. If this is unacceptable to the initiator, the initiator
MUST delete the SA. Note: Except when using this option to negotiate MUST delete the SA. Note: Except when using this option to negotiate
transport mode, all Child SAs will use tunnel mode. transport mode, all Child SAs will use tunnel mode.
The ESP_TFC_PADDING_NOT_SUPPORTED notification asserts that the The ESP_TFC_PADDING_NOT_SUPPORTED notification asserts that the
sending endpoint will NOT accept packets that contain Traffic Flow sending endpoint will not accept packets that contain Traffic Flow
Confidentiality (TFC) padding over the Child SA being negotiated. If Confidentiality (TFC) padding over the Child SA being negotiated. If
neither endpoint accepts TFC padding, this notification is included neither endpoint accepts TFC padding, this notification is included
in both the request and the response. If this notification is in both the request and the response. If this notification is
included in only one of the messages, TFC padding can still be sent included in only one of the messages, TFC padding can still be sent
in the other direction. in the other direction.
The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation
control. See [IPSECARCH] for a fuller explanation. Both parties control. See [IPSECARCH] for a fuller explanation. Both parties
need to agree to sending non-first fragments before either party does need to agree to sending non-first fragments before either party does
so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is
included in both the request proposing an SA and the response included in both the request proposing an SA and the response
accepting it. If the responder does not want to send or receive non- accepting it. If the responder does not want to send or receive non-
first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification
from its response, but does not reject the whole Child SA creation. from its response, but does not reject the whole Child SA creation.
An IPCOMP_SUPPORTED notification, covered in Section 2.22, can also An IPCOMP_SUPPORTED notification, covered in Section 2.22, can also
be included in the request/response pair. be included in the exchange.
Failure of an attempt to create a Child SA SHOULD NOT tear down the A failed attempt to create a Child SA SHOULD NOT tear down the IKE
IKE SA: there is no reason to lose the work done to set up the IKE SA: there is no reason to lose the work done to set up the IKE SA.
SA. See Section 2.21 for a list of error messages that might occur See Section 2.21 for a list of error messages that might occur if
if creating a Child SA fails. creating a Child SA fails.
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA request for rekeying an IKE SA is: The CREATE_CHILD_SA request for rekeying an IKE SA is:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {SA, Ni, KEi} --> HDR, SK {SA, Ni, KEi} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
skipping to change at line 756 skipping to change at line 751
The notifications described in Section 1.3.1 may also be sent in a The notifications described in Section 1.3.1 may also be sent in a
rekeying exchange. Usually these will be the same notifications that rekeying exchange. Usually these will be the same notifications that
were used in the original exchange; for example, when rekeying a were used in the original exchange; for example, when rekeying a
transport mode SA, the USE_TRANSPORT_MODE notification will be used. transport mode SA, the USE_TRANSPORT_MODE notification will be used.
The REKEY_SA notification MUST be included in a CREATE_CHILD_SA The REKEY_SA notification MUST be included in a CREATE_CHILD_SA
exchange if the purpose of the exchange is to replace an existing ESP exchange if the purpose of the exchange is to replace an existing ESP
or AH SA. The SA being rekeyed is identified by the SPI field in the or AH SA. The SA being rekeyed is identified by the SPI field in the
Notify payload; this is the SPI the exchange initiator would expect Notify payload; this is the SPI the exchange initiator would expect
in inbound ESP or AH packets. There is no data associated with this in inbound ESP or AH packets. There is no data associated with this
Notify type. The Protocol ID field of the REKEY_SA notification is Notify message type. The Protocol ID field of the REKEY_SA
set to match the protocol of the SA we are rekeying, for example, 3 notification is set to match the protocol of the SA we are rekeying,
for ESP and 2 for AH. for example, 3 for ESP and 2 for AH.
The CREATE_CHILD_SA response for rekeying a Child SA is: The CREATE_CHILD_SA response for rekeying a Child SA is:
<-- HDR, SK {SA, Nr, [KEr], <-- HDR, SK {SA, Nr, [KEr],
TSi, TSr} TSi, TSr}
The responder replies (using the same Message ID to respond) with the The responder replies (using the same Message ID to respond) with the
accepted offer in an SA payload, and a Diffie-Hellman value in the accepted offer in an SA payload, and a Diffie-Hellman value in the
KEr payload if KEi was included in the request and the selected KEr payload if KEi was included in the request and the selected
cryptographic suite includes that group. cryptographic suite includes that group.
skipping to change at line 817 skipping to change at line 812
The processing of an INFORMATIONAL exchange is determined by its The processing of an INFORMATIONAL exchange is determined by its
component payloads. component payloads.
1.4.1. Deleting an SA with INFORMATIONAL Exchanges 1.4.1. Deleting an SA with INFORMATIONAL Exchanges
ESP and AH SAs always exist in pairs, with one SA in each direction. ESP and AH SAs always exist in pairs, with one SA in each direction.
When an SA is closed, both members of the pair MUST be closed (that When an SA is closed, both members of the pair MUST be closed (that
is, deleted). Each endpoint MUST close its incoming SAs and allow is, deleted). Each endpoint MUST close its incoming SAs and allow
the other endpoint to close the other SA in each pair. To delete an the other endpoint to close the other SA in each pair. To delete an
SA, an INFORMATIONAL exchange with one or more delete payloads is SA, an INFORMATIONAL exchange with one or more Delete payloads is
sent listing the SPIs (as they would be expected in the headers of sent listing the SPIs (as they would be expected in the headers of
inbound packets) of the SAs to be deleted. The recipient MUST close inbound packets) of the SAs to be deleted. The recipient MUST close
the designated SAs. Note that one never sends delete payloads for the designated SAs. Note that one never sends delete payloads for
the two sides of an SA in a single message. If there are many SAs to the two sides of an SA in a single message. If there are many SAs to
delete at the same time, one includes delete payloads for the inbound delete at the same time, one includes Delete payloads for the inbound
half of each SA pair in the INFORMATIONAL exchange. half of each SA pair in the INFORMATIONAL exchange.
Normally, the response in the INFORMATIONAL exchange will contain Normally, the response in the INFORMATIONAL exchange will contain
delete payloads for the paired SAs going in the other direction. delete payloads for the paired SAs going in the other direction.
There is one exception. If by chance both ends of a set of SAs There is one exception. If by chance both ends of a set of SAs
independently decide to close them, each may send a delete payload independently decide to close them, each may send a delete payload
and the two requests may cross in the network. If a node receives a and the two requests may cross in the network. If a node receives a
delete request for SAs for which it has already issued a delete delete request for SAs for which it has already issued a delete
request, it MUST delete the outgoing SAs while processing the request request, it MUST delete the outgoing SAs while processing the request
and the incoming SAs while processing the response. In that case, and the incoming SAs while processing the response. In that case,
skipping to change at line 844 skipping to change at line 839
since that would result in duplicate deletion and could in theory since that would result in duplicate deletion and could in theory
delete the wrong SA. delete the wrong SA.
Similar to ESP and AH SAs, IKE SAs are also deleted by sending an Similar to ESP and AH SAs, IKE SAs are also deleted by sending an
Informational exchange. Deleting an IKE SA implicitly closes any Informational exchange. Deleting an IKE SA implicitly closes any
remaining Child SAs negotiated under it. The response to a request remaining Child SAs negotiated under it. The response to a request
that deletes the IKE SA is an empty INFORMATIONAL response. that deletes the IKE SA is an empty INFORMATIONAL response.
Half-closed ESP or AH connections are anomalous, and a node with Half-closed ESP or AH connections are anomalous, and a node with
auditing capability should probably audit their existence if they auditing capability should probably audit their existence if they
persist. Note that this specification nowhere specifies time persist. Note that this specification does not specify time periods,
periods, so it is up to individual endpoints to decide how long to so it is up to individual endpoints to decide how long to wait. A
wait. A node MAY refuse to accept incoming data on half-closed node MAY refuse to accept incoming data on half-closed connections
connections but MUST NOT unilaterally close them and reuse the SPIs. but MUST NOT unilaterally close them and reuse the SPIs. If
If connection state becomes sufficiently messed up, a node MAY close connection state becomes sufficiently messed up, a node MAY close the
the IKE SA, as described above. It can then rebuild the SAs it needs IKE SA, as described above. It can then rebuild the SAs it needs on
on a clean base under a new IKE SA. a clean base under a new IKE SA.
1.5. Informational Messages outside of an IKE SA 1.5. Informational Messages outside of an IKE SA
There are some cases in which a node receives a packet that it cannot There are some cases in which a node receives a packet that it cannot
process, but it may want to notify the sender about this situation. process, but it may want to notify the sender about this situation.
o If an ESP or AH packet arrives with an unrecognized SPI. This o If an ESP or AH packet arrives with an unrecognized SPI. This
might be due to the receiving node having recently crashed and might be due to the receiving node having recently crashed and
lost state, or because of some other system malfunction or attack. lost state, or because of some other system malfunction or attack.
skipping to change at line 888 skipping to change at line 883
UDP port as the destination port if the packet was UDP (UDP- UDP port as the destination port if the packet was UDP (UDP-
encapsulated ESP or AH). In this case, it should only be used by the encapsulated ESP or AH). In this case, it should only be used by the
recipient as a hint that something might be wrong (because it could recipient as a hint that something might be wrong (because it could
easily be forged). This message is not part of an INFORMATIONAL easily be forged). This message is not part of an INFORMATIONAL
exchange, and the receiving node MUST NOT respond to it because doing exchange, and the receiving node MUST NOT respond to it because doing
so could cause a message loop. The message is constructed as so could cause a message loop. The message is constructed as
follows: there are no IKE SPI values that would be meaningful to the follows: there are no IKE SPI values that would be meaningful to the
recipient of such a notification; using zero values or random values recipient of such a notification; using zero values or random values
are both acceptable, this being the exception to the rule in are both acceptable, this being the exception to the rule in
Section 3.1 that prohibits zero IKE Initiator SPIs. The Initiator Section 3.1 that prohibits zero IKE Initiator SPIs. The Initiator
flag is set, the Response bit is set to 0, and the version flags are flag is set to 1, the Response flag is set to 0, and the version
set in the normal fashion. flags are set in the normal fashion; these flags are described in
Section 3.1.
In the second and third cases, the message is always sent without In the second and third cases, the message is always sent without
cryptographic protection (outside of an IKE SA), and includes either cryptographic protection (outside of an IKE SA), and includes either
an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no
notification data). The message is a response message, and thus it notification data). The message is a response message, and thus it
is sent to the IP address and port from whence it came with the same is sent to the IP address and port from whence it came with the same
IKE SPIs and the Message ID and Exchange Type are copied from the IKE SPIs and the Message ID and Exchange Type are copied from the
request. The Response bit is set to 1, and the version flags are set request. The Response flag is set to 1, and the version flags are
in the normal fashion. set in the normal fashion.
1.6. Requirements Terminology 1.6. Requirements Terminology
Definitions of the primitive terms in this document (such as Security Definitions of the primitive terms in this document (such as Security
Association or SA) can be found in [IPSECARCH]. It should be noted Association or SA) can be found in [IPSECARCH]. It should be noted
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
skipping to change at line 925 skipping to change at line 921
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.
This document makes the figures and references a bit more regular This document makes the figures and references a bit more consistent
than 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
normal English sense, not the interoperability sense of [MUSTSHOULD]. normal English sense, not the interoperability sense of [MUSTSHOULD].
IKEv2 (and IKEv1) developers have noted that there is a great deal of IKEv2 (and IKEv1) developers have noted that there is a great deal of
skipping to change at line 976 skipping to change at line 972
4306. Also, many of those lists are now preceded with the very 4306. Also, many of those lists are now preceded with the very
important instruction to developers that they really should look at important instruction to developers that they really should look at
the IANA registry at the time of development because new items have the IANA registry at the time of development because new items have
been added since RFC 4306. been added since RFC 4306.
This document adds clarification on when notifications are and are This document adds clarification on when notifications are and are
not sent encrypted, depending on the state of the negotiation at the not sent encrypted, depending on the state of the negotiation at the
time. time.
This document discusses more about how to negotiate combined-mode This document discusses more about how to negotiate combined-mode
ciphers such as GCM and GMAC. ciphers.
In section 1.3.2, changed "The KEi payload SHOULD be included" to be In section 1.3.2, changed "The KEi payload SHOULD be included" to be
"The KEi payload MUST be included". This also led to changes in "The KEi payload MUST be included". This also led to changes in
section 2.18. section 2.18.
In Section 2.1, there is new material covering how the initiator's In Section 2.1, there is new material covering how the initiator's
SPI and/or IP is used to differentiate if this is a "half-open" IKE SPI and/or IP is used to differentiate if this is a "half-open" IKE
SA or a new request. SA or a new request.
This document clarifies the use of the critical flag in Section 2.5. This document clarifies the use of the critical flag in Section 2.5.
skipping to change at line 1018 skipping to change at line 1014
where error responses are needed and the appropriate responses to where error responses are needed and the appropriate responses to
them. them.
Section 2.23 clarified that, in NAT traversal, now both UDP Section 2.23 clarified that, in NAT traversal, now both UDP
encapsulated IPsec packets and non-UDP encapsulated IPsec packets encapsulated IPsec packets and non-UDP encapsulated IPsec packets
packets need to be understood when receiving. packets need to be understood when receiving.
Added Section 2.23.1 to describe NAT traversal when transport mode is Added Section 2.23.1 to describe NAT traversal when transport mode is
requested. requested.
All of Section 2.25 was added to explain how to act when there are Added Section 2.25 to explain how to act when there are timing
timing collisions when deleting and/or rekeying SAs, and two new collisions when deleting and/or rekeying SAs, and two new error
error notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were
defined. defined.
In Section 3.6, added "Implementations MUST support the HTTP method In Section 3.6, added "Implementations MUST support the HTTP method
for hash-and-URL lookup. The behavior of other URL methods is not for hash-and-URL lookup. The behavior of other URL methods is not
currently specified, and such methods SHOULD NOT be used in the currently specified, and such methods SHOULD NOT be used in the
absence of a document specifying them." absence of a document specifying them."
In Section 3.15.3, added a pointer to a new document that is related In Section 3.15.3, added a pointer to a new document that is related
to configuration of IPv6 addresses. to configuration of IPv6 addresses.
skipping to change at line 1048 skipping to change at line 1044
protocol, IKE includes in its definition recovery from transmission protocol, IKE includes in its definition recovery from transmission
errors, including packet loss, packet replay, and packet forgery. errors, including packet loss, packet replay, and packet forgery.
IKE is designed to function so long as (1) at least one of a series IKE is designed to function so long as (1) at least one of a series
of retransmitted packets reaches its destination before timing out; of retransmitted packets reaches its destination before timing out;
and (2) the channel is not so full of forged and replayed packets so and (2) the channel is not so full of forged and replayed packets so
as to exhaust the network or CPU capacities of either endpoint. Even as to exhaust the network or CPU capacities of either endpoint. Even
in the absence of those minimum performance requirements, IKE is in the absence of those minimum performance requirements, IKE is
designed to fail cleanly (as though the network were broken). designed to fail cleanly (as though the network were broken).
Although IKEv2 messages are intended to be short, they contain Although IKEv2 messages are intended to be short, they contain
structures with no hard upper bound on size (in particular, X.509 structures with no hard upper bound on size (in particular, digital
certificates), and IKEv2 itself does not have a mechanism for certificates), and IKEv2 itself does not have a mechanism for
fragmenting large messages. IP defines a mechanism for fragmentation fragmenting large messages. IP defines a mechanism for fragmentation
of oversize UDP messages, but implementations vary in the maximum of oversized UDP messages, but implementations vary in the maximum
message size supported. Furthermore, use of IP fragmentation opens message size supported. Furthermore, use of IP fragmentation opens
an implementation to denial of service (DoS) attacks [DOSUDPPROT]. an implementation to denial of service (DoS) attacks [DOSUDPPROT].
Finally, some NAT and/or firewall implementations may block IP Finally, some NAT and/or firewall implementations may block IP
fragments. fragments.
All IKEv2 implementations MUST be able to send, receive, and process All IKEv2 implementations MUST be able to send, receive, and process
IKE messages that are up to 1280 octets long, and they SHOULD be able IKE messages that are up to 1280 octets long, and they SHOULD be able
to send, receive, and process messages that are up to 3000 octets to send, receive, and process messages that are up to 3000 octets
long. IKEv2 implementations need to be aware of the maximum UDP long. IKEv2 implementations need to be aware of the maximum UDP
message size supported and MAY shorten messages by leaving out some message size supported and MAY shorten messages by leaving out some
skipping to change at line 1077 skipping to change at line 1073
Child SA is established, recursion issues could prevent this Child SA is established, recursion issues could prevent this
technique from working. technique from working.
The UDP payload of all packets containing IKE messages sent on port The UDP payload of all packets containing IKE messages sent on port
4500 MUST begin with the prefix of four zeros; otherwise, the 4500 MUST begin with the prefix of four zeros; otherwise, the
receiver won't know how to handle them. receiver won't know how to handle them.
2.1. Use of Retransmission Timers 2.1. Use of Retransmission Timers
All messages in IKE exist in pairs: a request and a response. The All messages in IKE exist in pairs: a request and a response. The
setup of an IKE SA normally consists of two request/response pairs. setup of an IKE SA normally consists of two exchanges. Once the IKE
Once the IKE SA is set up, either end of the security association may SA is set up, either end of the security association may initiate
initiate requests at any time, and there can be many requests and requests at any time, and there can be many requests and responses
responses "in flight" at any given moment. But each message is "in flight" at any given moment. But each message is labeled as
labeled as either a request or a response, and for each request/ either a request or a response, and for each exchange, one end of the
response pair one end of the security association is the initiator security association is the initiator and the other is the responder.
and the other is the responder.
For every pair of IKE messages, the initiator is responsible for For every pair of IKE messages, the initiator is responsible for
retransmission in the event of a timeout. The responder MUST never retransmission in the event of a timeout. The responder MUST never
retransmit a response unless it receives a retransmission of the retransmit a response unless it receives a retransmission of the
request. In that event, the responder MUST ignore the retransmitted request. In that event, the responder MUST ignore the retransmitted
request except insofar as it causes a retransmission of the response. request except insofar as it causes a retransmission of the response.
The initiator MUST remember each request until it receives the The initiator MUST remember each request until it receives the
corresponding response. The responder MUST remember each response corresponding response. The responder MUST remember each response
until it receives a request whose sequence number is larger than or until it receives a request whose sequence number is larger than or
equal to the sequence number in the response plus its window size equal to the sequence number in the response plus its window size
skipping to change at line 1137 skipping to change at line 1132
sent, there is no reason to gratuitously retransmit one-way messages. sent, there is no reason to gratuitously retransmit one-way messages.
Given that all these messages are errors, it makes sense to send them Given that all these messages are errors, it makes sense to send them
only once per "offending" packet, and only retransmit if further only once per "offending" packet, and only retransmit if further
offending packets are received. Still, it also makes sense to limit offending packets are received. Still, it also makes sense to limit
retransmissions of such error messages. retransmissions of such error messages.
2.2. Use of Sequence Numbers for Message ID 2.2. Use of Sequence Numbers for Message ID
Every IKE message contains a Message ID as part of its fixed header. Every IKE message contains a Message ID as part of its fixed header.
This Message ID is used to match up requests and responses, and to This Message ID is used to match up requests and responses, and to
identify retransmissions of messages. identify retransmissions of messages. Retransmission of a message
MUST use the same Message ID as the original message.
The Message ID is a 32-bit quantity, which is zero for the The Message ID is a 32-bit quantity, which is zero for the
IKE_SA_INIT messages (including retries of the message due to IKE_SA_INIT messages (including retries of the message due to
responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for
each subsequent exchange. Thus, the first pair of IKE_AUTH messages each subsequent exchange. Thus, the first pair of IKE_AUTH messages
will have ID of 1, the second (when EAP is used) will be 2, and so will have ID of 1, the second (when EAP is used) will be 2, and so
on. The Message ID is reset to zero in the new IKE SA after the IKE on. The Message ID is reset to zero in the new IKE SA after the IKE
SA is rekeyed. SA is rekeyed.
Each endpoint in the IKE Security Association maintains two "current" Each endpoint in the IKE Security Association maintains two "current"
skipping to change at line 1159 skipping to change at line 1155
the next one it expects to see in a request from the other end. the next one it expects to see in a request from the other end.
These counters increment as requests are generated and received. These counters increment as requests are generated and received.
Responses always contain the same message ID as the corresponding Responses always contain the same message ID as the corresponding
request. That means that after the initial exchange, each integer n request. That means that after the initial exchange, each integer n
may appear as the message ID in four distinct messages: the nth may appear as the message ID in four distinct messages: the nth
request from the original IKE initiator, the corresponding response, request from the original IKE initiator, the corresponding response,
the nth request from the original IKE responder, and the the nth request from the original IKE responder, and the
corresponding response. If the two ends make very different numbers corresponding response. If the two ends make very different numbers
of requests, the Message IDs in the two directions can be very of requests, the Message IDs in the two directions can be very
different. There is no ambiguity in the messages, however, because different. There is no ambiguity in the messages, however, because
the (I)nitiator and (R)esponse bits in the message header specify the Initiator and Response flags in the message header specify which
which of the four messages a particular one is. of the four messages a particular one is.
Throughout this document, "initiator" refers to the party who Throughout this document, "initiator" refers to the party who
initiated the exchange being described. The "original initiator" initiated the exchange being described. The "original initiator"
always refers to the party who initiated the exchange which resulted always refers to the party who initiated the exchange which resulted
in the current IKE SA. In other words, if the "original responder" in the current IKE SA. In other words, if the "original responder"
starts rekeying the IKE SA, that party becomes the "original starts rekeying the IKE SA, that party becomes the "original
initiator" of the new IKE SA. initiator" of the new IKE SA.
Note that Message IDs are cryptographically protected and provide Note that Message IDs are cryptographically protected and provide
protection against message replays. In the unlikely event that protection against message replays. In the unlikely event that
skipping to change at line 1226 skipping to change at line 1222
(unlike the window size in TCP, for example). In particular, it is (unlike the window size in TCP, for example). In particular, it is
not defined what the responder should do when it receives a not defined what the responder should do when it receives a
SET_WINDOW_SIZE notification containing a smaller value than is SET_WINDOW_SIZE notification containing a smaller value than is
currently in effect. Thus, there is currently no way to reduce the currently in effect. Thus, there is currently no way to reduce the
window size of an existing IKE SA; you can only increase it. When window size of an existing IKE SA; you can only increase it. When
rekeying an IKE SA, the new IKE SA starts with window size 1 until it rekeying an IKE SA, the new IKE SA starts with window size 1 until it
is explicitly increased by sending a new SET_WINDOW_SIZE is explicitly increased by sending a new SET_WINDOW_SIZE
notification. notification.
The INVALID_MESSAGE_ID notification is sent when an IKE message ID The INVALID_MESSAGE_ID notification is sent when an IKE message ID
outside the supported window is received. This Notify MUST NOT be outside the supported window is received. This Notify message MUST
sent in a response; the invalid request MUST NOT be acknowledged. NOT be sent in a response; the invalid request MUST NOT be
Instead, inform the other side by initiating an INFORMATIONAL acknowledged. Instead, inform the other side by initiating an
exchange with Notification data containing the four octet invalid INFORMATIONAL exchange with Notification data containing the four
message ID. Sending this notification is optional, and notifications octet invalid message ID. Sending this notification is OPTIONAL, and
of this type MUST be rate limited. notifications of this type MUST be rate limited.
2.4. State Synchronization and Connection Timeouts 2.4. State Synchronization and Connection Timeouts
An IKE endpoint is allowed to forget all of its state associated with An IKE endpoint is allowed to forget all of its state associated with
an IKE SA and the collection of corresponding Child SAs at any time. an IKE SA and the collection of corresponding Child SAs at any time.
This is the anticipated behavior in the event of an endpoint crash This is the anticipated behavior in the event of an endpoint crash
and restart. It is important when an endpoint either fails or and restart. It is important when an endpoint either fails or
reinitializes its state that the other endpoint detect those reinitializes its state that the other endpoint detect those
conditions and not continue to waste network bandwidth by sending conditions and not continue to waste network bandwidth by sending
packets over discarded SAs and having them fall into a black hole. packets over discarded SAs and having them fall into a black hole.
skipping to change at line 1256 skipping to change at line 1252
recipient MAY use this information to delete any other IKE SAs it has recipient MAY use this information to delete any other IKE SAs it has
to the same authenticated identity without waiting for a timeout. to the same authenticated identity without waiting for a timeout.
This notification MUST NOT be sent by an entity that may be This notification MUST NOT be sent by an entity that may be
replicated (e.g., a roaming user's credentials where the user is replicated (e.g., a roaming user's credentials where the user is
allowed to connect to the corporate firewall from two remote systems allowed to connect to the corporate firewall from two remote systems
at the same time). The INITIAL_CONTACT notification, if sent, MUST at the same time). The INITIAL_CONTACT notification, if sent, MUST
be in the first IKE_AUTH request or response, not as a separate be in the first IKE_AUTH request or response, not as a separate
exchange afterwards; receiving parties MAY ignore it in other exchange afterwards; receiving parties MAY ignore it in other
messages. messages.
Since IKE is designed to operate in spite of denial of service Since IKE is designed to operate in spite of DoS attacks from the
attacks from the network, an endpoint MUST NOT conclude that the network, an endpoint MUST NOT conclude that the other endpoint has
other endpoint has failed based on any routing information (e.g., failed based on any routing information (e.g., ICMP messages) or IKE
ICMP messages) or IKE messages that arrive without cryptographic messages that arrive without cryptographic protection (e.g., Notify
protection (e.g., Notify messages complaining about unknown SPIs). messages complaining about unknown SPIs). An endpoint MUST conclude
An endpoint MUST conclude that the other endpoint has failed only that the other endpoint has failed only when repeated attempts to
when repeated attempts to contact it have gone unanswered for a contact it have gone unanswered for a timeout period or when a
timeout period or when a cryptographically protected INITIAL_CONTACT cryptographically protected INITIAL_CONTACT notification is received
notification is received on a different IKE SA to the same on a different IKE SA to the same authenticated identity. An
authenticated identity. An endpoint should suspect that the other endpoint should suspect that the other endpoint has failed based on
endpoint has failed based on routing information and initiate a routing information and initiate a request to see whether the other
request to see whether the other endpoint is alive. To check whether endpoint is alive. To check whether the other side is alive, IKE
the other side is alive, IKE specifies an empty INFORMATIONAL message specifies an empty INFORMATIONAL message that (like all IKE requests)
that (like all IKE requests) requires an acknowledgement (note that requires an acknowledgement (note that within the context of an IKE
within the context of an IKE SA, an "empty" message consists of an SA, an "empty" message consists of an IKE header followed by an
IKE header followed by an Encrypted payload that contains no Encrypted payload that contains no payloads). If a cryptographically
payloads). If a cryptographically protected (fresh, i.e. not protected (fresh, i.e. not retransmitted) message has been received
retransmitted) message has been received from the other side from the other side recently, unprotected Notify messages MAY be
recently, unprotected notifications MAY be ignored. Implementations ignored. Implementations MUST limit the rate at which they take
MUST limit the rate at which they take actions based on unprotected actions based on unprotected messages.
messages.
Numbers of retries and lengths of timeouts are not covered in this Numbers of retries and lengths of timeouts are not covered in this
specification because they do not affect interoperability. It is specification because they do not affect interoperability. It is
suggested that messages be retransmitted at least a dozen times over suggested that messages be retransmitted at least a dozen times over
a period of at least several minutes before giving up on an SA, but a period of at least several minutes before giving up on an SA, but
different environments may require different rules. To be a good different environments may require different rules. To be a good
network citizen, retransmission times MUST increase exponentially to network citizen, retransmission times MUST increase exponentially to
avoid flooding the network and making an existing congestion avoid flooding the network and making an existing congestion
situation worse. If there has only been outgoing traffic on all of situation worse. If there has only been outgoing traffic on all of
the SAs associated with an IKE SA, it is essential to confirm the SAs associated with an IKE SA, it is essential to confirm
liveness of the other endpoint to avoid black holes. If no liveness of the other endpoint to avoid black holes. If no
cryptographically protected messages have been received on an IKE SA cryptographically protected messages have been received on an IKE SA
or any of its Child SAs recently, the system needs to perform a or any of its Child SAs recently, the system needs to perform a
liveness check in order to prevent sending messages to a dead peer. liveness check in order to prevent sending messages to a dead peer.
(This is sometimes called "dead peer detection" or "DPD", although it (This is sometimes called "dead peer detection" or "DPD", although it
is really detecting live peers, not dead ones.) Receipt of a fresh is really detecting live peers, not dead ones.) Receipt of a fresh
cryptographically protected message on an IKE SA or any of its Child cryptographically protected message on an IKE SA or any of its Child
SAs ensures liveness of the IKE SA and all of its Child SAs. Note SAs ensures liveness of the IKE SA and all of its Child SAs. Note
that this places requirements on the failure modes of an IKE that this places requirements on the failure modes of an IKE
endpoint. An implementation MUST NOT continue sending on any SA if endpoint. An implementation needs to stop sending on any SA if some
some failure prevents it from receiving on all of the associated SAs. failure prevents it from receiving on all of the associated SAs. If
If Child SAs can fail independently from one another without the a system creates Child SAs that can fail independently from one
associated IKE SA being able to send a delete message, then they MUST another without the associated IKE SA being able to send a delete
be negotiated by separate IKE SAs. message, then the system MUST negotiate such Child SAs using separate
IKE SAs.
There is a denial of service attack on the initiator of an IKE SA There is a DoS attack on the initiator of an IKE SA that can be
that can be avoided if the initiator takes the proper care. Since avoided if the initiator takes the proper care. Since the first two
the first two messages of an SA setup are not cryptographically messages of an SA setup are not cryptographically protected, an
protected, an attacker could respond to the initiator's message attacker could respond to the initiator's message before the genuine
before the genuine responder and poison the connection setup attempt. responder and poison the connection setup attempt. To prevent this,
To prevent this, the initiator MAY be willing to accept multiple the initiator MAY be willing to accept multiple responses to its
responses to its first message, treat each as potentially legitimate, first message, treat each as potentially legitimate, respond to it,
respond to it, and then discard all the invalid half-open connections and then discard all the invalid half-open connections when it
when it receives a valid cryptographically protected response to any receives a valid cryptographically protected response to any one of
one of its requests. Once a cryptographically valid response is its requests. Once a cryptographically valid response is received,
received, all subsequent responses should be ignored whether or not all subsequent responses should be ignored whether or not they are
they are cryptographically valid. cryptographically valid.
Note that with these rules, there is no reason to negotiate and agree Note that with these rules, there is no reason to negotiate and agree
upon an SA lifetime. If IKE presumes the partner is dead, based on upon an SA lifetime. If IKE presumes the partner is dead, based on
repeated lack of acknowledgement to an IKE message, then the IKE SA repeated lack of acknowledgement to an IKE message, then the IKE SA
and all Child SAs set up through that IKE SA are deleted. and all Child SAs set up through that IKE SA are deleted.
An IKE endpoint may at any time delete inactive Child SAs to recover An IKE endpoint may at any time delete inactive Child SAs to recover
resources used to hold their state. If an IKE endpoint chooses to resources used to hold their state. If an IKE endpoint chooses to
delete Child SAs, it MUST send Delete payloads to the other end delete Child SAs, it MUST send Delete payloads to the other end
notifying it of the deletion. It MAY similarly time out the IKE SA. notifying it of the deletion. It MAY similarly time out the IKE SA.
skipping to change at line 1346 skipping to change at line 1342
The major version number should be incremented only if the packet The major version number should be incremented only if the packet
formats or required actions have changed so dramatically that an formats or required actions have changed so dramatically that an
older version node would not be able to interoperate with a newer older version node would not be able to interoperate with a newer
version node if it simply ignored the fields it did not understand version node if it simply ignored the fields it did not understand
and took the actions specified in the older specification. The minor and took the actions specified in the older specification. The minor
version number indicates new capabilities, and MUST be ignored by a version number indicates new capabilities, and MUST be ignored by a
node with a smaller minor version number, but used for informational node with a smaller minor version number, but used for informational
purposes by the node with the larger minor version number. For purposes by the node with the larger minor version number. For
example, it might indicate the ability to process a newly defined example, it might indicate the ability to process a newly defined
notification message. The node with the larger minor version number Notify message type. The node with the larger minor version number
would simply note that its correspondent would not be able to would simply note that its correspondent would not be able to
understand that message and therefore would not send it. understand that message and therefore would not send it.
If an endpoint receives a message with a higher major version number, If an endpoint receives a message with a higher major version number,
it MUST drop the message and SHOULD send an unauthenticated it MUST drop the message and SHOULD send an unauthenticated Notify
notification message of type INVALID_MAJOR_VERSION containing the message of type INVALID_MAJOR_VERSION containing the highest
highest (closest) version number it supports. If an endpoint (closest) version number it supports. If an endpoint supports major
supports major version n, and major version m, it MUST support all version n, and major version m, it MUST support all versions between
versions between n and m. If it receives a message with a major n and m. If it receives a message with a major version that it
version that it supports, it MUST respond with that version number. supports, it MUST respond with that version number. In order to
In order to prevent two nodes from being tricked into corresponding prevent two nodes from being tricked into corresponding with a lower
with a lower major version number than the maximum that they both major version number than the maximum that they both support, IKE has
support, IKE has a flag that indicates that the node is capable of a flag that indicates that the node is capable of speaking a higher
speaking a higher major version number. major version number.
Thus, the major version number in the IKE header indicates the Thus, the major version number in the IKE header indicates the
version number of the message, not the highest version number that version number of the message, not the highest version number that
the transmitter supports. If the initiator is capable of speaking the transmitter supports. If the initiator is capable of speaking
versions n, n+1, and n+2, and the responder is capable of speaking versions n, n+1, and n+2, and the responder is capable of speaking
versions n and n+1, then they will negotiate speaking n+1, where the versions n and n+1, then they will negotiate speaking n+1, where the
initiator will set a flag indicating its ability to speak a higher initiator will set a flag indicating its ability to speak a higher
version. If they mistakenly (perhaps through an active attacker version. If they mistakenly (perhaps through an active attacker
sending error messages) negotiate to version n, then both will notice sending error messages) negotiate to version n, then both will notice
that the other side can support a higher version number, and they that the other side can support a higher version number, and they
skipping to change at line 1428 skipping to change at line 1424
known by the sender. known by the sender.
Incoming IKE packets are mapped to an IKE SA only using the packet's Incoming IKE packets are mapped to an IKE SA only using the packet's
SPI, not using (for example) the source IP address of the packet. SPI, not using (for example) the source IP address of the packet.
Unlike ESP and AH where only the recipient's SPI appears in the Unlike ESP and AH where only the recipient's SPI appears in the
header of a message, in IKE the sender's SPI is also sent in every header of a message, in IKE the sender's SPI is also sent in every
message. Since the SPI chosen by the original initiator of the IKE message. Since the SPI chosen by the original initiator of the IKE
SA is always sent first, an endpoint with multiple IKE SAs open that SA is always sent first, an endpoint with multiple IKE SAs open that
wants to find the appropriate IKE SA using the SPI it assigned must wants to find the appropriate IKE SA using the SPI it assigned must
look at the I(nitiator) Flag bit in the header to determine whether look at the Initiator flag in the header to determine whether it
it assigned the first or the second eight octets. assigned the first or the second eight octets.
In the first message of an initial IKE exchange, the initiator will In the first message of an initial IKE exchange, the initiator will
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. 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.
An expected attack against IKE is state and CPU exhaustion, where the Two expected attacks against IKE are state and CPU exhaustion, where
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 if an addresses. This attack can be made less effective a responder uses
implementation of a responder uses minimal CPU and commits no state minimal CPU and commits no state to an SA until it knows the
to an SA until it knows the initiator can receive packets at the initiator can receive packets at the address from which it claims to
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
the received data as the first payload, and all other payloads the received data as the first payload, and all other payloads
unchanged. The initial exchange will then be as follows: unchanged. The initial exchange will then be as follows:
skipping to change at line 1479 skipping to change at line 1480
message sequence numbers in the last two messages will be one. 'A' message sequence numbers in the last two messages will be one. 'A'
is the SPI assigned by the initiator, while 'B' is the SPI assigned is the SPI assigned by the initiator, while 'B' is the SPI assigned
by the responder. by the responder.
An IKE implementation can implement its responder cookie generation An IKE implementation can implement its responder cookie generation
in such a way as to not require any saved state to recognize its in such a way as to not require any saved state to recognize its
valid cookie when the second IKE_SA_INIT message arrives. The exact valid cookie when the second IKE_SA_INIT message arrives. The exact
algorithms and syntax used to generate cookies do not affect algorithms and syntax used to generate cookies do not affect
interoperability and hence are not specified here. The following is interoperability and hence are not specified here. The following is
an example of how an endpoint could use cookies to implement limited an example of how an endpoint could use cookies to implement limited
DOS protection. DoS protection.
A good way to do this is to set the responder cookie to be: A good way to do this is to set the responder cookie to be:
Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>) Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
where <secret> is a randomly generated secret known only to the where <secret> is a randomly generated secret known only to the
responder and periodically changed and | indicates concatenation. responder and periodically changed and | indicates concatenation.
<VersionIDofSecret> should be changed whenever <secret> is <VersionIDofSecret> should be changed whenever <secret> is
regenerated. The cookie can be recomputed when the IKE_SA_INIT regenerated. The cookie can be recomputed when the IKE_SA_INIT
arrives the second time and compared to the cookie in the received arrives the second time and compared to the cookie in the received
skipping to change at line 1511 skipping to change at line 1512
there are lots of machines behind one NAT box who are all trying to there are lots of machines behind one NAT box who are all trying to
connect. connect.
If a new value for <secret> is chosen while there are connections in If a new value for <secret> is chosen while there are connections in
the process of being initialized, an IKE_SA_INIT might be returned the process of being initialized, an IKE_SA_INIT might be returned
with other than the current <VersionIDofSecret>. The responder in with other than the current <VersionIDofSecret>. The responder in
that case MAY reject the message by sending another response with a that case MAY reject the message by sending another response with a
new cookie or it MAY keep the old value of <secret> around for a new cookie or it MAY keep the old value of <secret> around for a
short time and accept cookies computed from either one. The short time and accept cookies computed from either one. The
responder should not accept cookies indefinitely after <secret> is responder should not accept cookies indefinitely after <secret> is
changed, since that would defeat part of the denial of service changed, since that would defeat part of the DoS protection. The
protection. The responder should change the value of <secret> responder should change the value of <secret> frequently, especially
frequently, especially if under attack. if under attack.
When one party receives an IKE_SA_INIT request containing a cookie When one party receives an IKE_SA_INIT request containing a cookie
whose contents do not match the value expected, that party MUST whose contents do not match the value expected, that party MUST
ignore the cookie and process the message as if no cookie had been ignore the cookie and process the message as if no cookie had been
included; usually this means sending a response containing a new included; usually this means sending a response containing a new
cookie. The initiator should limit the number of cookie exchanges it cookie. The initiator should limit the number of cookie exchanges it
tries before giving up. An attacker can forge multiple cookie tries before giving up, possibly using exponential back-off. An
responses to the initiator's IKE_SA_INIT message, and each of those attacker can forge multiple cookie responses to the initiator's
forged cookie replies will cause two packets: one packet from the IKE_SA_INIT message, and each of those forged cookie replies will
initiator to the responder (which will reject those cookies), and one cause two packets to be sent: one packet from the initiator to the
response from responder to initiator that includes the correct responder (which will reject those cookies), and one response from
cookie. responder to initiator that includes the correct cookie.
A note on terminology: the term "cookies" originates with Karn and A note on terminology: the term "cookies" originates with Karn and
Simpson [PHOTURIS] in Photuris, an early proposal for key management Simpson [PHOTURIS] in Photuris, an early proposal for key management
with IPsec, and it has persisted. The Internet Security Association with IPsec, and it has persisted. The Internet Security Association
and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header
includes two eight-octet fields called "cookies", and that syntax is includes two eight-octet fields called "cookies", and that syntax is
used by both IKEv1 and IKEv2, although in IKEv2 they are referred to used by both IKEv1 and IKEv2, although in IKEv2 they are referred to
as the "IKE SPI" and there is a new separate field in a Notify as the "IKE SPI" and there is a new separate field in a Notify
payload holding the cookie. payload holding the cookie.
skipping to change at line 1609 skipping to change at line 1610
combinations are acceptable. combinations are acceptable.
If an initiator proposes both normal ciphers with integrity If an initiator proposes both normal ciphers with integrity
protection as well as combined-mode ciphers, then two proposals are protection as well as combined-mode ciphers, then two proposals are
needed. One of the proposals includes the normal ciphers with the needed. One of the proposals includes the normal ciphers with the
integrity algoritms for them, and the other proposal includes all the integrity algoritms for them, and the other proposal includes all the
combined mode ciphers without the integrity algorithms (because combined mode ciphers without the integrity algorithms (because
combined mode ciphers are not allowed to have any integrity algorithm combined mode ciphers are not allowed to have any integrity algorithm
other than "none"). other than "none").
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. However, if the
responder sends a non-zero responder SPI, the initiator should not
reject the response for only that reason.
2.8. Rekeying 2.8. Rekeying
IKE, ESP, and AH security associations use secret keys that should be IKE, ESP, and AH security associations use secret keys that should be
used only for a limited amount of time and to protect a limited used only for a limited amount of time and to protect a limited
amount of data. This limits the lifetime of the entire security amount of data. This limits the lifetime of the entire security
association. When the lifetime of a security association expires, association. When the lifetime of a security association expires,
the security association MUST NOT be used. If there is demand, new the security association MUST NOT be used. If there is demand, new
security associations MAY be established. Reestablishment of security associations MAY be established. Reestablishment of
security associations to take the place of ones that expire is security associations to take the place of ones that expire is
referred to as "rekeying". referred to as "rekeying".
skipping to change at line 1722 skipping to change at line 1717
redundant SAs). To reduce the probability of this happening, the redundant SAs). To reduce the probability of this happening, the
timing of rekeying requests SHOULD be jittered (delayed by a random timing of rekeying requests SHOULD be jittered (delayed by a random
amount of time after the need for rekeying is noticed). amount of time after the need for rekeying is noticed).
This form of rekeying may temporarily result in multiple similar SAs This form of rekeying may temporarily result in multiple similar SAs
between the same pairs of nodes. When there are two SAs eligible to between the same pairs of nodes. When there are two SAs eligible to
receive packets, a node MUST accept incoming packets through either receive packets, a node MUST accept incoming packets through either
SA. If redundant SAs are created though such a collision, the SA SA. If redundant SAs are created though such a collision, the SA
created with the lowest of the four nonces used in the two exchanges created with the lowest of the four nonces used in the two exchanges
SHOULD be closed by the endpoint that created it. "Lowest" means an SHOULD be closed by the endpoint that created it. "Lowest" means an
octet-by-octet, lexicographical comparison (instead of, for instance, octet-by-octet comparison (instead of, for instance, comparing the
comparing the nonces as large integers). In other words, start by nonces as large integers). In other words, start by comparing the
comparing the first octet; if they're equal, move to the next octet, first octet; if they're equal, move to the next octet, and so on. If
and so on. If you reach the end of one nonce, that nonce is the you reach the end of one nonce, that nonce is the lower one. The
lower one. The node that initiated the surviving rekeyed SA should node that initiated the surviving rekeyed SA should delete the
delete the replaced SA after the new one is established. replaced SA after the new one is established.
The following is an explanation on the impact this has on The following is an explanation on the impact this has on
implementations. Assume that hosts A and B have an existing Child SA implementations. Assume that hosts A and B have an existing Child SA
pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same
time: time:
Host A Host B Host A Host B
------------------------------------------------------------------- -------------------------------------------------------------------
send req1: N(REKEY_SA,SPIa1), send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. --> SA(..,SPIa2,..),Ni1,.. -->
skipping to change at line 1859 skipping to change at line 1854
--> recv req3 --> recv req3
At this point, host B sees a request to close the IKE_SA. There's At this point, host B sees a request to close the IKE_SA. There's
not much more to do than to reply as usual. However, at this point not much more to do than to reply as usual. However, at this point
host B should stop retransmitting req2, since once host A receives host B should stop retransmitting req2, since once host A receives
resp3, it will delete all the state associated with the old IKE_SA resp3, it will delete all the state associated with the old IKE_SA
and will not be able to reply to it. and will not be able to reply to it.
<-- send resp3: () <-- send resp3: ()
Support of the TEMPORARY_FAILURE notification is not negotiated, so The TEMPORARY_FAILURE notification was not included in RFC 4306, and
older peers may receive these notifications. In that case, they will support of the TEMPORARY_FAILURE notification is not negotiated.
treat it the same as any other unknown error notification, and will Thus, older peers that implement RFC 4306 but not this document may
stop the exchange. Because the other peer has already rekeyed the receive these notifications. In that case, they will treat it the
exchange, doing so does not have any ill effects. same as any other unknown error notification, and will stop the
exchange. Because the other peer has already rekeyed the exchange,
doing so does not have any ill effects.
2.8.3. Rekeying the IKE SA Versus Reauthentication 2.8.3. Rekeying the IKE SA Versus Reauthentication
Rekeying the IKE SA and reauthentication are different concepts in Rekeying the IKE SA and reauthentication are different concepts in
IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and
resets the Message ID counters, but it does not authenticate the resets the Message ID counters, but it does not authenticate the
parties again (no AUTH or EAP payloads are involved). parties again (no AUTH or EAP payloads are involved).
Although rekeying the IKE SA may be important in some environments, Although rekeying the IKE SA may be important in some environments,
reauthentication (the verification that the parties still have access reauthentication (the verification that the parties still have access
to the long-term credentials) is often more important. to the long-term credentials) is often more important.
IKEv2 does not have any special support for reauthentication. IKEv2 does not have any special support for reauthentication.
Reauthentication is done by creating a new IKE SA from scratch (using Reauthentication is done by creating a new IKE SA from scratch (using
IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
payloads), creating new Child SAs within the new IKE SA (without payloads), creating new Child SAs within the new IKE SA (without
REKEY_SA notify payloads), and finally deleting the old IKE SA (which REKEY_SA Notify payloads), and finally deleting the old IKE SA (which
deletes the old Child SAs as well). deletes the old Child SAs as well).
This means that reauthentication also establishes new keys for the This means that reauthentication also establishes new keys for the
IKE SA and Child SAs. Therefore, while rekeying can be performed IKE SA and Child SAs. Therefore, while rekeying can be performed
more often than reauthentication, the situation where "authentication more often than reauthentication, the situation where "authentication
lifetime" is shorter than "key lifetime" does not make sense. lifetime" is shorter than "key lifetime" does not make sense.
While creation of a new IKE SA can be initiated by either party While creation of a new IKE SA can be initiated by either party
(initiator or responder in the original IKE SA), the use of EAP (initiator or responder in the original IKE SA), the use of EAP
authentication and/or configuration payloads means in practice that authentication and/or configuration payloads means in practice that
skipping to change at line 1902 skipping to change at line 1899
original IKE SA. IKEv2 does not currently allow the responder to original IKE SA. IKEv2 does not currently allow the responder to
request reauthentication in this case; however, there are extensions request reauthentication in this case; however, there are extensions
that add this functionality such as [REAUTH]. that add this functionality such as [REAUTH].
2.9. Traffic Selector Negotiation 2.9. Traffic Selector Negotiation
When an RFC4301-compliant IPsec subsystem receives an IP packet that When an RFC4301-compliant IPsec subsystem receives an IP packet that
matches a "protect" selector in its Security Policy Database (SPD), matches a "protect" selector in its Security Policy Database (SPD),
the subsystem protects that packet with IPsec. When no SA exists the subsystem protects that packet with IPsec. When no SA exists
yet, it is the task of IKE to create it. Maintenance of a system's yet, it is the task of IKE to create it. Maintenance of a system's
SPD is outside the scope of IKE (see [PFKEY] for an example SPD is outside the scope of IKE, although some implementations might
programming interface, although it only applies to IKEv1), though update their SPD in connection with the running of IKE (for an
some implementations might update their SPD in connection with the example scenario, see Section 1.1.3).
running of IKE (for an example scenario, see Section 1.1.3).
Traffic Selector (TS) payloads allow endpoints to communicate some of Traffic Selector (TS) payloads allow endpoints to communicate some of
the information from their SPD to their peers. TS payloads specify the information from their SPD to their peers. These must be
the selection criteria for packets that will be forwarded over the communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY]
newly set up SA. This can serve as a consistency check in some uses the SADB_ACQUIRE message). TS payloads specify the selection
scenarios to assure that the SPDs are consistent. In others, it criteria for packets that will be forwarded over the newly set up SA.
guides the dynamic update of the SPD. This can serve as a consistency check in some scenarios to assure
that the SPDs are consistent. In others, it guides the dynamic
update of the SPD.
Two TS payloads appear in each of the messages in the exchange that Two TS payloads appear in each of the messages in the exchange that
creates a Child SA pair. Each TS payload contains one or more creates a Child SA pair. Each TS payload contains one or more
Traffic Selectors. Each Traffic Selector consists of an address Traffic Selectors. Each traffic selector consists of an address
range (IPv4 or IPv6), a port range, and an IP protocol ID. range (IPv4 or IPv6), a port range, and an IP protocol ID.
The first of the two TS payloads is known as TSi (Traffic Selector- The first of the two TS payloads is known as TSi (Traffic Selector-
initiator). The second is known as TSr (Traffic Selector-responder). initiator). The second is known as TSr (Traffic Selector-responder).
TSi specifies the source address of traffic forwarded from (or the TSi specifies the source address of traffic forwarded from (or the
destination address of traffic forwarded to) the initiator of the destination address of traffic forwarded to) the initiator of the
Child SA pair. TSr specifies the destination address of the traffic Child SA pair. TSr specifies the destination address of the traffic
forwarded to (or the source address of the traffic forwarded from) forwarded to (or the source address of the traffic forwarded from)
the responder of the Child SA pair. For example, if the original the responder of the Child SA pair. For example, if the original
initiator requests the creation of a Child SA pair, and wishes to initiator requests the creation of a Child SA pair, and wishes to
skipping to change at line 1970 skipping to change at line 1968
similarly include two traffic selectors in TSr. If the initiator similarly include two traffic selectors in TSr. If the initiator
creates the Child SA pair not in response to an arriving packet, but creates the Child SA pair not in response to an arriving packet, but
rather, say, upon startup, then there may be no specific addresses rather, say, upon startup, then there may be no specific addresses
the initiator prefers for the initial tunnel over any other. In that the initiator prefers for the initial tunnel over any other. In that
case, the first values in TSi and TSr can be ranges rather than case, the first values in TSi and TSr can be ranges rather than
specific values. specific values.
The responder performs the narrowing as follows: The responder performs the narrowing as follows:
o If the responder's policy does not allow it to accept any part of o If the responder's policy does not allow it to accept any part of
the proposed traffic selectors, it responds with TS_UNACCEPTABLE. the proposed traffic selectors, it responds with a TS_UNACCEPTABLE
Notify message.
o If the responder's policy allows the entire set of traffic covered o If the responder's policy allows the entire set of traffic covered
by TSi and TSr, no narrowing is necessary, and the responder can by TSi and TSr, no narrowing is necessary, and the responder can
return the same TSi and TSr values. return the same TSi and TSr values.
o If the responder's policy allows it to accept the first selector o If the responder's policy allows it to accept the first selector
of TSi and TSr, then the responder MUST narrow the traffic of TSi and TSr, then the responder MUST narrow the traffic
selectors to a subset that includes the initiator's first choices. selectors to a subset that includes the initiator's first choices.
In this example above, the responder might respond with TSi being In this example above, the responder might respond with TSi being
(198.51.100.43 - 198.51.100.43) with all ports and IP protocols. (198.51.100.43 - 198.51.100.43) with all ports and IP protocols.
skipping to change at line 2011 skipping to change at line 2010
the responder's policy being that each of those ranges should be sent the responder's policy being that each of those ranges should be sent
over a different SA. Continuing the example above, the responder over a different SA. Continuing the example above, the responder
might have a policy of being willing to tunnel those addresses to and might have a policy of being willing to tunnel those addresses to and
from the initiator, but might require that each address pair be on a from the initiator, but might require that each address pair be on a
separately negotiated Child SA. If the initiator didn't generate its separately negotiated Child SA. If the initiator didn't generate its
request based on the packet, but (for example) upon startup, there request based on the packet, but (for example) upon startup, there
would not be the very specific first traffic selectors helping the would not be the very specific first traffic selectors helping the
responder to select the correct range. There would be no way for the responder to select the correct range. There would be no way for the
responder to determine which pair of addresses should be included in responder to determine which pair of addresses should be included in
this tunnel, and it would have to make a guess or reject the request this tunnel, and it would have to make a guess or reject the request
with a status of SINGLE_PAIR_REQUIRED. with a SINGLE_PAIR_REQUIRED Notify message.
The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA
request is unacceptable because its sender is only willing to accept request is unacceptable because its sender is only willing to accept
traffic selectors specifying a single pair of addresses. The traffic selectors specifying a single pair of addresses. The
requestor is expected to respond by requesting an SA for only the requestor is expected to respond by requesting an SA for only the
specific traffic it is trying to forward. specific traffic it is trying to forward.
Few implementations will have policies that require separate SAs for Few implementations will have policies that require separate SAs for
each address pair. Because of this, if only some parts of the TSi each address pair. Because of this, if only some parts of the TSi
and TSr proposed by the initiator are acceptable to the responder, and TSr proposed by the initiator are acceptable to the responder,
skipping to change at line 2102 skipping to change at line 2101
from the connection and gets access to all of the long-term keys of from the connection and gets access to all of the long-term keys of
the two endpoints cannot reconstruct the keys used to protect the the two endpoints cannot reconstruct the keys used to protect the
conversation without doing a brute force search of the session key conversation without doing a brute force search of the session key
space. space.
Achieving perfect forward secrecy requires that when a connection is Achieving perfect forward secrecy requires that when a connection is
closed, each endpoint MUST forget not only the keys used by the closed, each endpoint MUST forget not only the keys used by the
connection but also any information that could be used to recompute connection but also any information that could be used to recompute
those keys. those keys.
Since the computing of Diffie-Hellman exponentials is computationally Because computing Diffie-Hellman exponentials is computationally
expensive, an endpoint may find it advantageous to reuse those expensive, an endpoint may find it advantageous to reuse those
exponentials for multiple connection setups. There are several exponentials for multiple connection setups. There are several
reasonable strategies for doing this. An endpoint could choose a new reasonable strategies for doing this. An endpoint could choose a new
exponential only periodically though this could result in less-than- exponential only periodically though this could result in less-than-
perfect forward secrecy if some connection lasts for less than the perfect forward secrecy if some connection lasts for less than the
lifetime of the exponential. Or it could keep track of which lifetime of the exponential. Or it could keep track of which
exponential was used for each connection and delete the information exponential was used for each connection and delete the information
associated with the exponential only when some corresponding associated with the exponential only when some corresponding
connection was closed. This would allow the exponential to be reused connection was closed. This would allow the exponential to be reused
without losing perfect forward secrecy at the cost of maintaining without losing perfect forward secrecy at the cost of maintaining
more state. more state.
Whether and when to reuse Diffie-Hellman exponentials are private Whether and when to reuse Diffie-Hellman exponentials are private
decisions in the sense that they will not affect interoperability. decisions in the sense that they will not affect interoperability.
An implementation that reuses exponentials MAY choose to remember the An implementation that reuses exponentials MAY choose to remember the
exponential used by the other endpoint on past exchanges and if one exponential used by the other endpoint on past exchanges and if one
is reused to avoid the second half of the calculation. See [REUSE] is reused to avoid the second half of the calculation. See [REUSE]
for a security analysis of this practice and for additional security for a security analysis of this practice and for additional security
considerations when reusing ephemeral DH keys. considerations when reusing ephemeral Diffie-Hellman keys.
2.13. Generating Keying Material 2.13. Generating Keying Material
In the context of the IKE SA, four cryptographic algorithms are In the context of the IKE SA, four cryptographic algorithms are
negotiated: an encryption algorithm, an integrity protection negotiated: an encryption algorithm, an integrity protection
algorithm, a Diffie-Hellman group, and a pseudo-random function algorithm, a Diffie-Hellman group, and a pseudo-random function
(PRF). The PRF is used for the construction of keying material for (PRF). The PRF is used for the construction of keying material for
all of the cryptographic algorithms used in both the IKE SA and the all of the cryptographic algorithms used in both the IKE SA and the
Child SAs. Child SAs.
skipping to change at line 2146 skipping to change at line 2145
part of the cryptographic transform negotiated (see Section 3.3.5 for part of the cryptographic transform negotiated (see Section 3.3.5 for
the definition of the Key Length transform attribute). For the definition of the Key Length transform attribute). For
algorithms for which not all values are valid keys (such as DES or algorithms for which not all values are valid keys (such as DES or
3DES with key parity), the algorithm by which keys are derived from 3DES with key parity), the algorithm by which keys are derived from
arbitrary values MUST be specified by the cryptographic transform. arbitrary values MUST be specified by the cryptographic transform.
For integrity protection functions based on Hashed Message For integrity protection functions based on Hashed Message
Authentication Code (HMAC), the fixed key size is the size of the Authentication Code (HMAC), the fixed key size is the size of the
output of the underlying hash function. output of the underlying hash function.
It is assumed that PRFs accept keys of any length, but have a It is assumed that PRFs accept keys of any length, but have a
preferred key size. The preferred key size is used as the length of preferred key size. The preferred key size MUST be used as the
SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based on the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based
HMAC construction, the preferred key size is equal to the length of on the HMAC construction, the preferred key size is equal to the
the output of the underlying hash function. Other types of PRFs MUST length of the output of the underlying hash function. Other types of
specify their preferred key size. PRFs MUST specify their preferred key size.
Keying material will always be derived as the output of the Keying material will always be derived as the output of the
negotiated PRF algorithm. Since the amount of keying material needed negotiated PRF algorithm. Since the amount of keying material needed
may be greater than the size of the output of the PRF, the PRF is may be greater than the size of the output of the PRF, the PRF is
used iteratively. The term "prf+" describes a function that outputs used iteratively. The term "prf+" describes a function that outputs
a pseudo-random stream based on the inputs to a pseudo-random a pseudo-random stream based on the inputs to a pseudo-random
function called "prf". function called "prf".
In the following, | indicates concatenation. prf+ is defined as: In the following, | indicates concatenation. prf+ is defined as:
skipping to change at line 2194 skipping to change at line 2193
The shared keys are computed as follows. A quantity called SKEYSEED The shared keys are computed as follows. A quantity called SKEYSEED
is calculated from the nonces exchanged during the IKE_SA_INIT is calculated from the nonces exchanged during the IKE_SA_INIT
exchange and the Diffie-Hellman shared secret established during that exchange and the Diffie-Hellman shared secret established during that
exchange. SKEYSEED is used to calculate seven other secrets: SK_d exchange. SKEYSEED is used to calculate seven other secrets: SK_d
used for deriving new keys for the Child SAs established with this used for deriving new keys for the Child SAs established with this
IKE SA; SK_ai and SK_ar used as a key to the integrity protection IKE SA; SK_ai and SK_ar used as a key to the integrity protection
algorithm for authenticating the component messages of subsequent algorithm for authenticating the component messages of subsequent
exchanges; SK_ei and SK_er used for encrypting (and of course exchanges; SK_ei and SK_er used for encrypting (and of course
decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are
used when generating an AUTH payload. The lengths of SK_d, SK_pi, used when generating an AUTH payload. The lengths of SK_d, SK_pi,
and SK_pr are the preferred key length of the agreed-to PRF. and SK_pr MUST be the preferred key length of the agreed-to PRF.
SKEYSEED and its derivatives are computed as follows: SKEYSEED and its derivatives are computed as follows:
SKEYSEED = prf(Ni | Nr, g^ir) SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
(indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
SK_pi, and SK_pr are taken in order from the generated bits of the SK_pi, and SK_pr are taken in order from the generated bits of the
skipping to change at line 2226 skipping to change at line 2225
The two directions of traffic flow use different keys. The keys used The two directions of traffic flow use different keys. The keys used
to protect messages from the original initiator are SK_ai and SK_ei. to protect messages from the original initiator are SK_ai and SK_ei.
The keys used to protect messages in the other direction are SK_ar The keys used to protect messages in the other direction are SK_ar
and SK_er. and SK_er.
2.15. Authentication of the IKE SA 2.15. Authentication of the IKE SA
When not using extensible authentication (see Section 2.16), the When not using extensible authentication (see Section 2.16), the
peers are authenticated by having each sign (or MAC using a padded peers are authenticated by having each sign (or MAC using a padded
shared secret as the key, as described later in this section) a block shared secret as the key, as described later in this section) a block
of data. For the responder, the octets to be signed start with the of data. In these calculations, IDi' and IDr' are the entire ID
first octet of the first SPI in the header of the second message payloads excluding the fixed header. For the responder, the octets
(IKE_SA_INIT response) and end with the last octet of the last to be signed start with the first octet of the first SPI in the
payload in the second message. Appended to this (for purposes of header of the second message (IKE_SA_INIT response) and end with the
computing the signature) are the initiator's nonce Ni (just the last octet of the last payload in the second message. Appended to
value, not the payload containing it), and the value prf(SK_pr,IDr') this (for purposes of computing the signature) are the initiator's
where IDr' is the responder's ID payload excluding the fixed header. nonce Ni (just the value, not the payload containing it), and the
Note that neither the nonce Ni nor the value prf(SK_pr,IDr') are value prf(SK_pr, IDr'). Note that neither the nonce Ni nor the value
transmitted. Similarly, the initiator signs the first message prf(SK_pr, IDr') are transmitted. Similarly, the initiator signs the
(IKE_SA_INIT request), starting with the first octet of the first SPI first message (IKE_SA_INIT request), starting with the first octet of
in the header and ending with the last octet of the last payload. the first SPI in the header and ending with the last octet of the
Appended to this (for purposes of computing the signature) are the last payload. Appended to this (for purposes of computing the
responder's nonce Nr, and the value prf(SK_pi,IDi'). In the above signature) are the responder's nonce Nr, and the value prf(SK_pi,
calculation, IDi' and IDr' are the entire ID payloads excluding the IDi'). It is critical to the security of the exchange that each side
fixed header. It is critical to the security of the exchange that sign the other side's nonce.
each side sign the other side's nonce.
The initiator's signed octets can be described as: The initiator's signed octets can be described as:
InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage1 = RealIKEHDR | RestOfMessage1 RealMessage1 = RealIKEHDR | RestOfMessage1
NonceRPayload = PayloadHeader | NonceRData NonceRPayload = PayloadHeader | NonceRData
InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData RestOfInitIDPayload = IDType | RESERVED | InitIDData
skipping to change at line 2349 skipping to change at line 2347
While this document references [EAP] with the intent that new methods While this document references [EAP] with the intent that new methods
can be added in the future without updating this specification, some can be added in the future without updating this specification, some
simpler variations are documented here. [EAP] defines an simpler variations are documented here. [EAP] defines an
authentication protocol requiring a variable number of messages. authentication protocol requiring a variable number of messages.
Extensible Authentication is implemented in IKE as additional Extensible Authentication is implemented in IKE as additional
IKE_AUTH exchanges that MUST be completed in order to initialize the IKE_AUTH exchanges that MUST be completed in order to initialize the
IKE SA. IKE SA.
An initiator indicates a desire to use extensible authentication by An initiator indicates a desire to use extensible authentication by
leaving out the AUTH payload from message 3. By including an IDi leaving out the AUTH payload from the first message in the IKE_AUTH
payload but not an AUTH payload, the initiator has declared an exchange. (Note that the AUTH payload is required for non-EAP
identity but has not proven it. If the responder is willing to use authentication, and is thus not marked as optional in the rest of
an extensible authentication method, it will place an Extensible this document.) By including an IDi payload but not an AUTH payload,
Authentication Protocol (EAP) payload in message 4 and defer sending the initiator has declared an identity but has not proven it. If the
SAr2, TSi, and TSr until initiator authentication is complete in a responder is willing to use an extensible authentication method, it
subsequent IKE_AUTH exchange. In the case of a minimal extensible will place an Extensible Authentication Protocol (EAP) payload in the
response of the IKE_AUTH exchange and defer sending SAr2, TSi, and
TSr until initiator authentication is complete in a subsequent
IKE_AUTH exchange. In the case of a minimal extensible
authentication, the initial SA establishment will appear as follows: authentication, the initial SA establishment will appear as follows:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ] <-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERTREQ,] HDR, SK {IDi, [CERTREQ,]
[IDr,] SAi2, [IDr,] SAi2,
TSi, TSr} --> TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH, <-- HDR, SK {IDr, [CERT,] AUTH,
skipping to change at line 2446 skipping to change at line 2447
where g^ir (new) is the shared secret from the ephemeral Diffie- where g^ir (new) is the shared secret from the ephemeral Diffie-
Hellman exchange of this CREATE_CHILD_SA exchange (represented as an Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
octet string in big endian order padded with zeros in the high-order octet string in big endian order padded with zeros in the high-order
bits if necessary to make it the length of the modulus). bits if necessary to make it the length of the modulus).
A single CHILD_SA negotiation may result in multiple security A single CHILD_SA negotiation may result in multiple security
associations. ESP and AH SAs exist in pairs (one in each direction), associations. ESP and AH SAs exist in pairs (one in each direction),
so two SAs are created in a single Child SA negotiation for them. so two SAs are created in a single Child SA negotiation for them.
Furthermore, Child SA negotiation may include some future IPsec Furthermore, Child SA negotiation may include some future IPsec
protocol(s) in addition to, or instead of, ESP or AH (for example, protocol(s) in addition to, or instead of, ESP or AH (for example,
ROHC_INTEG). In any case, keying material for each child SA MUST be ROHC_INTEG as described in [ROHCV2]). In any case, keying material
taken from the expanded KEYMAT using the following rules: for each child SA MUST be taken from the expanded KEYMAT using the
following rules:
o All keys for SAs carrying data from the initiator to the responder o All keys for SAs carrying data from the initiator to the responder
are taken before SAs going from the responder to the initiator. are taken before SAs going from the responder to the initiator.
o If multiple IPsec protocols are negotiated, keying material for o If multiple IPsec protocols are negotiated, keying material for
each Child SA is taken in the order in which the protocol headers each Child SA is taken in the order in which the protocol headers
will appear in the encapsulated packet. will appear in the encapsulated packet.
o If an IPsec protocol requires multiple keys, the order in which o If an IPsec protocol requires multiple keys, the order in which
they are taken from the SA's keying material needs to be described they are taken from the SA's keying material needs to be described
in protocol specification. For ESP and AH, [IPSECARCH] defines in the protocol's specification. For ESP and AH, [IPSECARCH]
the order, namely: the encryption key (if any) MUST be taken from defines the order, namely: the encryption key (if any) MUST be
the first bits and the integrity key (if any) MUST be taken from taken from the first bits and the integrity key (if any) MUST be
the remaining bits. taken from the remaining bits.
Each cryptographic algorithm takes a fixed number of bits of keying Each cryptographic algorithm takes a fixed number of bits of keying
material specified as part of the algorithm, or negotiated in SA material specified as part of the algorithm, or negotiated in SA
payloads (see Section 2.13 for description of key lengths, and payloads (see Section 2.13 for description of key lengths, and
Section 3.3.5 for the definition of the Key Length transform Section 3.3.5 for the definition of the Key Length transform
attribute). attribute).
2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA
(see and Section 1.3.2 and Section 2.8). New initiator and responder (see Section 1.3.2 and Section 2.8). New initiator and responder
SPIs are supplied in the SPI fields in the Proposal structures inside SPIs are supplied in the SPI fields in the Proposal structures inside
the Security Association (SA) payloads (not the SPI fields in the IKE the Security Association (SA) payloads (not the SPI fields in the IKE
header). The TS payloads are omitted when rekeying an IKE SA. header). The TS payloads are omitted when rekeying an IKE SA.
SKEYSEED for the new IKE SA is computed using SK_d from the existing SKEYSEED for the new IKE SA is computed using SK_d from the existing
IKE SA as follows: IKE SA as follows:
SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr)
where g^ir (new) is the shared secret from the ephemeral Diffie- where g^ir (new) is the shared secret from the ephemeral Diffie-
Hellman exchange of this CREATE_CHILD_SA exchange (represented as an Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
skipping to change at line 2496 skipping to change at line 2498
The old and new IKE SA may have selected a different PRF. Because The old and new IKE SA may have selected a different PRF. Because
the rekeying exchange belongs to the old IKE SA, it is the old IKE the rekeying exchange belongs to the old IKE SA, it is the old IKE
SA's PRF that is used to generate SKEYSEED. SA's PRF that is used to generate SKEYSEED.
The main reason for rekeying the IKE SA is to ensure that the The main reason for rekeying the IKE SA is to ensure that the
compromise of old keying material does not provide information about compromise of old keying material does not provide information about
the current keys, or vice versa. Therefore, implementations MUST the current keys, or vice versa. Therefore, implementations MUST
perform a new Diffie-Hellman exchange when rekeying the IKE SA. In perform a new Diffie-Hellman exchange when rekeying the IKE SA. In
other words, an initiator MUST NOT propose the value "NONE" for the other words, an initiator MUST NOT propose the value "NONE" for the
D-H transform, and a responder MUST NOT accept such a proposal. This Diffie-Hellman transform, and a responder MUST NOT accept such a
means that a successful exchange rekeying the IKE SA always includes proposal. This means that a successful exchange rekeying the IKE SA
the KEi/KEr payloads. always includes the KEi/KEr payloads.
The new IKE SA MUST reset its message counters to 0. The new IKE SA MUST reset its message counters to 0.
SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new
exchange, and using the new IKE SA's PRF. exchange, and using the new IKE SA's PRF.
2.19. Requesting an Internal Address on a Remote Network 2.19. Requesting an Internal Address on a Remote Network
Most commonly occurring in the endpoint-to-security-gateway scenario, Most commonly occurring in the endpoint-to-security-gateway scenario,
skipping to change at line 2552 skipping to change at line 2554
(either IPv4 or IPv6) but MAY contain any number of additional (either IPv4 or IPv6) but MAY contain any number of additional
attributes the initiator wants returned in the response. attributes the initiator wants returned in the response.
For example, message from initiator to responder: For example, message from initiator to responder:
CP(CFG_REQUEST)= CP(CFG_REQUEST)=
INTERNAL_ADDRESS() INTERNAL_ADDRESS()
TSi = (0, 0-65535,0.0.0.0-255.255.255.255) TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
TSr = (0, 0-65535,0.0.0.0-255.255.255.255) TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
NOTE: Traffic Selectors contain (protocol, port range, address NOTE: Traffic selectors contain (protocol, port range, address
range). range).
Message from responder to initiator: Message from responder to initiator:
CP(CFG_REPLY)= CP(CFG_REPLY)=
INTERNAL_ADDRESS(192.0.2.202) INTERNAL_ADDRESS(192.0.2.202)
INTERNAL_NETMASK(255.255.255.0) INTERNAL_NETMASK(255.255.255.0)
INTERNAL_SUBNET(192.0.2.0/255.255.255.0) INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535,192.0.2.202-192.0.2.202) TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
TSr = (0, 0-65535,192.0.2.0-192.0.2.255) TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
skipping to change at line 2591 skipping to change at line 2593
FAILED_CP_REQUIRED error. FAILED_CP_REQUIRED error.
2.20. Requesting the Peer's Version 2.20. Requesting the Peer's Version
An IKE peer wishing to inquire about the other peer's IKE software An IKE peer wishing to inquire about the other peer's IKE software
version information MAY use the method below. This is an example of version information MAY use the method below. This is an example of
a configuration request within an INFORMATIONAL exchange, after the a configuration request within an INFORMATIONAL exchange, after the
IKE SA and first Child SA have been created. IKE SA and first Child SA have been created.
An IKE implementation MAY decline to give out version information An IKE implementation MAY decline to give out version information
prior to authentication or even after authentication to prevent prior to authentication or even after authentication in case some
trolling in case some implementation is known to have some security implementation is known to have some security weakness. In that
weakness. In that case, it MUST either return an empty string or no case, it MUST either return an empty string or no CP payload if CP is
CP payload if CP is not supported. not supported.
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK{CP(CFG_REQUEST)} --> HDR, SK{CP(CFG_REQUEST)} -->
<-- HDR, SK{CP(CFG_REPLY)} <-- HDR, SK{CP(CFG_REPLY)}
CP(CFG_REQUEST)= CP(CFG_REQUEST)=
APPLICATION_VERSION("") APPLICATION_VERSION("")
CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar
skipping to change at line 2636 skipping to change at line 2638
DELETE payload. Other error conditions MAY require such an exchange DELETE payload. Other error conditions MAY require such an exchange
if policy dictates that this is needed. If the exchange is if policy dictates that this is needed. If the exchange is
terminated with EAP Failure, an AUTHENTICATION_FAILED notification is terminated with EAP Failure, an AUTHENTICATION_FAILED notification is
not sent. not sent.
2.21.1. Error Handling in IKE_SA_INIT 2.21.1. Error Handling in IKE_SA_INIT
Errors that occur before a cryptographically protected IKE SA is Errors that occur before a cryptographically protected IKE SA is
established need to be handled very carefully. There is a trade-off established need to be handled very carefully. There is a trade-off
between wanting to help the peer to diagnose a problem and thus between wanting to help the peer to diagnose a problem and thus
responding to the error, and wanting to avoid being part of a denial responding to the error, and wanting to avoid being part of a DoS
of service attack based on forged messages. attack based on forged messages.
In an IKE_SA_INIT exchange, any error notification causes the In an IKE_SA_INIT exchange, any error notification causes the
exchange to fail. Note that some error notifications such as COOKIE, exchange to fail. Note that some error notifications such as COOKIE,
INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent
successful exchange. Because all error notifications are completely successful exchange. Because all error notifications are completely
unauthenticated, the recipient should continue trying for some time unauthenticated, the recipient should continue trying for some time
before giving up. The recipient should not immediately act based on before giving up. The recipient should not immediately act based on
the error notification unless corrective actions are defined in this the error notification unless corrective actions are defined in this
specification, such as for COOKIE, INVALID_KE_PAYLOAD, and specification, such as for COOKIE, INVALID_KE_PAYLOAD, and
INVALID_MAJOR_VERSION. INVALID_MAJOR_VERSION.
skipping to change at line 2692 skipping to change at line 2694
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. understand them 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 2742 skipping to change at line 2744
recipient has rebooted and forgotten the existence of an IKE SA. recipient has rebooted and forgotten the existence of an IKE SA.
A peer receiving such an unprotected Notify payload MUST NOT respond A peer receiving such an unprotected Notify payload MUST NOT respond
and MUST NOT change the state of any existing SAs. The message might and MUST NOT change the state of any existing SAs. The message might
be a forgery or might be a response that a genuine correspondent was be a forgery or might be a response that a genuine correspondent was
tricked into sending. A node should treat such a message (and also a tricked into sending. A node should treat such a message (and also a
network message like ICMP destination unreachable) as a hint that network message like ICMP destination unreachable) as a hint that
there might be problems with SAs to that IP address and should there might be problems with SAs to that IP address and should
initiate a liveness check for any such IKE SA. An implementation initiate a liveness check for any such IKE SA. An implementation
SHOULD limit the frequency of such tests to avoid being tricked into SHOULD limit the frequency of such tests to avoid being tricked into
participating in a denial of service attack. participating in a DoS attack.
If an error occurs outside the context of an IKE request (e.g., the If an error occurs outside the context of an IKE request (e.g., the
node is getting ESP messages on a nonexistent SPI), the node SHOULD node is getting ESP messages on a nonexistent SPI), the node SHOULD
initiate an INFORMATIONAL exchange with a Notify payload describing initiate an INFORMATIONAL exchange with a Notify payload describing
the problem. the problem.
A node receiving a suspicious message from an IP address (and port, A node receiving a suspicious message from an IP address (and port,
if NAT traversal is used) with which it has an IKE SA SHOULD send an if NAT traversal is used) with which it has an IKE SA SHOULD send an
IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. IKE Notify payload in an IKE INFORMATIONAL exchange over that SA.
The recipient MUST NOT change the state of any SAs as a result, but The recipient MUST NOT change the state of any SAs as a result, but
skipping to change at line 2769 skipping to change at line 2771
in each packet and a compression parameter index (CPI), the virtual in each packet and a compression parameter index (CPI), the virtual
"compression association" has no life outside the ESP or AH SA that "compression association" has no life outside the ESP or AH SA that
contains it. Compression associations disappear when the contains it. Compression associations disappear when the
corresponding ESP or AH SA goes away. It is not explicitly mentioned corresponding ESP or AH SA goes away. It is not explicitly mentioned
in any DELETE payload. in any DELETE payload.
Negotiation of IP compression is separate from the negotiation of Negotiation of IP compression is separate from the negotiation of
cryptographic parameters associated with a Child SA. A node cryptographic parameters associated with a Child SA. A node
requesting a Child SA MAY advertise its support for one or more requesting a Child SA MAY advertise its support for one or more
compression algorithms through one or more Notify payloads of type compression algorithms through one or more Notify payloads of type
IPCOMP_SUPPORTED. This notification may be included only in a IPCOMP_SUPPORTED. This Notify message may be included only in a
message containing an SA payload negotiating a Child SA and indicates message containing an SA payload negotiating a Child SA and indicates
a willingness by its sender to use IPComp on this SA. The response a willingness by its sender to use IPComp on this SA. The response
MAY indicate acceptance of a single compression algorithm with a MAY indicate acceptance of a single compression algorithm with a
Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT
occur in messages that do not contain SA payloads. occur in messages that do not contain SA payloads.
The data associated with this notification includes a two-octet The data associated with this Notify message includes a two-octet
IPComp CPI followed by a one-octet transform ID optionally followed IPComp CPI followed by a one-octet transform ID optionally followed
by attributes whose length and format are defined by that transform by attributes whose length and format are defined by that transform
ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED
notifications to indicate multiple supported algorithms. A message notifications to indicate multiple supported algorithms. A message
accepting an SA may contain at most one. accepting an SA may contain at most one.
The transform IDs are listed here. The values in the following table The transform IDs are listed here. The values in the following table
are only current as of the publication date of RFC 4306. Other are only current as of the publication date of RFC 4306. Other
values may have been added since then or will be added after the values may have been added since then or will be added after the
publication of this document. Readers should refer to [IKEV2IANA] publication of this document. Readers should refer to [IKEV2IANA]
skipping to change at line 2871 skipping to change at line 2873
decide which internal node should get a given packet. For this decide which internal node should get a given packet. For this
reason, even though IKE packets MUST be sent from and to UDP port 500 reason, even though IKE packets MUST be sent from and to UDP port 500
or 4500, they MUST be accepted coming from any port and responses or 4500, they MUST be accepted coming from any port and responses
MUST be sent to the port from whence they came. This is because the MUST be sent to the port from whence they came. This is because the
ports may be modified as the packets pass through NATs. Similarly, ports may be modified as the packets pass through NATs. Similarly,
IP addresses of the IKE endpoints are generally not included in the IP addresses of the IKE endpoints are generally not included in the
IKE payloads because the payloads are cryptographically protected and IKE payloads because the payloads are cryptographically protected and
could not be transparently modified by NATs. could not be transparently modified by NATs.
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 MUST endpoint that discovers a NAT between it and its correspondent (as
send all subsequent traffic from port 4500, which NATs should not described below) MUST send all subsequent traffic from port 4500,
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 with UDP encapsulation is not either side is using port 4500, sending ESP with UDP encapsulation is
required, but understanding received IKE and ESP packets with UDP not required, but understanding received UDP encapsulated ESP packets
encapsulation is required. UDP encapsulation MUST NOT be done on is required. If NAT-T is supported (that is, if NAT_DETECTION_*_IP
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 payloads were exchanged during IKE_SA_INIT), all devices MUST be able
to receive and process both UDP encapsulated and non-UDP encapsulated to receive and process both UDP encapsulated ESP and non-UDP
packets at any time. Either side can decide whether or not to use encapsulated ESP packets at any time. Either side can decide whether
UDP encapsulation irrespective of the choice made by the other side. or not to use UDP encapsulation for ESP irrespective of the choice
However, if a NAT is detected, both devices MUST send UDP made by the other side. However, if a NAT is detected, both devices
encapsulated packets. 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 IKE MUST listen on port 4500 as well as port 500. IKE MUST
respond to the IP address and port from which packets arrived.
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
the NAT. The location of the payloads in the IKE_SA_INIT packets the NAT. The location of the payloads in the IKE_SA_INIT packets
is just after the Ni and Nr payloads (before the optional CERTREQ is just after the Ni and Nr payloads (before the optional CERTREQ
payload). payload).
o The data associated with the NAT_DETECTION_SOURCE_IP notification o The data associated with the NAT_DETECTION_SOURCE_IP notification
is a SHA-1 digest of the SPIs (in the order they appear in the is a SHA-1 digest of the SPIs (in the order they appear in the
skipping to change at line 2939 skipping to change at line 2937
o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches
the expected value of the source IP and port found from the IP the expected value of the source IP and port found from the IP
header of the packet containing the payload, it means that the header of the packet containing the payload, it means that the
system sending those payloads is behind NAT (i.e., someone along system sending those payloads is behind NAT (i.e., someone along
the route changed the source address of the original packet to the route changed the source address of the original packet to
match the address of the NAT box). In this case, the system match the address of the NAT box). In this case, the system
receiving the payloads should allow dynamic update of the other receiving the payloads should allow dynamic update of the other
systems' IP address, as described later. systems' IP address, as described later.
o The IKE initiator MUST check these payloads if present and if they o The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or
do not match the addresses in the outer packet MUST tunnel all NAT_DETECTION_DESTINATION_IP payloads if present and if they do
future IKE and ESP packets associated with this IKE SA over UDP not match the addresses in the outer packet MUST tunnel all future
port 4500. IKE and ESP packets associated with this IKE SA over UDP port
4500.
o To tunnel IKE packets over UDP port 4500, the IKE header has four o To tunnel IKE packets over UDP port 4500, the IKE header has four
octets of zero prepended and the result immediately follows the octets of zero prepended and the result immediately follows the
UDP header. To tunnel ESP packets over UDP port 4500, the ESP UDP header. To tunnel ESP packets over UDP port 4500, the ESP
header immediately follows the UDP header. Since the first four header immediately follows the UDP header. Since the first four
octets of the ESP header contain the SPI, and the SPI cannot octets of the ESP header contain the SPI, and the SPI cannot
validly be zero, it is always possible to distinguish ESP and IKE validly be zero, it is always possible to distinguish ESP and IKE
messages. messages.
o Implementations MUST process received UDP-encapsulated ESP packets o Implementations MUST process received UDP-encapsulated ESP packets
even when no NAT was detected. even when no NAT was detected.
o The original source and destination IP address required for the o The original source and destination IP address required for the
transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])
are obtained from the Traffic Selectors associated with the are obtained from the traffic selectors associated with the
exchange. In the case of transport mode NAT traversal, the exchange. In the case of transport mode NAT traversal, the
Traffic Selectors MUST contain exactly one IP address, which is traffic selectors MUST contain exactly one IP address, which is
then used as the original IP address. This is covered in greater then used as the original IP address. This is covered in greater
detail in Section 2.23.1. detail in Section 2.23.1.
o There are cases where a NAT box decides to remove mappings that o There are cases where a NAT box decides to remove mappings that
are still alive (for example, the keepalive interval is too long, are still alive (for example, the keepalive interval is too long,
or the NAT box is rebooted). This will be apparent to a host if or the NAT box is rebooted). This will be apparent to a host if
it receives a packet whose integrity protection validates, but has it receives a packet whose integrity protection validates, but has
a different port, address, or both from the one that was a different port, address, or both from the one that was
associated with the SA in the validated packet. When such a associated with the SA in the validated packet. When such a
validated packet is found, a host that does not support other validated packet is found, a host that does not support other
methods of recovery such as MOBIKE [MOBIKE], and that is not methods of recovery such as MOBIKE [MOBIKE], and that is not
behind a NAT, SHOULD send all packets (including retransmission behind a NAT, SHOULD send all packets (including retransmission
packets) to the IP address and port in the validated packet, and packets) to the IP address and port in the validated packet, and
SHOULD store this as the new address and port combination for the SHOULD store this as the new address and port combination for the
SA (that is, they SHOULD dynamically update the address). A host SA (that is, they SHOULD dynamically update the address). A host
behind a NAT SHOULD NOT do this type of dynamic address update if behind a NAT SHOULD NOT do this type of dynamic address update if
a validated packet has different port and/or address values a validated packet has different port and/or address values
because it opens a possible denial of service attack (such as because it opens a possible DoS attack (such as allowing an
allowing an attacker to break the connection with a single attacker to break the connection with a single packet). Also,
packet). Also, dynamic address update should only be done in dynamic address update should only be done in response to a new
response to a new packet; otherwise, an attacker can revert the packet; otherwise, an attacker can revert the addresses with old
addresses with old replayed packets. Because of this, dynamic replayed packets. Because of this, dynamic update can only be
update can only be done safely if replay protection is enabled. done safely if replay protection is enabled. When IKEv2 is used
When IKEv2 is used with MOBIKE, dynamically updating the addresses with MOBIKE, dynamically updating the addresses described above
described above interferes with MOBIKE's way of recovering from interferes with MOBIKE's way of recovering from the same
the same situation. See Section 3.8 of [MOBIKE] for more situation. See Section 3.8 of [MOBIKE] for more information.
information.
2.23.1. Transport Mode NAT Traversal 2.23.1. Transport Mode NAT Traversal
Transport mode used with NAT Traversal requires special handling of Transport mode used with NAT Traversal requires special handling of
the traffic selectors used in the IKEv2. The complete scenario looks the traffic selectors used in the IKEv2. The complete scenario looks
like: like:
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
|Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server|
|node |<------>| A |<---------->| B |<------->| | |node |<------>| A |<---------->| B |<------->| |
skipping to change at line 3020 skipping to change at line 3018
the outer address of the NAT B, that is, the IPN2 address. If NAT B the outer address of the NAT B, that is, the IPN2 address. If NAT B
is a static NAT, then its address can be configured to the client's is a static NAT, then its address can be configured to the client's
configuration. Other options would be find it using some other configuration. Other options would be find it using some other
protocol (like DNS), but those are outside of scope of IKEv2. protocol (like DNS), but those are outside of scope of IKEv2.
In this scenario, both client and server are configured to use In this scenario, both client and server are configured to use
transport mode for the traffic originating from the client node and transport mode for the traffic originating from the client node and
destined to the server. destined to the server.
When the client starts creating the IKEv2 SA and Child SA for sending When the client starts creating the IKEv2 SA and Child SA for sending
traffic to the server, it may hve a triggering packet with source IP traffic to the server, it may have a triggering packet with source IP
address of IP1, and a destination IP address of IPN2. Its PAD and address of IP1, and a destination IP address of IPN2. Its PAD and
SPD needs to have configuration matching those addresses (or wildcard SPD needs to have configuration matching those addresses (or wildcard
entries covering them). Because this is transport mode, it uses entries covering them). Because this is transport mode, it uses
exactly same addresses as the traffic selectors and outer IP address exactly same addresses as the traffic selectors and outer IP address
of the IKE packets. For transport mode, it MUST use exactly one IP of the IKE packets. For transport mode, it MUST use exactly one IP
address in the TSi and TSr payloads. It can have multiple traffic address in the TSi and TSr payloads. It can have multiple traffic
selectors if it has, for example, multiple port ranges that it wants selectors if it has, for example, multiple port ranges that it wants
to negotiate, but all TSi entries must use IP1-IP1 range as the IP to negotiate, but all TSi entries must use IP1-IP1 range as the IP
addresses, and all TSr entries must have the IPN2-IPN2 range as IP addresses, and all TSr entries must have the IPN2-IPN2 range as IP
addresses. The first traffic selector of TSi and TSr SHOULD have addresses. The first traffic selector of TSi and TSr SHOULD have
very specific traffic selectors including protocol and port numbers, very specific traffic selectors including protocol and port numbers,
such as from the packet triggering the request. such as from the packet triggering the request.
NAT A will then replace the source address of the IKE packet from IP1 NAT A will then replace the source address of the IKE packet from IP1
to IPN1, and NAT B will replace the destination address of the IKE to IPN1, and NAT B will replace the destination address of the IKE
packet from IPN2 to IP2, so when the packet arrives to the server it packet from IPN2 to IP2, so when the packet arrives to the server it
will still have the exactly same traffic selectors which were sent by will still have the exactly same traffic selectors which were sent by
the client, but the IP address of the IKE packet has been replaced to the client, but the IP address of the IKE packet has been replaced to
IPN1 and IP2. IPN1 and IP2.
When the server receives this packet, it normally looks the PAD based When the server receives this packet, it normally looks in the Peer
Authorization Database (PAD) described in RFC 4301 [IPSECARCH] based
on the ID and then searches the SPD based on the traffic selectors. on the ID and then searches the SPD based on the traffic selectors.
Because IP1 does not really mean anything to the server (it is the Because IP1 does not really mean anything to the server (it is the
address client has behind the NAT), it is useless to do a lookup address client has behind the NAT), it is useless to do a lookup
based on that if transport mode is used. On the other hand, the based on that if transport mode is used. On the other hand, the
server cannot know whether transport mode is allowed by its policy server cannot know whether transport mode is allowed by its policy
before it finds the matching SPD entry. before it finds the matching SPD entry.
In this case, the server should first check that the initiator In this case, the server should first check that the initiator
requested transport mode, and then do address substitution on the requested transport mode, and then do address substitution on the
traffic selectors. It needs to first store the old traffic selector traffic selectors. It needs to first store the old traffic selector
skipping to change at line 3082 skipping to change at line 3081
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 NATs outer addresses. SPD entries, for example, for different known NAT's 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 3369 skipping to change at line 3368
in the flags field being set. The bits are as follows: in the flags field being set. The bits are as follows:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|X|X|R|V|I|X|X|X| |X|X|R|V|I|X|X|X|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
In the description below, a bit being 'set' means its value is In the description below, a bit being 'set' means its value is
'1', while 'cleared' means its value is '0'. "X" bits MUST be '1', while 'cleared' means its value is '0'. "X" bits MUST be
cleared when sending and MUST be ignored on receipt. cleared when sending and MUST be ignored on receipt.
* R(esponse) - This bit indicates that this message is a response * R (Response) - This bit indicates that this message is a
to a message containing the same message ID. This bit MUST be response to a message containing the same message ID. This bit
cleared in all request messages and MUST be set in all MUST be cleared in all request messages and MUST be set in all
responses. An IKE endpoint MUST NOT generate a response to a responses. An IKE endpoint MUST NOT generate a response to a
message that is marked as being a response. message that is marked as being a response (with one exception;
see Section 2.21.2).
* V(ersion) - This bit indicates that the transmitter is capable * V (Version) - This bit indicates that the transmitter is
of speaking a higher major version number of the protocol than capable of speaking a higher major version number of the
the one indicated in the major version number field. protocol than the one indicated in the major version number
Implementations of IKEv2 MUST clear this bit when sending and field. Implementations of IKEv2 MUST clear this bit when
MUST ignore it in incoming messages. sending and MUST ignore it in incoming messages.
* I(nitiator) - This bit MUST be set in messages sent by the * I (Initiator) - This bit MUST be set in messages sent by the
original initiator of the IKE SA and MUST be cleared in original initiator of the IKE SA and MUST be cleared in
messages sent by the original responder. It is used by the messages sent by the original responder. It is used by the
recipient to determine which eight octets of the SPI were recipient to determine which eight octets of the SPI were
generated by the recipient. This bit changes to reflect who generated by the recipient. This bit changes to reflect who
initiated the last rekey of the IKE SA. initiated the last rekey of the IKE SA.
o Message ID (4 octets) - Message identifier used to control o Message ID (4 octets, unsigned integer) - Message identifier used
retransmission of lost packets and matching of requests and to control retransmission of lost packets and matching of requests
responses. It is essential to the security of the protocol and responses. It is essential to the security of the protocol
because it is used to prevent message replay attacks. See because it is used to prevent message replay attacks. See
Section 2.1 and Section 2.2. Section 2.1 and Section 2.2.
o Length (4 octets) - Length of total message (header + payloads) in o Length (4 octets, unsigned integer) - Length of total message
octets. (header + payloads) in octets.
3.2. Generic Payload Header 3.2. Generic Payload Header
Each IKE payload defined in Section 3.3 through Section 3.16 begins Each IKE payload defined in Section 3.3 through Section 3.16 begins
with a generic payload header, shown in Figure 5. Figures for each with a generic payload header, shown in Figure 5. Figures for each
payload below will include the generic payload header, but for payload below will include the generic payload header, but for
brevity the description of each field will be omitted. brevity the description of each field will be omitted.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at line 3477 skipping to change at line 3477
not setting the critical bit for payloads defined in this document not setting the critical bit for payloads defined in this document
is that all implementations MUST understand all payload types is that all implementations MUST understand all payload types
defined in this document and therefore must ignore the Critical defined in this document and therefore must ignore the Critical
bit's value. Skipped payloads are expected to have valid Next bit's value. Skipped payloads are expected to have valid Next
Payload and Payload Length fields. See Section 2.5 for more Payload and Payload Length fields. See Section 2.5 for more
information on this bit. information on this bit.
o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on
receipt. receipt.
o Payload Length (2 octets) - Length in octets of the current o Payload Length (2 octets, unsigned integer) - Length in octets of
payload, including the generic payload header. the current payload, including the generic payload header.
Many payloads contain fields marked as "RESERVED". Some payloads in Many payloads contain fields marked as "RESERVED". Some payloads in
IKEv2 (and historically in IKEv1) are not aligned to 4-octet IKEv2 (and historically in IKEv1) are not aligned to 4-octet
boundaries. boundaries.
3.3. Security Association Payload 3.3. Security Association Payload
The Security Association Payload, denoted SA in this document, is The Security Association Payload, denoted SA in this document, is
used to negotiate attributes of a security association. Assembly of used to negotiate attributes of a security association. Assembly of
Security Association Payloads requires great peace of mind. An SA Security Association Payloads requires great peace of mind. An SA
skipping to change at line 3516 skipping to change at line 3516
allow for multiple possible combinations of algorithms to be encoded allow for multiple possible combinations of algorithms to be encoded
in a single SA. Sometimes there is a choice of multiple algorithms, in a single SA. Sometimes there is a choice of multiple algorithms,
whereas other times there is a combination of algorithms. For whereas other times there is a combination of algorithms. For
example, an initiator might want to propose using ESP with either example, an initiator might want to propose using ESP with either
(3DES and HMAC_MD5) or (AES and HMAC_SHA1). (3DES and HMAC_MD5) or (AES and HMAC_SHA1).
One of the reasons the semantics of the SA payload has changed from One of the reasons the semantics of the SA payload has changed from
ISAKMP and IKEv1 is to make the encodings more compact in common ISAKMP and IKEv1 is to make the encodings more compact in common
cases. cases.
The Proposal structure contains within it a Proposal # and an IPsec The Proposal structure contains within it a Proposal Num and an IPsec
protocol ID. Each structure MUST have a proposal number one (1) protocol ID. Each structure MUST have a proposal number one (1)
greater than the previous structure. The first Proposal in the greater than the previous structure. The first Proposal in the
initiator's SA payload MUST have a Proposal # of one (1). One reason initiator's SA payload MUST have a Proposal Num of one (1). One
to use multiple proposals is to propose both standard crypto ciphers reason to use multiple proposals is to propose both standard crypto
and combined-mode ciphers. Combined-mode ciphers include both ciphers and combined-mode ciphers. Combined-mode ciphers include
integrity and encryption in a single encryption algorithm, and MUST both integrity and encryption in a single encryption algorithm, and
either offer no integrity algorithm or a single integrity algorithm MUST either offer no integrity algorithm or a single integrity
of "none", with no integrity algorithm being the RECOMMENDED method. algorithm of "none", with no integrity algorithm being the
If an initiator wants to propose both combined-mode ciphers and RECOMMENDED method. If an initiator wants to propose both combined-
normal ciphers, it must include two proposals: one will have all the mode ciphers and normal ciphers, it must include two proposals: one
combined-mode ciphers, and the other will have all the normal ciphers will have all the combined-mode ciphers, and the other will have all
with the integrity algorithms. For example, one such proposal would the normal ciphers with the integrity algorithms. For example, one
have two proposal structures. Proposal 1 is ESP with AES-128, AES- such proposal would have two proposal structures. Proposal 1 is ESP
192, and AES-256 bits in CBC mode, with either HMAC-SHA1-96 or with AES-128, AES-192, and AES-256 bits in CBC mode, with either
XCBC-96 as the integrity algorithm; Proposal 2 is AES-128 or AES-256 HMAC-SHA1-96 or XCBC-96 as the integrity algorithm; Proposal 2 is
in GCM mode with an 8-octet ICV. Both proposals allow but do not AES-128 or AES-256 in GCM mode with an 8-octet ICV. Both proposals
require the use of ESN. This can be illustrated as: allow but do not require the use of ESN (extended sequence numbers).
This can be illustrated as:
SA Payload SA Payload
| |
+--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
| | 7 transforms, SPI = 0x052357bb ) | | 7 transforms, SPI = 0x052357bb )
| | | |
| +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 128 ) | | +-- Attribute ( Key Length = 128 )
| | | |
| +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Transform ENCR ( Name = ENCR_AES_CBC )
skipping to change at line 3630 skipping to change at line 3631
The payload type for the Security Association Payload is thirty three The payload type for the Security Association Payload is thirty three
(33). (33).
3.3.1. Proposal Substructure 3.3.1. Proposal Substructure
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 2 | RESERVED | Proposal Length | | 0 (last) or 2 | RESERVED | Proposal Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proposal # | Protocol ID | SPI Size |# of Transforms| | Proposal Num | Protocol ID | SPI Size |Num Transforms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (variable) ~ ~ SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <Transforms> ~ ~ <Transforms> ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Proposal Substructure Figure 7: Proposal Substructure
skipping to change at line 3652 skipping to change at line 3653
last Proposal Substructure in the SA. This syntax is inherited last Proposal Substructure in the SA. This syntax is inherited
from ISAKMP, but is unnecessary because the last Proposal could be from ISAKMP, but is unnecessary because the last Proposal could be
identified from the length of the SA. The value (2) corresponds identified from the length of the SA. The value (2) corresponds
to a Payload Type of Proposal in IKEv1, and the first four octets to a Payload Type of Proposal in IKEv1, and the first four octets
of the Proposal structure are designed to look somewhat like the of the Proposal structure are designed to look somewhat like the
header of a Payload. header of a Payload.
o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on
receipt. receipt.
o Proposal Length (2 octets) - Length of this proposal, including o Proposal Length (2 octets, unsigned integer) - Length of this
all transforms and attributes that follow. proposal, including all transforms and attributes that follow.
o Proposal # (1 octet) - When a proposal is made, the first proposal o Proposal Num (1 octet) - When a proposal is made, the first
in an SA payload MUST be #1, and subsequent proposals MUST be one proposal in an SA payload MUST be 1, and subsequent proposals MUST
more than the previous proposal (indicating an OR of the two be one more than the previous proposal (indicating an OR of the
proposals). When a proposal is accepted, the proposal number in two proposals). When a proposal is accepted, the proposal number
the SA payload MUST match the number on the proposal sent that was in the SA payload MUST match the number on the proposal sent that
accepted. was accepted.
o Protocol ID (1 octet) - Specifies the IPsec protocol identifier o Protocol ID (1 octet) - Specifies the IPsec protocol identifier
for the current negotiation. The values in the following table for the current negotiation. The values in the following table
are only current as of the publication date of RFC 4306. Other are only current as of the publication date of RFC 4306. Other
values may have been added since then or will be added after the values may have been added since then or will be added after the
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 header. During MUST be zero; the SPI is obtained from the outer IP header.
subsequent negotiations, it is equal to the size, in octets, of During subsequent negotiations, it is equal to the size, in
the SPI of the corresponding protocol (8 for IKE, 4 for ESP and octets, of the SPI of the corresponding protocol (8 for IKE, 4 for
AH). ESP and AH).
o # of 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.
3.3.2. Transform Substructure 3.3.2. Transform Substructure
skipping to change at line 3886 skipping to change at line 3887
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
allows specification (by a user or system administrator) of Diffie- allows specification (by a user or system administrator) of Diffie-
Hellman (DH) parameters (the generator, modulus, and exponent lengths Hellman parameters (the generator, modulus, and exponent lengths and
and values) for new DH groups. Implementations SHOULD provide a values) for new Diffie-Hellman groups. Implementations SHOULD
management interface through which these parameters and the provide a management interface through which these parameters and the
associated transform IDs may be entered (by a user or system associated transform IDs may be entered (by a user or system
administrator), to enable negotiating such groups. administrator), to enable negotiating such groups.
All implementations of IKEv2 MUST include a management facility that All implementations of IKEv2 MUST include a management facility that
enables a user or system administrator to specify the suites that are enables a user or system administrator to specify the suites that are
acceptable for use with IKE. Upon receipt of a payload with a set of acceptable for use with IKE. Upon receipt of a payload with a set of
transform IDs, the implementation MUST compare the transmitted transform IDs, the implementation MUST compare the transmitted
transform IDs against those locally configured via the management transform IDs against those locally configured via the management
controls, to verify that the proposed suite is acceptable based on controls, to verify that the proposed suite is acceptable based on
local policy. The implementation MUST reject SA proposals that are local policy. The implementation MUST reject SA proposals that are
skipping to change at line 4036 skipping to change at line 4037
number (KE) in the same message. If in the initial exchange the number (KE) in the same message. If in the initial exchange the
initiator offers to use one of several Diffie-Hellman groups, it initiator offers to use one of several Diffie-Hellman groups, it
SHOULD pick the one the responder is most likely to accept and SHOULD pick the one the responder is most likely to accept and
include a KE corresponding to that group. If the responder selects a include a KE corresponding to that group. If the responder selects a
proposal using a different Diffie-Hellman group (other than NONE), proposal using a different Diffie-Hellman group (other than NONE),
the responder will indicate the correct group in the response and the the responder will indicate the correct group in the response and the
initiator SHOULD pick an element of that group for its KE value when initiator SHOULD pick an element of that group for its KE value when
retrying the first message. It SHOULD, however, continue to propose retrying the first message. It SHOULD, however, continue to propose
its full supported set of groups in order to prevent a man-in-the- its full supported set of groups in order to prevent a man-in-the-
middle downgrade attack. If one of the proposals offered is for the middle downgrade attack. If one of the proposals offered is for the
Diffie-Hellman group of NONE, the responder MUST ignore the Diffie-Hellman group of NONE, and the responder selects that Diffie-
initiator's KE payload and omit the KE payload from the response. Hellman group, then it MUST ignore the initiator's KE payload and
omit the KE payload from the response.
3.4. Key Exchange Payload 3.4. Key Exchange Payload
The Key Exchange Payload, denoted KE in this document, is used to The Key Exchange Payload, denoted KE in this document, is used to
exchange Diffie-Hellman public numbers as part of a Diffie-Hellman exchange Diffie-Hellman public numbers as part of a Diffie-Hellman
key exchange. The Key Exchange Payload consists of the IKE generic key exchange. The Key Exchange Payload consists of the IKE generic
payload header followed by the Diffie-Hellman public value itself. payload header followed by the Diffie-Hellman public value itself.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH Group # | RESERVED | | Diffie-Hellman Group Num | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Key Exchange Data ~ ~ Key Exchange Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Key Exchange Payload Format Figure 10: Key Exchange Payload Format
A key exchange payload is constructed by copying one's Diffie-Hellman A key exchange payload is constructed by copying one's Diffie-Hellman
public value into the "Key Exchange Data" portion of the payload. public value into the "Key Exchange Data" portion of the payload.
The length of the Diffie-Hellman public value for MODP groups MUST be The length of the Diffie-Hellman public value for MODP groups MUST be
equal to the length of the prime modulus over which the equal to the length of the prime modulus over which the
exponentiation was performed, prepending zero bits to the value if exponentiation was performed, prepending zero bits to the value if
necessary. necessary.
The DH Group # identifies the Diffie-Hellman group in which the Key The Diffie-Hellman Group Num identifies the Diffie-Hellman group in
Exchange Data was computed (see Section 3.3.2). This Group # MUST which the Key Exchange Data was computed (see Section 3.3.2). This
match a DH Group specified in a proposal in the SA payload that is Diffie-Hellman Group Num MUST match a Diffie-Hellman Group specified
sent in the same message, and SHOULD match the DH group in the first in a proposal in the SA payload that is sent in the same message, and
group in the first proposal, if such exists. If none of the SHOULD match the Diffie-Hellman group in the first group in the first
proposals in that SA payload specifies a DH Group, the KE payload proposal, if such exists. If none of the proposals in that SA
MUST NOT be present. If the selected proposal uses a different payload specifies a Diffie-Hellman Group, the KE payload MUST NOT be
Diffie-Hellman group (other than NONE), the message MUST be rejected present. If the selected proposal uses a different Diffie-Hellman
with a Notify payload of type INVALID_KE_PAYLOAD. See also group (other than NONE), the message MUST be rejected with a Notify
Section 1.2 and Section 2.7. payload of type INVALID_KE_PAYLOAD. See also Section 1.2 and
Section 2.7.
The payload type for the Key Exchange payload is thirty four (34). The payload type for the Key Exchange payload is thirty four (34).
3.5. Identification Payloads 3.5. Identification Payloads
The Identification Payloads, denoted IDi and IDr in this document, The Identification Payloads, denoted IDi and IDr in this document,
allow peers to assert an identity to one another. This identity may allow peers to assert an identity to one another. This identity may
be used for policy lookup, but does not necessarily have to match be used for policy lookup, but does not necessarily have to match
anything in the CERT payload; both fields may be used by an anything in the CERT payload; both fields may be used by an
implementation to perform access control decisions. When using the implementation to perform access control decisions. When using the
skipping to change at line 4165 skipping to change at line 4168
ID_RFC822_ADDR is, "jsmith@example.com". The string MUST NOT ID_RFC822_ADDR is, "jsmith@example.com". The string MUST NOT
contain any terminators. Because of [EAI], implementations would contain any terminators. Because of [EAI], implementations would
be wise to treat this field as UTF-8 encoded text, not as be wise to treat this field as UTF-8 encoded text, not as
pure ASCII. pure ASCII.
ID_IPV6_ADDR 5 ID_IPV6_ADDR 5
A single sixteen (16) octet IPv6 address. A single sixteen (16) octet IPv6 address.
ID_DER_ASN1_DN 9 ID_DER_ASN1_DN 9
The binary Distinguished Encoding Rules (DER) encoding of an The binary Distinguished Encoding Rules (DER) encoding of an
ASN.1 X.500 Distinguished Name [X.501]. ASN.1 X.500 Distinguished Name [PKIX].
ID_DER_ASN1_GN 10 ID_DER_ASN1_GN 10
The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX].
ID_KEY_ID 11 ID_KEY_ID 11
An opaque octet stream which may be used to pass vendor- An opaque octet stream which may be used to pass vendor-
specific information necessary to do certain proprietary specific information necessary to do certain proprietary
types of identification. types of identification.
Two implementations will interoperate only if each can generate a Two implementations will interoperate only if each can generate a
type of ID acceptable to the other. To assure maximum type of ID acceptable to the other. To assure maximum
interoperability, implementations MUST be configurable to send at interoperability, implementations MUST be configurable to send at
least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
MUST be configurable to accept all of these types. Implementations MUST be configurable to accept all of these four types.
SHOULD be capable of generating and accepting all of these types. Implementations SHOULD be capable of generating and accepting all of
IPv6-capable implementations MUST additionally be configurable to these types. IPv6-capable implementations MUST additionally be
accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY
to send only ID_IPV6_ADDR instead of ID_IPV6_ADDR for IP addresses. be configurable to send only ID_IPV6_ADDR instead of ID_IPV4_ADDR for
IP addresses.
EAP [EAP] does not mandate the use of any particular type of EAP [EAP] does not mandate the use of any particular type of
identifier, but often EAP is used with Network Access Identifiers identifier, but often EAP is used with Network Access Identifiers
(NAIs) defined in [NAI]. Although NAIs look a bit like email (NAIs) defined in [NAI]. Although NAIs look a bit like email
addresses (e.g., "joe@example.com"), the syntax is not exactly the addresses (e.g., "joe@example.com"), the syntax is not exactly the
same as the syntax of email address in [MAILFORMAT]. For those NAIs same as the syntax of email address in [MAILFORMAT]. For those NAIs
that include the realm component, the ID_RFC822_ADDR identification that include the realm component, the ID_RFC822_ADDR identification
type SHOULD be used. Responder implementations should not attempt to type SHOULD be used. Responder implementations should not attempt to
verify that the contents actually conform to the exact syntax given verify that the contents actually conform to the exact syntax given
in [MAILFORMAT], but instead should accept any reasonable-looking in [MAILFORMAT], but instead should accept any reasonable-looking
NAI. For NAIs that do not include the realm component,the ID_KEY_ID NAI. For NAIs that do not include the realm component, the ID_KEY_ID
identification type SHOULD be used. identification type SHOULD be used.
3.6. Certificate Payload 3.6. Certificate Payload
The Certificate Payload, denoted CERT in this document, provides a The Certificate Payload, denoted CERT in this document, provides a
means to transport certificates or other authentication-related means to transport certificates or other authentication-related
information via IKE. Certificate payloads SHOULD be included in an information via IKE. Certificate payloads SHOULD be included in an
exchange if certificates are available to the sender. The Hash and exchange if certificates are available to the sender. The Hash and
URL formats of the Certificate payloads should be used in case the URL formats of the Certificate payloads should be used in case the
peer has indicated an ability to retrieve this information from peer has indicated an ability to retrieve this information from
skipping to change at line 4276 skipping to change at line 4280
certificate revocation list. certificate revocation list.
o "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER- o "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER-
encoded RSAPublicKey structure (see [RSA] and [PKCS1]). encoded RSAPublicKey structure (see [RSA] and [PKCS1]).
o Hash and URL encodings allow IKE messages to remain short by o Hash and URL encodings allow IKE messages to remain short by
replacing long data structures with a 20 octet SHA-1 hash (see replacing long data structures with a 20 octet SHA-1 hash (see
[SHA]) of the replaced value followed by a variable-length URL [SHA]) of the replaced value followed by a variable-length URL
that resolves to the DER encoded data structure itself. This that resolves to the DER encoded data structure itself. This
improves efficiency when the endpoints have certificate data improves efficiency when the endpoints have certificate data
cached and makes IKE less subject to denial of service attacks cached and makes IKE less subject to DoS attacks that become
that become easier to mount when IKE messages are large enough to easier to mount when IKE messages are large enough to require IP
require IP fragmentation [DOSUDPPROT]. fragmentation [DOSUDPPROT].
The "Hash and URL of a bundle" type uses the following ASN.1 The "Hash and URL of a bundle" type uses the following ASN.1
definition for the X.509 bundle: definition for the X.509 bundle:
CertBundle CertBundle
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cert-bundle(34) } id-mod-cert-bundle(34) }
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
skipping to change at line 4309 skipping to change at line 4313
cert [0] Certificate, cert [0] Certificate,
crl [1] CertificateList } crl [1] CertificateList }
CertificateBundle ::= SEQUENCE OF CertificateOrCRL CertificateBundle ::= SEQUENCE OF CertificateOrCRL
END END
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
two Hash and URL formats (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 method for hash-and-URL lookup.
The behavior of other URL methods is not currently specified, and The behavior of other URL methods is not currently specified, and
such methods SHOULD NOT be used in the absence of a document such methods SHOULD NOT be used in the absence of a document
specifying them. specifying them.
skipping to change at line 4505 skipping to change at line 4509
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Nonce Payload Format Figure 15: Nonce Payload Format
o Nonce Data (variable length) - Contains the random data generated o Nonce Data (variable length) - Contains the random data generated
by the transmitting entity. by the transmitting entity.
The payload type for the Nonce Payload is forty (40). The payload type for the Nonce Payload is forty (40).
The size the Nonce Data MUST be between 16 and 256 octets inclusive. The size of the Nonce Data MUST be between 16 and 256 octets
Nonce values MUST NOT be reused. inclusive. Nonce values MUST NOT be reused.
3.10. Notify Payload 3.10. Notify Payload
The Notify Payload, denoted N in this document, is used to transmit The Notify Payload, denoted N in this document, is used to transmit
informational data, such as error conditions and state transitions, informational data, such as error conditions and state transitions,
to an IKE peer. A Notify Payload may appear in a response message to an IKE peer. A Notify Payload may appear in a response message
(usually specifying why a request was rejected), in an INFORMATIONAL (usually specifying why a request was rejected), in an INFORMATIONAL
Exchange (to report an error not in an IKE request), or in any other Exchange (to report an error not in an IKE request), or in any other
message to indicate sender capabilities or to modify the meaning of message to indicate sender capabilities or to modify the meaning of
the request. the request.
skipping to change at line 4557 skipping to change at line 4561
o SPI Size (1 octet) - Length in octets of the SPI as defined by the o SPI Size (1 octet) - Length in octets of the SPI as defined by the
IPsec protocol ID or zero if no SPI is applicable. For a IPsec protocol ID or zero if no SPI is applicable. For a
notification concerning the IKE SA, the SPI Size MUST be zero and notification concerning the IKE SA, the SPI Size MUST be zero and
the field must be empty. the field must be empty.
o Notify Message Type (2 octets) - Specifies the type of o Notify Message Type (2 octets) - Specifies the type of
notification message. notification message.
o SPI (variable length) - Security Parameter Index. o SPI (variable length) - Security Parameter Index.
o Notification Data (variable length) - Informational or error data o Notification Data (variable length) - Status or error data
transmitted in addition to the Notify Message Type. Values for transmitted in addition to the Notify Message Type. Values for
this field are type specific (see below). this field are type specific (see below).
The payload type for the Notify Payload is forty one (41). The payload type for the Notify Payload is forty one (41).
3.10.1. Notify Message Types 3.10.1. Notify Message Types
Notification information can be error messages specifying why an SA Notification information can be error messages specifying why an SA
could not be established. It can also be status data that a process could not be established. It can also be status data that a process
managing an SA database wishes to communicate with a peer process. managing an SA database wishes to communicate with a peer process.
skipping to change at line 4607 skipping to change at line 4611
INVALID_IKE_SPI 4 INVALID_IKE_SPI 4
See Section 2.21. See Section 2.21.
INVALID_MAJOR_VERSION 5 INVALID_MAJOR_VERSION 5
See Section 2.5. See Section 2.5.
INVALID_SYNTAX 7 INVALID_SYNTAX 7
Indicates the IKE message that was received was invalid because Indicates the IKE message that was received was invalid because
some type, length, or value was out of range or because the some type, length, or value was out of range or because the
request was rejected for policy reasons. To avoid a denial of request was rejected for policy reasons. To avoid a DoS
service attack using forged messages, this status may only be attack using forged messages, this status may only be
returned for and in an encrypted packet if the message ID and returned for and in an encrypted packet if the message ID and
cryptographic checksum were valid. To avoid leaking information cryptographic checksum were valid. To avoid leaking information
to someone probing a node, this status MUST be sent in response to someone probing a node, this status MUST be sent in response
to any error not covered by one of the other status types. to any error not covered by one of the other status types.
To aid debugging, more detailed error information should be To aid debugging, more detailed error information should be
written to a console or log. written to a console or log.
INVALID_MESSAGE_ID 9 INVALID_MESSAGE_ID 9
See Section 2.3. See Section 2.3.
skipping to change at line 4730 skipping to change at line 4734
is the SPI the sending endpoint would expect in inbound ESP or AH is the SPI the sending endpoint would expect in inbound ESP or AH
packets. packets.
The Delete Payload is defined as follows: The Delete Payload is defined as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | # of SPIs | | Protocol ID | SPI Size | Num of SPIs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Security Parameter Index(es) (SPI) ~ ~ Security Parameter Index(es) (SPI) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Delete Payload Format Figure 17: Delete Payload Format
o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3 o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3
for ESP. for ESP.
o SPI Size (1 octet) - Length in octets of the SPI as defined by the o SPI Size (1 octet) - Length in octets of the SPI as defined by the
protocol ID. It MUST be zero for IKE (SPI is in message header) protocol ID. It MUST be zero for IKE (SPI is in message header)
or four for AH and ESP. or four for AH and ESP.
o # of SPIs (2 octets) - The number of SPIs contained in the Delete o Num of SPIs (2 octets, unsigned integer) - The number of SPIs
payload. The size of each SPI is defined by the SPI Size field. contained in the Delete payload. The size of each SPI is defined
by the SPI Size field.
o Security Parameter Index(es) (variable length) - Identifies the o Security Parameter Index(es) (variable length) - Identifies the
specific security association(s) to delete. The length of this specific security association(s) to delete. The length of this
field is determined by the SPI Size and # of SPIs fields. field is determined by the SPI Size and Num of SPIs fields.
The payload type for the Delete Payload is forty two (42). The payload type for the Delete Payload is forty two (42).
3.12. Vendor ID Payload 3.12. Vendor ID Payload
The Vendor ID Payload, denoted V in this document, contains a vendor The Vendor ID Payload, denoted V in this document, contains a vendor
defined constant. The constant is used by vendors to identify and defined constant. The constant is used by vendors to identify and
recognize remote instances of their implementations. This mechanism recognize remote instances of their implementations. This mechanism
allows a vendor to experiment with new features while maintaining allows a vendor to experiment with new features while maintaining
backward compatibility. backward compatibility.
skipping to change at line 4902 skipping to change at line 4907
o TS Type (one octet) - Specifies the type of traffic selector. o TS Type (one octet) - Specifies the type of traffic selector.
o IP protocol ID (1 octet) - Value specifying an associated IP o IP protocol ID (1 octet) - Value specifying an associated IP
protocol ID (such as UDP, TCP, and ICMP). A value of zero means protocol ID (such as UDP, TCP, and ICMP). A value of zero means
that the protocol ID is not relevant to this traffic selector-- that the protocol ID is not relevant to this traffic selector--
the SA can carry all protocols. the SA can carry all protocols.
o Selector Length - Specifies the length of this Traffic Selector o Selector Length - Specifies the length of this Traffic Selector
substructure including the header. substructure including the header.
o Start Port (2 octets) - Value specifying the smallest port number o Start Port (2 octets, unsigned integer) - Value specifying the
allowed by this Traffic Selector. For protocols for which port is smallest port number allowed by this traffic selector. For
undefined (including protocol 0), or if all ports are allowed, protocols for which port is undefined (including protocol 0), or
this field MUST be zero. ICMP and ICMPv6 Type and Code values, as if all ports are allowed, this field MUST be zero. ICMP and
well as MIPv6 MH Type values, are represented in this field as ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are
specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type and Code represented in this field as specified in Section 4.4.1.1 of
values are treated as a single 16-bit integer port number, with [IPSECARCH]. ICMP Type and Code values are treated as a single
Type in the most significant eight bits and Code in the least 16-bit integer port number, with Type in the most significant
significant eight bits. MIPv6 MH Type values are treated as a eight bits and Code in the least significant eight bits. MIPv6 MH
single 16-bit integer port number, with Type in the most Type values are treated as a single 16-bit integer port number,
significant eight bits and the least significant eight bits set to with Type in the most significant eight bits and the least
zero. significant eight bits set to zero.
o End Port (2 octets) - Value specifying the largest port number o End Port (2 octets, unsigned integer) - Value specifying the
allowed by this Traffic Selector. For protocols for which port is largest port number allowed by this traffic selector. For
undefined (including protocol 0), or if all ports are allowed, protocols for which port is undefined (including protocol 0), or
this field MUST be 65535. ICMP and ICMPv6 Type and Code values, if all ports are allowed, this field MUST be 65535. ICMP and
as well as MIPv6 MH Type values, are represented in this field as ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are
specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type and Code represented in this field as specified in Section 4.4.1.1 of
values are treated as a single 16-bit integer port number, with [IPSECARCH]. ICMP Type and Code values are treated as a single
Type in the most significant eight bits and Code in the least 16-bit integer port number, with Type in the most significant
significant eight bits. MIPv6 MH Type values are treated as a eight bits and Code in the least significant eight bits. MIPv6 MH
single 16-bit integer port number, with Type in the most Type values are treated as a single 16-bit integer port number,
significant eight bits and the least significant eight bits set to with Type in the most significant eight bits and the least
zero. significant eight bits set to zero.
o Starting Address - The smallest address included in this Traffic o Starting Address - The smallest address included in this Traffic
Selector (length determined by TS type). Selector (length determined by TS type).
o Ending Address - The largest address included in this Traffic o Ending Address - The largest address included in this Traffic
Selector (length determined by TS type). Selector (length determined by TS type).
Systems that are complying with [IPSECARCH] that wish to indicate Systems that are complying with [IPSECARCH] that wish to indicate
"ANY" ports MUST set the start port to 0 and the end port to 65535; "ANY" ports MUST set the start port to 0 and the end port to 65535;
note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems
skipping to change at line 5135 skipping to change at line 5140
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Configuration Attribute Format Figure 23: Configuration Attribute Format
o Reserved (1 bit) - This bit MUST be set to zero and MUST be o Reserved (1 bit) - This bit MUST be set to zero and MUST be
ignored on receipt. ignored on receipt.
o Attribute Type (15 bits) - A unique identifier for each of the o Attribute Type (15 bits) - A unique identifier for each of the
Configuration Attribute Types. Configuration Attribute Types.
o Length (2 octets) - Length in octets of Value. o Length (2 octets, unsigned integer) - Length in octets of Value.
o Value (0 or more octets) - The variable-length value of this o Value (0 or more octets) - The variable-length value of this
Configuration Attribute. The following lists the attribute types. Configuration Attribute. The following lists the attribute types.
The values in the following table are only current as of the The values in the following table are only current as of the
publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and
INTERNAL_IP6_NBNS which were removed by this document). Other values INTERNAL_IP6_NBNS which were removed by this document). Other values
may have been added since then or will be added after the publication may have been added since then or will be added after the publication
of this document. Readers should refer to [IKEV2IANA] for the latest of this document. Readers should refer to [IKEV2IANA] for the latest
values. values.
skipping to change at line 5444 skipping to change at line 5449
shortage problem on the responder will probably only be fixed when shortage problem on the responder will probably only be fixed when
more entries are returned to the address pool when other clients more entries are returned to the address pool when other clients
disconnect or when responder is reconfigured with larger address disconnect or when responder is reconfigured with larger address
pool. pool.
3.16. Extensible Authentication Protocol (EAP) Payload 3.16. Extensible Authentication Protocol (EAP) Payload
The Extensible Authentication Protocol Payload, denoted EAP in this The Extensible Authentication Protocol Payload, denoted EAP in this
document, allows IKE SAs to be authenticated using the protocol document, allows IKE SAs to be authenticated using the protocol
defined in RFC 3748 [EAP] and subsequent extensions to that protocol. defined in RFC 3748 [EAP] and subsequent extensions to that protocol.
The full set of acceptable values for the payload is defined When using EAP, an appropriate EAP method needs to be selected. Many
elsewhere, but a short summary of RFC 3748 is included here to make of these methods have been defined, specifying the protocol's use
this document stand alone in the common cases. with various authentication mechanisms. EAP method types are listed
in [EAP-IANA]. A short summary of the EAP format is included here
for clarity.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ EAP Message ~ ~ EAP Message ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 5481 skipping to change at line 5488
o Code (1 octet) indicates whether this message is a Request (1), o Code (1 octet) indicates whether this message is a Request (1),
Response (2), Success (3), or Failure (4). Response (2), Success (3), or Failure (4).
o Identifier (1 octet) is used in PPP to distinguish replayed o Identifier (1 octet) is used in PPP to distinguish replayed
messages from repeated ones. Since in IKE, EAP runs over a messages from repeated ones. Since in IKE, EAP runs over a
reliable protocol, it serves no function here. In a response reliable protocol, it serves no function here. In a response
message, this octet MUST be set to match the identifier in the message, this octet MUST be set to match the identifier in the
corresponding request. corresponding request.
o Length (2 octets) is the length of the EAP message and MUST be o Length (2 octets, unsigned integer) is the length of the EAP
four less than the Payload Length of the encapsulating payload. message and MUST be four less than the Payload Length of the
encapsulating payload.
o Type (1 octet) is present only if the Code field is Request (1) or o Type (1 octet) is present only if the Code field is Request (1) or
Response (2). For other codes, the EAP message length MUST be Response (2). For other codes, the EAP message length MUST be
four octets and the Type and Type_Data fields MUST NOT be present. four octets and the Type and Type_Data fields MUST NOT be present.
In a Request (1) message, Type indicates the data being requested. In a Request (1) message, Type indicates the data being requested.
In a Response (2) message, Type MUST either be Nak or match the In a Response (2) message, Type MUST either be Nak or match the
type of the data requested. Note that since IKE passes an type of the data requested. Note that since IKE passes an
indication of initiator identity in message 3 of the protocol, the indication of initiator identity in the first message in the
responder SHOULD NOT send EAP Identity requests (type 1). The IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity
initiator MAY, however, respond to such requests if it receives requests (type 1). The initiator MAY, however, respond to such
them. requests if it receives them.
o Type_Data (Variable Length) varies with the Type of Request and o Type_Data (Variable Length) varies with the Type of Request and
the associated Response. For the documentation of the EAP the associated Response. For the documentation of the EAP
methods, see [EAP]. methods, see [EAP].
Note that since IKE passes an indication of initiator identity in Note that since IKE passes an indication of initiator identity in the
message 3 of the protocol, the responder should not send EAP Identity first message in the IKE_AUTH exchange, the responder should not send
requests. The initiator may, however, respond to such requests if it EAP Identity requests. The initiator may, however, respond to such
receives them. requests if it receives them.
4. Conformance Requirements 4. Conformance Requirements
In order to assure that all implementations of IKEv2 can In order to assure that all implementations of IKEv2 can
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. There are a series interoperate with all compliant implementations. The following are
of optional features that can easily be ignored by a particular some of the features that can be omitted in a minimal implementation:
implementation if it does not support that feature. Those features
include:
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 5548 skipping to change at line 5554
payload types that it does not support unless the critical bit is set payload types that it does not support unless the critical bit is set
in the payload header. If the critical bit is set in an unsupported in the payload header. If the critical bit is set in an unsupported
payload header, all implementations MUST reject the messages payload header, all implementations MUST reject the messages
containing those payloads. containing those payloads.
Every implementation MUST be capable of doing four-message Every implementation MUST be capable of doing four-message
IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
one for ESP or AH). Implementations MAY be initiate-only or respond- one for ESP or AH). Implementations MAY be initiate-only or respond-
only if appropriate for their platform. Every implementation MUST be only if appropriate for their platform. Every implementation MUST be
capable of responding to an INFORMATIONAL exchange, but a minimal capable of responding to an INFORMATIONAL exchange, but a minimal
implementation MAY respond to any INFORMATIONAL message with an empty implementation MAY respond to any request in the INFORMATIONAL
INFORMATIONAL response (note that within the context of an IKE SA, an exchange with an empty response (note that within the context of an
"empty" message consists of an IKE header followed by an Encrypted IKE SA, an "empty" message consists of an IKE header followed by an
payload with no payloads contained in it). A minimal implementation Encrypted payload with no payloads contained in it). A minimal
MAY support the CREATE_CHILD_SA exchange only in so far as to implementation MAY support the CREATE_CHILD_SA exchange only in so
recognize requests and reject them with a Notify payload of type far as to recognize requests and reject them with a Notify payload of
NO_ADDITIONAL_SAS. A minimal implementation need not be able to type NO_ADDITIONAL_SAS. A minimal implementation need not be able to
initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA
expires (based on locally configured values of either lifetime or expires (based on locally configured values of either lifetime or
octets passed), and implementation MAY either try to renew it with a octets passed), and implementation MAY either try to renew it with a
CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
create a new one. If the responder rejects the CREATE_CHILD_SA create a new one. If the responder rejects the CREATE_CHILD_SA
request with a NO_ADDITIONAL_SAS notification, the implementation request with a NO_ADDITIONAL_SAS notification, the implementation
MUST be capable of instead deleting the old SA and creating a new MUST be capable of instead deleting the old SA and creating a new
one. one.
Implementations are not required to support requesting temporary IP Implementations are not required to support requesting temporary IP
addresses or responding to such requests. If an implementation does addresses or responding to such requests. If an implementation does
support issuing such requests and its policy requires using temporary support issuing such requests and its policy requires using temporary
IP addresses, it MUST include a CP payload in message 3 containing at IP addresses, it MUST include a CP payload in the first message in
least a field of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. the IKE_AUTH exchange containing at least a field of type
All other fields are optional. If an implementation supports INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All other fields are
responding to such requests, it MUST parse the CP payload of type optional. If an implementation supports responding to such requests,
CFG_REQUEST in message 3 and recognize a field of type it MUST parse the CP payload of type CFG_REQUEST in the first message
in the IKE_AUTH exchange and recognize a field of type
INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing
an address of the appropriate type, it MUST return a CP payload of an address of the appropriate type, it MUST return a CP payload of
type CFG_REPLY containing an address of the requested type. The type CFG_REPLY containing an address of the requested type. The
responder may include any other related attributes. responder may include any other related attributes.
For an implementation to be called conforming to this specification, For an implementation to be called conforming to this specification,
it MUST be possible to configure it to accept the following: it MUST be possible to configure it to accept the following:
o PKIX Certificates containing and signed by RSA keys of size 1024 o PKIX Certificates containing and signed by RSA keys of size 1024
or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
skipping to change at line 5645 skipping to change at line 5652
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 elliptical 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 denial of network. Implementation vulnerabilities, particularly DoS attacks,
service attacks, can be exploited by unauthenticated peers. This can be exploited by unauthenticated peers. This issue is
issue is particularly worrisome because of the unlimited number of particularly worrisome because of the unlimited number of messages in
messages in EAP-based authentication. EAP-based authentication.
The strength of all keys is limited by the size of the output of the The strength of all keys is limited by the size of the output of the
negotiated PRF. For this reason, a PRF whose output is less than 128 negotiated PRF. For this reason, a PRF whose output is less than 128
bits (e.g., 3DES-CBC) MUST NOT be used with this protocol. bits (e.g., 3DES-CBC) MUST NOT be used with this protocol.
The security of this protocol is critically dependent on the The security of this protocol is critically dependent on the
randomness of the randomly chosen parameters. These should be randomness of the randomly chosen parameters. These should be
generated by a strong random or properly seeded pseudo-random source generated by a strong random or properly seeded pseudo-random source
(see [RANDOMNESS]). Implementers should take care to ensure that use (see [RANDOMNESS]). Implementers should take care to ensure that use
of random numbers for both keys and nonces is engineered in a fashion of random numbers for both keys and nonces is engineered in a fashion
skipping to change at line 5844 skipping to change at line 5851
the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI,
each of which has its own list of authors. Hugh Daniel suggested the each of which has its own list of authors. Hugh Daniel suggested the
feature of having the initiator, in message 3, specify a name for the feature of having the initiator, in message 3, specify a name for the
responder, and gave the feature the cute name "You Tarzan, Me Jane". responder, and gave the feature the cute name "You Tarzan, Me Jane".
David Faucher and Valery Smyslov helped refine the design of the David Faucher and Valery Smyslov helped refine the design of the
traffic selector negotiation. traffic selector negotiation.
This paragraph lists references that appear only in figures. The This paragraph lists references that appear only in figures. The
section is only here to keep the 'xml2rfc' program happy, and needs section is only here to keep the 'xml2rfc' program happy, and needs
to be removed when the document is published. The RFC Editor will to be removed when the document is published. The RFC Editor will
remove it before publication. [EAI] [DES] [IDEA] [MD5] [X.501] remove it before publication. [EAI] [DES] [IDEA] [MD5] [DSS]
[X.509] [DSS]
8. References 8. References
8.1. Normative References 8.1. Normative References
[ADDGROUP] [ADDGROUP]
Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003. RFC 3526, May 2003.
[ADDRIPV6] [ADDRIPV6]
Hinden, R. and S. Deering, "Internet Protocol Version 6 Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 4291, February 2006. (IPv6) Addressing Architecture", RFC 4291, February 2006.
[AEAD] McGrew, D. and D. Black, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282,
August 2008.
[AESCMACPRF128] [AESCMACPRF128]
Song, J., "The Advanced Encryption Standard-Cipher-based Song, J., "The Advanced Encryption Standard-Cipher-based
Message Authentication Code-Pseudo-Random Function-128 Message Authentication Code-Pseudo-Random Function-128
(AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange
Protocol (IKE)", RFC 4615, August 2006. Protocol (IKE)", RFC 4615, August 2006.
[AESXCBCPRF128] [AESXCBCPRF128]
Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4434, Internet Key Exchange Protocol (IKE)", RFC 4434,
February 2006. February 2006.
skipping to change at line 5900 skipping to change at line 5911
[MUSTSHOULD] [MUSTSHOULD]
Bradner, S., "Key Words for use in RFCs to indicate Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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 3280, Certificate Revocation List (CRL) Profile", RFC 5280,
April 2002. May 2008.
[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.
8.2. Informative References 8.2. Informative References
[AEAD] McGrew, D. and D. Black, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282,
August 2008.
[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]
Carpenter, B., "Architectural Principles of the Internet", Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996. RFC 1958, June 1996.
skipping to change at line 5967 skipping to change at line 5973
for UDP-based protocols", ACM Conference on Computer and for UDP-based protocols", ACM Conference on Computer and
Communications Security , October 2003. Communications Security , October 2003.
[DSS] National Institute of Standards and Technology, U.S. [DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard", Department of Commerce, "Digital Signature Standard",
Draft FIPS 186-3, June 2008. Draft FIPS 186-3, June 2008.
[EAI] Abel, Y., "Internationalized Email Headers", RFC 5335, [EAI] Abel, Y., "Internationalized Email Headers", RFC 5335,
September 2008. September 2008.
[EAP-IANA]
"Extensible Authentication Protocol (EAP) Registry: Method
Types", <http://www.iana.org/assignments/eap-numbers>.
[EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in
Tunneled Authentication Protocols", November 2002, Tunneled Authentication Protocols", November 2002,
<http://eprint.iacr.org/2002/163>. <http://eprint.iacr.org/2002/163>.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[EXCHANGEANALYSIS] [EXCHANGEANALYSIS]
R. Perlman and C. Kaufman, "Analysis of the IPsec key R. Perlman and C. Kaufman, "Analysis of the IPsec key
exchange Standard", WET-ICE Security Conference, MIT , exchange Standard", WET-ICE Security Conference, MIT ,
skipping to change at line 6096 skipping to change at line 6106
[SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", IEEE Proceedings of the 1996 Mechanism for Internet", IEEE Proceedings of the 1996
Symposium on Network and Distributed Systems Security , Symposium on Network and Distributed Systems Security ,
1996. 1996.
[TRANSPARENCY] [TRANSPARENCY]
Carpenter, B., "Internet Transparency", RFC 2775, Carpenter, B., "Internet Transparency", RFC 2775,
February 2000. February 2000.
[X.501] ITU-T, "Recommendation X.501: Information Technology -
Open Systems Interconnection - The Directory: Models",
1993.
[X.509] ITU-T, "Recommendation X.509 (1997 E): Information
Technology - Open Systems Interconnection - The Directory:
Authentication Framework", 1997.
Appendix A. Summary of changes from IKEv1 Appendix A. Summary of changes from IKEv1
The goals of this revision to IKE are: The goals of this revision to IKE are:
1. To define the entire IKE protocol in a single document, 1. To define the entire IKE protocol in a single document,
replacing RFCs 2407, 2408, and 2409 and incorporating subsequent replacing RFCs 2407, 2408, and 2409 and incorporating subsequent
changes to support NAT Traversal, Extensible Authentication, and changes to support NAT Traversal, Extensible Authentication, and
Remote Address acquisition; Remote Address acquisition;
2. To simplify IKE by replacing the eight different initial 2. To simplify IKE by replacing the eight different initial
skipping to change at line 6144 skipping to change at line 6146
to 2; to 2;
7. To increase robustness by allowing the responder to not do 7. To increase robustness by allowing the responder to not do
significant processing until it receives a message proving that significant processing until it receives a message proving that
the initiator can receive messages at its claimed IP address; the initiator can receive messages at its claimed IP address;
8. To fix cryptographic weaknesses such as the problem with 8. To fix cryptographic weaknesses such as the problem with
symmetries in hashes used for authentication documented by Tero symmetries in hashes used for authentication documented by Tero
Kivinen; Kivinen;
9. To specify Traffic Selectors in their own payloads type rather 9. To specify traffic selectors in their own payloads type rather
than overloading ID payloads, and making more flexible the than overloading ID payloads, and making more flexible the
Traffic Selectors that may be specified; traffic selectors that may be specified;
10. To specify required behavior under certain error conditions or 10. To specify required behavior under certain error conditions or
when data that is not understood is received in order to make it when data that is not understood is received in order to make it
easier to make future revisions in a way that does not break easier to make future revisions in a way that does not break
backwards compatibility; backwards compatibility;
11. To simplify and clarify how shared state is maintained in the 11. To simplify and clarify how shared state is maintained in the
presence of network failures and denial of service attacks; and presence of network failures and DoS attacks; and
12. To maintain existing syntax and magic numbers to the extent 12. To maintain existing syntax and magic numbers to the extent
possible to make it likely that implementations of IKEv1 can be possible to make it likely that implementations of IKEv1 can be
enhanced to support IKEv2 with minimum effort. enhanced to support IKEv2 with minimum effort.
Appendix B. Diffie-Hellman Groups Appendix B. Diffie-Hellman Groups
There are two Diffie-Hellman groups defined here for use in IKE. There are two Diffie-Hellman groups defined here for use in IKE.
These groups were generated by Richard Schroeppel at the University These groups were generated by Richard Schroeppel at the University
of Arizona. Properties of these primes are described in [OAKLEY]. of Arizona. Properties of these primes are described in [OAKLEY].
The strength supplied by group one may not be sufficient for the The strength supplied by group 1 may not be sufficient for typical
mandatory-to-implement encryption algorithm and is here for historic uses and is here for historic reasons.
reasons.
Additional Diffie-Hellman groups have been defined in [ADDGROUP]. Additional Diffie-Hellman groups have been defined in [ADDGROUP].
B.1. Group 1 - 768 Bit MODP B.1. Group 1 - 768 Bit MODP
This group is assigned id 1 (one). This group is assigned id 1 (one).
The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
Its hexadecimal value is: Its hexadecimal value is:
skipping to change at line 6229 skipping to change at line 6230
normal response <-- SA, KE, Nr, normal response <-- SA, KE, Nr,
(no cookie) [N(NAT_DETECTION_SOURCE_IP), (no cookie) [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)], N(NAT_DETECTION_DESTINATION_IP)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[V+][N+] [V+][N+]
cookie response <-- N(COOKIE), cookie response <-- N(COOKIE),
[V+][N+] [V+][N+]
different D-H <-- N(INVALID_KE_PAYLOAD), different Diffie- <-- N(INVALID_KE_PAYLOAD),
group wanted [V+][N+] Hellman group [V+][N+]
wanted
C.2. IKE_AUTH Exchange without EAP C.2. IKE_AUTH Exchange without EAP
request --> IDi, [CERT+], request --> IDi, [CERT+],
[N(INITIAL_CONTACT)], [N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr], [IDr],
AUTH, AUTH,
[CP(CFG_REQUEST)], [CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+], [N(IPCOMP_SUPPORTED)+],
skipping to change at line 6319 skipping to change at line 6321
response [N(IPCOMP_SUPPORTED)], response [N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)], [N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)], [N(NON_FIRST_FRAGMENTS_ALSO)],
SA, Nr, [KEr], TSi, TSr, SA, Nr, [KEr], TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)] [N(ADDITIONAL_TS_POSSIBLE)]
[V+][N+] [V+][N+]
error case <-- N(error) error case <-- N(error)
different D-H <-- N(INVALID_KE_PAYLOAD), different Diffie- <-- N(INVALID_KE_PAYLOAD),
group wanted [V+][N+] Hellman group [V+][N+]
wanted
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA
request --> SA, Ni, KEi request --> SA, Ni, KEi
[V+][N+] [V+][N+]
response <-- SA, Nr, KEr response <-- SA, Nr, KEr
[V+][N+] [V+][N+]
C.6. INFORMATIONAL Exchange C.6. INFORMATIONAL Exchange
skipping to change at line 7260 skipping to change at line 7263
In the table in 1.2, added " (not a payload)" to "IKE Header" because In the table in 1.2, added " (not a payload)" to "IKE Header" because
the other items are, in fact, payloads. Also changed "E Encrypted" the other items are, in fact, payloads. Also changed "E Encrypted"
to "SK Encrypted and Authenticated". to "SK Encrypted and Authenticated".
Removed "When an IKE SA is not created, the error message return Removed "When an IKE SA is not created, the error message return
SHOULD NOT be encrypted because the other party will not be able to SHOULD NOT be encrypted because the other party will not be able to
authenticate that message." from the end of 1.3.1. [Issue #127] authenticate that message." from the end of 1.3.1. [Issue #127]
In 1.3.1, added "An IPCOMP_SUPPORTED notification, covered in In 1.3.1, added "An IPCOMP_SUPPORTED notification, covered in
Section 2.22, can also be included in the request/response pair." Section 2.22, can also be included in the exchange."
In 1.3.2, changed "New initiator and responder SPIs are supplied in In 1.3.2, changed "New initiator and responder SPIs are supplied in
the SPI fields of the SA payload." to "A new initiator SPI is the SPI fields of the SA payload." to "A new initiator SPI is
supplied in the SPI field of the SA payload." Also added "A new supplied in the SPI field of the SA payload." Also added "A new
responder SPI is supplied in the SPI field of the SA payload." a few responder SPI is supplied in the SPI field of the SA payload." a few
paragraphs down. paragraphs down.
In 1.3.3, changed the figure for the initiator from: In 1.3.3, changed the figure for the initiator from:
Initiator Responder Initiator Responder
skipping to change at line 7643 skipping to change at line 7646
(AUTHENTICATION_FAILED and EAP failure)...". Also added "If the (AUTHENTICATION_FAILED and EAP failure)...". Also added "If the
exchange is terminated with EAP Failure, an AUTHENTICATION_FAILED exchange is terminated with EAP Failure, an AUTHENTICATION_FAILED
notification is not sent." [Issue #152 and #160] notification is not sent." [Issue #152 and #160]
In 2.21.2, removed INVALID_SELECTORS from the list of things that are In 2.21.2, removed INVALID_SELECTORS from the list of things that are
returned from the piggybacked exchanges. [Issue #166] returned from the piggybacked exchanges. [Issue #166]
In 2.23, changed "In the case of NAT traversal, the Traffic Selectors In 2.23, changed "In the case of NAT traversal, the Traffic Selectors
MUST contain exactly one IP address, which is then used as the MUST contain exactly one IP address, which is then used as the
original IP address" to "In the case of transport mode NAT traversal, original IP address" to "In the case of transport mode NAT traversal,
the Traffic Selectors MUST contain exactly one IP address, which is the traffic selectors MUST contain exactly one IP address, which is
then used as the original IP address". [Issue #136] then used as the original IP address". [Issue #136]
In 2.23, completely replaced the paragraph that begins "An initiator In 2.23, completely replaced the paragraph that begins "An initiator
can use port 4500". [Issue #146] can use port 4500". [Issue #146]
In 2.23, changed "In addition, firewalls may be configured to pass In 2.23, changed "In addition, firewalls may be configured to pass
IPsec traffic over UDP but not ESP/AH or vice versa." to "In IPsec traffic over UDP but not ESP/AH or vice versa." to "In
addition, firewalls may be configured to pass UDP-encapsulated IPsec addition, firewalls may be configured to pass UDP-encapsulated IPsec
traffic but not plain, unencapsulated ESP/AH or vice versa". traffic but not plain, unencapsulated ESP/AH or vice versa".
skipping to change at line 7762 skipping to change at line 7765
were redundant with the preceding text but also used new terms that were redundant with the preceding text but also used new terms that
were not defined. [Issue #172] were not defined. [Issue #172]
In 5, removed "or overrun of either endpoint". [Issue #169] In 5, removed "or overrun of either endpoint". [Issue #169]
In 6, added that IANA should change "46 Encrypted E" to "46 Encrypted In 6, added that IANA should change "46 Encrypted E" to "46 Encrypted
SK". SK".
In 8.2, updated the pointer for IPV6CONFIG to RFC 5739. In 8.2, updated the pointer for IPV6CONFIG to RFC 5739.
D.16. Changes from draft-ietf-ipsecme-ikev2bis-08 to
draft-ietf-ipsecme-ikev2bis-09
These changes came during IETF Last Call.
Fixed more minor editorial nits.
Throughout, changed "#" in the name of variables to "Num" or "Number"
because "#" is US-centric and confusing.
Throughout, changed "denial of service" to "DoS" after the first
definition to be consistent.
In many places, changed "message 3" to "the first message in the
IKE_AUTH exchange".
In 1, changed 'The pair is called an "exchange"' to 'The pair is
called an "exchange", and is sometimes called "request/response"'.
Then changed most of the rest of "request/response" to "exchange"
throughout the document.
In 1, changed "We call the first messages establishing an IKE SA
IKE_SA_INIT and IKE_AUTH exchanges and subsequent IKE exchanges
CREATE_CHILD_SA or INFORMATIONAL exchanges" to "The first exchange of
messages establishing an IKE SA are called the IKE_SA_INIT and
IKE_AUTH exchanges; subsequent IKE exchanges are called the
CREATE_CHILD_SA or INFORMATIONAL exchanges".
In 1.2, added "see Section 2.13 and Section 2.14 for details on the
key derivation".
In 1.2, copied text from 2.2 to describe what a Message ID is before
we start talking about it.
In 1.2, added "The traffic selectors (TSi and TSr) are discussed in
Section 2.9" because it was ignored in the section.
In 1.2, changed "The recipients of messages 3 and 4 MUST verify..."
to "Both parties in the IKE_SA_INIT exchange MUST verify...".
In 1.2, changed "The list of responses..." to "Notify message
types...".
In 1.2, changed "If the failure is related to creating the IKE SA
(for example, AUTHENTICATION_FAILED)" to "If the failure is related
to creating the IKE SA (for example, an AUTHENTICATION_FAILED Notify
error message is returned)".
In 1.2, changed "the sender of the error indication" to "the sender
of the error Notify message".
In 1.3, removed the paragraph starting "All messages following..."
because it is a duplicate from 1.2.
In 1.3, changed "this notify" to "this notification".
In 1.3, removed "The CREATE_CHILD_SA is also used for rekeying IKE
SAs and Child SAs" because it is redundant with the first sentence of
the section.
In 1.3.1, changed "Failure of an attempt" to "A failed attempt".
In 1.5, added "these flags are described in Section 3.1" because they
had not beed defined yet.
In 2.2, added "Retransmission of a message MUST use the same Message
ID as the original message."
At the end of 2.3, changed "is optional" to "is OPTIONAL".
In 2.4, changed "Every implementation MUST be capable of responding
to an INFORMATIONAL exchange, but a minimal implementation MAY
respond to any INFORMATIONAL message with an empty INFORMATIONAL
response" to "Every implementation MUST be capable of responding to
an INFORMATIONAL exchange, but a minimal implementation MAY respond
to any request in the INFORMATIONAL exchange with an empty response".
In 2.4, changed "An implementation MUST NOT continue sending on any
SA if some failure prevents it from receiving on all of the
associated SAs" to "An implementation needs to stop sending on any
SA..." because there is no way for the implementation to know if
"some failure" has occured.
In 2.4, changed "If Child SAs can fail independently from one another
without the associated IKE SA being able to send a delete message,
then they MUST be negotiated by separate IKE SAs" to "If a system
creates Child SAs that can fail independently from one another
without the associated IKE SA being able to send a delete message,
then the system MUST negotiate such Child SAs using separate IKE
SAs". [Issue #181]
In 2.6, changed "will cause two packets:" to "will cause two packets
to be sent:".
In 2.6, added "possibly using exponential back-off" to the discussion
of limiting the number of cookies it sends.
Moved the paragraph that starts "When the IKE_SA_INIT exchange does
not result" from 2.7 to 2.6. Also changed"the responder's SPI will
be zero" to "the responder's SPI will be zero also in the response
message".
In 2.8.1, removed "lexicographical" because it was undefined and
unnecessary.
In 2.8.2, last paragraph: Change the beginning of the sentence and
changed "older peers may receive these notifications" to "older peers
that implement RFC 4306 but not this document may receive these
notifications".
Fixed the first two paragraphs of 2.9 to talk about PFKEY in the
correct context.
In 2.9, changed "reject the request with a status of
SINGLE_PAIR_REQUIRED" with "reject the request with a
SINGLE_PAIR_REQUIRED Notify message".
In 2.13, changed "The preferred key size is used as the length of
SK_d, SK_pi, and SK_pr" to "The preferred key size MUST be used as
the length of SK_d, SK_pi, and SK_pr".
In 2.14, changed "The lengths of SK_d, SK_pi, and SK_pr are the
preferred key length of the agreed-to PRF" to "The lengths of SK_d,
SK_pi, and SK_pr MUST be the preferred key length of the agreed-to
PRF".
In 2.15, moved "In the above calculation, IDi' and IDr' are the
entire ID payloads excluding the fixed header" earlier and removed
redundant definitions.
In 2.16, added "(Note that the AUTH payload is required for non-EAP
authentication, and is thus not marked as optional in the rest of
this document.)"
In 2.17, added a reference to [ROHCV2].
In 2.20, removed "to prevent trolling" because it is not a widely-
known term.
In 2.21.2, added "using the Vendor ID payload" to the last sentence.
In 2.23, clarified the paragraph that starts "An initiator can
use..." in many places, saying that it is UDP encapsulated ESP.
In the bulleted list in 2.23 that lists what implementations that
support NAT traversal must do, removed "IKE MUST listen on port 4500
as well as port 500. IKE MUST respond to the IP address and port
from which packets arrived". That requirement applies to all IKE
implementations.
In 2.23, changed "these payloads" to "the NAT_DETECTION_SOURCE_IP or
NAT_DETECTION_DESTINATION_IP payloads".
Throughout subsections of 3, added ", unsigned integer" in
definitions of multi-octet items such as Message ID and Payload
Length.
In 3.1, added "(with one exception; see Section 2.21.2)" to the
discussion of the Response flag.
In 3.3.1, changed "the SPI is obtained from outer header" to "the SPI
is obtained from outer IP header".
In 3.3.6, changed "If one of the proposals offered is for the Diffie-
Hellman group of NONE, the responder MUST ignore the initiator's KE
payload and omit the KE payload from the response" to "If one of the
proposals offered is for the Diffie-Hellman group of NONE, and the
responder selects that Diffie-Hellman group, then it MUST ignore the
initiator's KE payload and omit the KE payload from the response".
[Issue #176]
In 3.5, changed "[X.501]" and "[X.509]" to "[PKIX]". Also removed
those two now-unneeded references. [Issue #183]
In 3.5, changed "IPv6-only implementations MAY be configurable to
send only ID_IPV6_ADDR instead of ID_IPV6_ADDR for IP addresses" to
"IPv6-only implementations MAY be configurable to send only
ID_IPV6_ADDR instead of ID_IPV4_ADDR for IP addresses".
In 3.5, changed "and MUST be configurable to accept all of these
types" to "and MUST be configurable to accept all of these four
types". [Issue #186]
In 3.6, changed "MUST be capable of being configured to send and
accept the two Hash and URL formats (with HTTP URLs)" to "MUST be
capable of being configured to send and accept the Hash and URL
format (with HTTP URLs)" because there is only one format.
At the beginning of 3.16, changed "The full set of acceptable values
for the payload is defined elsewhere, but a short summary of RFC 3748
is included here to make this document stand alone in the common
cases" to "When using EAP, an appropriate EAP method needs to be
selected. Many of these methods have been defined, specifying the
protocol's use with various authentication mechanisms. EAP method
types are listed in [EAP-IANA]. A short summary of the EAP format is
included here for clarity.". Also added the reference to [EAP-IANA]
to the informative references. [Issue #187]
In 4, changed "There are a series of optional features that can
easily be ignored by a particular implementation if it does not
support that feature. Those features include:" to "The following are
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".
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. 146 change blocks. 
476 lines changed or deleted 690 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/