Internet Key Exchange (IKE)

Before IPSec sends authenticated or encrypted IP data, both the sender and receiver must agree on the protocols, encryption algorithms and keys to use. HP-UX IPSec uses the Internet Key Exchange (IKE) protocol to negotiate the encryption and authentication methods, and generate shared encryption keys. The IKE protocol also provides primary authentication - verifying the identity of the remote system before negotiating the encryption algorithm and keys.

The IKE protocol is a hybrid of three other protocols: Internet Security Association and Key Management Protocol (ISAKMP), Oakley, and Versatile Secure Key Exchange Mechanism for Internet protocol (SKEME). ISAKMP provides a framework for authentication and key exchange, but does not define them (neither authentication nor key exchange). The Oakley protocol describes a series of modes for key exchange and the SKEME protocol defines key exchange techniques.

Security Associations (SAs) and IKE Phases

A Security Association (SA) is a secure communication channel and its parameters, such as the encryption algorithm, keys and lifetime. There are two SA negotiation phases within ISAKMP, which are sometimes referred to by the Oakley modes used to establish the SAs. The general flow of the IKE protocol is as follows:

ISAKMP Phase One (Main Mode, MM)
- Negotiate and establish an ISAKMP SA, a secure communication channel for further IKE communication.
  The two systems generate a Diffie-Hellman shared value (described below) that is used as the base for a symmetric (shared) key, and further IKE communication is encrypted using this symmetric key.
- Verify the remote system’s identity (primary authentication)
ISAKMP Phase Two (Quick Mode, QM)
Using the secure communication channel provided by the ISAKMP/MM SA, negotiate one or more SAs for IPSec transforms (AH or ESP). A Phase Two negotiation typically negotiates two SAs for an IPSec transform: one for inbound and one for outbound traffic.

Figure 1-9 SA Establishment

Generating Shared Keys: Diffie-Hellman

SAs use a symmetric key to encrypt communication. This symmetric key is based on a shared value generated using the Diffie-Hellman algorithm.

With Diffie-Hellman key generation, each party generates two numbers, one public and one private. These values are based on a selected, well-known numeric base, or “Diffie-Hellman group.” The two parties exchange public values (this exchange may occur via an insecure channel). Each party then uses its private value and the other party’s public value to generate a new value. Because of the mathematical properties of the numbers, each party will generate the same value, which can then be used as a symmetric key.

Figure 1-10 Diffie-Hellman Key Generation

Diffie-Hellman is vulnerable to attacks where a third-party intercepts messages between the sender and receiver and assumes the identity of the other party. Because of this, Diffie-Hellman is used with some form of authentication to ensure that symmetric keys are established between correct parties.

In summary, if two entities use the same, well-known Diffie-Hellman group, they can publicly exchange values and generate the same shared value that they can use as a symmetric key, or use as a base for a symmetric key. Diffie-Hellman should be used with some form of authentication.

IKE Primary Authentication

IKE must authenticate the identities of the systems using the Diffie-Hellman algorithm. This process is known as primary authentication. HP-UX IPSec IKE can use two primary authentication methods:

Preshared keys
Digital Signatures

IKE Preshared Key Authentication

With preshared key authentication, you must manually configure the same, shared symmetric key on both systems, a preshared key. The preshared key is used only for the primary authentication. The two negotiating entities then generate dynamic shared keys for the IKE SAs and IPSec/QM SAs.

Preshared keys do not require a Certificate Authority or Public Key Infrastructure.

Digital Signatures

Digital signatures are based on security certificates, and are managed using a Public Key Infrastructure (PKI). HP-UX IPSec supports the following security certificates from the following products:

VeriSign Managed PKI (formerly VeriSign OnSite for VPNs)
Baltimore UniCERT 3.5

For more information on using certificate-based authentication for IKE, see Chapter 4 “Using Certificates with HP-UX IPSec ”.

Re-using Negotiations

For efficiency, you can specify that a single ISAKMP Phase One (ISAKMP/MM) SA can be used to negotiate multiple ISAKMP Phase Two (IPSec/QM) negotiations.

Conversely, you can specify that each Phase One SA can be used for only one ISAKMP Phase Two negotiation. The IKE daemon will create a new ISAKMP SA for each IPSec SA negotiation. This can provide a feature known as Perfect Forward Secrecy (PFS) with key and identity protection. With PFS, the compromise (exposure) of one key exposes only the data protected by that key.

IKE Automatic Re-keying

The IKE protocol also allows HP-UX IPSec to dynamically negotiate new IPSec keys rather than exposing the same key for long periods. You can configure key lifetimes based on time or number of bytes sent.

Internet Key Exchange (IKE)

Technical documentation

» Table of Contents

» Glossary

» Index