ISAKMP and IKE

ISAKMP AND IKE

Last updated
November 27th, 1998

Martti Kuparinen
<>
Oy L M Ericsson Ab
Finland

The Internet Security Association and Key Management Protocol (ISAKMP) is a protocol utilizing security concepts needed for establishing Security Associations and cryptographic keys between two or more hosts in a network. The Internet Key Exchange (IKE) is based partly on ISAKMP. The purpose of IKE is to obtain keying material and other security associations, such as AH (Authentication Header) and ESP (Encapsulated Security Payload), for IPSEC. This paper gives a short introduction to both ISAKMP and IKE and tries to justify the existence of these protocols.  

The Internet Security Association and Key Management Protocol (ISAKMP) combines the security concepts of authentication, key management and Security Associations (SA) to establish secure communication channels between two or more hosts.

A Security Association (SA) is a relationship between two or more entities that describes how the entities will utilize security services to communicate securely. This relationship is represented by a set of information that can be considered a contract between entities. The information must be agreed upon and shared between all entities. The SA attributes required and recommended for the IP Security include authentication mechanism, cryptographic algorithm, algorithm mode, key length and initialization vector (IV).

A domain of interpretation (DOI) is used to group related protocols using ISAKMP to negotiate security associations. DOI defines how to interpret payload data content, how to name identifiers, which are the applicable security policies, etc. An example of the DOIs is the "IP Security Domain of Interpretation" [].

ISAKMP defines procedures and packet formats to establish, negotiate, modify and delete security associations. However, it does not define the actual protocols to be used (such as key exchange protocols and hash functions), these are implementation specific. One example of the ISAKMP implementation is the Internet Key Exchange (IKE) [] which will be described later in this document.

ISAKMP is intended to support the negotiation of SAs for security protocols at all layers of the network stack. The following figure illustrates a high level view of the ISAKMP suite within network operating systems. In that figure only the IP layer is involved with SAs.

Implementations of the ISAKMP are usually Unix daemons. They can use the standard socket services for communication with other entities in the network. They also interact with some network layer (such as with IP as in Figure 1) within the kernel. This could be done through some specific application programming interface (API) such as system calls or raw sockets.

ISAKMP can be implemented over any transport protocol or over IP itself. Implementations must, however, support at least the User Datagram Protocol (UDP) at port 500.

Figure 1. ISAKMP in the operating system

Figure 2 illustrates the two negotiation phases used in ISAKMP. In the first phase, two entities such as ISAKMP servers agree on how to protect further negotiation traffic. As a result of this negotiation, an ISAKMP SA is established. In the second phase security associations for other protocols such IPSEC are established. Usually there is need for only one phase one negotiation while there can be several phase two negotiations.

Figure 2. Overview of the ISAKMP

ISAKMP payloads provide modular building blocks for constructing ISAKMP messages. The exchange type field located in the ISAKMP header defines the presence and ordering of payloads. By combining several payloads, it is possible to construct all the exchange messages needed to setup and maintain SAs between hosts.

Each ISAKMP message begins with a fixed header (Figure 2). This header contains information required by protocol to maintain state, process payloads and prevent denial of service and replay attacks. Denial of service and other attacks are described in more detail in section .

Figure 3. ISAKMP Header

The initiator and responder cookies are used e.g. to prevent replay attacks. The next payload field defines type of the first payload in the message. The version field contain two subfields: major version and minor version. Implementations based on the current Internet-Draft are expected to use 1.0 as the version number.

The message ID is used to identify protocol state during Phase 2 negotiations. This value is randomly generated, so that this is likely to be different across concurrent negotiations. Length is the total message size (header + payloads) in 8-byte octets.

Each ISAKMP payload begins with a generic header (Figure 3). It provides a payload "chaining" capability and clearly defines the boundaries of a payload.

Figure 4. Generic Payload Header

The are several instances within ISAKMP where it is necessary to represent Data Attributes (DA). These DAs are not ISAKMP payloads, but are contained within ISAKMP payloads. There can be several DAs within one payload.

Figure 5. Data Attributes

Type defines the attribute types. These are defined as part of the DOI-specific information.

