How IKE Negotiates SAs

IKE follows an established procedure to negotiate the IPsec SA Security Association. This procedure has two phases, the first of which establishes a preliminary tunnel (IKE SA), and the second establishes the IPsec SA. When you understand this process, you will find it much easier to configure and troubleshoot your Threat Management Services (TMS) zl Module to make VPN connections.

IKE Phase 1: IKE SA

During phase 1, IKE must fulfill three tasks:

  • Negotiate security parameters for the IKE SA

  • Generate the keys that are used to secure data that is sent over the IKE SA

  • Authenticate the end points of the tunnel (the two VPN devices)

Typically, IKE phase 1 involves three exchanges between devices, making six total messages.

1. Security Parameters

The device that initiates the VPN connection sends a message to the remote device, proposing one or more security policies. Each policy specifies an authentication method, an authentication algorithm, and an encryption algorithm.

The remote device searches its IKE policies for one that matches one of the proposed policies. When it finds a match, it returns these security parameters to the original device. If the remote device cannot find a match, the VPN connection fails. For this reason, it is very important that you match the IKE settings at both ends of the connection.

2. Key Generation

An encryption algorithm is a mathematical method for transforming data with a key. The key is what actually defines and secures the tunnel, and it must be unique. When you use IKE, however, you need only to configure the algorithms that IKE proposes in the first exchange. IKE generates the actual keys for you, using the DH Diffie-Hellman key-agreement protocol. The DH exchange takes place in the second set of exchanges of IKE phase 1.

This shared value that is created in the DH key agreement is the authentication or encryption key that is used to secure data in the final IKE phase 1 exchange and in all IKE phase 2 exchanges. In this way, IPsec provides an additional layer of security; devices transmit their authentication information in secured packets, and secured packets negotiate the IPsec SA.

3. Authentication

In the third IKE phase 1 exchange, the devices confirm each other’s identities, according to the method agreed upon in the first exchange. The method can be:

  • preshared key — the devices are preconfigured with a shared secret

  • certificate — the devices use the public and private keys from a CA Certificate Authority

 

IKE Phase 2: IPsec SA

The goal of IKE phase 2 is to negotiate the IPsec SA. For this reason, even though IKE carries out both phases, phase 1 is associated with IKE policies and phase 2 with IPsec policies. Like an IKE SA, an IPsec SA defines unique authentication and encryption keys, as well as other security parameters for the VPN connection. Keys generated during IKE phase 2 will secure all of the data that is exchanged during the lifetime of the VPN tunnel.

When negotiating the IPsec SA, IKE follows much the same process that it did in IKE phase 1.

1. Security Proposal

The initiating device sends IP packets (now secured by the IKE SA) that propose one or more security policies. Each policy includes an encapsulation mode, an authentication algorithm and (if using ESP Encapsulating Security Protocol ) an encryption algorithm. The responding device searches its IPsec policies for a match. When it finds a match, it returns the policy to the initiating device.

2. Key Generation

IKE then manages the generation and exchange of any authentication and encryption keys. It also associates an SPI Security Parameters Index with the IPsec SA. Peers can now transmit data securely over the VPN tunnel.