13.3. IKE

Our discussion of ISAKMP and its payloads was long and detailed but will make our examination of IKE much easier. Like ISAKMP, IKE has five exchange types, and three of them are instantiations of ISAKMP exchanges. The two new exchangesQuick Mode and New Groupare used only in phase 2 negotiations.

In the previous section, we did not examine the protocols used to implement the exchange types. We do that now, as we look at phase 1 and 2 negotiations in detail.

IKE Phase 1

Let's imagine two nodes that want to establish an IPsec tunnel between themselves. We can suppose that they have policies that allow such a tunnel and specify acceptable transforms, but at the start, they have no shared state. The purpose of phase 1 is to establish an encrypted, authenticated channel between the two nodes so that they can securely negotiate the appropriate IPsec SAs, such as ESP or AH. A further requirement of the phase 1 SA negotiation is that each node authenticate its identity to its peer. Thus, after the phase 1 SA is established, both peers will know that they are talking to the proper endpoint and will have a secure channel over which they can negotiate further SAs. Unlike phase 2 SAs, phase 1 SAs are bidirectional; that is, a single SA protects both inbound and outbound traffic.

IKE has two modes, or exchange types, that it can use to negotiate a phase 1 SA. The first of these, Main mode, is more flexible and can hide the identities of the endpoints, but it requires twice as many messages (six) as the other, Aggressive mode. Regardless of which mode is used, there are four ways of authenticating a peer:

• A shared secret

• A digital signature

• Public key encryption

• Revised public key encryption

Thus, there are eight ways of negotiating a phase 1 SA. We examine each one and remark on its benefits and disadvantages. It is easier to contrast Main mode and Aggressive mode if we consider them together for each of the authentication methods, but first, let's look at generic Main and Aggressive mode negotiations so that we can appreciate their differences without the distraction of a particular authentication method.

The IKE Main mode exchange is an instantiation of the ISAKMP Identity Protect exchange. Figure 13.27 shows a Main mode exchange. The exchange proceeds in three stages. First, the initiator sends a message that contains an ISAKMP header (HDR) and an SA payload (SA). As we saw in the previous section, the SA payload will contain a list of proposals and transforms from which the responder must choose. The responder replies with its own header and an SA payload that contains its chosen proposals and transforms.

Recall that each side has also contributed a cookie in the ISAKMP header. The initiator sends its cookie, CKY_i, and sets the responder's cookie field to 0. The responder contributes its own cookie, CKY_r, and returns it and the initiator's cookie in its ISAKMP header. These two cookies are the identifier for this SA. When the responder gets the next message from the initiator, the message must have the same set of cookies, or the responder will abort the negotiation. Once the responder gets the second message, it knows that the IP address of the initiator is legitimate; otherwise, the initiator would not have received the responder's cookie. This is the protection against DOS attacks that we mentioned earlier.

In the next stage, the initiator sends a header, a Key Exchange payload (KE), and a nonce (NONCE_i). The Key Exchange payload will contain the initiator's Diffie-Hellman private key, g^x_i (see Chapter 3), that the responder will use to calculate the Diffie-Hellman shared secret. The nonce serves two purposes: It will be used in the key-generation algorithms to ensure that each side contributes to the final keys, and, because it is used as part of the authentication procedure, it offers a proof of liveness. That is, the nonce enables a peer to detect whether an attacker is replaying an old exchange. We'll see this aspect in action when we examine the various authentication methods. The responder replies with its own header, Key Exchange payload, and nonce. At this point, both sides can calculate the Diffie-Hellman shared secret that is used to generate the keying material. As we'll see, the exact means of generating the keying material depends on the authentication method, but they use the Diffie-Hellman shared secret, the nonces, and the cookies as inputs.

In the third and final stage, the initiator sends a header, an Identification payload (ID_i), and some authentication information (AUTH). We show the Identification and Authentication payloads in italics to indicate that they are encrypted, using the keys derived from the information in the first two stages. Notice how this protects the identification information. This may not make any sense until we realize that the two nodes can use proxies to negotiate their SAs for them. In this case, the identity of the proxies will be known from their IP addresses, but the identities of their clients will be hidden.

