Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Internet Key Exchange

Introduction to IKE

Internet Key Exchange (IKE) is a secure key management protocol that is used to set up a secure, authenticated communications channel between two devices.

IKE does the following:

  • Negotiates and manages IKE and IPsec parameters

  • Authenticates secure key exchange

  • Provides mutual peer authentication by means of shared secrets (not passwords) and public keys

  • Provides identity protection (in main mode)

  • Employs Diffie-Hellman methods and is optional in IPsec (the shared keys can be entered manually at the endpoints).

IKE Versions

Two versions of the IKE standards are available:

  • IKE version 1 - IKE protocol defined in RFC 2409.

  • IKE version 2 - IKE version 2 (IKEv2) is the latest version of the IKE protocol defined in RFC 7296.

Internet Key Exchange version 2 (IKEv2) is the latest version of the Internet Key Exchange (IKE) protocol defined in RFC 7296. A VPN peer is configured as either IKEv1 or IKEv2. When a peer is configured as IKEv2, it cannot fall back to IKEv1 if its remote peer initiates IKEv1 negotiation.

The advantages of using IKEv2 over IKEv1 are as follows:

  • Replaces eight initial exchanges with a single four-message exchange.

  • Reduces the latency for the IPsec SA setup and increases connection establishment speed.

  • Increases robustness against DOS attacks.

  • Improves reliability through the use of sequence numbers, acknowledgments, and error correction.

  • Improves reliability, as all messages are requests or responses. The initiator is responsible for retransmitting if it does not receive a response.

Interaction Between IKE and IPSec

IPsec can establish a VPN in either of the following way:

  • Internet Key Exchange (IKE) protocol— IPsec supports automated generation and negotiation of keys and security associations using the IKE protocol. Using IKE to negotiate VPNs between two endpoints provides more security than the manual key exchange.

  • Manual key exchange—IPsec supports using and exchanging of keys manually (example: phone or email) on both sides to establish VPN.

IKEv1 Message Exchange

IKE negotiation includes two phases:

  • Phase 1—Negotiate exchange of proposals for how to authenticate and secure the channel.

  • Phase 2—Negotiate security associations (SAs) to secure the data that traverses through the IPsec tunnel.

Phase 1 of IKE Tunnel Negotiation

Phase 1 of an AutoKey Internet Key Exchange (IKE) tunnel negotiation consists of the exchange of proposals for how to authenticate and secure the channel. The participants exchange proposals for acceptable security services such as:

  • Encryption algorithms—Data Encryption Standard (DES), triple Data Encryption Standard (3DES), and Advanced Encryption Standard (AES). (See IPsec Overview.)

  • Authentication algorithms—Message Digest 5 (MD5 ) and Secure Hash Algorithm (SHA). (See IPsec Overview.)

  • Diffie-Hellman (DH) group. (See IPsec Overview.)

  • Preshared key or RSA/DSA certificates. (See IPsec Overview.)

A successful Phase 1 negotiation concludes when both ends of the tunnel agree to accept at least one set of the Phase 1 security parameters proposed and then process them. Juniper Networks devices support up to four proposals for Phase 1 negotiations, allowing you to define how restrictive a range of security parameters for key negotiation you will accept. Junos OS provides predefined standard, compatible, and basic Phase 1 proposal sets. You can also define custom Phase 1 proposals.

Phase 1 exchanges can take place in either main mode or aggressive mode. You can choose your mode during IKE policy configuration.

This topic includes the following sections:

Main Mode

In main mode, the initiator and recipient send three two-way exchanges (six messages total) to accomplish the following services:

  • First exchange (messages 1 and 2)—Proposes and accepts the encryption and authentication algorithms.

  • Second exchange (messages 3 and 4)—Executes a DH exchange, and the initiator and recipient each provide a pseudorandom number.

  • Third exchange (messages 5 and 6)—Sends and verifies the identities of the initiator and recipient.

