MARCO LEGAL

Even though complete understanding of IKE conversation requires understanding of ISAKMP, we stop mentally torturing of the readers interested only in IKE highlights and provide an overview of the IKE conversation. Those interested in the details can read the following sections on the ISAKMP and the IKE authentication process.

IKE is a peer-to-peer protocol, but it distinguishes between the party that starts the conversation (initiator) and the party that responds to the initiator (responder). It may or may not be intuitive to the reader that even though IKE serves the purpose of key manage- ment for IPsec (a layer-3 protocol), IKE conversations run above transport layer: IKE runs over UDP port 500.

IKE conversation has a two-phase nature, imitating the two phases of ISAKMP: in the first phase of IKE, the two parties establish a secure communications channel that is also called the IKE SA. During its second phase, IKE uses the IKE SA to securely negotiate the IPsec SAs, including the keys and transforms. It should be noted that unlike IPsec SAs, the IKE SA (the ISAKMP SA) is a bidirectional SA that is identified by the initiator cookie (CKY_I), followed by the responder’s cookie (CKY_R). As mentioned earlier, IKE is a peer-to-peer protocol, which does not segregate between the initiator and the responder except the fact that the party that starts the conversation is the initiator and hence that party’s cookie is the initiator cookie. For that reason, it is important that the cookies do not swap places during the signaling, so that each party can easily identify the IKE SA. In the following, we will provide a brief overview of the two IKE phases.

4.3.2.1 IKE Phase 1

The purpose for IKE phase 1 is establishment of an ISAKMP security association (IKE SA). As shown in Figure 4.5, the basic mode of IKE phase 1 (called main mode) involves a total of six messages between the two peers, requiring three exchanges (three round trips).

The first round involves exchange of initiator and responder cookies, CKY_I and CKY_R, respectively, and SA transform proposals, such as Diffie–Hellman groups and so on. Note that peer identifiers are not exchanged at this point to protect their privacy. In the picture, the cookies are called C_i and C_r for simplicity. The details of cookie generation are implementation- dependent, but the cookie must be unique to the party generating the cookie (possibly based on some local secrets). In other words, it must not be possible for anyone other than the issuing peer to generate the cookie.

The second round accomplishes the Diffie–Hellman exchange itself. However, the DH exchange within IKE uses the cookies exchanged previously (to prevent an attacker launching many DH negotiations with the responder) and nonces, N_i and N_r, to prevent replay attacks. X and Y in the figure are the DH half keys that were explained in Chapter 3. Once the two peers performed the DH exchange, they now share a secret that can be used to encrypt the following traffic.

During the third exchange of IKE phase 1, the two peers engage in a protected mutual authentication, including exchange of both their identities and their authentication credentials. This way, the identity of the peers are protected by the encryption provided for this exchange. Several authentication mechanisms are suggested for IKE as described later. For that reason, we keep the generic notation “Auth” within the figure. When the third exchange of IKE phase 1 is complete, the two peers share an IKE SA that can be used to protect the conversations during phase 2.

4.3.2.2 IKE Phase 2

During phase 2 conversations, the two peers negotiate the details of IPsec SAs to be used to protect the data traffic. The basic mode of operation in this phase is called quick mode. (No, there is no slow mode!) Except the message headers (explained later on), all payload carrying the exchanged information are protected by the IKE SA negotiated during the phase 1. The IPsec SA details that are negotiated in this phase include keys, transforms (algorithms), and IPsec proto- cols (ESP and AH) for protection of the session. Note that IPsec SAs are unidirectional, and therefore a pair of IPsec SAs must be established for each IPsec transform during this phase.

Once the IPsec SAs negotiation is complete, the original IKE SA can terminate after the phase 2 exchanges, while the IPsec SAs remain in existence as long as their lifetime allows. However, the original IKE SA typically is kept alive for future refreshment of IPsec SAs.

It is implicitly assumed that the identities passed during phase 2 are the IP addresses of the peers. Phase 2 exchanges must always follow a phase 1 performed earlier and cannot be initi- ated prior to completion of phase 1. However, once the non-ISAKMP SA (e.g. IPsec SA) are established as a result of the first phase 2 exchange, these exchanges can be repeated at later times to refresh the keys for those SAs. This is done by producing new nonces (Ni and Nr) and running the exchange again. This is one of the major advantages of IKE over plain Diffie–Hellman exchange that does not provide key refreshes. Periodic re-keying is a desired feature for protection of long-lived sessions.

4.3.2.3 Round Trip Optimizations

As we can see, the number of round trips required by the two IKE phases is rather large, making the key exchange process very lengthy and CPU consuming. For those reasons, people have been looking for ways to reduce the delay associated with these round trips.

Initiator Responder

Phase 1: (1) Cookie and proposals, Ci, ISAi

Phase 1 (3): DH exchange, Ci, Cr, X, Ni

Phase 1 (5): (Encrypted) Auth. exchange, Ci, Cr, Idi

Phase 2: Ci, Cr, AUTHi, SAi, Ni, [X], [IDi, IDr] Phase 1 (4), DH exchange, Ci, Cr, Y, Nr

Phase 1: (2) Cookie and proposal response, Cr, ISAr

Phase 2 (6) (Encrypted) Auth. exchange, Ci, Cr, Idr

Phase 2: Ci, Cr, AUTHr, SAr, Nr, [Y], [IDi, IDr] Phase 2: Ci, Cr, AUTH

Figure 4.5 Basic IKE conversation consisting of two phases with total of nine messages. A main mode phase 1 and a quick mode phase 2 exchange are shown

The IKE specification [IKE2409] provides a faster alternative for phase 1, called aggressive mode, which requires only three messages (1.5 round trips) as opposed to the three round trips required by the main mode. As shown in Figure 4.6, aggressive mode combines the cookie and proposal exchange with the Diffie–Hellman exchange. Also as one can see in the figure, the peer identities are carried in the clear, which means in the aggressive mode is less secure when it comes to protecting the privacy of the clients.

IKE specification provides two modes for phase 2 as well. Besides the quick mode, there is another mode called new group mode, which can be used to change the cryptographic group for future negotiations without establishing any new SAs on its own.