At the end of the Main mode exchange, the two nodes have agreed on encryption and data integrity algorithms for the phase 1 SA and have generated the keys for those algorithms. The two nodes can now use this SA to negotiate further IPsec SAs in the phase 2 negotiations.

Main mode requires the exchange of six messages. Aggressive mode, shown in Figure 13.28, requires only three. As the name suggests, the IKE Aggressive mode is an instantiation of the ISAKMP Aggressive mode.

In the first message, the initiator sends a header and SA, Key Exchange, Nonce, and Identification payloads. Notice that this combines the first two messages that the initiator sends in Main mode.

The responder replies with its own header and SA, Key Exchange, Nonce, and Identification payloads. It also sends some authentication information (AUTH). At this point, both sides can generate their keying material, and the responder has authenticated itself to the initiator.

In the final message, the initiator authenticates itself to the responder by sending it authentication information. The ISAKMP specification, RFC 2409, specifies that this last message should be encrypted, so we have shown it in italics. IKE makes the encryption of the last message optional, the idea being that the peers can delay the expensive key-generation operations until each side has authenticated itself to its peer.

Key Generation

IKE doesn't generate any encryption or authentication keys directly; that's up to the particular encryption and authentication algorithms that get negotiated. What IKE does do is provide keying material for those algorithms. That is, if the encryption algorithm requires 128 bits of data to generate a key, IKE will provide that data.

The keying material depends on the ISAKMP cookies, the nonces, and the Diffie-Hellman shared secret, but the exact method of calculation depends on the authentication method. The process begins with the calculation of the quantity SKEYID. This value is calculated in a distinct manner for each of the authentication methods and is why the keying material depends on the authentication method. We'll look at how SKEYID is calculated as we examine each authentication method.

Once we have SKEYID, we can calculate the other sources of keying material:

SKEYID_d = prf (SKEYID, g^x_ix_r||CKY_i||CKY_r||0)

SKEYID_a = prf (SKEYID, SKEYID_d||g^x_ix_r||CKY_i||CKY_r||1)

SKEYID_e = prf (SKEYID, SKEYID_a||g^x_ix_r||CKY_i||CKY_r||2)

where prf is a pseudorandom function that is negotiated in the SA payload. Currently, no pseudorandom functions are defined, so we use the default, which is HMAC, using whatever hash function was negotiated for authentication.

SKEYID_d is used to derive further keying material for non-ISAKMP SAs, such as those negotiated in phase 2. SKEYID_a is the keying material used to authenticate the ISAKMP negotiation. Similarly, SKEYID_e is the keying material used to encrypt the messages on the ISAKMP secure channel.

SKEYID_e will have however many bits the underlying hash function outputs. For example, if the prf function is HMAC-SHA-1, SKEYID_e will be 160 bits. If the negotiated encryption algorithm requires more bits, the key can be expanded by feeding it back into the prf function in the usual way:

K₁ = prf (SKEYID_e, 0)

K₂ = prf (SKEYID_e, K₁)

. . .

K_n = prf (SKEYID_e, K_n-1)

K = K₁||K₂|| . . . ||K_n

Authentication with a Shared Secret

The simplest authentication method is for the two nodes to share a secret. This sounds vaguely like a password-based scheme, but although the secret is long lived, it is not a key and is never sent directly to a peer, even over an encrypted channel. Rather, it is used as an input into the key-generation operation and, through that, appears as part of an authentication hash. We'll look at the exact details momentarily.

Figure 13.29 shows a Main mode negotiation using a shared secret. Notice that the figure is identical to Figure 13.27 except that the authentication placeholders, AUTH, in the last two messages, are replaced with the two hashes HASH_i and HASH_r. For shared-secret authentication, we calculate SKEYID as

SKEYID = prf (shared_secret, body(NONCE_i)||body(NONCE_r))

where body(P) means the P payload minus the generic header. This is the only place that the shared secret is used.