2.2.4 Security Association Payload

The security association payload is used to negotiate security attributes and to indicate the domain of interpretation and situation under which the negotiation is taking place.

Figure 6. Security Association Payload

The proposal consists of security mechanisms, or transforms, to be used to secure the communications channel.

Transform Payload

The transform payload defines the DOI-specific transforms and SA attributes.

Key Exchange Payload

The key exchange payload supports several key exchange techniques such as Oakley, Diffie-Hellman and RSA.

Identification Payload

The identification payload contains DOI-specific data used to exchange identification information.

Certificate Payload

The certificate payload is used to transport certificates or certificate-related information. These can appear in any ISAKMP message.

Normally certificates are distributes using a directory service such as secure DNS. When these kinds of services are unavailable, certificates can be transmitted in normal ISAKMP negotiations.

There are currently 10 different certificate types defined such as DNS signed key, PGP certificate and SPKI certificate. Certificate types and formats are not generally DOI-specific. It is expected that there will be only few different types and that most of the DOIs will accept all these types.

Certificate Request Payload

The certificate request payload is used when requesting certificates via ISAKMP.

Hash Payload

The hash payload contains data generated by the hash function (such as MD5). The function is selected during SA establishment exchange. The hash value is calculated over some part of the message or the ISAKMP state. This is used to verify the integrity of the data in a message or for authentication of the negotiating entities.

Signature Payload

The signature payload contains data generated by the digital signature function. Also this function is selected during SA establishment exchange and the value is calculated over some part of the message or the ISAKMP state. Like the hash value, this payload is used to verify the integrity of the data in an ISAKMP message.

Nonce Payload

The nonce payload contains random data. The purpose of this payload is to guarantee liveness during an exchange and prevent replay attacks. When preventing replay attacks this information could be related to the current time and date.

Notification Payload

The notification payload can be used to transmit informational data such as error codes and status information to peer entities. This payload contains a 16-bit type field. There are currently 30 error codes defined.

Delete Payload

The delete payload contains a protocol-specific security association identifier that the sender has removed from its database and is thus no longer valid. It is not a request to for the responder to delete a SA, but an advisory from the initiator to the responder. The responder is not expected to acknowledge receipt of a delete payload message.

Vendor ID Payload

The vendor ID payload contains a vendor-defined constant. This is used to identify and recognize remote instances of vendor's implementations. This could be used to experiment with new features and at the same time maintain backward compatibility.

This value is a hash over some text. The choice of hash function and the text is unspecified. As an example the text could be

"FooBar Inc., IPSEC version 1.2" and the hash function could be MD5.

ISAKMP allows the creation of exchanges for the establishment of security associations and keying material. There are currently five exchange types defined for ISAKMP. These provide different security protection for the exchange itself and information exchanged that they can be used in both phases of the negotiation. They are not meant to satisfy all domain of interpretation and key exchange protocol requirements. All implementations are expected to support the informational exchange. The remaining four exchanges are optional but should be implemented.

A security association establishment message consists of a single SA payload followed by one or more proposal payloads and one or more transform payloads associated with each proposal payload.

Proposals can be grouped together with logical OR and AND operations. Use of different proposal numbers is a logical OR between proposal, i.e. "Proposal 1 OR Proposal 2". Use of the same proposal number is a logical AND, i.e. "Proposal 1 AND Proposal 2".

Transforms can also be grouped with the logical OR operation. Use of the same transform number is several transform payloads provides a second level OR operation, i.e. "Transform 1 OR Transform 2".

Security association modification within ISAKMP is accomplished by creating a new SA and initiating communication using that new SA. The old SA can be deleted anytime after the new SA is established. This deletion is dependent on local policy. A protocol implementation should begin using the newly created SA and at the same time continue support incoming traffic on the old SA.

Modification of an ISAKMP SA (phase 1) follows the same procedure as creation of an ISAKMP SA. There is no relationship between the two SAs. Modification of a protocol SA (phase 2) follows the same procedure as creation of a protocol SA. The creation of a new SA is protected by an existing ISAKMP SA.

