Chapter 05: Site-to-Site VPNs (Part03)

IKE Protocol

IPsec implements a VPN solution using an encryption process that involves the periodic changing of encryption keys. IPsec uses the IKE protocol to authenticate a peer computer and to generate encryption keys. IKE negotiates a security association (SA), which is an agreement between two peers engaging in an IPsec exchange, and consists of all the required parameters necessary to establish successful communication.

IPsec uses the IKE protocol to provide these functions:

• Negotiation of SA characteristics

• Automatic key generation

• Automatic key refresh

• Manageable manual configuration

To establish a secure communication channel between two peers, the IKE protocol uses the following three modes of operation:

• Main mode: In main mode, an IKE session begins with one computer (the initiator) sending a proposal or proposals to another computer (the responder). The proposal sent by the initiator defines what encryption and authentication protocols are acceptable, how long keys should remain active, and whether Perfect Forward Secrecy (PFS) should be enforced. There are three exchanges typical of the main mode:

  • The first exchange between the initiator and the responder establishes the basic security policy. The responder chooses a proposal best suited to the security situation and then sends that proposal to the initiator.

  • The next exchange passes DH public keys between the two users. DH key exchange is a cryptographic protocol that allows two parties that have no prior knowledge of each other to establish a shared-secret key over an unsecure communications channel. All further negotiation is encrypted within the IKE SA.

  • The third exchange authenticates an Internet Security Association and Key Management Protocol (ISAKMP) session. Once the IKE SA is established, IPsec quick mode negotiation begins.

• Aggressive mode: Aggressive mode compresses the IKE SA negotiation phases described thus far into three packets. In aggressive mode, the initiator passes all data that is required for the SA. The responder sends the proposal, key material, and ID and authenticates the session in the next packet. The initiator replies by authenticating the session. Negotiation is quicker, and the initiator and responder IDs pass in plaintext.

• Quick mode: Quick mode IPsec negotiation takes place after successful IKE SA negotiation. Quick mode is similar to aggressive mode IKE negotiation, except that negotiation is protected within an IKE SA. Quick mode negotiates the SA for the data encryption and manages the key exchange for that IPsec SA.

To establish a secure communication channel between two peers, the IKE protocol executes the following phases:

• IKE Phase 1: In IKE Phase 1, two IPsec peers perform the initial negotiation of SAs. In this phase, the SA negotiations are bidirectional; data may be sent and received using the same encryption key. In IKE Phase 1, the transform sets, hash methods, and other parameters are determined. Optionally, IKE Phase 1 can include authentication, in which each peer in the SA negotiation is able to verify the identity of the other. Even if the SA negotiation data stream between the two IPsec peers is compromised, there is little chance that the encryption keys could be guessed and thus the traffic decrypted.

• IKE Phase 2: In IKE Phase 2, SAs are negotiated by the IKE process ISAKMP on behalf of other services, such as IPsec, that need encryption key material for operation. Quick mode negotiates the IKE Phase 2 SAs. In this phase, the SAs that IPsec uses are unidirectional; therefore, a separate key exchange is required for each data flow.

  Note

  Other, optional parameters are sometimes negotiated between IKE Phase 1 and IKE Phase 2, such as level of DH, encryption algorithms, and methods of authentication.

IKE Phase 1

The basic purpose of IKE Phase 1, shown in Figure 5-15, is to negotiate IKE policy sets, authenticate the peers, and set up a secure channel between the peers. IKE Phase 1 occurs in two modes: main mode and aggressive mode.

Figure 5-15: IKE Phase 1

Main mode has three two-way exchanges between the initiator and receiver:

• First exchange: Peers negotiate and agree on the algorithms and hashes that will be used to secure the IKE communications.

• Second exchange: DH generates public and private values. The peers exchange their public values, and the result is a shared secret. The shared-secret key is used to generate all the other encryption and authentication keys.

• Third exchange: The identity of the other side is verified. The main outcome of main mode is a secure communications path for subsequent exchanges between the peers.

Note

In aggressive mode, fewer exchanges are done, and the exchanges have fewer packets. As an example, with aggressive mode, the peers will exchange their identity and a hash of the PSK even though DH have not been negotiated yet, and therefore there is no shared secret to send data in an encrypted format.

IKE Phase 1: Example

When you are trying to make a secure connection between Host A and B through the Internet, a secure path (a tunnel) is established between Router A and Router B. Through the tunnel, the encryption, authentication, and other protocols are negotiated.