The authentication is done by taking a hash over the Diffie-Hellman private keys, the cookies, and the bodies of the SA and Identification payloads:

HASH_i = prf(SKEYID, g^x_i||g^x_r||CKY_i||CKY_r||body(SA_i)||body(ID_i))

HASH_r = prf(SKEYID, g^x_r||g^x_i||CKY_r||CKY_i||body(SA_i)||body(ID_r))

Notice that these hashes authenticate all the relevant state and will not calculate the expected value unless the shared secret is correct. Thus, when each node verifies its peer's hash, it will know that the messages were not tampered with during transmission and that its peer possesses the shared secret and therefore is who it claims to be.

Figure 13.30 shows the message flow for Aggressive mode with shared-secret authentication. Notice that we have shown HASH_i as encrypted, but as noted previously, IKE does not require this.

Let's take a moment to consider the advantages and disadvantages of Aggressive mode over Main mode. The first advantage of Aggressive mode is clear: It requires only half the messages that Main mode does. Given the relative infrequency of ISAKMP negotiations between two peers, this may or may not be significant.

The second advantage is more subtle. Recalling Figure 13.29, we see that in Main mode, the responder must decide on what shared secret to apply to the negotiation, based on the initiator's IP address, because that is the only identification of the initiator it has when it calculates SKEYID. This means that it is not possible to negotiate the SA unless the responder can map the initiator's IP address to the correct shared secret. If we consider a mobile host with a variable IP address or the common case of a host that gets a dynamic IP address from its ISP's DHCP server, we see that Main mode with shared-secret authentication will not work in all situations.

With Aggressive mode, however, the peers receive the Identification payload at the same time they receive the Key Exchange payload and are therefore able to deal with hosts whose IP addresses they don't know beforehand. This means that the responder can use the information in the Identification payload to determine the shared secret, rather than depending on the IP address. With the increasing use of mobile computers, this is a significant advantage.

On the other hand, Aggressive mode suffers from a lack of flexibility. Because the Key Exchange payload is sent in the same message as the SA payload, the peers cannot negotiate which Diffie-Hellman group to use, as they can with Main mode. Also note that Aggressive mode does not hide the identification information as Main mode does. This may or may not be a problem, depending on the threat model.

Authentication with Signatures

Authentication with signatures is similar to that with shared secrets, but instead of including a shared secret in the SKEYID calculation, the peers digitally sign the hashes HASH_i and HASH_r.

Figure 13.31 shows the message flow for Main mode with signatures; Figure 13.32, for Aggressive mode. Instead of including HASH_i and HASH_r directly, as with shared-secret authentication, the hashes are signed and their signatures sent instead. That is, SIG_i and SIG_r are the signatures of HASH_i and HASH_r respectively.

RFC 2409 specifies that the function used to generate the signature should be the prf function, unless the signature method negotiated mandates a particular hash. For example, DSS mandates the use of SHA-1 (see Chapter 3).

When RSA signatures are used, the signatures are encoded as a private key encryption (not signature) in PKCS #1 format.

After a peer has the Key Exchange payload, it calculates SKEYID as

SKEYID = prf (body(NONCE_i)||body(NONCE_r), g^x_ix_r )

SKEYID_d, SKEYID_a, SKEYID_e, and the two hashes HASH_i and HASH_r are calculated just as they were for the shared-secret authentication method.

Notice from the figures that each side can optionally include a certificate. This is a convenient way of handling authentication with signatures. For example, an organization might distribute certificates signed by the organization to each of its "road warriors." When the mobile host negotiates its phase 1 SA, it sends the certificate that contains its public key to the responder, which might be a security gateway on the organization's network. The responder can use the public key to verify the signature; because the certificate is signed, the responder knows that the public key is legitimate.

Authentication with Public Key Encryption

In authentication with public key encryption, each node encrypts the Nonce and Identification payloads with the public key of its peer. The peers prove their authenticity with the exchange of the HASH_i and HASH_r payloads. Because these hashes include the encrypted data in their calculations, sending the correct hash implies that the sender was able to decrypt the message and thus possesses the private key.

