Dynamic key management - IKE and IPSec negotiations

The primary role of the IKE daemon in an IP security environment is the automatic management of cryptographic keys. Dynamic key management, as provided by the IKE daemon, removes much of the administrative burden that is associated with the creation, distribution, and maintenance of cryptographic keys. IKE provides the following services:

Host authentication (ensuring that both hosts are certain of the other's identity)
The negotiation of a Security Association as follows:
- Agreeing on the type of traffic to be protected
- Agreeing on the authentication and encryption algorithms to be used
- Generating cryptographic keys
Nondisruptive periodic refresh of keys
The deletion of Security Associations whose lifetimes have expired

There are two versions of the IKE protocol: IKEv1 and IKEv2. The architectural differences between IKEv1 and IKEv2 are as follows:

IKEv2 requires fewer network flows for Security Association establishment.
IKEv2 provides a mechanism for re-keying an IKE Security Association without reauthentication, which reduces the CPU cost.
IKEv2 allows each peer to manage its own values for lifetime and lifesize, whereas in IKEv1 Security Association lifetimes and lifesizes are negotiable attributes. This reduces coordination of configuration parameters between the peer nodes and avoids potential race conditions when the SAs expire.
IKEv2 supports the hash and URL certificate encoding types, but IKEv1 does not.

The following difference between IKEv1 and IKEv2 is specific to the z/OS® implementation:

To use any authentication method for IKEv2 based on a digital signature, the certificate service must be provided by an NSS server. You cannot use the IKED native certificate service.

IKE operates at the application layer. IKE negotiations are communicated between two IKE peers by a series of UDP messages. Ports 500 and 4500 are used by the IKE daemon. For both IKEv1 and IKEv2, Security Association negotiation proceeds in phases. In each phase, IKE negotiates a Security Association with a remote host. During the initial phase, IKE negotiates a phase 1 Security Association, which establishes a secure channel over which the IKE peers communicate. The phase 2 Security Association is negotiated to provide data authentication and encryption for subsequent IP traffic. The distinction between a phase 1 Security Association and a phase 2 Security Association is what the Security Associations protect:

Phase 1 Security Associations are used to protect IKE messages that are exchanged between two IKE peers, or security endpoints.
Phase 2 Security Associations are used to protect IP traffic, as specified by the security policy for a specific type of traffic, between two data endpoints.

Every Security Association that the IKE daemon negotiates contains information about the type of traffic it is to protect, the IP addresses of the two endpoints, the type of encryption or authentication that is provided, the keys that are used to protect data, how often the keys are refreshed, and an identifier called a Security Parameter Index (SPI) that is used to uniquely identify the Security Association.

An IPSec configuration contains separate policies governing each phase. Although many of the same attributes apply for phase 1 and phase 2 negotiations and keys, there are two major differences:

The phase 1 Security Association can specify only a single IP address for the security endpoints, while the phase 2 Security Association can specify a contiguous range or subnet as the data endpoint.
The phase 1 Security Association must specify an encryption method, while encryption is optional for the phase 2 Security Association. An authentication method must be specified for both the phase 1 and phase 2 Security Association.

The exact specifications for each phase 1 Security Association and each phase 2 Security Association are configured in the IP security configuration file. The specific IP security policy statements that apply to the phase 1 and phase 2 specifications are the KeyExchangeOffer statement (phase 1) and the IpDataOffer statement (phase 2). For more details about the KeyExchangeOffer statement and the IpDataOffer statement, see z/OS Communications Server: IP Configuration Reference.

Because the IKE protocols deal with initializing keys, they must be capable of running over links where no security is assumed to exist. IKE addresses the problem of secure key distribution by automatically deriving the keying material using a Diffie-Hellman exchange during the IKE phase 1 negotiation. This automatic creation and distribution of the key during phase 1 eliminates the need to manually distribute the session key between remote sites. Besides the obvious administrative advantage of IKE, the manual method of key distribution is prone to key compromise.

In addition, IKE non-disruptively refreshes the session keys based on the security policy of the installation. IKE specifies that this can be based on time (lifetime) and bytes transmitted (life size). IKE provides a property called perfect forward secrecy (PFS), and if PFS is used, each phase 2 key is derived independently through a separate Diffie-Hellman exchange. With PFS, if a single key is compromised, the integrity of subsequently generated keys is not affected.