Chapter 3. Comparison of IKEv1 and IKEv2

This chapter describes the history of the Internet Key Exchange protocol and examines the differences between the Internet Key Exchange version 1 (IKEv1) and Internet Key Exchange version 2 (IKEv2) protocols. Details are given in the differences of the exchanges and the rationale for the decisions made when differences were introduced between both protocols.

IKEv1 and IKEv2 are incompatible protocols, so you will never have an IKEv1 device communicating with an IKEv2 device. Both protocols achieve the same goals, but in totally different manners. These differences are covered in detail below.

IKEv2 introduces a number of features that are not available in IKEv1, such as the use of next-generation encryption protocols and anti-denial-of-service capabilities, which are described throughout the chapter.

IKEv1 offers some of the authentication methods that are used in IKEv2; however, IKEv1 does not allow the use of Extensible Authentication Protocol (EAP), which allows IKEv2 to be the perfect solution for remote-access termination.

IKEv2 has been designed to be more efficient than IKEv1: the packet exchanges are restructured to be lighter, so fewer packets are exchanged and less bandwidth is needed compared to IKEv1.

At the end of this chapter, you will understand that during the development of IKEv1 as many features were not considered in the initial design; however, these issues are addressed in IKEv2.

Brief History of IKEv1

In 1998 a number of protocols were released via the IETF as Request for Comments (RFCs), relating to secure communication over the Internet. These documents described IPsec and covered architecture, the Encapsulation Security Payload protocol, Authentication Header protocol, encryption algorithms, authentication algorithms, Domain of Interpretation (DoI) and key management.

The following RFCs were published by the IETF:

Image RFC 2401 Security Architecture for the Internet Protocol

Image RFC 2402 IP Authentication Header

Image RFC 2403 The Use of HMAC-MD5-96 within Encapsulation Security Payload and Authentication Header

Image RFC 2404 The Use of HMAC-SHA-1-96 within Encapsulation Security Payload and Authentication Header

Image RFC 2405 The Encapsulation Security Payload DES-CBC Cipher Algorithm With Explicit IV

Image RFC 2406 IP Encapsulating Security Payload

Image RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP

Image RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP)

Image RFC 2409 The Internet Key Exchange (IKE)

Image RFC 2410 The NULL Encryption Algorithm and Its Use With IPsec

Image RFC 2411 IP Security Document Roadmap

Image RFC 2412 The OAKLEY Key Determination Protocol

The Internet Key Exchange (IKE), described in RFC 2409, actually referenced a number of other protocols:

Image ISAKMP provides a framework for authentication and key exchange but did not actually define these. ISAKMP was designed to be key-exchange independent, allowing the use of numerous key-exchange mechanisms within the framework.

Image OAKLEY describes a number of key exchange mechanisms and the services which were provided by each (perfect forward secrecy for keys, identity protection, and authentication). The OAKLEY protocol is used to establish a shared key with an assigned identifier and associated authenticated identities for the two parties within the exchange.

Image SKEME describes a versatile key exchange technique that provides a number of modes that delivers the ability for anonymity, reputability, and quick key refreshment.

The Internet Key Exchange describes a protocol using part of the OAKLEY protocol and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as Authentication Header and Encapsulation Security Payload for the IETF IPsec DOI.

Over time numerous RFCs were created that related to RFC 2409 including:

Image RFC 3715 IPsec-Network Address Translation (NAT) Compatibility Requirements

Image RFC 3947 Negotiation of NAT-Traversal in the IKE

Image RFC 3948 UDP Encapsulation of IPsec Encapsulation Security Payload Packets

These three RFCs describe ways to detect the use of Network Address Translation between two IKE peers and then the method to encapsulate the traffic within User Datagram Protocol for better NAT traversal of IKE and IPsec traffic.

Image RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange Peers, describes the ability for a liveness check between IKE peers.

Image RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association, allows larger 64-bit sequence numbers to be employed on Security Associations.

RFC 2409 did not address technologies related to Remote Access; this resulted in a number of Internet Drafts being developed to address the requirement to support Remote Access technologies within the Internet Key Exchange.

Image Extended Authentication within IKE (XAUTH)

Image Extended Authentication within ISAKMP/Oakley (XAUTH)

Image The ISAKMP Configuration Method