The information transmitted in the third exchange of messages is protected by the encryption algorithm established in the first two exchanges. Thus, the participants’ identities are encrypted and therefore not transmitted “in the clear.”

Aggressive Mode

In aggressive mode, the initiator and recipient accomplish the same objectives as with main mode, but in only two exchanges, with a total of three messages:

  • First message—The initiator proposes the security association (SA), initiates a DH exchange, and sends a pseudorandom number and its IKE identity.

    When configuring aggressive mode with multiple proposals for Phase 1 negotiations, use the same DH group in all proposals because the DH group cannot be negotiated. Up to four proposals can be configured.

  • Second message—The recipient accepts the SA; authenticates the initiator; and sends a pseudorandom number, its IKE identity, and, if using certificates, the recipient's certificate.

  • Third message—The initiator authenticates the recipient, confirms the exchange, and, if using certificates, sends the initiator's certificate.

Because the participants’ identities are exchanged in the clear (in the first two messages), aggressive mode does not provide identity protection.

Main and aggressive modes applies only to IKEv1 protocol. IKEv2 protocol does not negotiate using main and aggressive modes.

See Also

Phase 2 of IKE Tunnel Negotiation

After the participants have established a secure and authenticated channel, they proceed through Phase 2, in which they negotiate security associations (SAs) to secure the data to be transmitted through the IPsec tunnel.

Similar to the process for Phase 1, the participants exchange proposals to determine which security parameters to employ in the SA. A Phase 2 proposal also includes a security protocol—either Encapsulating Security Payload (ESP) or Authentication Header (AH)—and selected encryption and authentication algorithms. The proposal can also specify a Diffie-Hellman (DH) group, if Perfect Forward Secrecy (PFS) is desired.

Regardless of the mode used in Phase 1, Phase 2 always operates in quick mode and involves the exchange of three messages.

This topic includes the following sections:

Proxy IDs

In Phase 2, the peers exchange proxy IDs. A proxy ID consists of a local and remote IP address prefix. The proxy ID for both peers must match, which means that the local IP address specified for one peer must be the same as the remote IP address specified for the other peer.

Perfect Forward Secrecy

PFS is a method for deriving Phase 2 keys independent from and unrelated to the preceding keys. Alternatively, the Phase 1 proposal creates the key (the SKEYID_d key) from which all Phase 2 keys are derived. The SKEYID_d key can generate Phase 2 keys with a minimum of CPU processing. Unfortunately, if an unauthorized party gains access to the SKEYID_d key, all your encryption keys are compromised.

PFS addresses this security risk by forcing a new DH key exchange to occur for each Phase 2 tunnel. Using PFS is thus more secure, although the rekeying procedure in Phase 2 might take slightly longer with PFS enabled.

Replay Protection

A replay attack occurs when an unauthorized person intercepts a series of packets and uses them later either to flood the system, causing a denial of service (DoS), or to gain entry to the trusted network. Junos OS provides a replay protection feature that enables devices to check every IPsec packet to see if it has been received previously. If packets arrive outside a specified sequence range, Junos OS rejects them. Use of this feature does not require negotiation, because packets are always sent with sequence numbers. You simply have the option of checking or not checking the sequence numbers.

See Also

IKEv2 Message Exchange

IKE version 2 is the successor to the IKEv1 method. It provides a secure VPN communication channel between peer VPN devices and defines negotiation and authentication for IPsec security associations (SAs) in a protected manner.

IKEv2 does not include phase 1 and phase 2 similar to IKEv1, but there are four message exchanges occur to negotiate an IPsec tunnel with IKEv2. The message exchange in IKEv2 are:

  • Negotiates the security attributes to establish the IPsec tunnel. This includes exchanging the protocols/parameters used, and Diffie-Hellman groups.

  • Each peer establishes or authenticates their identities while the IPsec tunnel is established.

  • Peers to create additional security associations between each other.

  • Peers perform liveliness detection, removing SA relationships, and reporting error messages.

IKEv2 Configuration Payload

