IPSec Key Management

Before IPSec sends authenticated or encrypted IP data, both the sender and receiver must agree on the encryption algorithm and key or keys to use. IPSec/9000 uses the Internet Key Exchange (IKE) protocol to automatically establish and negotiate keys

IKE Automatic Keying

IPSec/9000 uses the Internet Key Exchange (IKE) protocol to negotiate the protocols, encryption algorithms and encryption keys used. The IKE protocol also provides primary authentication - verifying the identity of the remote system before negotiating the encryption algorithm and keys.

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

The IKE protocol is a hybrid of three other protocols: ISAKMP (Internet Security Association and Key Management Protocol), Oakley and 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 and IKE Phases

A secure communication channel and its parameters, such as encryption method, keys and lifetime are sometimes referred to as a Security Association (SA). There are two Security Association 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)
- Negotiate and establish an ISAKMP Security Association (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)
- Using the ISAKMP SA's secure communication channel, negotiate one or more Security Associations for IPSec AH or ESP encryption.

Figure 4-9 SA Establishment

Re-using Negotiations

For efficiency, you can specify that a single ISAKMP Phase One negotiation can be used to negotiate multiple ISAKMP Phase Two negotiations.

Conversely, you can specify that the ISAKMP phase one negotiations cannot be re-used by limiting the maximum number of ISAKMP phase two negotiations to one (The ISAKMP SAs cannot be re-used). This can provide Perfect Forward Secrecy (PFS) of the keys and the identities of both the ISAKMP negotating peers.

Generating Shared Keys: Diffie-Hellman

Security Associations (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. (Refer to Appendix A for more information on Diffie-Hellman key generation.)

Figure 4-10 Diffie-Hellman Key Exchange

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 should be 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. And, 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. IPSec/9000 IKE can use two primary authentication methods:

Digital Signatures
Pre-shared keys

Digital signature and public-key encryption are both based on asymmetric key encryption and require a mechanism for distributing public keys. This is usually done using security certificates and a Public Key Infrastructure (PKI).

IKE Digital Signature Authentication

A digital signature is similar to a symmetric-key hash value. The sender uses its private key to encrypt a one-way hash output of the data (or its private key and the data are used as input for a keyed-hash function). One difference between a digital signature and a symmetric-key hash value is that only the holder of the private key can generate the digital signature, while either holder of a symmetric key can generate a symmetric-key hash value. Since only the private key holder can generate the digital signature, a digital signature also provides non-repudiation which makes it difficult for the sender to deny sending the message.

For IKE Digital Signature Authentication, the initiator and responder first obtain the other entity's public key, using one of the methods defined below. Once the initiator and responder have the other entity's public key, they exchange messages with digital signatures. They each verify the other entity's digital signatures using the other entity's public key.

Public Key Distribution

In asymmetric-key cryptosystems, a single entity holds the private key while the public key is distributed to multiple entities. The owner of the private key must keep the private key secret, while the public key can be freely distributed over a non-secure communication channel.

However, there must be some assurance that a particular public key is the actual public key of the entity with which you want to communicate. This is usually done by distributing public keys in the form of security certificates.

Security Certificates

A public key certificate associates (or binds) a public key with a particular person, device, or other entity. The public-key certificate is issued by an entity, in whom users have put their trust, called a certificate authority (CA) that guarantees or confirms the identity of the holder (person, device, or other entity) of the corresponding private key. The CA digitally signs the certificate with the CA's private key, so the certificate can be verified using the CA's public key.

The format for public-key certificates is defined by the International Organization for Standardization (ISO) X.509 standard, Version 3.

Certificates are issued with a specific lifetime, defined by a start date/time and an expiration date/time. However, situations can arise, such as a compromised key value, that necessitate the revocation of the certificate. In this case, the certificate authority can revoke the certificate. This is accomplished by including the certificate's serial number on a Certificate Revocation List (CRL) updated and published on a regular basis by the CA and made available to certificate users.

IKE Public Key Distribution

IKE primary authentication with digital signatures and public/private key encryption both require that the IKE initiator and responder obtain the other entity's public key, typically using security certificates. This may be done as part of the IKE negotiation - the two entities may exchange certificates at the beginning of the IKE negotiation. Alternatively, this may be done independent of the IKE negotiation and each entity may get the other entity's certificate from a CA or certificate directory service. The method used varies according to the CA used and the services provided by the CA.

IKE Pre-shared Key Authentication

With pre-shared key authentication, the two entities must manually exchange and configure a shared, symmetric key. Note that the pre-shared key is used only for the primary authentication. The two negotiating entities then generate dynamic shared keys for the IKE SAs and IPSec SAs.

Pre-shared keys do not require a Certificate Authority or Public Key Infrastructure.