ISAKMP

   

ISAKMP defines how two peers communicate, how the messages they use to communicate are constructed, and also defines the state transitions they go through to secure their communication. It provides the means to authenticate a peer, to exchange information for a key exchange, and to negotiate security services. It does not, however, define how a particular authenticated key exchange is done, nor does it define the attributes necessary for establishment of security associations. That is left to other documents, namely a key exchange document (such as the Internet Key Exchange) and a Domain of Interpretation (such as the Internet IP Security Domain of Interpretation).

Messages and Payloads

Messages exchanged in an ISAKMP-based key management protocol are constructed by chaining together ISAKMP payloads to an ISAKMP header (Figure 7.1).

Figure 7.1. The ISAKMP Header

graphics/07fig01.gif

The initiator cookie and responder cookie are created by each peer and are used, along with the message ID, to identify the state that defines an ISAKMP exchange in progress. The next payload field indicates which of the various ISAKMP payloads immediately follows the header. ISAKMP versions are identified by major/minor number in the major version and minor version fields. The specific type of ISAKMP exchange is identified by the exchange field. The entire length of the ISAKMP message, including the length of the header itself, is denoted in the message length field. The flags field gives the recipient additional information pertinent to the message. Flags are represented by a bit mask where each bit signifies the presence of an option. There are 3 flags defined (in an 8-bit field, which allows for growth): encryption, which signifies that the payloads following the header are encrypted; the commit flag, which signifies that a peer wishes a notification of exchange completion (more on this in the description of IKE); and the authentication-only bit, used primarily by those who wish to add key recovery to ISAKMP.

There are 13 distinct payloads defined in ISAKMP. They all begin with the same generic header, as shown in Figure 7.2.

Figure 7.2. The ISAKMP Generic Header

graphics/07fig02.gif

The type of ISAKMP payload that follows the current payload is denoted by the next payload field. The entire length of an ISAKMP payload, including the header, is denoted by the payload length field. The reserved field is not used and must be set to zero.

Some payloads are dependent on each other. For instance, a transform payload is always encapsulated by a proposal payload that in turn is always encapsulated by a security association payload. Several payloads also define attributes specific to their type. For instance, a certificate payload defines what sort of certificate it is an X.509 signature certificate, or a CRL, or a PKCS#7 wrapped certificate, etc.

ISAKMP defines payloads to express certain constructs during an exchange. Some of these are generic, like hash digests or pseudo-random nonces, or specific, like certificates or security associations. The generic payloads are all syntactically identical and differ only in what they contain. These include:

  • a hash payload, which contains the digest output of a particular hash function.

  • a signature payload, which contains a digital signature.

  • a nonce payload, which contains some pseudo-random information necessary for the exchange.

  • a vendor ID payload, which is, in effect, an opaque blob. Each vendor defines his own and is therefore able to identify his own implementations on the network.

  • a key exchange payload, which contains information necessary to perform a key exchange, for instance, a Diffie-Hellman public value.

Some payloads are syntactically different. The construct construct they represent are different enough to have a unique payload specification. These include:

  • a security association payload, which defines a security association both an ISAKMP SA and one for other security protocols like IPSec.

  • a certificate payload.

  • a certificate request payload.

  • an identification payload.

There are two other payloads that are dependent on and encapsulated by a security association payload and may not appear alone. These are the proposal payload, which describes a single proposal of a security association, and a transform payload, which describes a single transform for a proposal.

Each transform payload contains a set of attributes that apply to the transform. These attributes are quite flexible and therefore also quite complicated. An attribute is basically a type/value pair. Each attribute is identified by its type and that type has a value. For instance, an attribute of type "encryption algorithm" may have an attribute value of "CAST." (Of course these type/value pairs are not English words but are numbers whose values are assigned by IANA the Internet Assigned Number Authority). Attribute types are represented by simple 16-bit words while their values may be variable length or also a 16-bit word. The high-order bit of the type field denotes whether the attribute is a basic attribute whose value is a single 16-bit word, or a variable-precision integer, or VPI attribute, whose length is a single 16-bit word and whose value is contained in a variable length field. The remainder of the attribute type field is the actual numeric definition of the type. A basic attribute value immediately follows the attribute type, a VPI attribute value follows the length field. The attribute payload is shown in Figure 7.3.

Figure 7.3. The Attribute Payload

graphics/07fig03.gif

where the first bit is the attribute format, A/F, flag which signals whether the low-order two bytes of the four-byte payload is the value of the attribute (A/F = 1) or whether they are the length of the value that follows the four-byte payload (A/F = 0). If A/F equals 1 the entire attribute is four bytes; if A/F equals 0 the entire attribute is four bytes plus the length of the value. These variable length attributes are necessary to express values that may be too large to hold in a 16-bit word, like Diffie-Hellman exponentials.