However, none of these Drafts achieved RFC status and so had limited uptake by vendors. As these solutions were not standardized implementations, different vendors implemented each feature in differently. These non-standard implementations caused interoperability issues between software from different vendors.

RFC 4754 IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA).

This RFC describes additional authentication methods using the Elliptic Curve Digital Signature Algorithm.

It soon became apparent that the Internet Key Exchange (IKE) protocol described in RFC 2409 had some limitations and that the number of RFCs that were developed to interact with RFC 2409 caused a degree of confusion. When Internet Key Exchange version 2 was developed, these limitations seemed to have been addressed with the lessons learned from developing and implementing IKEv1.

Exchange Modes

This section discusses the exchange modes for both IKEv1 and IKEv2.

IKEv1

In IKEv1, multiple modes could be used to establish secure IKE connectivity and authenticate each peer: Aggressive Mode or Main Mode.

Aggressive Mode consists of a three message exchange. Each message in the exchange is known as AMx, where x denotes the message number. Odd numbers always come from the initiator and even numbers from the responder. The shorter exchange generally resulted in a faster connection; however, it sacrificed the following: the ability to protect identities, the requirement for the responder to authenticate itself first in the exchange, and allowed an intruder with ability to capture the exchange to perform an offline brute force attack if Pre-Shared-Key authentication was used.

Main Mode consists of six message exchanges, which allow for both peers to create a secure IKE session and authenticate each other. Each message in the exchange is known as MMx, where x denotes the message number. Odd numbers are always from the initiator and even numbers from the responder.

From a high level, the first pair of messages (MM1 and MM2) negotiate cryptographic ciphers, the second pair of messages (MM3 and MM4) exchange key material, and the third pair of messages (MM5 and MM6) are encrypted and used to prove the identity. Unlike Aggressive Mode, the Identity is protected within the exchange. Main Mode has limited anti-DoS capabilities in the form of cookies; however, the exchange of six messages increases the time to establish a session compared to Aggressive Mode, which lacks any form of DOS protection.

Once the IKEv1 peers have established an IKE session, one or more IPsec Security Association(s) can be created; the method used to establish the IPsec Security Association is known as Quick Mode. Each message in the exchange is known as QMx, where x denotes the message number. Quick Mode commonly uses a three-message exchange, with the first message (QM1) from the initiator containing the cryptographic algorithms to be used and the traffic selectors to define what will be protected. The second message (QM2) in the exchange comes from the responder and contains the cryptographic algorithms to be used and the traffic selectors to define what will be protected. The third message (QM3) comes from the initiator and essentially just acknowledges the responder’s previous message. Note that if the commit-bit is set, which requests confirmation for a message, four messages are used. RFC 2408 describes this behavior, where the Responder will send an acknowledgement to the Initiator (QM4).

Assuming that Quick Mode uses three messages, for IKEv1 to create an IPsec Security Association using Aggressive Mode a total of six messages will be exchanged. If Main Mode is used, nine messages will be exchanged.

Figure 3-1 illustrates IKEv1 exchanges using Main Mode and Aggressive Mode.

Image

Figure 3-1 IKEv1 Main Mode and Aggressive Mode

IKEv2

IKEv2 reduces the number of exchanges from potentially six or nine messages down to four. IKEv2 has no option for either Main Mode or Aggressive Mode; there is only SA_INIT (Security Association Initialization). Essentially the initial IKEv2 exchange (SA_INIT) exchanges cryptographic algorithms and key material. So the information exchanged in the first two pairs of messages (MM1 to MM4) in IKEv1 is exchanged in the first pair of messages in IKEv2. The next IKEv2 exchange (IKE_AUTH) is used to authenticate each peer and also create a single pair of IPsec Security Associations. The information that was exchanged in messages MM5 and MM6 of Main Mode and in QM1 and QM2 of Quick Mode is exchanged in the IKE_AUTH exchange, in which both peers establish an authenticated, cryptographically protected IPsec Security Association. With IKEv2 all exchanges occur in pairs, and all messages sent require an acknowledgement (see Figure 3-2). Note if an acknowledgement is not received, the sender of the message is responsible for retransmitting it.

Image

Figure 3-2 Relationship of Attributes Sent in IKEv1 Exchanges, Compared to IKEv2

