14.5. IKE

The most significant changes in the new protocols are in IKE. IKEv2 is considerably different from the first version, which we discussed in Chapter 13. As we'll see, the SA establishment protocol is considerably simplified. At the same time, IKEv2 has significantly enhanced capabilities to negotiate fine-grained SAs in a reliable manner.

IKEv2 exchanges consist of two messages: a request and a response. The sender of the request provides reliability by implementing a TCP-like retransmission strategy. The default behavior is for a node to send a request and wait for the response, but messages are sequenced, so the peers can agree to multiplex several exchanges onto a single SA at the same time.

IKE Messages

IKEv2 messages are formed almost exactly as they were in IKEv1. Each message begins with an IKE header that has the same format (see Figure 13.1) that it did in IKEv1, except that the initiator and responder cookies are renamed the initiator and responder SPIs.

Following the header are one or more IKE payloads, each of which begins with a generic header, just as in IKEv1. The IKEv2 generic header is the same as in IKEv1 (see Figure 13.4), except that a critical bit has been added at bit 8 to indicate that the responder must recognize this payload. Although we won't discuss the payload formats in detail, most of them have, and are similar to, an IKEv1 equivalent.

IKE Exchanges

Recall from Chapter 13 that IKEv1 had eight possible exchange sequences that it could use to establish an IKE SA. After the IKE SA was in place, a three-message quick exchange was needed to establish a phase 2 SA. In IKEv2, the process of establishing these SAs is considerably simplified.

IKEv2 uses three exchange types to negotiate SAs:

IKE_SA_INIT	This is the initial exchange, in which the peers establish a secure channel. After the IKE_SA_INIT exchange, all further exchanges are encrypted.
IKE_AUTH	This is the second exchange, in which the peers authenticate themselves to each other and create the first child SA, a phase 2 SA in IKEv1 terminology.
CREATE_CHILD_SA	This exchange is used to create additional child SAs. It serves the same function that the Quick mode exchange does in IKEv1.

Each of these exchanges is only two messages, so the process of establishing an IKE SA and its first child SA involves only four messages. Each additional child SA takes two messages. Note that IKEv2 no longer speaks of phase 1 and 2 SAs; instead, it uses the terms IKE SA and child SA.

Let's see how IKE uses these exchanges to negotiate SAs. Figure 14.2 shows the normal IKE_SA_INIT/IKE_AUTH exchange sequence that establishes an IKE SA and its first child SA. In the typical case of a single ESP tunnel between two nodes, this is all that is required to establish the VPN. The first two messages are the IKE_SA_INIT exchange. The peers exchange keying material and nonces in the KE and NONCE payloads and negotiate IKE SA encryption and authentication parameters in the SA₁ payloads. The responder can request a certificate from the initiator by including the optional CERTREQ payload. If it wants a certificate from the responder, the initiator will request it in the IKE_AUTH exchange.

Figure 14.2. The IKE_SA_INIT and IKE_AUTH Exchanges

[View full size image]

The second two messages are the IKE_AUTH exchange. The two peers exchange their identities in the Identification (ID) payloads and authenticate them with data carried in the AUTH payloads. The exact data in the AUTH payload depends on the authentication method. If the responder has more than one identity, the initiator can indicate which identity it wishes to use, by including the ID_r payload in its IKE_AUTH message. Except for the header, everything is encrypted in the IKE_AUTH message.

We are using the same convention as in Chapter 13: Payloads that are encrypted are set in italics.

The SA₂, TS_i, and TS_r payloads are used to negotiate the child SA. The SA₂ payloads negotiate the IPsec protocol and the cryptographic primitives that it will use. Unlike IKEv1, the traffic selectors are not specified in the SA payload but are specified in their own TS_i and TS_r payloads.

Also unlike IKEv1, the generation of keying material does not depend on the type of peer authentication that is used. One of the cryptographic primitives negotiated in the SA₁ payloads is a pseudorandom function prf(K, M). This, in turn, is used to define the iterative function prf^*(K, M) as

prf^*(K, M) = T₁||T₂|| . . . ||T_n

where

T₁ = prf (K, M ||0x01)

T₂ = prf (K, T₁||M||0x02)

. . .

T_n = prf (K, T_n-1||M||n)

