ISAKMP (Internet Security Association and Key Management Protocol)

ISAKMP (Internet Security Association and Key Management Protocol) is a protocol for establishing Security Associations (SA) and cryptographic keys in an Internet environment. ISAKMP provides a framework for authentication and key exchange. It is designed to be key exchange independent. Authenticated keying material for use with ISAKMP are provided by protocols such asInternet Key Exchange and Kerberized Internet Negotiation of Keys.

• defines procedures and packet formats to establish, negotiate, modify and delete Security Associations (SAs)
• defines payloads for exchanging key generation and authentication data
• provides a consistent framework for transferring key and authentication data which is independent of the key generation technique, encryption algorithm and authentication mechanism

Each message consists of a header that is followed by at least one payload.

HEADER FORMAT

• initiator cookie - cookie of initiator, notification or deletion of SA
• responder cookie - null if first message
• next payload - first payload type in the message
• MjV, MnV - major and minor version of currently used ISAKMP
• exchange type - how keys will be exchanged
  • base type, identity protection, authentication only, aggressive type
• flags - indicators of specific options
• message ID - unique identifier
• length - total length of the message (header + payloads) in bytes

PAYLOAD FORMAT

• generic header
  • next payload - 0 for the last payload in the message, other values define the type of the following payload
  • reserved - for the future
  • payload length - length of the payload (including generic header) in bytes
• payload

PAYLOAD TYPES

• Security association (SA) payload
  • parameters: interpretation domain, situation
  • negotiation of security parameters for a SA
• Proposal (P) payload
  • parameters: serial number, protocol ID, security parameter indicator (SPI), SPI size, number of transforms (cryptographic algorithms), transforms statement
  • used in SA negotiation phase
  • indicates whether ESP or AH is going to be used with this SA
• Transform (T) payload
  • parameters: transform ID, security association attributes
  • for security association and transforms negotiation
• Key exchange (KE) payload
  • parameters: data for key exchange
  • support for various key exchange techniques
• Certificate (CERT) payload
  • parameters: certificate encoding type (X.509, PHP, SPKI), certificate
  • used for transportation of digital signed certificates and other relevant information
• Certificate request (CR) payload
  • parameters: certificate type, number of certificates, certificates, number of CAs and CAs
  • provides means to request certificates
• Hash payload
  • contains hash values of the message
  • assures integrity
  • serves to authenticate entities during negotiation
• Signature (SIG) payload
  • parameters: digital signature
  • uses the same data as hash payload
  • data is signed - non-repudiation
• Identification (ID) payload
  • parameters: identification and types of data
  • used for identification (e.g. IP number)
• Nonce payload
  • serves to protect against replies
• Notification payload
  • parameters: interpretation domain (DOI), protocol ID, security parameters index (SPI), SPI size, notification type, notification data
  • serves to transmit informational data (errors, status ...)
• Deletion (D) payload
  • parameters: DOI, protocol ID, quantity and size of SPI, SPIs
  • SAs that the sender has deleted from its database and are invalid

ISAKMP TYPES

Base exchange

• simultaneous key and authentication material exchange
• first two messages use cookies and establish an SA with agreed protocol and transforms; both use nonces to prevent replay attacks
• last two messages exchange keys, user IDs, payload for authentication of keys, IDs and nonces from first two msgs
• provides no identity protection
• requires only four exchanges

Identity protection exchange

• first two messages establish the SA
• second two perform key exchange (prevention of replays trough use of nonces)
• computation of secret session key
• encrypted messages are exchanged enabling authentication

Authentication only exchange

• provides mutual authentication
• no key exchange
• first two messages establish SA
• responder transfers its ID in second message (this one is authenticated)
• in the third message initiator transmits its authenticated ID

Aggressive exchange

• minimal number of exchanges
• does not provide identity protection
• initiator proposes an SA, protocol and transforms and provides its ID in first message
• responder indicates its acceptance of SA with a particular protocol and transform, completes key exchange and authenticates transferred data
• initiator transmits authentication result encrypted with the session key

Informational exchange

• one way communication
• data convey for SA management