If additional IPsec Security Associations were required in IKEv1, a minimum of three messages would be used by Quick Mode to create these, whereas IKEv2 employs just two messages with a CREATE_CHILD_SA exchange.

Anti-Denial of Service

The reduction in message exchanges within IKEv2 comes at a cost that wasn’t a problem within IKEv1. Because cryptographically expensive key material is exchanged in the first two messages (SA_INIT), an intruder could consume resources on a VPN gateway by sending many SA_INIT requests with a spoofed source address; as a result the gateway would generate expensive key material and dedicate resource to connections that would not be established. To counter this threat, IKEv2 has the ability to use a stateless cookie, which results in a zero state being assigned to an IKEv2 session if the VPN gateway is under attack.

Lifetime

In IKEv1 the lifetime of the IKE Security Association was negotiated in the first pair of messages (MM1 and MM2). The lifetime configured on the responder must be equal to or less than the lifetime proposed by the initiator for a successful match to occur. This requirement resulted in incompatibilities; IKEv1 sessions would not be established between incorrectly configured peers or peers that had mismatching default lifetimes. In IKEv2 the lifetime is a locally configured value that is not negotiated between peers; a peer will delete or rekey a session when its local lifetime expires. This allows for each IKEv2 peer to control which party will initiate a rekey. This removes any chance that a session will not be established due to a misconfigured lifetime.

Authentication

RFC 2409 defined the ability to use a number of methods for authentication:

Image Pre-Shared Key (PSK)

Image Digital Signature (RSA-Sig)

Image Public Key Encryption

Image Revised Mode of Public key Encryption

RFC 4754 introduced the ability for IKEv1 to use the Elliptic Curve Digital Signature Algorithm (ECDSA) for authentication; however, because this was introduced relatively late in the lifetime of IKEv1, it has seen little acceptance.

IKEv2 allows the use of:

Image Pre-Shared Key (PSK)

Image Digital Signature (RSA-Sig)

Image Extensible Authentication Protocol (EAP)

RFC 4754 introduced the ability for IKEv2 to use the Elliptic Curve Digital Signature Algorithm (ECDSA) for authentication; unlike IKEv1, ECDSA was adopted widely in IKEv2, and it is a requirement for implementations to support RFC 6380, Suite B Profile for Internet Protocol Security (IPsec).

IKEv2 introduced the ability to authenticate peers via the Extensible Authentication Protocol (EAP), which was described in RFC 3748. This allows clients to authenticate via an already established standardized mechanism, unlike IKEv1, which required non-standard extensions. EAP is an authentication framework that allows the use of a number of different authentication methods to validate the identities of peers. Due to its flexibility, it was chosen to be used natively within IKEv2.

Within IKEv1, the authentication method was negotiated as part of the transforms exchanged within MM1 and MM2. Because the authentication method is required to match between both peers, each peer had to support the same authentication method as the device it was connecting to. IKEv2 removes the requirement to negotiate the authentication method and introduces the ability to specify the authentication method in the IKE_AUTH exchange. As a result, each peer is able to choose its method of authentication. This allows for asymmetric authentication to occur, so the peers can use different authentication methods.

High Availability

IKEv1 offers no support for any mechanisms to provide high availability; the only option for high availability is to use tricks such as DNS round robin to load between VPN gateways or to use a dedicated load balancer. IKEv2 provides the ability for a client to be redirected to another VPN gateway. This is documented in RFC 5685, Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2), which allows any client that supports this ability to be redirected by any compliant IKEv2 VPN Gateway.

Traffic Selectors

The IKEv1 exchange requires a combination of a source IP range, a destination IP range, a source port, and a destination port per IPsec Security Association. Both parties must agree on the exact traffic selector. However IKEv2 allows for the responder to select a narrower set of traffic selectors than the one the initiator proposed. IKEv2 also allows the use of multiple combinations of a source IP range, a destination IP range, a source port range, and a destination port range per Child SA. As a result, IKEv2 is able to support both IPv4 and IPv6 traffic for a single IPsec Security Association.

Note that Cisco IOS does not allow both IPv4 and IPv6 traffic to be sent over the same IPsec Security Association.

Use of Identities

IKEv2 supports the ability to generate multiple connections between peers using the same IP address and port pair for the IPsec Security Association, but with the use of different identities. Having the ability to use multiple identities allows IPsec Security Association to be protected by different algorithms and authenticated by a different means.

