Feature |
Product |
Release introduced |
---|---|---|
Internet Key Exchange (IKE) v2 Note:
VOSS Releases 6.0 and 6.0.1 do not support this feature. |
5320 Series |
Fabric Engine 8.6 |
5420 Series |
VOSS 8.4 |
|
5520 Series |
VOSS 8.2.5 |
|
5720 Series |
Fabric Engine 8.7 |
|
7520 Series |
Fabric Engine 8.10 |
|
7720 Series |
Fabric Engine 8.10 |
|
VSP 4450 Series |
VOSS 5.1.2 |
|
VSP 4900 Series |
VOSS 8.1 |
|
VSP 7200 Series |
VOSS 5.1.2 |
|
VSP 7400 Series |
VOSS 8.0 |
|
VSP 8200 Series |
VOSS 5.1.2 |
|
VSP 8400 Series |
VOSS 5.1.2 |
|
VSP 8600 Series |
VSP 8600 8.0 demonstration feature |
|
XA1400 Series |
VOSS 8.0.50 |
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.
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.
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.
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:
DES
3DES
AES
MD5
SHA1
SHA256
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).
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.
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.
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.