The base exchange allows the key exchange and authentication information to be transmitted together in one message. This reduces the number of round-trips at the expense of security. This does not provide identity protection because they are exchanged before a common shared secret has been established.

The identity protection exchange separates the key exchange from the identity and authentication related information to provide identity protection. This adds two additional messages but identities are exchanged under the protection of a previously established common shared secret.

The authentication only exchange allows only the authentication related information to be transmitted. This means that none of the transmitted information will be encrypted, it is just authenticated. Use of this method saves computational capacity since no encryption keys needs to be calculated.

2.3.4. Aggressive Exchange

The aggressive exchange allows the security association, key exchange and authentication related information to be transmitted together. This reduces the amount of messages into one, but at the expense of not providing identity protection.

2.3.5. Informational Exchange

The informational exchange is an exchange and not an ISAKMP message. It is used as a one-way information transmission packet for security association management. If the Informational exchange occurs prior to the exchange of keying material during an ISAKMP phase 1 negotiation, there will be no protection for this exchange. In later phases the information is transmitted under the protection provided by the ISAKMP or the keying material.

Every ISAKMP message is checked before performing any action based on the payload data. These checks insure protocol reliability and minimize threats such as denial of service and replay attacks.

For all packets the following things must be verified:

Payload length

Next payload

Cookies

Message ID

Version information

Payload length is verified against the real packet length. Should this simple test fail, the packet is dropped immediately without informing the peer entity.

The next payload field points to the next ISAKMP Payload message. Should this pointer be invalid, the packet is invalid and should be dropped. An error message could be sent to the sender, but this is optional. This field is used when chaining several payloads so this field must be valid for the ISAKMP to work.

The initiator and responder cookies must pass the validation. Also the message ID must what is expected. Error in these tests may indicate security problems such as a replay attack.

Mismatches in the version fields (major and minor version) could indicate problems with the ISAKMP implementations. This is not, however, an error since newer version should be backward compatible.

2.4.2. Security Association Payload Processing

The transmitting entity determines the domain of interpretation, situation within the DOI and proposal(s) and transform(s) and transmit the security association payload.

The receiving entity verifies that the domain of interpretation (DOI) is supported by this implementation. After this it verifies the situation and processes the remaining payloads such as proposal and transform payloads.

The transmitting entity determines first the protocol for this proposal. Then it determines the number of proposal and transforms to be offered and generates a unique SPI and constructs the actual proposal payload.

The receiving entity checks if the protocol as described by the protocol field is supported, if the SPI is valid and that the proposals are valid. After these checks it processes the proposal and transform payloads as defined by the next payload field.

The transmitting entity determines the transform number and the number of transforms to be offered and constructs the actual payload.

The receiving entity checks if the transform is supported and that the transforms are valid. After these it processes the payload and the following transforms and proposals as defined by the next payload field.

The sender determines the key exchange to use and constructs the payload. The receiver verifies that the Key Exchange is actually supported. In both cases the key exchange is is defined by the domain of interpretation.

The remaining payloads are:

Identification payload

Certificate payload

Certificate request payload

Hash payload

Signature payload

Nonce payload

Notification payload

Delete payload

When processing these payload the common rules apply; all data is verifies before it is used. For a complete description how to process these payload see.

2.5. Security Issues

ISAKMP was designed to as resistive as possible against various attacks and error conditions. This section describes some possible scenarios and how they are handled in ISAKMP.

Absolute protection against denial of service is impossible. Some attempts have, however, been made to protect the computing resources from attacks without spending too much processor capacity on the authentication determination. An anti-clogging token, also known as a cookie, could be used to improve the security.

An attacker could hijack a connection by allowing first the peer entities to authenticate each other and then intercept all traffic and impersonate one entity to the other in later phases of the communication. These include the key and security association exchanges and the actual data traffic. This kind of attack is prevented by ISAKMP. The protection is based on linking the authentication, key exchange and security association exchanges.

Man-in-the-middle attacks include interception, insertion, deletion and modification of messages, reflecting messages back to the sender, replaying old messages and redirecting messages. All these attacks are prevented by ISAKMP. As an example protection against replaying old messages is achieved with the help of cookies. These cookies contain time variable data inside, and can therefore not forged.

