Understanding Internet Key Exchange (IKE) Protocol
IKE Operation
Main Mode Vs Aggressive Mode
IKE Phase-1
IKE Phase-2
Conclusion
IKE Operation
IPsec uses the Internet Key Exchange (IKE) protocol to negotiate and establish secured site-to-site or remoteaccess VPN tunnels. IKE is a framework provided by the Internet Security Association and Key Management Protocol (ISAKMP).
When ISAKMP is negotiating tunnel parameters, it does so in two phases. The frst one is called phase 1. This phase is used for identifcation and authentication, and it sets up a tunnel in order to securely negotiate the phase 2 parameters. And in phase 2, the
actual tunnel parameters themselves are negotiated. So remember, phase 1 is about setting up a secure tunnel in order to negotiate the tunnel parameters. And in phase 2, the actual negotiation starts. This then creates a physical security association and then sets up the IPSec tunnel in order to make sure that data transfer is secure.
Main Vs Aggressive Modes
You can establish a Phase 1 security association (SA) in main mode or aggressive mode. In main mode, the IPsec peers complete a six-packet exchange in three round trips to negotiate the ISAKMP SA, whereas aggressive mode completes the SA negotiation in three packet exchanges. Main mode provides identity protection if pre-shared keys are used. Aggressive mode offers identity protection only if digital certificates are employed.
IKE Phese-1
The Phase-1 is used for identifcation and authentication, and it sets up a tunnel in order to securely negotiate the phase 2 parameters. IKE uses UDP port 500 for communication. UDP port 500 is employed to send all the packets described in the following steps.
The following figure illustrates the six-packet exchange in main mode negotiation:
1. R1 (the initiator) has two ISAKMP proposals configured. In the first packet, R1 sends its configured proposals to R2.
2. R2 evaluates the received proposal. Because it has a proposal that matches the offer of the initiator, R2 sends the accepted proposal back to R1 in the second packet.
3. Diffie-Hellman exchange and calculation is started. Diffie-Hellman is a key agreement protocol that enables two users or devices to authenticate each other’s pre-shared keys without actually sending the keys over the unsecured medium. R1 sends the Key Exchange (KE) payload and a randomly generated value called a nonce.
4. R2 receives the information and reverses the equation, using the proposed Diffie-Hellman group/exchange to generate the SKEYID. The SKEYID is a string derived from secret material that is known only to the active participants in the exchange.
5. R1 sends its identity information. The fifth packet is encrypted with the keying material derived from the SKEYID.
6. R2 validates the identity of R1, and R2 sends its own identity information to R1. This packet is also encrypted.
IKEv1 Phase 2
- Phase 2 is used to negotiate the IPsec SAs. This phase is also known as quick mode. The ISAKMP SA protects the IPsec SAs because all payloads are encrypted except the ISAKMP header.
- A single IPsec SA negotiation always creates two security associations—one inbound and one outbound. Each SA is assigned two unique security parameter index (SPI) values—one by the initiator and the other by the responder.
IPsec can use quick mode to negotiate these multiple Phase 2 SAs, using the single pre-established ISAKMP (IKEv1 Phase 1) SA. In addition to generating the keying material, quick mode also negotiates identity information. The Phase 2 identity information specifies which network, protocol, and/or port number to encrypt.
The following Figure illustrates the Phase 2 negotiation between the two routers:
- The Initiator sends the identity information, IPsec SA proposal, nonce payload, and (optional) Key Exchange
(KE) payload if Perfect Forward Secrecy (PFS) is used. - Responder evaluates the received proposal against its configured proposal and sends the accepted proposal
back to Initiator, along with its identity information, nonce payload, and the optional KE payload. - Finally, the Initiator evaluates the Responder proposal and sends a confirmation that the IPsec SAs have been
successfully negotiated. This starts the data encryption process.
Conclusion
IKEv1 was not designed to be extensible, making it hard to adapt to new cryptographic standards and authentication mechanisms. Customization or upgrades required vendor-specific implementations, leading to interoperability issues. IKEv1 initially did not support NAT traversal (NAT-T), which caused issues when peers were behind NAT devices. The IKEv1 protocol is vulnerable to Denial of Service (DoS) attacks, especially during Phase 1 when resource-intensive operations (like Diffie-Hellman) are performed before authentication. All its(IKEv1) several notable drawbacks led to the development of IKEv2 which we are going to discuss in another article.
References: OCG and Networklessions.com
...................................................................................Thank you very much..! ....................................................................................