Configuration payload is an IKEv2 option offered to propagate provisioning information from a responder to an initiator. IKEv2 configuration payload is supported with route-based VPNs only.

RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2), defines 15 different configuration attributes that can be returned to the initiator by the responder.

IKEv2 Rekeying and Reauthentication

With IKEv2, rekeying and reauthentication are separate processes.

Rekeying establishes new keys for the IKE security association (SA) and resets message ID counters, but it does not reauthenticate the peers.

Reauthentication verifies that VPN peers retain their access to authentication credentials. Reauthentication establishes new keys for the IKE SA and child SAs; rekeys of any pending IKE SA or child SA are no longer needed. After the new IKE and child SAs are created, the old IKE and child SAs are deleted.

IKEv2 reauthentication is disabled by default. You enable reauthentication by configuring a reauthentication frequency value between 1 and 100. The reauthentication frequency is the number of IKE rekeys that occurs before reauthentication occurs. For example, if the configured reauthentication frequency is 1, reauthentication occurs every time there is an IKE rekey. If the configured reauthentication frequency is 2, reauthentication occurs at every other IKE rekey. If the configured reauthentication frequency is 3, reauthentication occurs at every third IKE rekey, and so on.

IKEv2 Fragmentation

When certificate-based authentication is used, IKEv2 packets can exceed the path MTU if multiple certificates are transmitted. If the IKE message size exceeds the path MTU, the messages are fragmented at the IP level. Some network equipment, such as NAT devices, does not allow IP fragments to pass through, which prevents the establishment of IPsec tunnels.

IKEv2 message fragmentation, as described in RFC 7383, Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation, allows IKEv2 to operate in environments where IP fragments might be blocked and peers would not be able to establish an IPsec security association (SA). IKEv2 fragmentation splits a large IKEv2 message into a set of smaller ones so that there is no fragmentation at the IP level. Fragmentation takes place before the original message is encrypted and authenticated, so that each fragment is separately encrypted and authenticated. On the receiver, the fragments are collected, verified, decrypted, and merged into the original message.

Traffic Selectors for IKEv2

You can configure traffic Selectors in IKEv2 used during IKE negotiation. A traffic selector is an agreement between IKE peers to permit traffic through a VPN tunnel if the traffic matches a specified pair of local and remote addresses. Only the traffic that conforms to a traffic selector is permitted through the associated security association (SA). Traffic selectors are used during the tunnel creation to set up the tunnel and to determine what traffic is allowed through the tunnel.

Proxy ID

A proxy-ID is used during phase 2 of Internet Key Exchange (IKE) Virtual Private Network (VPN) negotiations. Both ends of a VPN tunnel either have a proxy-ID manually configured (route-based VPN) or just use a combination of source IP, destination IP, and service in a tunnel policy. When phase 2 of IKE is negotiated, each end compares the configured local and remote proxy-ID with what is actually received.

Traffic Selectors

Proxy ID is supported for both route-based and policy-based VPNs. However, the multi-proxy ID is supported for only route-based VPNs. The multi-proxy ID is also known as traffic selector. A traffic selector is an agreement between IKE peers to permit traffic through a tunnel, if the traffic matches a specified pair of local and remote addresses. You define a traffic selector within a specific route-based VPN, which can result in multiple Phase 2 IPsec SAs. Only traffic that conforms to a traffic selector is permitted through an SA. The traffic selector is commonly required when remote gateway devices are non-Juniper Networks devices.

IKE Authentication (Preshared Key and Certificate-Based Authentication)

The IKE negotiations provides the ability to establish a secure channel over which two parties can communicate. You can define how the two parties authenticate each other using a preshared key authentication or certificate based authentication.

Preshared Key Authentication

Certificate-Based Authentication

Common way to establish a VPN connection.