Looking at the Main mode (Figure 13.33) and Aggressive mode (Figure 13.34) exchanges helps make this clearer. In the message flow diagrams, P_x(Y) indicates the encryption of the body of Y with the public key of x.

The generic header is still included in the payload but is in the clear. Thus, P_x(Y) consists of the generic header of Y in the clear, followed by the body of Y encrypted by the public key of x.

It may be that a responder has several public keys available for use. In that case, the initiator can send a hash of the certificate containing the key that it used. We show this as the optional HASH₁ in the two figures. The hash is calculated with the negotiated hash algorithm.

This really makes sense only for Main mode where the SA negotiation is complete. The IKE specification, RFC 2409, does not give any guidance as to which hash function should be used in Aggressive mode.

Using public key encryption for authentication has several advantages. In the first place, there is extra security, because an attacker must break both the Diffie-Hellman exchange and the RSA encryption to obtain the state needed to generate the session keys. Second, this method offers both sides repudiation. Because either side could generate the entire exchange, there is no proof that a conversation between the two peers actually took place. Finally, note that this authentication method hides the Identification payloads even in Aggressive mode.

Authentication with Revised Public Key Authentication

Although public key authentication offers advantages over the other methods we've examined, it requires each node to perform four expensive public key calculations: two encryptions and two decryptions. Recall from Chapter 3 that each of these calculations can take up to two orders of magnitude more time than even a slow symmetric encryption. This won't matter much if we're setting up a single VPN between two hosts, but it can become a significant overhead on a busy security gateway that is handling hundreds of VPNs between multiple endpoints.

To alleviate this problem, IKE offers authentication with revised public key encryption. This mode offers all the advantage of authentication with public key encryption, but with half the public key calculations. The basic idea is that only the Nonce payload is encrypted with the public key; the Key Exchange, Identification, and optional Certificate payloads are encrypted with a symmetric encryption algorithm using a key derived from the nonce. The optional certificate provides the responder with the initiator's public key.

Figure 13.35 (Main mode) and Figure 13.36 (Aggressive mode) show the message flows for this method.

Figure 13.35. Main Mode with Authentication, Using Revised Public Key Encryption

[View full size image]

Figure 13.36. Aggressive Mode with Authentication, Using Revised Public Key Encryption

[View full size image]

The notation E_Kx (Y) indicates symmetric encryption of the body of Y, using a key derived from NONCE_x.

As with P_x(Y), the generic header is still included in E_Kx (Y) but is in the clear.

The symmetric encryption algorithm is the one negotiated in the SA payload.

The symmetric keys K_i and K_r are derived from keying material N_i and N_r, respectively, according to the encryption algorithm's specification. The keying material is derived from the nonces NONCE_i and NONCE_r as follows:

N_i = prf(body(NONCE_i), CKY_i)

N_r = prf(body(NONCE_i), CKY_r)

If this doesn't produce enough keying material for the encryption algorithm, the keying material is expanded exactly as it is for SKEYID_e.

New Group Exchange

As we've seen, ISAKMP and IKE have several predefined groups that the peers can use for making their Diffie-Hellman calculations. Additional groups may be negotiated in Main mode by sending the group attributesprime and generator for Diffie-Hellman over Z_p, for examplein the negotiated Transform payloads. In addition, the peers can negotiate a new Diffie-Hellman group after phase 1 has concluded, by using the new group exchange.

Although the New Group exchange can take place only after the conclusion of phase 1, it is not a phase 2 negotiation. We should think of it as taking place outside of either phase 1 or phase 2 but only after phase 1.

As with groups negotiated with Main mode, the new group can be specified either with its predefined group number or by sending its attributes. The receiving peer should verify that the group is acceptable and respond with a Notify message if it's not.

Figure 13.37 shows the message flow for a New Group exchange.

The two hashes are calculated as:

HASH₁ = prf(SKEYID_a, MsgID||SA)

