If you’re using IPSec, chances are you’re running Internet Key Exchange (IKE) to allow for the sending and receiving devices to agree on the various IPSec parameters to use, and to exchange and manage the keys used in authentication and encryption. You don’t have to use IKE but it’s unlikely your IPSec deployment will scale without it. What does it do, why do you need it — and how do you configure it?

IKE Overview
There’s a lot written about IKE and most of it is confusing. You’ll probably have to plough through several books until you start to grasp what they’re trying to say. So here’s a somewhat simplistic, but accurate, description of what IKE actually does for you.

The main IPSec protocol, ISAKMP (RFC 2408), specifies the format of the IPSec management connection and the mechanics for the key exchange protocol and security parameter negotiation process. However, it does not actually detail how the keys should be shared or managed. This is why IKE is needed.

There are various steps to the IKE process:

1. The two peers who wish to communicate need to authenticate each other to make sure they are talking to who they think they are.

2. They then set up a temporary secure connection, to allow them to negotiate secure connection protocols and key information to let them build a secure IPSec management connection. Steps 1 and 2 here are commonly known as IKE Phase 1.

3. This management connection is then used to allow them to again negotiate a set of parameters to create the actual user IPSec connection and pass data. This is IKE Phase 2.

In a bit more detail:

IKE Phase 1:
The two peers authenticate each other to prove that they are who they say they are. The options here (not all of which are supported by all systems) are either pre-shared keys, IPSec nonces or RSA digital signatures.

Pre-shared keys is the simplest method. Any two peers that need to communicate must have the same key manually configured on them. It’s pretty obvious that this won’t scale and will very shortly become an administrative nightmare in a large IPSec environment. However, it is an option for smaller networks where you know who will be talking to who, such as for site-to-site VPNs.

Nonces are basically long numbers that are used with private/public key combinations and also require a lot of manual configuration. They are a bit more secure than pre-shared keys, but les scaleable, so not widely used.

RSA signatures use the concept of Certificate Authorities (see the box below) in conjunction with a private key to allow peers to authenticate each other. This is more of a centralised management system. It scales much better than the other two methods and is typically used for very large deployments, or for remote-access IPSec VPNs.

Once authenticated, the peers negotiate some security policies, one of which relates to a Diffie-Hellman parameter. The Diffie-Hellman algorithm is used to set up a temporary secure connection between the peers to let them work out the ‘real’ security parameters for the IPSec connection.

By using Diffie-Hellman, it is possible for each peer to create the same secret key knowing only their own private key and the other peer’s public key. This secret key, which therefore can’t be calculated by a third party (since it doesn’t know the private keys) is then used as the key to build a secure management connection. Also during Phase 1, negotiation of other security parameters takes place to determine, for instance, whether the management connection will use DES or 3DES for encryption, and how long the management connection can exist — see the next section for more detail.

IKE Phase 2
Once the management connection has been created, the two peers can communicate securely to negotiate how to create their IPSec user connection (or Security Association) so that they can actually exchange data, which is, it has to be remembered, the whole point of the exercise.

They have to agree on a security policy, which will include several parameters. You will have to configure the capabilities of your end devices and some of the options are given below. The peers have to be able to agree (they will negotiate to the best common denominator that they can). Typically you will create one or more policies, each of which has one set of parameters. Depending on how you prioritise these policies within your device, they will in effect scroll through them until they get to two that match, otherwise they will not create an IPSec connection.

The parameters we are talking about are the actual security protocol, the ESP encryption algorithm, hashing function, lifetime of the connection and, for the creation of the management connection, the type of Diffie-Hellman algorithm to use.

Configuring IKE
The actual configuration steps will obviously depend on the device you are dealing with, be it Nokia firewall, Cisco VPN concentrator or whatever. But what are the options you have to choose between?

Security protocol: You have to decide if you want to use ESP, or AH, on your IPSec tunnel, or both.

Encryption algorithm: The options here are 56-bit DES and 168-bit 3DES. If your company policy dictates that only 3DES is permissible, then all your policies must specify 3DES. If you prefer 3DES, but don’t mind DES, then create two policies, with 3DES preferred, but DES allowable.

Hash algorithm: MD5 and SHA-1. MD5 has a smaller digest and is a bit faster than SHA-1 but not quite as secure, although MD5 is probably more common.

Authentication method: pre-shared keys, nonces or signatures using CAs. As we’ve already discussed, pre-shared keys are simpler if you have a small IPSec environment. However, for scalability using a CA is a better option.

Diffie-Hellman algorithm: for setting up initial secure links: 768-bit DH (group 1) or 1024-bit DH (group 2). As you’d expect, the more bits, the more secure and conversely the greater CPU usage.

Lifetime before renegotiation: anything from a few seconds to a day or more. A few hours is a common default.

You will also have platform-dependant configurations: specifying which traffic is to be protected via IPSec, for instance. It’s quite possible for some traffic that passes through your network device to go over the IPSec link, whilst other data travels in the clear.

Certificate Authorities
Certificate Authorities (CAs) provide a centralised key management service for all participating IPSec peers. For two potential peers to authenticate each other, they use an encryption/decryption combination of their own private key and the other’s public key. This means they need to know the other peer’s public key and they need to be sure that the peer at the far end is actually the peer they think it is.

Now while it is possible to configure an IPSec peer with the public keys of every other device they might want to communicate with, this obviously doesn’t scale - unless it is a pretty closed environment. But you can’t just let the far end tell you its public key — anyone could pretend to be that device, send its own key, and hijack the connection.

So authorised CAs, such as VeriSign, Microsoft and Entrust, have come into existence to provide this authentication and provision of keys as a global service, validating all IPSec peers so that you don’t have to. Now, if you need to talk to a remote peer, you exchange certificates, secure in the knowledge that the CA has verified the remote peer for you. You do need to know the public key of the CA, but this just needs setup during initial configuration of your IPSec endpoint. If it is for remote access IPSec VPNs, most web browsers are pre-configured with several CA keys. This allows each peer to enrol with the CA on installation and be issued with a certificate — there is nothing that needs to be done to all the other peers that may need to talk to it, thus allowing this sort of deployment to scale more or less indefinitely.