It should be noted that IKEv2 deliberately allows parallel Security Associations with the same traffic selectors between common endpoints. One of the primary purposes is the ability to use the Differentiated Services Code Point (DSCP) to differentiate traffic between different SAs. This provides the ability to utilize different SAs using different quality of service (QoS) attributes to minimize unnecessary packet drops due to anti-replay check failures.

Network Address Translation

With IKEv1, the ability to detect NAT on the transport network and then act accordingly was included not in the main RFC but in a number of an additional RFCs. IKEv2 included details of how to achieve within the RFC for the protocol itself. IKEv2 also defines how Dead Peer Detection and NAT keepalives are implemented, while these were described by additional RFCs within IKEv1.

Configuration Payload

IKEv1 did not include any method to push or receive configuration data natively, such as a client obtaining an IP address when connecting to a VPN gateway. The ISAKMP Configuration Method is an IETF Draft that allowed for this ability. IKEv2 has the inbuilt ability to support configuration data exchange between peers via the use of a configuration payload.

Mobility & Multi-homing

MOBIKE (IKEv2 Mobility and Multihoming Protocol RFC 4555) let’s a remote access VPN user move from one IP address to another without reestablishing all security associations with the VPN gateway. The ability to move between IP addresses without performing expensive cryptographic calculations and without the overhead of reconnecting to the VPN gateway improves the user experience. IKEv1 does not support any mechanism to do this, whereas IKEv2 does.

Note that Cisco IOS does not support MOBIKE.

Matching on Identity

For IKEv1 the SKEY (which is used to derive further session keys to protect the exchange) or secret key is composed according to the following formula;

SKEYID = prf(pre-shared-key, Ni_b | Nr_b)

You can see that the pre-shared key is used in the construction of the SKEY; this pre-shared key should be tied to an identity (IP address, FQDN, etc.). When the IKEv1 main mode exchanges are looked at, it is seen that exchanges MM5 and MM6 are encrypted using the SKEY; these packets contain the identity of the peer. As the pre-shared key must be known to decrypt the payload that contains the identity, this makes matching on any identity but IP address impossible when a pre-shared-key is used with IKEv1, as only the IP address is known (as this is the source of the traffic).

IKEv2 implements the SKEY using the following formula;

SKEYSEED = prf(Ni | Nr, g^ir)

Notice that the pre-shared key is not used in this calculation. The only values that are used (the nonces and Diffie-Hellman shared secret) were sent in the SA_INIT exchange that occurs before the SKEY is required in IKE_AUTH. IKEv2 can use an identity of IP address; however, this identity can be any IP address, not necessarily the source IP address used.

The IKE_AUTH exchange consists of the following;

HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2 TSi, TSr} —>

<— HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}

The SKEY is used to encrypt the payload within { } and also to decrypt it on the receiver. As the pre-shared key is not used in the SKEY calculation, the peer can decrypt the encrypted payload (using the attributes exchanged in SA_INIT) and then match the identity. Once the identity is known, the pre-shared key can be selected based on this identity. This key is then used to authenticate the peer.

For the initiator:

AUTH = prf( prf(Shared Secret, “Key Pad for IKEv2”), <InitiatorSignedOctets>)

For the responder:

AUTH = prf( prf(Shared Secret, “Key Pad for IKEv2”),<ResponderSignedOctets>)

IKEv2 removes the constraints of having a unique identity (IP address) per pre-shared key. When a VPN gateway is deployed with IKEv1, if there are multiple separate groups (consumers) of the VPN, each group requires a unique IP address on the VPN gateway to enforce separation so that one group does not have the shared secret of the other group. IKEv2 overcomes this limitation; separate groups can use a VPN gateway with the same IP address while using unique shared secrets. This allows service providers to reuse hardware for multiple customers at the same time protecting each customer’s data.

Note

