Internet Key Exchange Explained

In computing, Internet Key Exchange (IKE, versioned as IKEv1 and IKEv2) is the protocol used to set up a security association (SA) in the IPsec protocol suite. IKE builds upon the Oakley protocol and ISAKMP.[1] IKE uses X.509 certificates for authentication ‒ either pre-shared or distributed using DNS (preferably with DNSSEC) ‒ and a Diffie–Hellman key exchange to set up a shared session secret from which cryptographic keys are derived. In addition, a security policy for every peer which will connect must be manually maintained.

History

The Internet Engineering Task Force (IETF) originally defined IKE in November 1998 in a series of publications (Request for Comments) known as RFC 2407, RFC 2408 and RFC 2409:

updated IKE to version two (IKEv2) in December 2005.[5] clarified some open details in October 2006.[6] combined these two documents plus additional clarifications into the updated IKEv2,[7] published in September 2010. A later update upgraded the document from Proposed Standard to Internet Standard, published as in October 2014.

The parent organization of the IETF, the Internet Society (ISOC), has maintained the copyrights of these standards as freely available to the Internet community.

Architecture

Most IPsec implementations consist of an IKE daemon that runs in user space and an IPsec stack in the kernel that processes the actual IP packets.

User-space daemons have easy access to mass storage containing configuration information, such as the IPsec endpoint addresses, keys and certificates, as required. Kernel modules, on the other hand, can process packets efficiently and with minimum overhead—which is important for performance reasons.

The IKE protocol uses UDP packets, usually on port 500, and generally requires 4–6 packets with 2–3 round trips to create an ISAKMP security association (SA) on both sides. The negotiated key material is then given to the IPsec stack. For instance, this could be an AES key, information identifying the IP endpoints and ports that are to be protected, as well as what type of IPsec tunnel has been created. The IPsec stack, in turn, intercepts the relevant IP packets if and where appropriate and performs encryption/decryption as required. Implementations vary on how the interception of the packets is done—for example, some use virtual devices, others take a slice out of the firewall, etc.

IKEv1 consists of two phases: phase 1 and phase 2.[8]

IKEv1 phases

IKE phase one's purpose is to establish a secure authenticated communication channel by using the Diffie–Hellman key exchange algorithm to generate a shared secret key to encrypt further IKE communications. This negotiation results in one single bi-directional ISAKMP security association.[9] The authentication can be performed using either pre-shared key (shared secret), signatures, or public key encryption.[10] Phase 1 operates in either Main Mode or Aggressive Mode. Main Mode protects the identity of the peers and the hash of the shared key by encrypting them; Aggressive Mode does not.[8]

During IKE phase two, the IKE peers use the secure channel established in Phase 1 to negotiate Security Associations on behalf of other services like IPsec. The negotiation results in a minimum of two unidirectional security associations (one inbound and one outbound).[11] Phase 2 operates only in Quick Mode.[8]

Problems with IKE

Originally, IKE had numerous configuration options but lacked a general facility for automatic negotiation of a well-known default case that is universally implemented. Consequently, both sides of an IKE had to exactly agree on the type of security association they wanted to create option by option or a connection could not be established. Further complications arose from the fact that in many implementations the debug output was difficult to interpret, if there was any facility to produce diagnostic output at all.

The IKE specifications were open to a significant degree of interpretation, bordering on design faults (Dead Peer Detection being a case in point), giving rise to different IKE implementations not being able to create an agreed-upon security association at all for many combinations of options, however correctly configured they might appear at either end.

Improvements with IKEv2

The IKEv2 protocol was described in Appendix A of RFC 4306 in 2005. The following issues were addressed:

Supposing HostA has a Security Parameter Index (SPI) of A and HostB has an SPI of B, the scenario would look like this:

HostA -------------------------------------------------- HostB
     |HDR(A,0),sai1,kei,Ni-------------------------->   |
     |   <----------------------------HDR(A,0),N(cookie)|
     |HDR(A,0),N(cookie),sai1,kei,Ni---------------->   |
     |   <--------------------------HDR(A,B),SAr1,ker,Nr|

If HostB (the responder) is experiencing large amounts of half-open IKE connections, it will send an unencrypted reply message of IKE_SA_INIT to HostA (the initiator) with a notify message of type COOKIE, and will expect HostA to send an IKE_SA_INIT request with that cookie value in a notify payload to HostB. This is to ensure that the initiator is really capable of handling an IKE response from the responder.

Protocol extensions

The IETF ipsecme working group has standardized a number of extensions, with the goalof modernizing the IKEv2 protocol and adapting it better to high volume,production environments. These extensions include:

Implementations

IKE is supported as part of the IPsec implementation in Windows 2000, Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008.[13] The ISAKMP/IKE implementation was jointly developed by Cisco and Microsoft.[14]

Microsoft Windows 7 and Windows Server 2008 R2 partially support IKEv2 as well as MOBIKE through the VPN Reconnect feature (also known as Agile VPN).

There are several open source implementations of IPsec with associated IKE capabilities. On Linux, Libreswan, Openswan and strongSwan implementations provide an IKE daemon which can configure (i.e., establish SAs) to the KLIPS or XFRM/NETKEY kernel-based IPsec stacks. XFRM/NETKEY is the Linux native IPsec implementation available as of version 2.6.

The Berkeley Software Distributions also implements IPsec, IKE daemon via the OpenBSD Cryptographic Framework (OCF), which makes supporting cryptographic accelerators much easier. OCF has recently been ported to Linux.

A number of network equipment vendors have created their own IKE daemons (and IPsec implementations), or license a stack from one another.

There are a number of implementations of IKEv2 and some of the companies dealing in IPsec certification and interoperability testing are starting to hold workshops for testing as well as updated certification requirements to deal with IKEv2 testing.

The following open source implementations of IKEv2 are available:

Vulnerabilities

Leaked NSA presentations released in 2014 by German: [[Der Spiegel]] indicate that IKE is being exploited in an unknown manner to decrypt IPsec traffic, as is ISAKMP. The researchers who discovered the Logjam attack state that breaking a 1024-bit Diffie–Hellman group would break 66% of VPN servers, 18% of the top million HTTPS domains, and 26% of SSH servers, which the researchers claim is consistent with the leaks.[17] This claim was refuted in 2015 by both Eyal Ronen and Adi Shamir in their paper "Critical Review of Imperfect Forward Secrecy" [18] and by Paul Wouters of Libreswan in a 2015 article "66% of VPN’s are not in fact broken" [19]

IPsec VPN configurations which allow for negotiation of multiple configurations are subject to MITM-based downgrade attacks between the offered configurations, with both IKEv1 and IKEv2.[20] This can be avoided by careful segregation of client systems onto multiple service access points with stricter configurations.

Both versions of the IKE standard are susceptible to an offline dictionary attack when a low entropy password is used. For the IKEv1 this is true for main mode and aggressive mode.[21] [22] [23]

See also

External links

Notes and References

  1. The Internet Key Exchange (IKE), RFC 2409, §1 Abstract
  2. 2407 . The Internet IP Security Domain of Interpretation for ISAKMP .
  3. 2408 . Internet Security Association and Key Management Protocol (ISAKMP) .
  4. 2409 . The Internet Key Exchange (IKE) . D. Harkins .
  5. 4306 . Internet Key Exchange (IKEv2) Protocol . C. Kaufman (Microsoft) . December 2005 .
  6. 4718 . IKEv2 Clarifications and Implementation Guidelines . P. . Eronen . P. . Hoffman . October 2006 .
  7. 5996 . Internet Key Exchange (IKEv2) Protocol . C. . Kaufman . P. . Hoffman . Y. . Nir . P. . Eronen . September 2010 .
  8. "RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 5
  9. "RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 6
  10. "RFC 2409 The Internet Key Exchange (IKE)", Internet Engineering Task Force (IETF), p. 10-16
  11. "RFC 4306 Internet Key Exchange (IKEv2) Protocol", Internet Engineering Task Force (IETF), p. 11,33
  12. "RFC 4306: Internet Key Exchange (IKEv2) Protocol", Internet Engineering Task Force (IETF), p 38-40
  13. https://technet.microsoft.com/en-us/library/cc784994(WS.10).aspx Internet Key Exchange: Internet Protocol Security (IPsec): Technet
  14. http://www.securityfocus.com/infocus/1519 Using IPSec in Windows 2000 and XP, Part 1
  15. Web site: OpenIKEv2 . 2023-06-21 . GitHub . en.
  16. Web site: iked(8) - OpenBSD manual pages . 2023-06-21 . man.openbsd.org.
  17. Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice . David . Adrian . Karthikeyan . Bhargavan . Zakir . Durumeric . Pierrick . Gaudry . Matthew . Green . J. Alex . Halderman . Nadia . Heninger . Nadia Heninger . Drew . Springall . Emmanuel . Thomé . Luke . Valenta . Benjamin . VanderSloot . Eric . Wustrow . Santiago . Zanella-Béguelin . Paul . Zimmermann . 22nd ACM Conference on Computer and Communications Security (CCS ’15) . . October 2015 . 15 June 2016.
  18. Web site: Critical Review of Imperfect Forward Secrecy . Eyal . Ronen . Adi . Shamir . October 2015.
  19. Web site: 66% of VPN's are not in fact broken . Paul . Wouters . October 2015.
  20. Web site: Downgrade Resilience in Key-Exchange Protocols . Karthikeyan . Bhargavan . Christina . Brzuska . Cédric . Fournet . Markulf . Kohlweiss . Santiago . Zanella-Béguelin . Matthew . Green . January 2016 .
  21. Web site: Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets. Pliam. John. 2 October 1999. Johns Hopkins University. live. https://web.archive.org/web/20020610050311/http://www.ima.umn.edu/~pliam/xauth/. 10 June 2002. 5 February 2020.
  22. Web site: Great Cipher, But Where Did You Get That Key. McGrew. David. 5 July 2011. Cisco Blog. dead. https://web.archive.org/web/20110709020412/http://blogs.cisco.com/security/great-cipher-but-where-did-you-get-that-key/. 9 July 2011. 11 February 2020.
  23. Book: Felsch, Dennis. The Dangers of Key Reuse: Practical Attacks on IPsec IKE. August 2018. 27th USENIX Security Symposium. 9781939133045 . 11 February 2020.