The Internet Key Exchange (IKE) protocol is a hybrid containing three primary, existing protocols that are combined to provide specific key management for IPSec. The three protocols are:
1. ISAKMP 2. Oakley
3. SKEME (Secure Key Exchange Mechanism)
Different portions of each protocol work in conjunction to securely provide keying information specifically for the IETF IPSec DOI. The terms IKE and ISAKMP are used interchangeably by various vendors, and many use ISAKMP to describe the keying function. While this is correct, ISAKMP addresses the procedures and not the technical operations as they pertain to IPSec. IKE is the default standard that best represents the IPSec implementation of key management.
IKE is considerably complicated and several variations are available in the establish- ment of trust and providing keying material. Oakley and ISAKMP protocols, which are included in IKE, each define separate methods to establish an authenticated key exchange between systems. Oakley defines “modes” of operation to build a secure relationship path, and ISAKMP defines “phases” to accomplish much the same process in a hierarchical format. The relationship between these two is represented by IKE with different exchanges as modes, which operate in one of two phases.
ISAKMP
ISAKMP defines the procedures for authenticating a communicating peer and key generation techniques. All of these are necessary to establish and maintain an SA in an Internet environment. ISAKMP defines payloads for exchanging key and authentication data. These formats provide a consistent framework, which is independent of the encryption algorithm, authentication mechanism being implemented, and security pro- tocol, such as IPSec.
The majority of IKE is ISAKMP, and it is necessary to fully understand the phases of ISAKMP. Also, IKE’s packet structure and payload framework are exclusively based on ISAKMP. ISAKMP provides negotiation in the first phase to identify one another and agree on the further protection of information. The second phase can be protected by the first and focuses on creating SAs for the underlying protocol suite.
There are several advantages to a phased approach in key management. The first phase session can be distributed between several second-phase operations to provide the construction of a new ISA without renegotiation. This allows for the creation of subsequent ISAs to be preempted via secured communications in the second phase.
Another benefit is that the first-phase process can provide security services for the second phase in the form of encryption keying material. However, no data can be used from the first phase if it does not meet the security protection requirements of the second phase.
In addition, the first phase is providing peer identification; therefore, the second phase provides the creation of the security protocol SAs without concern for authen- tication of the peer. If the first phase were not available, each new IPSec SA would need to authenticate the peer.
Oakley
Oakley provides examples and processes of an exchange protocol for supporting the underlying communication for ISAKMP. Developed by Hilarie Orman, a cryptographer from the University of Arizona, the protocol defines several aspects of authentication and key creation. It details the process of modes used to enhance the security between peers, based on the negotiation of those properties.
Within the Oakley protocol definition, there are also Diffie-Hellman groups. Diffie- Hellman groups define the strength supplied to the Diffie-Hellman calculation for the later creation of keys by the peers. Richard Schroeppel, of the University of Arizona, generated the groups and provided the calculations for display in the RFC. There are currently two primary forms of key groups. Three of the five available groups are generated from MODP calculations and the leveraging of very large prime numbers. The other two groups are based on elliptic curves. Each of these groups are EC2N processes with varying characteristics.
Groups 1 and 2 are MODP based and provide primes at 96 bytes and 128 bytes, respectively. Groups 3 and 4 are EC2N based and provide 155-byte and 185-byte Diffie- Hellman values. The last group, group 5, is based on MODP and provides a prime of 192 bytes (1536 bits). Groups 1 and 2 are the most common, for two reasons. The EC2N process is typically not supported on currently available VPN systems and the last group is a very large number, and performance is crucial. For example, if using group 5, the prime to use in several calculations looks like (a lot):
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
IKE leverages the process of modes and groups from Oakley. IKE uses all the groups defined within Oakley, but only some of the modes that are available.
SKEME
In 1996, Hugo Krawczyk proposed a key management based on the use of Diffie-Hellman and public key cryptography. This allows the shared information to be authenticated. The process can be used to create random values that are shared using the public key of the peer. These values, once authenticated, can be used to create the keys. Therefore, the combination of SKEME sharing techniques and Diffie-Hellman provides for PFS.
IKE uses portions of SKEME for authentication with public keys and uses the sharing mechanisms for PFS.