Other payloads are defined to enable notification data, such as error conditions to be passed to a peer and delete messages to be passed instructing a peer to delete a specific security association. These payloads are the notify payload and the delete payload.

In addition, certain payloads define attributes that are specific to the payload. For instance, the certificate payload has a certificate type field that is used to specify what type of certificate is being conveyed in the payload.

The ISAKMP specification has a complete description of payload formats and payload-specific attributes.

Messages

Payloads are chained together in a message by using the next payload field in the generic header (see Figure 7.4). The ISAKMP header describes the first payload following the header, and each payload describes which payload comes next. The last payload in the message is zero. ISAKMP communication is done via UDP port 500. Other port/protocol combinations are possible, but UDP port 500 has been reserved by IANA for ISAKMP and all ISAKMP implementations are required to support communication over UDP port 500.

Figure 7.4. ISAKMP Payloads Chained to Form a Message

graphics/07fig04.gif

Exchanges and Phases

ISAKMP describes two separate phases of negotiation. In the first phase, peers establish an authenticated and secure channel between themselves. In the second phase that authenticated and secure channel is used to negotiate security services for a different protocol such as IPSec.

A phase one exchange establishes an ISAKMP "security association." The concept of this SA an abstraction of security policy and a key has some similarities to an IPSec SA but it is decidedly different. To establish this SA the peers must first negotiate the desired attributes for the SA, and a method to authenticate each other. After the peers have authenticated each other his SA is then used to protect subsequent phase two exchanges. There is no limit to the number of ISAKMP SAs two peers can share, but practically, one will do.

A phase two exchange establishes security associations for other protocols. Since the ISAKMP SA is already authenticated, it can be used to provide source authentication, integrity, and confidentiality to all messages in a phase two exchange. Once a phase two exchange finishes the state associated with it in the ISAKMP process it is destroyed but the ISAKMP SA can live on to secure subsequent phase two exchanges. There is no limit to the number of phase two exchanges, but one generally wants to limit the use of any secret derived from a single key exchange. This will be discussed further when we talk about IKE.

ISAKMP describes five exchanges. These exchanges are neither strictly phase one nor phase two exchanges, but are merely generic examples of how to use ISAKMP to negotiate a security association and perform an authenticated key exchange. These are not full exchanges in that the method of authentication is not described; authentication data is exchanged but the generation and processing of this data, the actual authentication step, is not described. Each exchange has slightly different goals and accomplishes them in differing numbers of steps. For instance, the identity protection exchange has the goal of hiding the identity of the peers from any eavesdroppers; it accomplishes this in six messages. The authentication only exchange is only concerned with authenticating the peers and not establishing a shared secret; it accomplishes this in three messages and does not include a key exchange.

Cookies

The first step of any exchange is an exchange of cookies. These are 8 byte pseudo-random numbers generated by each ISAKMP entity and assigned to each remote peer. Each cookie is unique to the remote peer and also to the particular exchange in which it is defined. The purpose of the cookies is to identify the ISAKMP SA and also to provide some anticlogging protection against certain denial of service attacks. While no method of cookie generation is proscribed in ISAKMP, the technique proposed by Karn and Simpson (in the Photuris key exchange) is the preferred method: The cookie is the result of hashing a unique identifier of the peer (e.g., his IP address and a port and protocol), a secret known only to the generator, and some timestamp. In this manner, each cookie is bound to the remote peer and it is trivial to check that the cookie presented by a peer is the one given to him. The cookies reside in the ISAKMP header.

To achieve the most anticlogging protection out of the cookies, an exchange will generally delay expensive and intensive operations such as exponentiation for a Diffie-Hellman exchange until cookies have been exchanged. In this way, some protection against rudimentary denial-of-service attacks is possible. For instance, an attacker who generates thousands of bogus ISAKMP messages with false return addresses would not cause his target to do any significant work because the second message that contains the cookie unique to the (bogus) address would not be received.

The cookie exchange takes place in the first two messages exchanged. The first message is from the initiator of the protocol to the responder. The initiator creates a cookie unique to the responder and the exchange he wishes to begin and inserts it into the initiator cookie portion of the ISAKMP header. Since this is the first message there is no responder cookie and that field is zero. After the message has been received and processed the responder generates a cookie for this exchange. To formulate a reply he copies this to the responder cookie portion of the header of his reply and copies the cookie provided by the initiator into the initiator cookie field of the header of his reply. The responder is able to create a larval ISAKMP security association identified by the cookies and send the message back to the initiator. Upon receipt of this response the initiator is able to update her larval SA with the responder's cookie and the exchange continues.

