Figure 1 - ISAKMP architecture.
April 24th, 1999
Mika Silander
Department of Computer Science
Helsinki University of Technology
Mika.Silander@hut.fi
The diversity of services in modern, heterogenuous IP networks impose great requirements on security services. Different security algorithms are needed due to different kinds of applications and security demands and most of all, because of the need of making secured services interoperable. Such services require dynamic agreement of security mechanisms and parameters. To achieve this in public networks encryption must be used and thus, interchange and management of encryption keys between communicating parties and the selection of mutually applicable cryptographic algorithms becomes a major task.
ISAKMP is a standard offering solutions for both of these problems. This paper, based on the corresponding RFC 2408, attempts to give a thorough explanation on ISAKMP. It hopefully exceeds the RFC 2408 in clarity, telling what ISAKMP is, what purposes it serves, how it works and why it is needed. So, "alea jacta est - this bugger has thrown himself at it", please do help yourself, the dinner is served for acid commentaries to flourish ...
When uttering the word 'public' in any networking context, it must be interpreted as 'eavesdroppable' and thus, vulnerable to many kinds of abuse. In order to ensure the security of communication, the only effective tool is cryptography. Modern cryptography relies on the secrecy being entirely in the encryption keys, not the algorithms since even the most secret algorithms have eventually been disclosed. This makes keys and key management the method for protecting communication in public networks.
When wanting secure communications over heterogeneous networks, one is always bound to make some preparatory security agreements with the counterparts before sending information. Until recently such agreement procedures and protocols were accomplished with ad hoc facilities each one suited for a special purpose with little or no general applicability. This reduces severely the interoperability of services. The Internet Security Association and Key Management Protocol (ISAKMP) framework[1] is aimed to remedy the problem by generalising this initial step so that different kinds of security services can be negotiated and incorporated confidentially in a standardized manner between the communicating parties.
2. ISAKMP
The Internet Security Association and Key Management Protocol
is a framework that defines standards and procedures for establishing,
negotiating, modifying and deleting different security parameters
between two or more communicating entities in both private as well as
public networks. "Entity" means in this context a host, a user on a
host or some uniquely identifiable software running on a host, e.g. a
server daemon. ISAKMP can thus be seen as a top level protocol within
which actual key management and other security protocols may be
executed.
The work on ISAKMP was initiated by the Internet Engineering Task Force (IETF) in 1994. In parallel with ISAKMP other contenders for standard such as Simple Key-Management for Internet Protocols (SKIP), Secure Key Exchange Mechanism (SKEME) and Photuris were evaluated. Two years later however, ISAKMP outperformed the others in terms of extensibility and generality, and was therefore adopted as the mandatory-to-implement key management protocol for IPv6. For IPv4 it was defined as optional.
Of the list of six fundamental security properties stated by IETF - confidentiality, authentication, integrity, non-repudiation, authorisation and accessibility - ISAKMP addresses the first two. The latter four properties may be covered with ISAKMP according to the specific needs at hand by making ISAKMP to negotiate them, i.e. agree on additional security services with the other communicating parties.
2.1 ISAKMP concepts
Prior to discussing the interiors of ISAKMP some auxiliary definitions
and terminology must be explained.
2.1.1 Security protocol
A Security protocol is a security service for network
communication performed at a single point in the network stack. For
example, the IPSec Encapsulating Security Payload (ESP) and Authentication
Header (AH) is a security protocol operating in the network layer.
2.1.2 Security Association
A Security Association (SA) defines a relationship between
two or more communicating entities. This relationship describes how
the entities will use security services, such as encryption, to
communicate securely. In clear text, a security association tells what
the security parameters and services commonly agreed are between the
communicating parties. Examples of such parameters are authentication
algorithms, authentication keys, encryption algorithms, encryption
keys and the time of validity of the SA itself.
Depending on what kind of traffic is in question, different kinds of SAs are set up. Ensuring security on the level of IP traffic needs its own kinds of SAs for example, and Secure Socket Layer (SSL) traffic another. SAs are often named according to the associated security protocol, e.g. ESP SA. The thing to note here is that ISAKMP doesn't define what the contents of SAs are, but rather how the communicating parties agree on the contents of SAs.
2.1.3 Situation
A Situation is a collection of information that is of
relevance when deciding what security services and parameters are
needed for a session. In other words, a situation defines the outer
conditions that must be taken into account when establishing a
communications session.
An example situation can contain information such as source and destination IP addresses, desired security classification (public, confidential) etc. This information is sent between ISAKMP servers so that according to it, the servers can decide what precise security services can be chosen for the SAs from a set of proposed ones.
For example, the IPSEC DOI defines three situations[2]:
3. ISAKMP architecture
ISAKMP services are usually offered by a dedicated ISAKMP server
(UNIX) connected to the port 500. According to specification, ISAKMP
must offer services with the UDP protocol, but the specification
states no hindrance for supporting other transport protocols as well,
such as TCP or directly IP.
Even though the below figure doesn't explicitly show that ISAKMP offers security service negotiation for all layers of the protocol stack, that is what ISAKMP has been designed for.
Figure 1 - ISAKMP architecture.
The messages ISAKMP servers interchange are made of different kinds of payloads. Each payload defines some security information that is needed to establish and maintain shared SAs and keys. Exchanges define what combinations of payloads must be sent and in which order. They can therefore be seen as protocol definitions for ISAKMP servers.
On the protocol level every ISAKMP message starts with the below header:
Figure 2 - ISAKMP protocol header.
4.1 Payloads
ISAKMP payloads are the building blocks of which ISAKMP messages are
created. With the help of payloads, ISAKMP servers share information
about common security associations and keys.
Physically a payload is made of a generic header and subsequent information which is unintelligible to ISAKMP. The idea is that ISAKMP knows the overall syntax of its own default payloads and the extension payloads introduced by the DOI specification, but leaves the exact interpretation of their contents to the DOI. This feature allows ISAKMP to be extended with new and/or enhanced protocols.
Figure 3 - Generic payload header.
The Next field tells what type of payload follows the current one in an ISAKMP message:
| Number | Payload | Number | Payload |
|---|---|---|---|
| 0 | None | 8 | Hash |
| 1 | Security Association | 9 | Signature |
| 2 | Proposal | 10 | Nonce |
| 3 | Transform | 11 | Notification |
| 4 | Key exchange | 12 | Delete |
| 5 | Identification | 13 | Vendor identifier |
| 6 | Certificate | 14 - 127 | Reserved |
| 7 | Certificate request | 128 - 255 | Private use |
The Reserved field is currently unused and fixed to 0. The Payload length tells the length of the current payload's contents which follow immediately after the header.
Figure 4 - Security Association payload.
Figure 5 - Proposal payload.
Transform payload
A transform payload can be seen as one atomic security parameter
suggestion in a proposal, as described above. Such a suggestion
consists of a specific security mechanism and the associated
attributes which will be included in the SA if this suggestion gets
accepted. It is strongly recommended that the SA attributes be defined
according to the Data attribute syntax.
Figure 6 - Transform payload.
The Certification type or Certification encoding defines what type of certificate is transported within the certificate (~ authority or ~ data) field.
Figure 7 - Certificate payloads.
Figure 8 - Notification payload.
The modification of already established SAs in ISAKMP is actually achieved with the help of this payload. Updating of SAs is done by establishing a new SA with the desired properties and then deleting the old one, i.e. the one that had to be modified.
What the additional attributes are and how they are interpreted is defined in the key exchange definitions which are fed to the ISAKMP server at startup. ISAKMP only defines the generic structure of data attributes:
Figure 9 - Data attribute header.
The AF - attribute flag bit defines if the third and fourth field
are interpreted as a) the attribute length and attribute
value, or as b) the attribute value and empty field.
4.3 Exchanges
Payloads as described above defined "atomic" pieces of information
that were contained within ISAKMP messages. ISAKMP exchanges define
what combinations of payloads must be sent and in which order for
establishing and maintaining SAs and keys. In other words, exchanges
define protocol steps for ISAKMP servers which they then follow to negotiate
security services and parameters.
ISAKMP itself defines five default exchanges (numbers 1 - 5 below) for initial interoperability:
| Number | Exchange | Number | Exchange |
|---|---|---|---|
| 0 | None | 5 | Informational |
| 1 | Base | 6 - 31 | Reserved for ISAKMP future use |
| 2 | Identity protection | 32 - 239 | DOI specific use |
| 3 | Authentication only | 240 - 255 | Reserved for private use |
| 4 | Aggressive |
More exchange types can and often must be defined in DOIs and key exchange definitions to meet all the needs of security and key management protocols, e.g. IP DOI and IKE[5] define some more exchanges for their own specific needs. All ISAKMP implementations must provide the Informational exchange and it is strongly recommended they'd implement the remaining four default exchange types as well.
This exchange is used primarily for establishing SAs. During the base exchange the initiator and responder cookies (nonces) shown in the ISAKMP header are generated. These mitigate Denial-of-Service attacks and prevent replay attacks against ISAKMP servers and services. When this exchange is successfully completed, one of the proposed protection suites (i.e. one proposed set of security services) has been selected, the necessary shared keys have been generated and the identities of the communicating parties verified. In other words, a new SA has been established.
In general, an exchange is made of a small number of individual ISAKMP messages sent between the ISAKMP servers. The Base exchange is a good example of this:
Figure 10 - The messages sent in a Base exchange.
The protection of the identities is achieved by separating the key exchange information from the authentication and identity information. In practise, the exchange starts with the generation of key material out of which both ISAKMP servers calculate the shared encryption key. When this key has been calculated, the exchange proceeds with sending the identities of the communicating parties to each other. The identities are encrypted with the shared key prior to sending. The end result is a new SA as in the base exchange.
It's worth noting that the aggressive exchange doesn't provide secrecy of the identities of the communicating parties because of the same reasons as the base exchange. Another point worth noting is that there can only be one proposal payload including only one transform payload, due to the restriction of one message, since the initiator would have to "guess" which proposal the recipient has chosen in case there were several proposals. This is of course impossible.
ISAKMP does allow the use of ordinary passwords for authentication, but the ISAKMP policy prefers certificates instead. In the absence of a certificate distribution mechanism, e.g. DNSSEC, ISAKMP can support the interchange of certificates with the help of the certificate payloads.
Even though public key cryptography ensures that the intended recipient is the only one able to decipher the contents of a message and in this case find out for example what the shared encryption key is, we still need the proof of the key really belonging to the one claiming it to be hers. This is where key certification and thus, certificate systems come into play.
Public encryption keys are certified by certificate authorities or trusted third parties as they also are called. The certification of a public key is done by the certificate authority by digitally signing it with the authority's own private key. When the signature of the new certified public key is later deciphered with the authority's public key, a proof of the certificate authority's signing is obtained.
There are many certificate standards available. Perhaps the most widely used X.509[6,7] and the emerging SPKI[8,9] are described briefly below.
5.1. Oakley
Oakley is a session key establishment protocol which can be applied
within the ISAKMP framework. These shared session keys are used for
symmetric encryption of the traffic between the communicating
parties. Oakley defines a set of key exchanges, which are called
"modes" in Oakley terminology[3]. These
provide services such as perfect forward secrecy, identity protection
and authentication[3].
Oakley uses the Diffie-Hellman algorithm for generating encryption key material between two communicating peers. The actual secret, shared key is calculated from this material. The benefit of this method is that even though the partial key material was intercepted by an attacker, the attacker cannot calculate the secret key. Digital signing of the public key with the secret key protects against man-in-the-middle attacks. The signing explicitly tells the communicating parties that the counterpart knows the secret key corresponding to the public key.
A complete description of Oakley can be found in the RFC 2412.
5.2. IKE
The Internet Key Exchange (IKE) is another key exchange
protocol. It provides for the negotiation of SAs and authenticated
keying material. IKE's functionality forms in practise a subset of
Oakley and SKEME[5].
IKE defines two methods for performing an authenticated key exchange: main mode and aggressive mode. These comply fully with the ISAKMP payload formats, attribute encoding etc and can be implemented with the default exchanges of ISAKMP. The main mode implements the Identity protection exchange of ISAKMP, while the aggressive mode implements the Aggressive exchange[5]. The modes have four different authentication variants: authentication with digital signatures, two variants of authentication with public key encryption - normal and revised - and authentication with a pre-shared key.
For more information on IKE, see the RFC 2409.
5.3. SPKI
The Simple Public Key Infrastructure (SPKI) is a standard
defining digital certificates and access control lists[8]. These are used to
associate names and authorisations with corresponding keys. These can
then be used to construct access control systems based on
certificates, i.e. on public key cryptography.
A SPKI certificate is a 5-tuple made of[8,10]:
Examples of above Authorisation tags are:
(tag (ftp nic.funet.fi matti))
stating that the Subject is allowed to access host nic.funet.fi as
user matti with FTP, and
(tag (http http://www.abcde.com/confidential))
stating that the Subject is allowed to access the web page behind
the URL.The complete description of SPKI is split into four individual documents[9]: the standard[8], the requirements[12], the theory[13] and the examples[10]. Info about the background motivations for SPKI can be found in the SPKI working group's document[11].
5.4. X.509
The ITU recommendation X.509 is a public key infrastructure framework
for authenticating entries in X.500 directory services[14]. Of today's
certificate systems, X.509 is one of the most widely used. The newest
version of X.509 is version 3[14,15].
An X.509 certificate is made of six fields[14,6]:
X.509 certificates are used in WWW browsers such as Netscape Navigator[15,6], the secure MIME encoding S/MIME, Privacy Enhanced Mail (PEM) and Secure Electronic Transaction (SET)[6] to name a few real life applications.
More information on X.509 can be found from the ITU WWW pages.
6. Conclusions
There was a clear need for a standard on how to apply security
services in public networks. ISAKMP meets those requirements well: it
allows heterogenuous systems to agree on security services, the
agreement procedure doesn't impose too much computational overhead and
its extensibility allows the adoption of enhanced and new security
services and protocols. All this should pave the way for a greater
diversification and interoperability of those services in public
networks that depend on reliable security mechanisms. Ad hoc or
dedicated security service implementations are likely to survive in
only the most time-critical applications and the ones in which only a
strictly limited set of security services are needed.
The flexibility of ISAKMP is clearly its greatest virtue. On the other hand, it may also be a drawback if the security service requirements are more complex, and subsequently requires dedicating substantial effort on defining a DOI and/or a key exchange. In most cases however, at least some of the default payloads and exchanges of ISAKMP can be used.
| [1] | Maughan D., Schertler M., Schneider M., Turner J. Internet Security Association and Key Management Protocol (ISAKMP), NSA, 1998 <ftp://nic.funet.fi/pub/doc/rfc/rfc2408.txt> |
| [2] | Piper D. The Internet IP Security Domain of Interpretation for ISAKMP, Network Alchemy, 1998 <ftp://nic.funet.fi/pub/doc/rfc/rfc2407.txt> |
| [3] | Orman H. The OAKLEY Key Determination Protocol, Univ. of Arizona, 1998 <ftp://nic.funet.fi/pub/doc/rfc/rfc2412.txt> |
| [4] | Cisco Systems. ISAKMP and Oakley Information, [ref. 26.1.1999] <http://www.cisco.com/public/library/isakmp.html> |
| [5] | Harkins D., Carrel D. The Internet Key Exchange (IKE), Cisco Systems, 1998 <ftp://nic.funet.fi/pub/doc/rfc/rfc2409.txt> |
| [6] | Brownell D., Prafullchandra H. Why should I care about X.509 certificates?, 1997 <http://www.neurospace.net/~phraktle/jdk12/security/cert3.html> |
| [7] | Anon. X.509, 1997 <http://webopedia.internet.com/TERM/X/X_509.html> |
| [8] | Ellison C. M., Frantz B., Lampson B., Rivest R., Thomas B. M., Ylönen T. Simple Public Key Certificate - draft-ietf-spki-cert-structure-05.txt, 13.3.1998 <http://www.clark.net/pub/cme/spki.txt> |
| [9] | Ellison C. SPKI Certificate Documentation, 9.4.1998 <http://ftp.clark.net/pub/cme/html/spki.html> |
| [10] | Ellison C. M., Frantz B., Lampson B., Rivest R., Thomas B. M., Ylönen T. SPKI Examples - draft-ietf-spki-cert-examples-01.txt, 10.3.1998 <http://ftp.clark.net/pub/cme/examples.txt> |
| [11] | Anon. SPKI Requirements, 26.2.1997 <http://www.clark.net/pub/cme/html/spki-reqts.html> |
| [12] | Ellison C. M. SPKI requirements - draft-ietf-spki-cert-req-02.txt, 24.10.1998 <http://ftp.clark.net/pub/cme/reqts.txt> |
| [13] | Ellison C. M., Frantz B., Lampson B., Rivest R., Thomas B. M., Ylönen T. SPKI Certificate Theory - draft-ietf-spki-cert-theory-04.txt, 17.11.1998 <http://ftp.clark.net/pub/cme/theory.txt> |
| [14] | Housley R., Ford W., Polk W., Solo D. Internet X.509 Public Key Infrastructure Certificate and CRL Profile, 1999 <ftp://nic.funet.fi/pub/doc/rfc/rfc2459.txt> |
| [15] | Anon. PKI Survey - X.509, 3.9.1997 <http://www1.xcert.com/~marcnarc//PKI/thesis/x509.html> |