A perfect forward secrecy (PFS) is achieved when that compromise of a single key will permit access to only data protected by that single key. This means that the key used to protect transmission of data must not be used to derive any additional keys.

One of the most important steps in establishing secure network communications is authentication of the entity at the other end. Public key based strong authentication, such as Digital Signature Standard (DSS) and Rivest-Shamir-Adleman (RSA), can be used to authenticate the peer entity reliably. Authentication based on digital signatures requires a trusted third party or a Certificate Authority (CA) to create, sign and distribute these certificates.

Certificates bind a specific entity's identity to its public keys and possibly other security-related information. There is a need for generation, verification, revocation, management and distribution of certificates. The Internet Policy Registration Authority (IPRA) has been established to direct this infrastructure for the IETF. The IPRA certifies Policy Certification Authorities (PCA). PCAs control Certificate Authorities (CA) which certify users and subordinate entities. One possible solution to distribute signed entity keys is to use the Domain Name System (DNS). This commonly referred as DNSSEC.

The Internet Key Exchange (IKE) can be used to negotiate security associations and authenticated keying material for this negotiation. One real life usage example is the virtual private network (VPN) establishment between a remote user and the corporate firewall.

There are two basic methods to establish an authenticated key exchange: main mode and aggressive mode. Exchanges conform to standard ISAKMP payload syntax, attribute encoding, etc. Exchanges in IKE have a fixed number of messages, i.e. a received certificate request will not increase the number of expected or transmitted messages.

Main mode implements the ISAKMP identity protect exchange, i.e. the first two messages negotiate the policy, then next two exchange Diffie-Hellman public values and the last two messages authenticate the Diffie-Hellman exchange.

Aggressive mode implements the ISAKMP aggressive exchange, i.e. it takes three messages to authenticate both parties and exchange Diffie-Hellman public values.

There are four different authentication methods in main mode and aggressive mode. The following sections describe these in more detail.

Authentication with Digital Signatures

This authentication can be used in either main mode or aggressive mode. In both modes the signed data is the result of the negotiated signature algorithm applied to a hash function.

Authentication with Public Key Encryption

Public key encryption increases the total security since an attacker would have to break not only the Diffie-Hellman exchange but also both RSA encryptions. There is no proof that the negotiation ever took place since each party can reconstruct both sides of the exchange. Additional benefit is that authentication with public key encryption allows identity protection even with aggressive mode.

In order to perform the public key encryption, the initiator must have the responder's public key. If the responder has several public keys, a hash of the public key being used is transmitted to the responder. With this hash the responder can select the corresponding private key.

The authentication message contains encrypted identities of the parties and the usual nonce. The payload headers are, however, not protected with encryption.

A Revised Method of Authentication with Public Key Encryption

In this mode the nonce is still encrypted with the public key encryption but the peer's identity is encrypted using the negotiated symmetric encryption algorithm. The key is derived from the nonce. This mode retains the advantages of public key authentication but with half the public key operations.

Authentication with a Pre-Shared Key

When authenticating with pre-shared keys both parties must communicate and agree upon a key using a (probably) insecure medium. The key is distributed in an out-of-band fashion. [] defines a 14-byte pre-shared key for the Internet Protocol. It is represented in ASCII as "mekmitasdigoat".

Quick mode is used as part of the SA negotiation process to derive keying material and negotiate shared policy for non-ISAKMP SAs. This is essentially a SA negotiation and an exchange of nonces to protect against replay attacks.

Base quick mode without the KE payload refreshes the keying material derived from the exponentiation in phase 1. This does not provide perfect forward secrecy because the keying material is derived from existing keys. When using the optional KE payload the perfect forward secrecy can be achieved.

The new group mode is used to specify the characteristics of the group (). The nature of the group can be hidden with this mode while passing only the group identifier in clear text in phase 1. For this reason this exchange is performed after establishing an ISAKMP SA, i.e. when this negotiation is secured by a SA.

Also these messages are protected, but only when an ISAKMP SA has been established. This message contains also a hash value. When there is no ISAKMP SA available, the exchange is done in clear without the trailing hash payload.