Obviously the initiator must create some state prior to sending out the first message. At a minimum, this state must contain the peer to which the message was sent and the cookie created for him. Since he sent out the message before he knew the responder's cookie, he must be prepared to identify this state based solely on his own cookie. After receiving the responder's first message, though, he's able to update that state to include the responder's cookie.

The responder also creates some state in the form of the larval ISAKMP SA. It does not do any significant work until it has received it's cookie back from the initiator and verified that that cookie is correct based on the peer's IP address.

After the cookie exchange the concatenation of the two cookies identifies the SA in the same manner in which an SPI identifies an IPSec SA. Since the cookies are passed as part of the ISAKMP header it is straightforward for an entity to look up the state associated with the message the ISAKMP SA upon receipt of the message. After a message is processed, the state of the ISAKMP SA is updated and a response, if required, is sent. In this manner, the exchange proceeds until the ISAKMP SA has been completed.

Policy Negotiation

Establishing a shared security association entails negotiation of security policy. Since policy may be complex (e.g., A and B or C), a flexible parsing of security association, proposal, and transform payloads must be allowed that in turn allows for the construction and processing of complex policy offers. ISAKMP accomplishes this with security association, proposal, and transform payloads (figure 7.5). A single security association may contain one or more proposals and each proposal may contain one or more transforms.

Figure 7.5. Security Association Payload, Proposal Payload, and Transform Payload

graphics/07fig05.gif

The DOI field of the security association payload defines the domain of interpretation to which the payload applies. A DOI value of zero is used for ISAKMP. Different DOI values are used for different security services. A separate DOI defines how ISAKMP is used to establish SAs for that particular service. The DOI for IPSec is described later in this chapter. The situation field of the SA payload contains information necessary to allow the recipient to make policy decisions during negotiation and is DOI-specific. Since multiple proposal payloads per SA payload are possible, the proposal payload contains a proposal number. Each proposal can result in a security association and therefore has an SPI, and an SPI size, and the protocol of the SA. Following a proposal payload is one or more transform payloads, and the proposal payload must therefore include a field to denote how many transform payloads follow. The transform payload contains a transform number and a transform identifier that indicates the type of transform. Following a transform are any attributes (encoded using the attribute payload) specific to that transform.

As mentioned, a single SA payload may contain multiple proposal payloads. The proposal number of the proposal payload is used to express the logical operators OR and AND. Matching proposal numbers are taken as a logical AND and differing proposal numbers are taken as a logical OR. For instance, if IPSec policy requires AH and ESP, the proposal payloads for each separate proposal one for each protocol would have identical proposal numbers. If IPSec policy required AH or ESP, the proposal payloads for each separate proposal one for each protocol would be different. In this manner it is possible to construct quite complex offers. If we include the IP payload compression protocol (more on that in section 11) in our policy, it is possible to express things such as: "authenticate everything and if possible also encrypt it, and if possible also compress it." Since order of preference in offers counts, this would be expressed as "[AH-1 or ESP-2 or (ESP-3 and PCP-3)]" where protocol-n is a proposal for protocol with proposal number n.

Each proposal may be, in fact, an offer of multiple transforms. Each of these transforms are a different way of accepting the proposal and each transform is the logical OR of the others. Continuing with our complex policy expression, we could add multiple transforms per proposal and desire 3DES over AES and SHA over MD5 and LZS over Deflate (for PCP) and our offer would be:

Proposal 1: AH

Transform 1: HMAC-SHA

Transform 2: HMAC-MD5

Proposal 2: ESP

Transform 1: 3DES with HMAC-SHA

Transform 2: 3DES with HMAC-MD5

Transform 3: AES with HMAC-SHA

Transform 4: AES with HMAC-MD5

Proposal 3: ESP

Transform 1: 3DES with HMAC-SHA

Transform 2: 3DES with HMAC-MD5

Transform 3: AES with HMAC-SHA

Transform 4: AES with HMAC-MD5

Proposal 3: PCP

Transform 1: LZS

Transform 2: Deflate

What we're offering here is ((AH-HMAC-SHA OR AH-HMAC-MD5) OR (3DES w/HMAC-SHA OR 3DES w/HMAC-MD5 OR AES w/HMAC-SHA OR AES w/HMAC-MD5) OR [(3DES w/HMAC-SHA OR 3DES w/HMAC-MD5 OR AES w/HMAC-SHA OR AES w/HMAC-MD5) AND (PCP-LZS OR PCP-DEFLATE)]). That's quite a complex offer!

Security association payload construction and parsing are complex because security policy is complex. Thankfully, other payloads are not so complicated.


   
Top


IPSec(c) The New Security Standard for the Internet, Intranets, and Virtual Private Networks
IPSec (2nd Edition)
ISBN: 013046189X
EAN: 2147483647
Year: 2004
Pages: 76

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net