Internet Key Exchange

Table 1. Internet Key Exchange product support
Feature	Product	Release introduced
Internet Key Exchange (IKE) v2	5320 Series	Fabric Engine 8.6
	5420 Series	VOSS 8.4
	5520 Series	VOSS 8.2.5
	5720 Series	Fabric Engine 8.7

Internet Key Exchange (IKE) protocol creates a Security Association (SA) in IPsec. The SA is the relationship between two network devices that define attributes such as authentication mechanism, encryption and hash algorithms, exchange mode, and key length for secured communications. The SA should be agreed by both devices.

The IKE protocol is based on Internet Security Association and Key Management Protocol (ISAKMP) which helps in building a secured connection between two or more hosts using the following concepts:

authentication
encryption
key management
security association (SA)
policy

IKE uses a key exchange mechanism based on the Diffie-Hellman encryption key exchange protocol. IKE provides periodic automatic key renegotiation, pre-shared and public key infrastructures, and anti-replay defense. It is layered on top of the UDP protocol and uses UDP port 500 to exchange information between peers.

IKE Phases

A switch negotiates with a peer using IKE in two phases.

In phase 1, the switch negotiates the IKE SA to protect the negotiations that take place in phase 2. The SAs negotiated in phase 1 are bi-directional, and are applicable to traffic originating in both directions.
In phase 2, the peers negotiate and establish the SAs for IPsec and session keys through quick mode. A Diffie-Hellman key exchange is done to achieve perfect forward secrecy, which ensures that the compromise of a single key does not permit access to data other than that protected by that compromised key. The SAs in phase 2 are uni-directional. They are used according to the direction of the traffic. The quick mode is initiated by either of the peer endpoints irrespective of who initiated phase 1.

IKE Modes

There are two modes of exchanging messages in Phase 1:

Main mode

This is a secure mode of exchanging messages. It allows protection of the confidentiality of the peers during negotiation. This mode provides more flexibility in proposals compared to aggressive mode. As the main mode requires a total of 6 messages to be exchanged between peers, it is more time consuming.
Aggressive mode

This mode is less secure than the main mode. It does not protect the confidentiality of the peers. However, it requires only a total of 3 messages to be exchanged for phase 1, which makes this mode faster than the main mode. The number of total message exchange is reduced in this mode because some messages are embedded in other messages.

The mode of message exchange in phase 2 is called quick mode. In this mode a total of 3 messages are exchanged between the peers. This mode is used to establish IPsec SA. The negotiations in the quick mode are protected during the phase 1 negotiations in main mode.

IKE Policies

A combination of security parameters used during the IKE SA negotiation is called a policy. The policies must be configured on both the peers and at least one of the policies should match on both ends to have a successful negotiation for. If a policy is not configured on both peers or if a policy does not match on both ends, an SA cannot be setup and data cannot be exchanged.

The following are the attributes of an IKE policy:

Encryption — This is the cryptographic algorithm that is sent in the proposal by the initiator or responder during the phase 1 negotiation. This cryptographic algorithm is used to encrypt phase 2 negotiation messages. The supported encryption algorithms are:
- DES
- 3DES
- AES
Hash function — This function is used as part of the authentication mechanism during the authentication of peers in phase 1. It is always used with the authentication algorithm. The supported values are:
- MD5
- SHA1
- SHA256
Authentication — This process authenticates the peers. Following are the supported authentication modes:
- Digital Signatures — The digital signatures use digital certificate which is signed by the certificate authority (CA) for authentication.
- Pre-shared keys (PSK) — The PSKs are shared out-of-band between the peers before hand. Using PSK in main mode exchange limits identifying the peer to an IP address (and not host name).
Diffe-Hellman (DH) Group — This is an algorithm used by two peers that are unknown to each other to establish a shared secret key. This key that is decided during phase 1 is used to encrypt subsequent message exchanges during phase 2 to establish security associations (SA) and security policies (SP) for IPsec sessions. The supported DH Groups are as follows:
- Group 1 (MODP768)
- Group 2 (MODP1024)
- Group 14 (MODP2048)
Lifetime — This is a time and data limit agreed by peers to protect an SA from getting compromised. It ensures that the peers renegotiate the SAs just before the lifetime value expires, that is, when the time limit is reached.
Dead-peer detection – This is a process in which the switch waits for a response from peer for a limited number of seconds before declaring the peer as dead. It is a keep-alive mechanism required to perform IKE peer fail-over and to reclaim lost resources by freeing up SAs that are no longer in use.

IKE Authentication

The security gateway of a peer must authenticate the security gateway of the peer it intends to communicate with. This ensures that IKE SAs are established between the peers. The switch supports the following two authentication methods:

Digital certificates (using RSA algorithms)

For digital certificate authentication, the initiator signs the message interchange data using the private key. The responder uses the public key of the initiator to verify the signature. The public key is exchanged by messages containing an X.509v3 certificate. This certificate provides an assurance that the identity of a peer, as represented in the certificate, is associated with a particular public key.
Pre-shared keys

Pre-shared key authentication, the same secret must be configured on both security gateways before the gateways can authenticate each other.

Signature Authentication

The switch receives the digital signature of its peer in a message exchange. The switch verifies the digital signature by using the public key of the peer. The certificate of the peer, received during the IKE negotiation, contains the public key. To ensure that the peer certificate is valid, the switch verifies its digital signature by using the certificate authority (CA) public key contained in the root CA certificate. The switch and its IKE peer require at least one common trusted root CA for authentication to work.

When IKE is configured to use digital certificates for authentication, the certificates are retrieved from the trusted certificate store in the switch, based on the provided distinguished name. The certificates received from the peer are verified with the public key.