The Oakley protocol defines four identifiers called groups. These define the basic Diffie-Hellman exchange parameters. All implementations must support at least one group; the remaining three are optional but should be implemented.

The first two groups are based on the MODP group. All IKE implementations are expected to support the first MODP group with the following characteristics:

prime: 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 } generator: 2

All IKE implementations should, but are not expected, to support the second MODP group with the following characteristics:

prime: 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 } generator: 2 The remaining two groups are based on the more complex EC2N group. The curve is both cases based on Galois field with field sizes 155 and 185. Also these two groups should, but are not expected, to be supported.

A more complete description of the Oakley groups is available in [] and [].

By extending ISAKMP to use public key cryptography and the certificates, it is possible to reduce the number of transmissions in the key exchange, detect masquerade faster and perform all transactions encrypted from the beginning. The number of transmissions is reduced by sending the security association, key exchange, nonce, identification and certificates together in a single message. The use of certificates in ISAKMP is described in [].

The currently defined IKE authentication modes share two properties: both parties authenticate each other and both use the same method for authentication. However, it is not always possible to use symmetric authentication. It is, however, usually necessary to preserve the mutual authentication. These issues, and more, are addressed in [].

The Internet Security Association and Key Management Protocol (ISAKMP) defines a simple, yet an effective framework for managing Security Associations between different entities in the network. The Security Association (SA) feature coupled with authentication and key establishment provides the security and flexibility that is needed for the future growth and diversity of the Internet. Multiple key exchange techniques, encryption algorithms and other security parameters allow users to select the appropriate security for their network communications. ISAKMP does not define the actual protocols to be used. This allows users to adopt for example new better and stronger encryption algorithms as they emerge.

ISAKMP is based on Diffie-Hellmann key exchange algorithms as a key establishment method. It does not guarantee correct correspondence between the host and the public key used in the key exchange. The public key cryptography has also similar problems. These problems can be solved by using a third party certificate authority (CA). Only the host, which corresponds to the public key, can access message if the message is encrypted with the public key.

The Internet Key Exchange (IKE) is used to negotiate and exchange keying material between entities in the Internet. It uses the well-defined ISAKMP framework, Oakley key exchanges and SKEME [] mechanism and the IP Security Domain of Interpretation [] which defines the actual exchanges, payloads and processing guidelines. IKE could be used for example to establish a virtual private network (VPN) between a remote user and the corporate firewall.

AH
API	Application Programming Interface
CA	Certificate Authority
DA	Data Attributes
DSS	Digital Signature Standard
DNS	Domain Name System
DOI	Domain of Interpretation
ESP	Encapsulating Security Payload
IKE
IP	Internet Protocol
IPRA	Internet Policy Registration Authority
ISAKMP	Internet Security Association and Key Management Protocol
IV	Initialization Vector
PCA	Policy Certification Authorities
PFS	Perfect Forward Secrecy
RSA	Rivest-Shamir-Adleman
SPI	Security Parameter Index
TCP	Transmission Control Protocol
UDP

[1]	Maughhan, D., Schertler, M., Schneider, M., and Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", < >
[2]	Maughhan, D., Schertler, M., Schneider, M., and Turner, J., "The Internet Key Exchange (IKE)", < >
[3]	Pereira, R. "Extended Authentication Within ISAKMP/Oakley", < >
[4]	Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", < >
[5]	Orman, H., "The Oakley Key Determination Protocol", < >
[6]	Piper, D., Harkins, D., "The Pre-shared Key for the Internet Protocol", < >
[7]	Krawczyk, H., "SKEME: A Versatile Secure Key Exchange Mechanism for Internet" IEEE Proceedings of the 1996 Symposium on Network and Distributes Systems Security.
[8]	Shigeyoshi, S. "ISAKMP Certificate Key Exchange Type Specification" < >
[9]	Litvin, M., Shamir, R., "A Hybrid Authentication Mode for IKE" < >
[10]	Earslake, D., Gudmudsson, O. "Storing Certificates in the Domain Name System" < >

$Id: isakmp.html,v 1.13 1998/11/27 17:12:38 martti Exp $