1

Section 10.9

Internet Security Association and Key Management Protocol

ISAKMP

ISAKMP

ISAKMP (Internet Security Association and Key Management Protocol) is a protocol for establishing Security Associations (SA) and cryptographic keys in an Internet environment. The protocol is defined by RFC 2408.

ISAKMP defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks).

ISAKMP typically utilizes IKE for key exchange, although other methods can be implemented. Preliminary SA is formed using this protocol; later a fresh keying is done.

ISAKMP

ISAKMP defines procedures and packet formats to establish, negotiate, modify and delete Security Associations.

SAs contain all the information required for execution of various network security services, such as the IP layer services (such as header authentication and payload encapsulation), transport or application layer services, or self-protection of negotiation traffic.

ISAKMP defines payloads for exchanging key generation and authentication data. These formats provide a consistent framework for transferring key and authentication data which is independent of the key generation technique, encryption algorithm and authentication mechanism.

ISAKMP

At the core of IPSec are four major components:

1. IPSec driver or core engine This is the component of IPSec that does the actual encryption (application of the Encapsulating Security Payload—ESP—protocol), decryption, signing (application of the Authenticated Header—AH—protocol), and signature verification.

2. IPSec Policy Agent This is the cognitive function of IPSec. The policy module examines the IPSec settings of a system and determines which traffic should be protected and some generic settings for that protection.

.

ISAKMP

3. Internet Security Association and Key Management Protocol (ISAKMP)ISAKMP is the negotiator for Internet security settings.

ISAKMP is a subcomponent of IKE.ISAKMP connects from a source computer to a destination computer using user datagram protocol (UDP) port 500.

4. Internet Key Exchange (IKE) Because IPSec uses shared secret key encryption, there must be some mechanism for the computers to contact each other and agree on a key. IKE manages this by providing generic key agreement services for IPSec.

An ISAKMP session is established prior to setting up an IPsec tunnel. Phase one occurs in main mode, and phase two occurs in quick mode.

http://packetlife.net/captures/protocol/isakmp/

http://ipseclab.eit.lth.se/tiki-index.php?page=5.%20IPSec

There are 6 packets in the phase one and 3 packets in the phase two. This .cap is included in the lesson.

phase one

phase two

Phase 1 and Packet 1

The initiator generates a cookie, sets the responder cookie to zero and sends to the responder.

Packet 1:

Proposal for ISAKMP Security Association (SA)

Encryption algorithm AES with CBC mode of operation proposed. Hash algorithm SHA proposed.

Packet 2

The responder generates a responder cookie, copies the initiator cookie to the message and sends it to the initiator.

Packet 2: Reply to the proposal.

The responder checks its support suite of encryption and authentication algorithms for IKE to decide whether it can fit one from the proposal lists.

Here in the case, the responder supports the specific one which the initiator proposes.

The cookie pair will be kept during the entire IKE negotiation process.

Packet 3

The initiator sends Key Exchange Payload which is used for generating the Diffie-Hellman (DH) key and the Nonce Data.

The nonce is a random number involved in the practical keys computing.

Packet 4: The ISAKMP SA is generated.

After this step, the negotiations are encrypted by the ISAKMP SA.

The responder replies with its Key Exchange Payload and Nonce Data, which serve the same function as the 3rd packet.

Packet 5: This step is encrypted

This step is encrypted.

The initiator announces its identity.

Pre-shared key, random number (nonce), initiator and responder cookie, and DH exchange data.

Packet 6: This step is encrypted

This step is encrypted.

The responder announces its identity in the same way as in the 5th packet.

Phase 2 and Packet 1

This step is encrypted.

There can be many quick mode (phase two) instances under the ISAKMP SA protection.

The cookies are the same for all instances, so the “Message ID” field is the only identification in phase two.

The initiator sends IPsec session proposal requests to the responder (encrypted).

Phase2 and Packet 2: this step is encrypted

This step is encrypted.

The “cookie” pair and “Message ID” are the same as the first packet.

The responder checks the suite of encryption and authentication algorithms it supports for the subsequent “IPsec session” to decide whether it can fit one from the proposal lists.

In this case, the responder supports the specific one which the initiator proposes.

Phase 2 and Packet 3: this step is encrypted.

This step is encrypted.

The initiator replies and agrees to the SA

Backup

The following set of slides illustrates another ISAKMP exchange.

This is an earlier example and shows the details of the interchange.

The .cap file for this exchange is not available.

http://ipseclab.eit.lth.se/tiki-index.php?page=5.%20IPSec