IKEv1 uses the pre-shared key in the construction of the shared secret, unlike IKEv2, which only uses the derived shared secret from the Diffie-Hellman exchange and the nonces. If an attack became apparent against Diffie-Hellman then the inclusion of the pre-shared key brings a number of security benefits. Using a pre-shared key in IKEv1, where the key is generated with strong entropy, would require an attacker to break not only the Diffie-Hellman exchange but also the pre-shared-key. In IKEv2, an attacker would only need to break the Diffie-Hellman exchange. For this reason at the time of this writing, IKEv1 with a pre-shared key is known to be resistant to attacks using quantum computing, or quantum resistant, but IKEv2 is not, at least not with the algorithms currently used. However the following IETF Draft describes a method to enable IKEv2 to act in a quantum-resistant manner: An Extension for Postquantum Security using Preshared Keys for IKEv2 draft-fluhrer-qr-ikev2-00.

This is purely speculative and is based on the question; what would happen if a quantum computer was ever made that could break Diffie-Hellman?

Reliability

All message exchanges within IKEv2 are always sent in pairs, consisting of a request and response message; if the sender of the request message does not receive a response, it will retransmit the request. Because all messages are in pairs and all messages must be acknowledged, all exchanges are reliable.

Cryptographic Exchange Bloat

Within IKEv1 all sets of cryptographic ciphers that are negotiated to protect the IKE session are transferred in separate transforms, so if a device was required to support multiple sets of cryptographic algorithms, it would send a separate transform for all the sets of cryptographic algorithms that it supported. Within IKEv2 all cryptographic algorithms are sent within one transform (or two transforms if combined and non-combined mode ciphers are used), which can greatly reduce the amount of traffic sent when negotiating and rekeying IKEv2 Security Associations.

Combined Mode Ciphers

IKEv1 uses separate algorithms to provide encryption and integrity protection. With the availability of combined mode ciphers, a new class of algorithms was introduced, in which a single algorithm can provide both encryption and integrity protection. IKEv2 provides the ability to use these ciphers; however, IKEv1 is not able to support these as they are not defined within the IANA assignments.

Continuous Channel Mode

IKEv2 introduced the concept of continuous channel mode. In it, once a new IKE Security Association is created, the new IKE SA inherits all the valid child Security Associations that belonged to the old IKE SA. These child Security Associations can be accessed from both the old and new SAs until the old SA expires. In addition deleting an IKEv2 SA will delete any associated IPsec Security Associations. IKEv1 operates in a noncontinuous channel mode, in which if a new IKE SA is generated, all corresponding IPsec Security Associations will be generated also. In IKEv1 an IPsec Security Association could exist without an IKEv1 SA, but in IKEv2 this is not possible, since the IKEv2 SA must exists for the IPsec Security Association to exist.

Summary

Internet Key Exchange version 1 has some limitations; like many protocols, its deficiencies were not discovered until implementations interoperated with each other. Internet Key Exchange version 2 was developed to overcome the limitations discovered within Internet Key Exchange version 1. Currently, there is little (to no) development within the IP Security Maintenance and Extensions (ipsecme) working group for IKEv1, whereas IKEv2 is actively being discussed and developed.

There are many benefits to using IKEv2 over IKEv1; especially the security that IKEv2 brings in the way of cryptographic algorithm support and its ability for to implement anti-DOS capabilities should a number of half-open connections be detected.

IKEv2 is far more efficient than IKEv1; it requires fewer messages to establish an IPsec Security Association and is able to send all available cryptographic algorithms in a single transform, unlike to IKE1, which requires a separate transform per set of cryptographic policies.

IKEv2 is very well suited to remote access solutions. It has features such as the ability to support MOBIKE and match on identity when using pre-shared key authentication that are not available in IKEv1.

As you have learned, there are many reasons to use IKEv2, and at the time of this writing the majority of new customer deployments are using IKEv2 instead of IKEv1 as the benefits are clear. The majority of third-party clients are now supporting IKEv2 and moving away from using IKEv1.

References

http://tools.ietf.org/html/draft-ietf-ipsec-ikev2-tutorial-01 Understanding IKEv2: Tutorial, and rationale for decisions

https://tools.ietf.org/html/rfc6071 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap

http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml Internet Key Exchange (IKE) Attributes

http://datatracker.ietf.org/wg/ipsecme/documents/ IP Security Maintenance and Extensions (ipsecme)

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.78.1517&rep=rep1&type=pdf IKEv1 and IKEv2: A Quantitative Analyses

https://tools.ietf.org/html/draft-dukes-ike-mode-cfg-00 The ISAKMP Configuration Method

https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-01 Postquantum Preshared Keys for IKEv2

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset