Internet Key Exchange and the Internet Security Association and Key Management Protocol were designed to allow crypto endpoints to dynamically exchange keys and negotiate security associations. Unlike the examples that we’ve discussed that use manual SAs, IKE SAs can be established on the fly and torn down at a time period negotiated. As we had discussed before, IPsec specifies two SAs. The type of SA is the IPsec SA, which we reviewed in fair detail in examples 2-1 through 2-9. The second one, which we have yet to discuss in great detail, is the IKE SA. It is over this SA, the one that IKE establishes, that IPsec can now dynamically establish and tear down its SA between crypto endpoints.
IKE and ISAKMP Terminology and Background
ISAKMP was originally defined as a framework implementing two critical services to growing IPsec environments, which are dynamic establishment of security associations and dynamic exchange of cryptographic keys over a secure channel. As such, ISAKMP defines procedures for:
- Crypto endpoint authentication procedures
- IPsec SA negotiation, maintenance, and timeout
- Cryptographic key generation and exchange techniques (Diffie-Hellman)
- Threat mitigation (antireplay, DoS mitigation techniques)
However, ISAKMP is a framework for delivering these servicesit does not define the protocol for them. As such, ISAKMP is designed to be key-exchange independent, and supports a number of key exchange protocols. In the IPsec world, we are concerned with one of these key exchange protocolsIKE.
The protocol used for key exchange and SA negotiation in IPsec today, IKE, uses the framework outlined in ISAKMP to deliver upon authentication, SA negotiation, key generation and exchange, and native threat mitigation services. IKE represents a number of key exchange and SA negotiation protocols (Oakley and SKEME) that have been combined to fit within the ISAKMP framework. Oakley is a key exchange and management protocol that allows for the exchange of multiple keys and their corresponding services. SKEME supplies anonymity and nonrepudiation using its own key exchange method. IKE combines the strengths of Oakley and SKEME in a comprehensive protocol for establishing a secure channel over which to establish IPsec SAs.
As IKE is the ISAKMP protocol for IPsec, we will be discussing Oakley and SKEME only insofar as their relevance to IKE. In-depth coverage of Oakley and SKEME is outside of the scope of this work.
IKE SA Negotiation and Maintenance
The concept of an IPsec SA lifetime does not exist when using manual keys. The security parameters that comprise an IPsec SA are all manually defined. This is not the case with IKE/ISAKMP. IKE dynamically creates IPsec SAs upon the transmittal of traffic matching the IPsec policy. This is done by exchanging a series of messages over UDP port 500. IKE allows the crypto endpoints to negotiate a lifetime for each SA. This enables network administrators to use their SADB more efficiently through establishing security associations only when needed and automatically tearing down stale SAs at the end of their agreed-upon lifetime. Example 2-10 illustrates the configuration of the IPsec SA lifetime that Charlie would like to negotiate with James during IKE.
IPsec Diffie-Hellman Shared Secret Key Generation Using IKE
As we’ve discussed already in our overview of cryptographic components, IPsec uses symmetric key encryption. This requires the use of a shared secret key to exist on both crypto endpoints. We’ve seen examples of how one can preplace the session key on each endpoint to establish IPsec SAs. However, this approach presents a number of problems affecting the administrative overhead, performance, and security of an IPsec VPN:
Session keys for every SA (inbound and outbound at each crypto endpoint) for every IPsec tunnel. This presents greatly increased administrative overhead, especially if crypto session keys are to be changed regularly for security purposes.
IPsec SAs will never time out. If IPsec SAs are not in use for extended periods of time, they cannot time out and reinitiate upon matching policy traffic. As a result, manual session key configuration requires that the crypto endpoints maintain all of the SAs configured in the SADB, as opposed to just those in use with IKE.
Session keys never change, unless they are manually altered. The more frequently one changes the session keys, the less likely they are to be compromised.
Manual keying negates antireplay techniques between crypto peers.
There is no CA support for manual session keys.
As we’ve discussed, IKE exists, at least in part, as an alternative that is designed to increase scalability in IPsec VPN designs. Because keys are no longer manually configured in IKE, they must be dynamically created. IKE uses the Diffie-Hellman algorithm to dynamically create session keys exchanged over IKE. Diffie-Hellman is configured as part of the ISAKMP policy. The default MODP is 768 bits in length, denoted by group 1. Administrators have the option to choose between 3 different MODP for Diffie-Hellman secret key generation, as illustrated in Example 2-11.
Diffie-Hellman group 5 was created for ciphers requiring larger keys, such as AES. It is supported only in IOS releases later than 12.2. Like RSA keys, larger Diffie-Hellman MODPs ensure a stronger Diffie-Hellman secret key. However, as Diffie-Hellman MODP values get larger, they become more computationally expensive.
A Diffie-Hellman derived keypair presents two mathematical tasks to would-be attackers who wish to compromise the shared secret key’s confidentiality. First, an attacker must be able to derive A from seeing Q ^ A. This would require the computation of a discrete algorithm. The second strength is similar to one of RSA’s key strengthsthe attacker must be able to factor two large prime numbers. Hence, Diffie-Hellman values for P and Q share the same requirement as an RSA key modulusit must be large and random. Diffie-Hellman does not typically specify a modulus size directly. Instead, the modulus of a Diffie-Hellman key is referred to as the Diffie-Hellman group. There are four different Diffie-Hellman Groups that yield a DHS that is approximately equal to a 7080-bit symmetric key in strength.
source : https://flylib.com/books/en/188.8.131.52/1/