Keying material for the IKE SA is generated by first calculating the quantity KEYSEED as

KEYSEED = prf(NONCE_i||NONCE_r, g^x_ix_r)

where g^x_ix_r is the Diffie-Hellman shared secret calculated from the Key Exchange payloads. Next, a long string of bits, KEYMAT, is generated by

KEYMAT = prf^*(KEYSEED, NONCE_i||NONCE_r||SPI_i||SPI_r)

and keying material for the authentication, encryption, and integrity algorithms is extracted from this string. A seed for further keying material, SK_d, is also extracted from KEYMAT.

Keying material for the first child SA is generated in a similar way, using SK_d instead of KEYSEED:

KEYMAT = prf^*(SK_d, NONCE_i||NONCE_r)

where the nonces are from the IKE_SA_INIT exchange.

IKEv2 has three methods for the peers to authenticate their identities. Two of these methods involve having the peers sign selected data from the exchanges. The peers may do this using the prf and a shared secret, or they can use one of the common signature methods, such as DSA or RSA.

The third method is to use the Extensible Authentication Protocol (EAP). In general, EAP is more complicated and will involve the exchange of additional messages, but it provides a general framework into which new authentication methods can be added without changing the IKEv2 protocol. EAP is specified in RFC 3748 [Aboba, Blunk, Vollbrecht et al. 2004].

If additional child SAs are required or if the IKE SA or one of the child SAs needs to be rekeyed, the peers execute a CREATE_CHILD_SA exchange. Figure 14.3 shows the CREATE_CHILD_SA exchange.

If the exchange is to rekey an existing SA, the first payload must be a Notify payload, N, that specifies which SA is being rekeyed. If a new child SA is being negotiated, the N payload must not be present.

For perfect forward secrecy, the peers can include the optional Key Exchange payloads in the exchange. In this case, the new keying material will be generated by

KEYMAT = prf^*(SK_d, g^x_ix_r||NONCE_i||NONCE_r)

where the g^x_ix_r is the new Diffie-Hellman shared secret from the exchange. The nonces are from the current exchange. If perfect forward secrecy is not required, the new keying material is generated the same way except that the Diffie-Hellman shared secret is not concatenated to the nonces.

There are two other types of exchanges. The first is used to help prevent denial-of-service attacks. The rationale for this exchange is much like the cookie exchange from IKEv1. An attacker can send dummy IKE_SA_INIT requests with a forged source address, forcing the responder to perform expensive Diffie-Hellman calculations for its response. If the responder notices that it has several half-completed IKE SAs, it can insist that its peer prove that it is reachable at its source address by sending a Notify payload containing a cookie instead of the response to the IKE_SA_INIT request. The requester then repeats its request, including the Notify payload with the cookie. Figure 14.4 shows the exchanges.

Figure 14.4. The Initial Exchange with a Cookie

[View full size image]

The HDR(x,y) notation shows the contents of the SPIs in the header: I indicates the initiator's SPI and R the responder's SPI; 0 indicates the SPI has not been determined yet.

The other exchange is the INFORMATIONAL exchange. Like all IKEv2 exchanges, each INFORMATIONAL exchange request expects a response. Three types of payloads can be included in an INFORMATIONAL exchange. Any number of any combination of payloads can be included, as shown in Figure 14.5.

We've already seen the Notify payload (N) in conjunction with cookies. There are several other types as well. They carry error and status information, much as they do in IKEv1. The Delete payload (D) informs the peer that the sender has deleted one or more of its incoming SAs. The responder is expected to delete those SAs as well and will usually include Delete payloads for the corresponding SAs in the other direction in its response message.

The Configuration payload (CP) is used to negotiate configuration data between the peers. One important use of the CP payload is to request (request) and assign (response) an address on a network protected by a security gateway. In the typical case, a mobile host will establish a VPN with a security gateway on its home network and will request that it be given an IP address on the home network. Notice that this eliminates one of the problems that the combined use of L2TP and IPsec (Chapter 5) is intended to solve.

IKEv2 is a very rich protocol, and we have looked only at some of its more important features here. IKEv2 is intended to simplify the key-management function in IPsec, to add new flexibility in negotiating SAs, and to solve some of the problems in IKEv1.