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 IKE V2
4 See also
5 External links

[edit] Overview

IKE is defined in RFC 2407, RFC 2408 and RFC 2409. IKEv2 is defined in RFC 4306. 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 which contains 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 - say an AES key and endpoint information (which IP endpoints and ports we are protecting) as well as what type of IPsec tunnel has been created - is then given to the IPsec stack. It 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. Some use virtual devices, others take a slice out of the firewall - it varies.

[edit] Interoperability matters

This article or section reads like a personal reflection or essay and may require cleanup.
Please improve this article by rewriting this article or section in an encyclopedic style. (documentation, talk)

IKE has a lot of configuration options. There is no general facility for automatic negotiation of a well known, reasonably safe default case that everybody implements. That is, both sides of an IKE must pretty much exactly agree on which kind of SA they want to create - option by option - or things will just not work. Usually the debug output is difficult for the un-initiated to interpret, if there is any at all.

The IKE specifications (there are a lot of RFCs involved) are open to a not insignificant degree of interpretation - bordering on design faults (Dead-Peer-Detection being a case in point). This gives rise to different IKE implementations not being able to create (agree upon) an SA at all for many combinations of options - however correctly configured they might appear at either end.

Confusion ensues as nobody can tell whether they are looking at an implementation, configuration or bad-debug-interpretation problem, or a combination thereof. This problem has given rise to commercial organizations that provide interoperability testing services for IPsec. Really, it is for IKE testing, because the rest of IPsec is straightforward by comparison. IPsec interoperability problems are almost certainly also a major if not the major reason why SSL-VPN's are becoming popular.

[edit] Implementations

There are several Open Source implementations of IPsec with associated IKE capabilities. On Linux, the Frees/wan, and now Openswan and strongSwan, implementations provide an IKE daemon called pluto which can configure (ie, establish SA's) to the KLIPS or NETKEY kernel based IPsec stacks. NETKEY is the Linux 2.6 kernel's native IPsec implementation. The BSDs 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.