First Exchange: IKE Policy Is Negotiated

Rather than negotiate each protocol individually, the protocols are grouped into sets, called IKE policy sets. IKE policy sets are exchanged during the IKE main mode, first exchange phase. If a policy match is found between peers, main mode continues. If no match is found, the tunnel is torn down.

In Figure 5-16, Router A sends IKE policy sets 10 and 20 to Router B. Router B compares its set, policy set 15, with those received from Router A. In this instance, there is a policy match. Policy set 10 of Router A matches the policy set 15 of Router B.

Figure 5-16: First Exchange: IKE Policy Is Negotiated

Note

Policy set numbers are only locally significant to a VPN device. The policy set numbers do not have to match between two VPN peers.

In a point-to-point application, each end may need only a single IKE policy set to be defined. However, in a hub-and-spoke environment, the central site may require multiple IKE policy sets to satisfy all the remote peers.

Second Exchange: DH Key Exchange

When the IKE policy is agreed on, including the size of the prime number to be used for DH, the two peers run the DH key exchange protocol, as shown in Figure 5-17. The result of DH will be the creation of a shared secret that is needed by the various encryption and hashing algorithms upon which IKE and IPsec will ultimately agree.

Figure 5-17: Second Exchange: DH Key Exchange

Several levels of DH key exchanges are available in Cisco IOS Software:

• DH Group 1: A key exchange that uses a 768-bit prime number. This group is the usual choice when the encryption algorithm is DES.

• DH Group 2: A key exchange that uses a 1024-bit prime number. This group is the usual choice when using 3DES for encryption.

• DH Group 5: A key exchange that uses a 1536-bit prime number. DH 5 should be used with AES.

• DH Group 7 (elliptic curve cryptography [ECC]): A key exchange that generates IPsec keys when the elliptic curve field is 163 bits. This group was designed to be used with low-powered hosts such as PDAs.

Third Exchange: Authenticate Peer Identity

When you are conducting business over the Internet, it is necessary to know who is at the other end of the tunnel. The device on the other end of the VPN tunnel must be authenticated before the communications path is considered secure. The last exchange of IKE Phase 1 authenticates the remote peer, as illustrated in Figure 5-18.

Figure 5-18: Third Exchange: Authenticate Peer Identity

There are three data origin authentication methods:

• PSKs: PSKs are a secret key value that is entered into each peer manually and is used to authenticate the peer.

• RSA signatures: RSA signatures are the exchange of digital certificates that is used to authenticate the peers.

• RSA encrypted nonces: Nonces are random numbers that are generated by each peer and are encrypted and then exchanged between peers. The two nonces are used during the peer-authentication process.

IKE Phase 2

The purpose of IKE Phase 2 is to negotiate the IPsec security parameters, as shown in Figure 5-19, that will be used to secure the IPsec tunnel. IKE Phase 2 performs the following functions:

Figure 5-19: IKE Phase 2

• Negotiates IPsec security parameters, known as IPsec transform sets

• Establishes IPsec SAs

• Periodically renegotiates IPsec SAs to ensure security

• Optionally performs an additional DH exchange

IKE Phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the secure tunnel in Phase 1. It negotiates a shared IPsec transform, derives shared-secret keying material that the IPsec security algorithms will use, and establishes IPsec SAs. Quick mode also exchanges nonces that are used to generate new shared-secret key material and prevent replay attacks from generating false SAs.

Quick mode also renegotiates a new IPsec SA when the IPsec SA lifetime expires. Basically, quick mode refreshes the keying material that creates the shared-secret key based on the keying material derived from the DH exchange in Phase 1.

Earlier, the text mentioned Perfect Forward Secrecy (PFS). The basic principle of PFS is that new keys (shared secrets) cannot be derived from older keys. The idea is that if keys are compromised, previous and subsequent keys are secured because they were generated from scratch and not derived. Therefore, PFS exists when a DH exchange is done at each rekeying interval, which is preferable, but might not be necessary, instead of deriving the new keys from the previous keys.

Key Topic

IKE negotiates matching IPsec policies.

Note

Because a picture is worth a thousand words, Figure 5-20 is the visual representation of IPsec I created to teach students the sequence of events when tunnels are being built. The process starts at the bottom of the figure with IKE Phase 1, followed by IKE Phase 2, and finally with the two unidirectional IPsec tunnels coming up to exchange the encrypted data. Figure 5-20: Visual Representation of IPsec Tunnels Being Built