Internet Key Exchange (IKE or IKEv2) is the protocol used to set up a security association (SA) in the IPsec protocol suite. 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.

History

IKE was originally defined in November 1998 by the Internet Engineering Task Force (IETF) in a series of publications (Request for Comments) known as RFC 2407, RFC 2408, and RFC 2409.

• RFC 2407 defined The Internet IP Security Domain of Interpretation for ISAKMP. ¹
• RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP) ²
• RFC 2409 defined The Internet Key Exchange (IKE) ³

IKE was updated to version two (IKEv2) in December 2005 by RFC 4306. ⁴ IKEv2 has been further expanded by RFCs 4301 (Security Architecture for the Internet Protocol) through RFC 4310 (DNS Security Extensions Mapping for the EPP). More RFCs are being added all the time as the need arises to further develop the features of the protocol.

The parent organization of the IETF, The Internet Society (ISOC), has maintained the copyrights of these standards as being freely available to the Internet community.

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.

Problems with IKE

Originally, IKE had numerous configuration options but lacked a general facility for automatic negotiation of a well-known default case that is universally implemented. Consequently, both sides of an IKE had to exactly agree on the type of security association they wanted to create — option by option — or a connection could not be established. Further complications arose from the fact that in many implementations the debug output was difficult to interpret, if there was any debug routine at all.

The IKE specifications were 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.

Improvements with IKEv2

The need and intent of an overhaul of the IKE protocol was described in Appendix A of RFC 4306. The following issues were addressed:

• Fewer RFCs: The specifications for IKE were covered in at least three RFCs, more if one takes into account NAT traversal and other extensions that are in common use. IKEv2 combines these in one RFC as well as making improvements to support for NAT traversal and firewall traversal in general.

All or part of this article may be confusing or unclear. Please help clarify the article. Suggestions may be on the talk page.

• Standard Mobility support: There is a standard extension for IKEv2 (named MOBIKE) used to support mobility and multihoming for it and ESP. for IPsec tunnels. By use of this extension IKEv2 and IPsec can be used by mobile and multihomed users.

• SCTP support: IKEv2 allows for the SCTP protocol as used in Internet Telephony VoIP.

• Simple message exchange: IKEv2 has one four-message initial exchange mechanism where IKE provided eight distinctly different initial exchange mechanisms, each one of which had slight advantages and disadvantages.

• Fewer cryptographic mechanisms: IKEv2 uses cryptographic mechanisms to protect its packets that are very similar to what IPsec Encapsulating Security Payload (ESP) uses to protect the IPsec packets. This lead to simpler implementations and certifications for Common Criteria and FIPS 140-2, which require each cryptographic implementation to be separately validated.

• Reliability and State management: IKEv2 uses sequence numbers and acknowledgments to provide reliability and mandates some error processing logistics and shared state management. IKE could end up in a dead state due to the lack of such reliability measures, where both parties were expecting the other to initiate an action - which never eventuated. Work arounds (such as Dead-Peer-Detection) were developed but not standardized. This meant that different implementations of work-arounds were not always compatible.

• Denial of Service (DOS) attack resilience: IKEv2 does not perform much processing until it determines if the requester actually exists. This addressed some of the DOS problems suffered by IKE which would perform a lot of expensive cryptographic processing from spoofed locations.

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.

As of May-2006 there are a number of implementations of IKEv2 and some of the companies dealing in IPsec certification and interoperability testing are starting to hold work-shops for testing as well as updated certification requirements to deal with IKEv2 testing. ICSA Labs held its latest IKEv2 Interoperability Workshop in Orlando, FL in March 2007 with 13 vendors from around the world.

The following Open Source implementations of IKEv2 are currently available:

• OpenIKEv2,
• strongSwan 4.1 (one of the successors of the FreeS/WAN project),
• IKEv2,
• Racoon2 from the KAME project.

See also

• Key-agreement protocol

References

External links

• RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP, Internet Engineering Task Force (IETF)
• RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP), Internet Engineering Task Force (IETF)
• RFC 2409 The Internet Key Exchange (IKE), Internet Engineering Task Force (IETF)
• RFC 4306: Internet Key Exchange (IKEv2) Protocol), Internet Engineering Task Force (IETF) (obsoletes RFC 2407, 2408, 2409)
• An architecture for the Internet Key Exchange Protocol
• Overview of IKE (from Cisco)