HASH₂ = prf(SKEYID_a, MsgID||SA)

The two hashes guarantee livenessthat is, protect against replayby including the message ID field from the ISAKMP header. Recall that every exchange that takes place over a phase 1 SA has a unique message number.

Although Figure 13.37 shows an initiator and a responder as usual, these roles may not be the same as they were during phase 1. That is, if host A initiates a phase 1 SA negotiation to host B, it is perfectly legal for host B to be the initiator of the New Group exchange.

The phase 1 cookies, CKY_i and CKY_r, retain their association with the original hosts and remain in the same order in the ISAKMP header. That's because those cookies are used to identify the phase 1 SA.

This same principle applies to phase 2 exchanges. Either peer may play the role of initiator.

Phase 2Quick Mode

Once a phase 1 SA is established, the peers can use it to negotiate phase 2 IPsec SAs. They do this with a phase 2 Quick mode exchange. The name comes from that fact that if perfect forward secrecy is not required, the two SAs can be negotiated very quickly with three messages and without requiring any expensive Diffie-Hellman calculations. If perfect forward secrecy is required, the exchange still requires only three messages, but the peers include optional Key Exchange payloads in the messages. Similarly, the identities of the peers are assumed to be determined by their IP addresses, unless they include optional Identification payloads. Figure 13.38 shows the message flow of a typical Quick mode exchange. We also show the optional Key Exchange and Identification payloads.

The two hashes HASH₁ and HASH₂ authenticate the messages. HASH₂ and HASH₃ provide proof of liveness. HASH₂ does this by including the body of the initiator's nonce, and HASH₃ does it by including the bodies of both nonces.

The three hashes are calculated as

HASH₁ = prf (SKEYID_a, MsgID||SA||NONCE_i [||KE] [||ID_i||ID_r])

HASH₂ = prf (SKEYID_a, MsgID|| body(NONCE_i)||SA||NONCE_r [||KE] [||ID_i||ID_r])

HASH₃ = prf (SKEYID_a, 0||MsgID|| body(NONCE_i)||body(NONCE_r))

When perfect forward secrecy is not required, the peers generate keying material for the new SAs as

KEYMAT = prf (SKEYID_d, protocol||SPI||body(NONCE_i)||body(NONCE_r))

where the protocol and SPI fields are from the ISAKMP proposal that contained the Transform payload of the algorithm that requires the keying material. Because there are two values for the SPIone from each peerthe keys for the inbound and outbound SAs will be different.

Note how quickly the keying material can be generated. Four quantities are concatenated and then run through an HMAC calculation. There is no expensive, big-number arithmetic that Diffie-Hellman exponentiation required.

When perfect forward secrecy is required, the peers exchange Diffie-Hellman private keys in the Key Exchange payloads and use them to calculate the Diffie-Hellman shared secret, g^x_ix_r. This shared secret is then used to calculate the keying material as

KEYMAT = prf (SKEYID_d, g^x_ix_r||protocol||SPI||body(NONCE_i)||body(NONCE_r))

Once the keying material is generated, all the state associated with the phase 2 Diffie-Hellman calculations is discarded.

If additional keying material is required, the peers generate it by feeding the output of one prf calculation into another in the usual way:

K₁ = prf (SKEYID_d, [g^x_ix_r|| ] protocol||SPI|| body(NONCE_i)||body(NONCE_r))

K₂ = prf (SKEYID_d, K₁|| [g^x_ix_r|| ] protocol||SPI|| body(NONCE_i)||body(NONCE_r))

. . .

K_n = prf (SKEYID_d, K_n-1|| [g^x_ix_r|| ] protocol||SPI|| body(NONCE_i)||body(NONCE_r))

KEYMAT = K₁||K₂|| . . . ||Kn

As usual, the individual cryptographic algorithms negotiated for the SA determine how to use the keying material to generate their keys.

As mentioned previously, a phase 2 Quick mode exchange can negotiate multiple SAs at once. This is done by merely including multiple SA payloads in the exchange, as shown in Figure 13.39.