https://www.techtarget.com/searchsecurity/definition/Internet-Key-Exchange
Internet Key Exchange (IKE) is a standard protocol used to set up a secure and authenticated communication channel between two parties via a virtual private network (VPN). The protocol ensures security for VPN negotiation, remote host and network access.
A critical role of IKE is negotiating security associations (SAs) for Internet Protocol Security (IPsec). SAs are the security policies for communication between two or more entities. They consist of a set of algorithms and mutually agreed-upon keys that both parties use when attempting to establish a VPN tunnel or connection. Each system maintains a list of SAs for the other systems it communicates with.
There are two versions of IKE standards:
Most often, IKE uses X.509 public key infrastructure certificates for authentication and a Diffie-Hellman key exchange protocol to establish a shared secret session.
A hybrid protocol, IKE also implements two earlier security protocols, Oakley and SKEME, within an Internet Security Association and Key Management Protocol (ISAKMP) TCP/IP-based framework.
The SKEME protocol is an alternate version for the exchange key. ISAKMP RFC 2408 is used for negotiations, establishing SAs and securing connections between IPsec peers, specifying the framework for key exchange and authentication. Oakley RFC 2412 is used for key agreements or exchanges and defines the mechanism used over the IKE session for key exchange. Diffie-Hellman is the default algorithm used for exchange.
IKE is used by many technologies that are protected by IPsec. Some examples are VPN, Secure File Transfer Protocol, Secure Shell and Point-to-Point Protocol connections.
IKE is a part of IPsec, a suite of protocols and algorithms used to secure sensitive data transmitted across a network. The Internet Engineering Task Force developed IPsec to provide security through authentication and encryption of IP network packets and secure VPNs.
In IPsec, IKE defines an automatic means of negotiation and authentication for IPsec SAs during the initial connection. This is required for the encryption and decryption process because it negotiates the security that is used for main communication. IKE offers several benefits for IPsec configuration, including automatic negotiation and authentication, antireplay services, certification authority support and the ability to change encryption keys during an IPsec session.
The IKE protocol uses User Datagram Protocol (UDP) packets during transmission, generally needing four to six packets with two to three messages. An IPsec stack intercepts relevant IP packets, encrypting and decrypting them as needed.
To illustrate the use of IKE, imagine two spies who have not met before need to start exchanging secret messages. IKE is when they first meet, using an agreed-upon secret to identify each other, such as "I'll be at the park bench wearing a red hat; you ask about the snow." Then, they can agree on how to encrypt and drop off messages. From then on, they never need to meet again in person and only need to follow the agreed way to exchange messages.
The original version of IKE sets up secure communications channels in two phases: phase 1 and phase 2.
In phase 1, an authenticated connection between the initiator and responder is established using a preshared key or a digital certificate. The goal is to secure the communications that occur in phase 2.
The Diffie-Hellman key exchange algorithm creates a secure authentication communication channel that is used for further communication. This digital encryption method uses numbers raised to specific powers to produce decryption keys. The negotiation should result in session keys and one bidirectional SA.
Phase 1 operates under one of two modes: main mode or aggressive mode. The main mode consists of both parties sending three two-way exchanges equaling six messages in total. The first two messages confirm encryption and authentication algorithms. The second set of two messages starts with a Diffie-Hellman key exchange, where both parties provide a random number. The third set of messages verifies the identities of each party.
Aggressive mode accomplishes the same task as the main mode but does so in just two exchanges of three messages. Whereas the main mode protects both parties' identities by encrypting them, the aggressive mode does not.
Phase 2 of IKE negotiates an SA to secure the data that travels through IPsec, using the secure channel created in phase 1. The result is a minimum of two SAs that are unidirectional. Both parties also exchange proposals to determine which security parameter to use in the SA.
Phase 2 operates in only one mode: quick mode. Quick mode provides three resources: proxy IDs, perfect forward secrecy (PFS) and replay protection. The proxy IDs of each participant are shared with each other. PFS delivers keys independent from preceding keys. Replay protection is a security method to protect against replay attacks.
The main and aggressive modes found in phase 1 only apply to IKEv1 and not to IKEv2.
IKEv1 came out in 1998 and was followed by the release of IKEv2 in 2005. IKEv2, updated in 2014, negotiates and authenticates IPsec SAs and provides secure VPN communication channels between devices. This version does not include phases 1 or 2 like its predecessor, but message exchanges still negotiate an IPsec tunnel.
The first of the four messages is a negotiation to decide a security attribute. The second is where each party authenticates its identity. The third includes the creation of additional SAs. The fourth message removes SA relationships, detects IPsec tunnel liveliness and reports errors.
Improvements in IKEv2 over IKEv1 are as follows:
Mobility and Multihoming Protocol is an extension of IKE in the v2 specification to support mobile devices, such as smartphones. It helps to quickly reestablish the connection when the device moves between networks.
An IKEv2 connection uses less steps than IKEv1:
IKE includes the following benefits:
IKE may pose the following challenges:
There is also a chance that a firewall or a network administrator could block IKEv2's UDP port, causing a VPN to stop working.
Internet service providers use Layer Two Tunneling Protocol (L2TP) combined with IPsec to enable a VPN to pass all traffic. By using IKE, this networking protocol negotiates and authenticates secure VPN connections. Using L2TP is a bit slower than other VPNs but enables it to pass the original packets unaltered.
IKE has been largely replaced by IKEv2. For automatic connections using IPsec, IKEv2 is still the best choice. If a system is being designed from scratch, other methods may be considered.
A manual IPsec tunnel can be configured that does not use IKE. For this to work, all the encryption types need to be preconfigured for both ends of the connection. By cutting out IKE, it can decrease the initial connection time. This may be useful for fixed tunnels, such as for a site-to-site VPN.
Other modern VPN technologies may offer better VPN performance than IPsec with IKE. OpenVPN is a popular and well-understood VPN technology. WireGuard is a recent VPN technology that offers superior performance but is not widely supported yet.
Explore the benefits of Always On VPN and the differences between VPN vs. zero trust vs. software-defined perimeter.
04 Feb 2025