IPsec, a Tutorial--Part VIII

IKE and ISAKMP
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 1 through 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 services--it 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 protocols--IKE.

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 10 illustrates the configuration of the IPsec SA lifetime that Charlie would like to negotiate with James during IKE.

Page 2: next page
Page 1 | 2 | 3