Introduction to IKE

`IKE or Internet key exchange is the protocol responsible for negotiating the IPsec tunnel?

characteristics between two IPsec peers. IKE's responsibilities in the IPsec protocol include

? Negotiating protocol parameters

? Exchanging public keys

? Authenticating both sides

? Managing keys after the exchange

IKE solves the problems of manual and unscalable IPsec implementation by automating the?

entire key-exchange process. This is one of IPsec's critical requirements.

IKE, like IPsec, is also a combination of three different protocols:

? SKEME- Provides a mechanism for using public key encryption for authentication?

purposes.

? Oakley- Provides a mode-based mechanism for arriving at an encryption key?

between two IPsec peers.

? ISAKMP- Defines the architecture for message exchange, including packet formats?

and state transitions between two IPsec peers.

IKE combines these three protocols in one framework to provide IPsec with the facilities just?

discussed. Figure 13-3 shows these three main components of IKE.

Figure 13-3. Composition of the IKE Protocol

IKE is defined as a standard in RFC 2409. Although IKE does provide a great deal of?

functionality to the IPsec protocol, some shortcomings in the protocol structure make it?

difficult to implement in code and scale to new challenges. Work is underway to improve?

the workings of the IKE protocol and its restandardization in an improved format. This is?

called the "son-of-IKE" or IKE v2 initiative. See the IETF website for more information on?

this initiative.

IKE is a two phase protocol. An IPsec tunnel is set up between two peers through the?

following sequence of events:

Step 1. Interesting traffic is received or generated by one of the IPsec peers on an?

the interface that has been configured to initiate an IPsec session for this traffic.

Step 2. Main mode or aggressive mode negotiation using IKE results in the creation?

of an IKE Security Association (SA) between the two IPsec peers.

Step 3. Quick mode negotiation using IKE results in the creation of two IPsec SAs?

between the two IPsec peers.

Step 4. Data starts passing over an encrypted tunnel using the ESP or AH?

encapsulation techniques (or both).

Based on Steps 2 and 3, you can see that IKE is a two-phase protocol. Phase 1 is?

accomplished using main mode or aggressive mode exchanges between the peers, and?

Phase 2 is accomplished using quick mode exchanges.

This list shows how IKE behaves in a two-phase mechanism:

Step 1. In a Phase 1 exchange, peers negotiate a secure, authenticated channel with?

which to communicate. The main mode or aggressive mode accomplishes a Phase I?

exchange.

Step 2. In a Phase 2 exchange, security associations are negotiated on behalf of?

IPsec services. Quick mode accomplishes a Phase II exchange.

Main-mode exchange takes place through the exchange of a total of six messages between?

the two IPsec peers. If aggressive mode is used, only three messages complete Phase 1 of?

the exchange. Quick-mode exchange is done using an additional three messages exchanged?

between the two IPsec peers.

Figure 13-4 shows main mode, aggressive mode, and quick mode in IKE.

Figure 13-4. IKE Main Mode, Aggressive Mode, and Quick Mode

Goals of Main Mode (or Aggressive Mode)

The primary goals of the main mode (or aggressive mode) are

Agreeing on a set of parameters that are to be used to authenticate the two peers?

and to encrypt a portion of the main mode and all of the quick mode exchange. None?

of the aggressive modes is encrypted if it is used as the method for negotiation.

Authenticate the two peers to each other.

? Generate keys that can be used to generate keying material for actual encryption of?

data as soon as the negotiations have been completed.

All the information negotiated in main mode or aggressive mode, including the keys that are?

later used to generate the keys to encrypt the data, is stored as what is known as IKE or?

ISAKMP security association (SA). Any two IPsec peers have only one ISAKMP security?

association between them.

Goals of Quick Mode

The primary role of quick mode is allow the two peers to agree on a set of attributes for?

creating the IPsec security associations that will be used to encrypt (in the case of ESP) the?

data between the two hosts. Also, in the case of PFS (Perfect Forward Secrecy, which you'll?

read about later), quick mode is responsible for redoing the Diffie-Hellman (DH) exchange?

so that new keying material is available before the IPsec data encryption keys are?

generated.