Internet key exchange

From Wikipedia, the free encyclopedia

Internet key exchange (IKE) is the protocol used to set up a security association (SA) in the IPsec protocol suite.

1 Overview
- 1.1 Architecture
- 1.2 Interoperability matters
2 Implementations
3 IKEv2
4 See also
5 External links

[edit] Overview

IKE was originally defined in RFC 2407, RFC 2408 and RFC 2409 and is currently defined in RFC 4306 as IKEv2. IKE uses a Diffie-Hellman key exchange to set up a shared session secret, from which cryptographic keys are derived. Public key techniques or, alternatively, a pre-shared key, are used to mutually authenticate the communicating parties.

IKE builds upon the Oakley protocol.

[edit] Architecture

Most IPsec implementations consist of an IKE daemon that runs in user space and an IPsec stack in the kernel that processes the actual IP packets.

User-space daemons have easy access to mass storage containing configuration information, such as the IPsec endpoint addresses, keys and certificates, as required. Kernel modules, on the other hand, can process packets efficiently and with minimum overhead—which is important for performance reasons.

The IKE protocol uses UDP packets, usually on port 500, and generally requires 4-6 packets with 2-3 turn-around times to create an SA on both sides. The negotiated key material is then given to the IPsec stack. For instance, this could be an AES key, information identifying the IP endpoints and ports that are to be protected, as well as what type of IPsec tunnel has been created. The IPsec stack, in turn, intercepts the relevant IP packets if and where appropriate and performs encryption/decryption as required. Implementations vary on how the interception of the packets is done—for example, some use virtual devices, others take a slice out of the firewall, etc.

[edit] Interoperability matters

IKE has numerous configuration options, but lacks a general facility for automatic negotiation of a well-known, reasonably safe default case that is universally implemented. Consequently, both sides of an IKE must exactly agree on the type of security association they want to create — option by option — or a connection cannot be established. Further complications arise from the fact that in many implementations, the debug output is difficult for the uninitiated to interpret, if there is any at all.

The IKE specifications are open to a significant degree of interpretation, bordering on design faults (Dead-Peer-Detection being a case in point), giving rise to different IKE implementations not being able to create an agreed-upon security association at all for many combinations of options, however correctly configured they might appear at either end.

Commercial organizations now provide interoperability testing services for IPsec. The core value of such services pertains to IKE testing, because the rest of IPsec is straightforward by comparison. IPsec's interoperability problems are also considered a major reason why SSL-based VPNs are becoming popular.

[edit] Implementations

There are several Open Source implementations of IPsec with associated IKE capabilities. On Linux, Openswan and strongSwan implementations provide an IKE daemon called pluto, which can configure (i.e., establish SAs) to the KLIPS or NETKEY kernel-based IPsec stacks. NETKEY is the Linux 2.6 kernel's native IPsec implementation.

The Berkeley Software Distributions also have an IPsec implementation and IKE daemon, and most importantly a cryptographic framework (OpenBSD Cryptographic Framework - OCF), which makes supporting cryptographic accelerators much easier. OCF has recently been ported to Linux.

A significant number of network equipment vendors have created their own IKE daemons (and IPsec implementations), or license a stack from one another.