Secure way to establish VPN connection.

  • Preshared key is a password that is the same for both the parties. This password is exchanged in advance using a phone, through a verbal exchange, or through less secure mechanisms, even e-mail.

  • Preshared key must consist of at least 8 characters (12 or more is recommended) using a combination of letters, numbers, and nonalphanumeric characters, along with different cases for the letters.

  • Preshared key must not use a dictionary word.

Certificates are composed of a public and private key, and can be signed by a primary certificate known as a certificate authority (CA)

The parties authenticate each other by encrypting the preshared key with the peer’s public key, which is obtained in the Diffie-Hellman exchange.

The parties check certificates to confirm if they are signed by a trusted CA.

Preshared keys are commonly deployed for site-to-site IPsec VPNs, either within a single organization or between different organizations.

Certificates are also far more ideal in larger scale environments with numerous peer sites that should not all share a preshared key.

Network Address Translation-Traversal (NAT-T)

Network Address Translation-Traversal (NAT-T) is a method for getting around IP address translation issues encountered when data protected by IPsec passes through a NAT device for address translation.

Any changes to the IP addressing, which is the function of NAT, causes IKE to discard packets. After detecting one or more NAT devices along the data path during Phase 1 exchanges, NAT-T adds a layer of User Datagram Protocol (UDP) encapsulation to IPsec packets so they are not discarded after address translation. NAT-T encapsulates both IKE and ESP traffic within UDP with port 4500 used as both the source and destination port. Because NAT devices age out stale UDP translations, keepalive messages are required between the peers.

The location of a NAT device can be such that:

  • Only the IKEv1 or IKEv2 initiator is behind a NAT device. Multiple initiators can be behind separate NAT devices. Initiators can also connect to the responder through multiple NAT devices.

  • Only the IKEv1 or IKEv2 responder is behind a NAT device.

  • Both the IKEv1 or IKEv2 initiator and the responder are behind a NAT device.

Suite B and PRIME Cryptographic Suites

Suite B is a set of cryptographic algorithms designated by the U.S. National Security Agency to allow commercial products to protect traffic that is classified at secret or top secret levels. Suite B protocols are defined in RFC 6379, Suite B Cryptographic Suites for IPsec. The Suite B cryptographic suites provide Encapsulating Security Payload (ESP) integrity and confidentiality and should be used when ESP integrity protection and encryption are both required. Protocol Requirements for IP Modular Encryption (PRIME), an IPsec profile defined for public sector networks in the United Kingdom, is based on the Suite B cryptographic suite, but uses AES-GCM rather than AES-CBC for IKEv2 negotiations.

The following cryptographic suites are supported:

  • Suite-B-GCM-128

    • ESP: Advanced Encryption Standard (AES) encryption with 128-bit keys and 16-octet integrity check value (ICV) in Galois Counter Mode (GCM).

    • IKE: AES encryption with 128-bit keys in cipher block chaining (CBC) mode, integrity using SHA-256 authentication, key establishment using Diffie-Hellman (DH) group 19, and authentication using Elliptic Curve Digital Signature Algorithm (ECDSA) 256-bit elliptic curve signatures.

  • Suite-B-GCM-256

    • ESP: AES encryption with 256-bit keys and 16-octet ICV in GCM for ESP.

    • IKE: AES encryption with 256-bit keys in CBC mode, integrity using SHA-384 authentication, key establishment using DH group 20, and authentication using ECDSA 384-bit elliptic curve signatures.

  • PRIME-128

    • ESP: AES encryption with 128-bit keys and 16-octet ICV in GCM.

    • IKE: AES encryption with 128-bit keys in GCM, key establishment using DH group 19, and authentication using ECDSA 256-bit elliptic curve signatures.

  • PRIME-256

    • ESP: AES encryption with 256-bit keys and 16-octet ICV in GCM for ESP.

    • IKE: AES encryption with 256-bit keys in GCM, key establishment using DH group 20, and authentication using ECDSA 384-bit elliptic curve signatures.

Suite-B cryptographic suites support IKEv1 and IKEv2. PRIME cryptographic suites only support IKEv2.