RFC 4306
Internet Key Exchange (IKEv2) Protocol
Network Working Group C. Kaufman, Ed. Request for Comments: 4306 Microsoft Obsoletes: 2407, 2408, 2409 December 2005 Category: Standards Track Internet Key Exchange (IKEv2) Protocol Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005).Abstract
This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). This version of the IKE specification combines the contents of what were previously separate documents, including Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network Address Translation (NAT) Traversal, Legacy authentication, and remote address acquisition. Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port.
Table of Contents
1. Introduction ....................................................3 1.1. Usage Scenarios ............................................5 1.2. The Initial Exchanges ......................................7 1.3. The CREATE_CHILD_SA Exchange ...............................9 1.4. The INFORMATIONAL Exchange ................................11 1.5. Informational Messages outside of an IKE_SA ...............12 2. IKE Protocol Details and Variations ............................12 2.1. Use of Retransmission Timers ..............................13 2.2. Use of Sequence Numbers for Message ID ....................14 2.3. Window Size for Overlapping Requests ......................14 2.4. State Synchronization and Connection Timeouts .............15 2.5. Version Numbers and Forward Compatibility .................17 2.6. Cookies ...................................................18 2.7. Cryptographic Algorithm Negotiation .......................21 2.8. Rekeying ..................................................22 2.9. Traffic Selector Negotiation ..............................24 2.10. Nonces ...................................................26 2.11. Address and Port Agility .................................26 2.12. Reuse of Diffie-Hellman Exponentials .....................27 2.13. Generating Keying Material ...............................27 2.14. Generating Keying Material for the IKE_SA ................28 2.15. Authentication of the IKE_SA .............................29 2.16. Extensible Authentication Protocol Methods ...............31 2.17. Generating Keying Material for CHILD_SAs .................33 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange ........34 2.19. Requesting an Internal Address on a Remote Network .......34 2.20. Requesting the Peer's Version ............................35 2.21. Error Handling ...........................................36 2.22. IPComp ...................................................37 2.23. NAT Traversal ............................................38 2.24. Explicit Congestion Notification (ECN) ...................40 3. Header and Payload Formats .....................................41 3.1. The IKE Header ............................................41 3.2. Generic Payload Header ....................................44 3.3. Security Association Payload ..............................46 3.4. Key Exchange Payload ......................................56 3.5. Identification Payloads ...................................56 3.6. Certificate Payload .......................................59 3.7. Certificate Request Payload ...............................61 3.8. Authentication Payload ....................................63 3.9. Nonce Payload .............................................64 3.10. Notify Payload ...........................................64 3.11. Delete Payload ...........................................72 3.12. Vendor ID Payload ........................................73 3.13. Traffic Selector Payload .................................74 3.14. Encrypted Payload ........................................77
3.15. Configuration Payload ....................................79
3.16. Extensible Authentication Protocol (EAP) Payload .........84
4. Conformance Requirements .......................................85
5. Security Considerations ........................................88
6. IANA Considerations ............................................90
7. Acknowledgements ...............................................91
8. References .....................................................91
8.1. Normative References ......................................91
8.2. Informative References ....................................92
Appendix A: Summary of Changes from IKEv1 .........................96
Appendix B: Diffie-Hellman Groups .................................97
B.1. Group 1 - 768 Bit MODP ....................................97
B.2. Group 2 - 1024 Bit MODP ...................................97
1. Introduction
IP Security (IPsec) provides confidentiality, data integrity, access
control, and data source authentication to IP datagrams. These
services are provided by maintaining shared state between the source
and the sink of an IP datagram. This state defines, among other
things, the specific services provided to the datagram, which
cryptographic algorithms will be used to provide the services, and
the keys used as input to the cryptographic algorithms.
Establishing this shared state in a manual fashion does not scale
well. Therefore, a protocol to establish this state dynamically is
needed. This memo describes such a protocol -- the Internet Key
Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was
defined in RFCs 2407, 2408, and 2409 [Pip98, MSST98, HC98]. This
single document is intended to replace all three of those RFCs.
Definitions of the primitive terms in this document (such as Security
Association or SA) can be found in [RFC4301].
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
"MAY" that appear in this document are to be interpreted as described
in [Bra97].
The term "Expert Review" is to be interpreted as defined in
[RFC2434].
IKE performs mutual authentication between two parties and
establishes an IKE security association (SA) that includes shared
secret information that can be used to efficiently establish SAs for
Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication
Header (AH) [RFC4302] and a set of cryptographic algorithms to be
used by the SAs to protect the traffic that they carry. In this
document, the term "suite" or "cryptographic suite" refers to a
complete set of algorithms used to protect an SA. An initiator proposes one or more suites by listing supported algorithms that can be combined into suites in a mix-and-match fashion. IKE can also negotiate use of IP Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA. We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get set up through that IKE_SA we call "CHILD_SAs". All IKE communications consist of pairs of messages: a request and a response. The pair is called an "exchange". 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. In the common case, there is a single IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four messages) to establish the IKE_SA and the first CHILD_SA. In exceptional cases, there may be more than one of each of these exchanges. In all cases, all IKE_SA_INIT exchanges MUST complete before any other exchange type, then all IKE_AUTH exchanges MUST complete, and following that any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur in any order. In some scenarios, only a single CHILD_SA is needed between the IPsec endpoints, and therefore there would be no additional exchanges. Subsequent exchanges MAY be used to establish additional CHILD_SAs between the same authenticated pair of endpoints and to perform housekeeping functions. IKE message flow always consists of a request followed by a response. It is the responsibility of the requester to ensure reliability. If the response is not received within a timeout interval, the requester needs to retransmit the request (or abandon the connection). The first request/response of an IKE session (IKE_SA_INIT) negotiates security parameters for the IKE_SA, sends nonces, and sends Diffie- Hellman values. The second request/response (IKE_AUTH) transmits identities, proves knowledge of the secrets corresponding to the two identities, and sets up an SA for the first (and often only) AH and/or ESP CHILD_SA. The types of subsequent exchanges are CREATE_CHILD_SA (which creates a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error conditions, or does other housekeeping). Every request requires a response. An INFORMATIONAL request with no payloads (other than the empty Encrypted payload required by the syntax) is commonly used as a check for liveness. These subsequent exchanges cannot be used until the initial exchanges have completed.
In the description that follows, we assume that no errors occur. Modifications to the flow should errors occur are described in section 2.21.1.1. Usage Scenarios
IKE is expected to be used to negotiate ESP and/or AH SAs in a number of different scenarios, each with its own special requirements.1.1.1. Security Gateway to Security Gateway Tunnel
+-+-+-+-+-+ +-+-+-+-+-+ ! ! IPsec ! ! Protected !Tunnel ! tunnel !Tunnel ! Protected Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet ! ! ! ! +-+-+-+-+-+ +-+-+-+-+-+ Figure 1: Security Gateway to Security Gateway Tunnel In this scenario, neither endpoint of the IP connection implements IPsec, but network nodes between them protect traffic for part of the way. Protection is transparent to the endpoints, and depends on ordinary routing to send packets through the tunnel endpoints for processing. Each endpoint would announce the set of addresses "behind" it, and packets would be sent in tunnel mode where the inner IP header would contain the IP addresses of the actual endpoints.1.1.2. Endpoint-to-Endpoint Transport
+-+-+-+-+-+ +-+-+-+-+-+ ! ! IPsec transport ! ! !Protected! or tunnel mode SA !Protected! !Endpoint !<---------------------------------------->!Endpoint ! ! ! ! ! +-+-+-+-+-+ +-+-+-+-+-+ Figure 2: Endpoint to Endpoint In this scenario, both endpoints of the IP connection implement IPsec, as required of hosts in [RFC4301]. Transport mode will commonly be used with no inner IP header. If there is an inner IP header, the inner addresses will be the same as the outer addresses. A single pair of addresses will be negotiated for packets to be protected by this SA. These endpoints MAY implement application layer access controls based on the IPsec authenticated identities of the participants. This scenario enables the end-to-end security that has been a guiding principle for the Internet since [RFC1958],
[RFC2775], and a method of limiting the inherent problems with complexity in networks noted by [RFC3439]. Although this scenario may not be fully applicable to the IPv4 Internet, it has been deployed successfully in specific scenarios within intranets using IKEv1. It should be more broadly enabled during the transition to IPv6 and with the adoption of IKEv2. It is possible in this scenario that one or both of the protected endpoints will be behind a network address translation (NAT) node, in which case the tunneled packets will have to be UDP encapsulated so that port numbers in the UDP headers can be used to identify individual endpoints "behind" the NAT (see section 2.23).1.1.3. Endpoint to Security Gateway Tunnel
+-+-+-+-+-+ +-+-+-+-+-+ ! ! IPsec ! ! Protected !Protected! tunnel !Tunnel ! Subnet !Endpoint !<------------------------>!Endpoint !<--- and/or ! ! ! ! Internet +-+-+-+-+-+ +-+-+-+-+-+ Figure 3: Endpoint to Security Gateway Tunnel In this scenario, a protected endpoint (typically a portable roaming computer) connects back to its corporate network through an IPsec- protected tunnel. It might use this tunnel only to access information on the corporate network, or it might tunnel all of its traffic back through the corporate network in order to take advantage of protection provided by a corporate firewall against Internet-based attacks. In either case, the protected endpoint will want an IP address associated with the security gateway so that packets returned to it will go to the security gateway and be tunneled back. This IP address may be static or may be dynamically allocated by the security gateway. In support of the latter case, IKEv2 includes a mechanism for the initiator to request an IP address owned by the security gateway for use for the duration of its SA. In this scenario, packets will use tunnel mode. On each packet from the protected endpoint, the outer IP header will contain the source IP address associated with its current location (i.e., the address that will get traffic routed to the endpoint directly), while the inner IP header will contain the source IP address assigned by the security gateway (i.e., the address that will get traffic routed to the security gateway for forwarding to the endpoint). The outer destination address will always be that of the security gateway, while the inner destination address will be the ultimate destination for the packet.
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 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 routed properly.1.1.4. Other Scenarios
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 subnet may make all external accesses through a remote security gateway using an IPsec tunnel, where the addresses on the subnet are routed to the security gateway by the rest of the Internet. An example would be someone's home network being virtually on the Internet with static IP addresses even though connectivity is provided by an ISP that assigns a single dynamically assigned IP address to the user's security gateway (where the static IP addresses and an IPsec relay are provided by a third party located elsewhere).1.2. The Initial Exchanges
Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH exchanges (known in IKEv1 as Phase 1). These initial exchanges normally consist of four messages, though in some scenarios that number can grow. All communications using IKE consist of request/response pairs. We'll describe the base exchange first, followed by variations. The first pair of messages (IKE_SA_INIT) negotiate cryptographic algorithms, exchange nonces, and do a Diffie-Hellman exchange [DH]. The second pair of messages (IKE_AUTH) authenticate the previous messages, exchange identities and certificates, and establish the first CHILD_SA. Parts of these messages are encrypted and integrity protected with keys established through the IKE_SA_INIT exchange, so the identities are hidden from eavesdroppers and all fields in all the messages are authenticated. In the following descriptions, the payloads contained in the message are indicated by names as listed below. Notation Payload AUTH Authentication CERT Certificate CERTREQ Certificate Request CP Configuration D Delete E Encrypted
EAP Extensible Authentication
HDR IKE Header
IDi Identification - Initiator
IDr Identification - Responder
KE Key Exchange
Ni, Nr Nonce
N Notify
SA Security Association
TSi Traffic Selector - Initiator
TSr Traffic Selector - Responder
V Vendor ID
The details of the contents of each payload are described in section
3. Payloads that may optionally appear will be shown in brackets,
such as [CERTREQ], indicate that optionally a certificate request
payload can be included.
The initial exchanges are as follows:
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
HDR contains the Security Parameter Indexes (SPIs), version numbers,
and flags of various sorts. The SAi1 payload states the
cryptographic algorithms the initiator supports for the IKE_SA. The
KE payload sends the initiator's Diffie-Hellman value. Ni is the
initiator's nonce.
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
The responder chooses a cryptographic suite from the initiator's
offered choices and expresses that choice in the SAr1 payload,
completes the Diffie-Hellman exchange with the KEr payload, and sends
its nonce in the Nr payload.
At this point in the negotiation, each party can generate SKEYSEED,
from which all keys are derived for that IKE_SA. All but the headers
of all the messages that follow are encrypted and integrity
protected. The keys used for the encryption and integrity protection
are derived from SKEYSEED and are 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 direction. In addition to the keys SK_e
and SK_a derived from the DH value for protection of the IKE_SA,
another quantity SK_d is derived and used for derivation of further
keying material for CHILD_SAs. The notation SK { ... } indicates
that these payloads are encrypted and integrity protected using that
direction's SK_e and SK_a.
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr} -->
The initiator asserts its identity with the IDi payload, proves
knowledge of the secret corresponding to IDi and integrity protects
the contents of the first message using the AUTH payload (see section
2.15). It might also send its certificate(s) in CERT payload(s) and
a list of its trust anchors in CERTREQ payload(s). If any CERT
payloads are included, the first certificate provided MUST contain
the public key used to verify the AUTH field. 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 machine on
which the responder is running is hosting multiple identities at the
same IP address. The initiator begins negotiation of a CHILD_SA
using the SAi2 payload. The final fields (starting with SAi2) are
described in the description of the CREATE_CHILD_SA exchange.
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
The responder asserts its identity with the IDr payload, optionally
sends one or more certificates (again with the certificate containing
the public key used to verify AUTH listed first), authenticates its
identity and protects the integrity of the second message with the
AUTH payload, and completes negotiation of a CHILD_SA with the
additional fields described below in the CREATE_CHILD_SA exchange.
The recipients of messages 3 and 4 MUST verify that all signatures
and MACs are computed correctly and that the names in the ID payloads
correspond to the keys used to generate the AUTH payload.
1.3. The CREATE_CHILD_SA Exchange
This exchange consists of a single request/response pair, and was
referred to as a phase 2 exchange in IKEv1. It MAY be initiated by
either end of the 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. All subsequent messages included an Encrypted Payload, even if
they are referred to in the text as "empty".
Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
section the term "initiator" refers to the endpoint initiating this
exchange.
A CHILD_SA is created by sending a CREATE_CHILD_SA request. The
CREATE_CHILD_SA request MAY optionally contain a KE payload for an
additional Diffie-Hellman exchange to enable stronger guarantees of
forward secrecy for the CHILD_SA. The keying material for the
CHILD_SA is a function of SK_d established during the establishment
of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA
exchange, and the Diffie-Hellman value (if KE payloads are included
in the CREATE_CHILD_SA exchange).
In the CHILD_SA created as part of the initial exchange, a second KE
payload and nonce MUST NOT be sent. The nonces from the initial
exchange are used in computing the keys for the CHILD_SA.
The CREATE_CHILD_SA request contains:
Initiator Responder
----------- -----------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, optionally a Diffie-Hellman value in the KEi payload, and
the proposed traffic selectors in the TSi and TSr payloads. If this
CREATE_CHILD_SA exchange is rekeying an existing SA other than the
IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA
being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an
existing SA, the N payload MUST be omitted. If the SA offers include
different Diffie-Hellman groups, KEi MUST be an element of the group
the initiator expects the responder to accept. If it guesses wrong,
the CREATE_CHILD_SA exchange will fail, and it will have to retry
with a different KEi.
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 response contains:
<-- HDR, SK {SA, Nr, [KEr],
[TSi, TSr]}
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
KEr payload if KEi was included in the request and the selected
cryptographic suite includes that group. If the responder chooses a
cryptographic suite with a different group, it MUST reject the
request. The initiator SHOULD repeat the request, but now with a KEi
payload from the group the responder selected.
The traffic selectors for traffic to be sent on that SA are specified in the TS payloads, which may be a subset of what the initiator of the CHILD_SA proposed. Traffic selectors are omitted if this CREATE_CHILD_SA request is being used to change the key of the IKE_SA.1.4. The INFORMATIONAL Exchange
At various points during the operation of an IKE_SA, peers may desire to convey control messages to each other regarding errors or notifications of certain events. To accomplish this, IKE defines an INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur after the initial exchanges and are cryptographically protected with the negotiated keys. Control messages that pertain to an IKE_SA MUST be sent under that IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent under the protection of the IKE_SA which generated them (or its successor if the IKE_SA was replaced for the purpose of rekeying). Messages in an INFORMATIONAL exchange contain zero or more Notification, Delete, and Configuration payloads. The Recipient of an INFORMATIONAL exchange request MUST send some response (else the Sender will assume the message was lost in the network and will retransmit it). That response MAY be a message with no payloads. The request message in an INFORMATIONAL exchange MAY also contain no payloads. This is the expected way an endpoint can ask the other endpoint to verify that it is alive. 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. When SAs are nested, as when data (and IP headers if in tunnel mode) are encapsulated first with IPComp, then with ESP, and finally with AH between the same pair of endpoints, all of the SAs MUST be deleted together. Each endpoint MUST close its incoming SAs and allow 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 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 the designated SAs. Normally, the reply in the INFORMATIONAL exchange will contain 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 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 delete request for SAs for which it has already issued a delete request, it MUST delete the outgoing SAs while processing the request and the incoming SAs while processing the response. In that
case, the responses MUST NOT include delete payloads for the deleted
SAs, since that would result in duplicate deletion and could in
theory delete the wrong SA.
A node SHOULD regard half-closed connections as anomalous and audit
their existence should they persist. Note that this specification
nowhere specifies time periods, so it is up to individual endpoints
to decide how long to wait. A node MAY refuse to accept incoming
data on half-closed connections but MUST NOT unilaterally close them
and reuse the SPIs. If connection state becomes sufficiently messed
up, a node MAY close the IKE_SA; doing so will implicitly close all
SAs negotiated under it. It can then rebuild the SAs it needs on a
clean base under a new IKE_SA.
The INFORMATIONAL exchange is defined as:
Initiator Responder
----------- -----------
HDR, SK {[N,] [D,] [CP,] ...} -->
<-- HDR, SK {[N,] [D,] [CP], ...}
The processing of an INFORMATIONAL exchange is determined by its
component payloads.
1.5. Informational Messages outside of an IKE_SA
If an encrypted IKE packet arrives on port 500 or 4500 with an
unrecognized SPI, it could be because the receiving node has recently
crashed and lost state or because of some other system malfunction or
attack. If the receiving node has an active IKE_SA to the IP address
from whence the packet came, it MAY send a notification of the
wayward packet over that IKE_SA in an INFORMATIONAL exchange. If it
does not have such an IKE_SA, it MAY send an Informational message
without cryptographic protection to the source IP address. Such a
message is not part of an informational exchange, and the receiving
node MUST NOT respond to it. Doing so could cause a message loop.
(page 12 continued on part 2)
