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

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

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:

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

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

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.

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

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.

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.

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

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:

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.

The two phase one exchanges—main mode and aggressive mode—each accomplish the same thing: establishment of a secure and authenticated communications channel (the IKE SA) and authenticated keys used to provide confidentiality, message integrity, and message source authentication to the IKE communications between the two peers. All the other exchanges defined in IKE have an authenticated IKE SA as a prerequisite. Therefore a phase one exchange, either main mode or aggressive mode, must be performed before any other exchange.

The IKE SA has various parameters that define how it was created and authenticated and how it is to protect phase 2 exchanges. For all these negotiated parameters, IKE defines attributes and the range of values that these attributes may have.

The parameters—encryption algorithm, hash algorithm, authentication method, and Diffie-Hellman group—are referred to as a protection suite. Protection suites are negotiated as a unit by exchanging ISAKMP SA payloads. Each of the attributes of the protection suite are contained in transform payloads. In addition to those mandatory attributes there are also optional attributes that may be negotiated as part of a protection suite. Foremost among these optional attributes is a lifetime. The lifetime attribute determines how long the IKE SA exists. The longer an IKE SA exists, the greater the risk of leakage of its key, so an implementation is encouraged to include lifetimes in the protection suites offered to peers.

A hash algorithm is negotiated as part of a protection suite, but its use is usually in HMAC form. IKE uses an HMAC version of the hash algorithm as a pseudo-random function (PRF) to generate a seemingly random bitstream. It is possible to negotiate other PRF functions with IKE, but usually an HMAC version of the negotiated hash algorithm is used.

The encryption algorithm and hash algorithm attributes are straightforward. They determine which algorithm will be used for message encryption and authentication. But what about the rest?

The Diffie-Hellman group is a basic attribute that determines the parameters to use when the peers engage in a Diffie-Hellman exchange. You're probably wondering how a single basic attribute can express the required parameters to perform a Diffie-Hellman exchange. This is because IKE defines five groups and assigns unique values to them. Therefore, when a peer refers to “group number 2" the other peer knows the generator and prime modulus of the group implicitly and the two can participate in a Diffie-Hellman exchange. There are three types of Diffie-Hellman groups that can be expressed in IKE—traditional exponentiation over a prime modulus (MODP), and two types of elliptic curves, one over G[P] (ECP) and another over G[2^N] (EC2N). The groups IKE defines are:

More groups can be easily defined and using the New Group Exchange two peers can define their own. Only group two is mandatory to implement. It is generally felt that groups 1 and 3 provide roughly similar amounts of security to an exchange, one using a prime modulus and the other an elliptic curve. Similarly, groups 2 and 4 also provide roughly similar amounts of security. The difference between the two is the speed considerations that can be realized by using elliptic curve cryptography (groups 3 and 4) over traditional exponentiation in a finite field (groups 1 and 2). Currently there is no Elliptic Curve analog to group 5.

The attribute with the most impact on the IKE exchange is the authentication method. The other attributes will determine the contents of payloads and how messages are protected, but the authentication method determines which payloads are exchanged and when they are exchanged. An IKE exchange may actually change depending on the authentication method negotiated by the two peers! The acceptable methods of authentication are: (1) preshared keys; (2) digital signatures using the Digital Signature Algorithm; (3) digital signatures using the Rivest-Shamir-Adelman algorithm; and (4) two similar methods of authenticating via exchange of encrypted nonces.

These attributes are negotiated between the peers as part of the first messages they exchange. These are the external and visible characteristics of the IKE SA—their negotiation takes place “in the clear”. But each side also maintains some secret information that will not be visible to a casual observer (or an active attacker!) of an IKE exchange. This secret information is the keys that are authenticated used to protect IKE messages and also derive keys for other security services. The peers generate a secret, SKEYID, and then three other secrets based on SKEYID: SKEYID_d, which is used to derive keying material for IPSec (and others) SAs, SKEYID_a, which is used to provide data integrity and data source authentication to IKE messages; and, SKEYID_e which is used to encrypt IKE messages. The generation of SKEYID is dependent on the authentication method negotiated. All other SKEYID-based secrets are generated identically, regardless of authentication method.

Each side contributes a cookie and a nonce to SKEYID state generation: The initiator contributes his cookie, CKY-I, and his nonce, Ni; similarly, the responder contributes CKY-R and Nr. These are used as a “liveliness” proof: Each side demonstrates to the other that it possesses the other's nonce and cookie and is therefore “live” and not “Memorex.” They also provide some additional freshness to each secret. As a result of the Diffie-Hellman exchange the peers share the Diffie-Hellman shared secret, g^xy, which is also used in SKEYID generation. Using '|' to denote concatenation, SKEYID state is generated as follows:

where PRF, the aforementioned pseudo-random function, usually the HMAC-version of the negotiated hash function. Once SKEYID has been generated the remainder of the secrets can be generated:

Note that all SKEYID state is generated by PRF functions. The block size of the PRF function will therefore determine the resulting size of the SKEYID state. For cases where the output of the PRF is too small to be used as an encryption key, SKEYID_e must be expanded. For example, a PRF of HMAC-MD5 will produce 128-bits of output but the Blowfish cipher can require 448 bits of keying material. In this case, SKEYID_e is expanded by using a feedback and concatenation technique until the requisite number of bits has been achieved. Using our MD5 and Blowfish example, SKEYID_e would be the first (high-order) 448 bits of K, where:

Phase one exchanges are authenticated by each side computing a hash that only they could know. Since it is impossible to determine the inputs to a hash function from the output of the hash function, and the same inputs will always produce the same output, the production of the appropriate digest authenticates the peer. The computation of the hash is identical regardless of the authentication method negotiated, but the initiator and responder compute their respective digests differently. The initiator's authenticating hash is:

The responder's authenticating hash is:

Where gⁱ and g^r are the Diffie-Hellman public numbers of the initiator and responder, respectively, SA-offer is the entire SA payload with all protection suites offered by the initiator to the responder, and ID-I and ID-R are the identities of the initiator and responder respectively.

Inclusion of the entire SA payload is important to prevent a man-in-the-middle attack where an attacker could modify the protections suites offered down to their lowest or weakest protection suite. For instance, if both peers would prefer to use Triple-DES as the encryption algorithm but would reluctantly settle for DES, an attacker could modify a request of “Triple-DES or DES” to merely “DES.” The responder would reluctantly accept it and neither party would be aware that they could have been communicating more securely. By including the entire offered SA payload in the authenticating hash, such an attack is prevented.

The IKE SA differs from an IPSec SA in that it is bidirectional. There are specific roles assumed by the participants of an exchange. Specifically, one party is the initiator and the other is the responder, but once the SA has been established it may be used to protect both inbound and outbound traffic. Also, regardless of who initiated the phase one exchange that established the IKE SA, either party may initiate a phase two exchange and protect it with the IKE SA. The cookies in the ISAKMP header are not swapped if the responder in phase one becomes the initiator in phase two since the cookie pair is used to identify the appropriate SA in the IKE SADB.

In the following exchange diagrams, payloads encrypted using SKEYID_e as the key are italicized. All ciphers used in IKE must be in CBC mode and therefore require, in addition to a key, an initialization vector (IV). The initial IV is generated by hashing the two Diffie-Hellman public values together, and after each successive encryption and decryption the IV becomes the last ciphertext block processed. In this way the IV chains cipher operations together and “runs” from block to block.

Main mode uses six messages, in three round trips, to establish the IKE SA. These three steps are SA negotiation, a Diffie-Hellman exchange and an exchange of nonces, and the authentication of the peer. The features of main mode are identity protection and the full use of the ISAKMP's negotiation capabilities. Identity protection is important when the peers wish to hide their identities. The breadth of negotiation capabilities will become apparent when we discuss aggressive mode. As mentioned, the authentication method can influence the composition of payloads and even their placement in messages, but the intent and purpose of the messages—the steps taken in Main Mode—remain regardless.

When used with preshared key authentication, main mode is the exchange of messages shown in Figure 7.6.

In the first exchange of messages the peers negotiate the parameters of the IKE SA and agree on what the rest of the exchange will look like. They also exchange cookies in the ISAKMP header of each message—the initiator chooses his in his first message, placing it in the initiator cookie portion of the ISAKMP header, the responder chooses his in the second message, placing it in the responder cookie portion of the ISAKMP header. In the second exchange of messages the peers exchange Diffie-Hellman public values (computed in the group negotiated as part of a protection suite in the first message exchange) and pseudo-random nonces. At this point the peers can complete their Diffie-Hellman exchange and generate the SKEYID secrets. In the last message exchange the peers identify themselves and exchange the authenticating hash digest. The final two messages exchanged are encrypted with SKEYID_e.

An observant reader will notice that since SKEYID_e must be used before the ID payloads are exchanged, a preshared key can be based only on the IP address of the peer. This is an acknowledged limitation of preshared keys with Main Mode. For most situations this is not an issue, but for remote-access environments where the initiator of the protocol is coming from an IP address that cannot be known a priori there is a problem. The responder cannot maintain preshared keys for addresses that it does not know. An easy way out of this problem is for remote-access environments to use a public key signature-based authentication method and not use preshared keys. If preshared keys must be used, aggressive mode can be used as a phase one exchange since it does not have this limitation. More on aggressive mode later.

Main mode can also be authenticated with public key signatures, either DSS or RSA. Public keys are usually obtained from certificates and IKE allows for certificates to be exchanged and also for certificates to be requested from a peer. Using public key signatures, main mode is the exchange of messages shown in Figure 7.7.

where optional payloads are bracketed. Notice the similarity to main mode with preshared keys. Excluding the optional payloads, the one difference is that the authentication is accomplished by a digital signature and not a hash digest. The optional payloads allow for certificates to be requested—the Cert_Req payload—and be exchanged—the Cert payload.

There are two types of authentication methods that use an exchange of encrypted nonces—a standard public key encryption method, and a revised method of public key encryption. The revised method arose because of a criticism against the standard method, that it requires two separate, and expensive, public key encryptions. The revised mode only requires a single public key encryption and encrypts the other payloads with a symmetric cipher. During development of the IPSec and IKE standards there was discussion of removing the standard mode, but since several implementations of it were already in existence another method was added.

Both of these methods have the feature of being repudiable. That is, each side could deny that they were a party to the exchange even if all the messages and state associated with the IKE session are saved. If you've ever done something you don't want anyone to know about, these are the exchanges you should've used to establish your IPSec SAs! The proof of authentication is ability of the peer to decrypt the key and reconstruct the authenticating digest is proof that the peer holds the corresponding private key—after all, he was able to decrypt the nonce—and therefore is proof of identity. The reason these are deniable is because the nonces exchanged in main mode are encrypted in the peer's public key—the initiator's nonce is encrypted with the responder's public key and vice versa. Since anyone can encrypt anything in your public key and since both sides know the entire contents of each side of the exchange, the entire exchange can be faked! Of course, when two parties are actively engaged in one of these exchanges, they have proof of identity via the ability of the peer to compute the right digest, but either party could deny the exchange to a third party at a later date.

Since both these methods use public key encryption it is not possible to use DSS with them. The most common manner of implementing these methods is to use RSA public keys that provide for a way to encrypt with a public key. The El-Gamal variant of the Diffie-Hellman public key cryptosystem is also a viable possibility for use with these methods.

The standard method of public key encryption is the exchange of messages shown in Figure 7.8.

where {}pub_x is used to denote encryption with the public key of “x.” Notice that in this exchange the ID payloads are exchanged with the second message. This is because the initiator has to give the responder some indication of his identity so the responder can properly locate his public key and encrypt the response to him. The ID protection feature of main mode is ensured by each peer also encrypting his identity with the public key of the peer.

Two public key encryptions are a drawback of this method. Another is that it does not allow for certificates to be requested or exchanged. To exchange a certificate would be to lose the identity protection of main mode. The initiator must know the identity of the responder prior to initiation of this exchange. This is generally not an issue since the initiator knows where he wants to go on the network and knows to whom he must talk to get there. Since there is no way to pass a certificate in this authentication method each side must support some other method of obtaining certificates.

You're probably asking, why not just encrypt the two payloads together? If both payloads were encrypted together the header of the nonce payload would be hidden. To properly parse the message then, the payload length of the ID payload would have to include the encrypted nonce payload. Such behavior would have a detrimental impact on the receiver of such a packet. A sanity check on the received message would be precluded since there would be no way to check the nonce payload's generic header for correctness. Also, the true length of the ID payload could not be determined. The receiver would have to guess where the ID stops and the generic header of the nonce begins! So, two public key encryptions are required.

As mentioned, the revised method of public key encryption does not have the drawbacks of the standard method. It requires half the public key operations and also provides for a capability for the initiator to provide a certificate to the responder. The initiator must still use some means outside of IKE to obtain the certificate of the responder, though. The revised method of authentication with public key encryption is the exchange of messages shown in Figure 7.9.

where {}ke_x indicates symmetric key encryption with the key “Ne_x.” Now you're probably asking: Where does the key for the symmetric cipher come from and which algorithm do you use? Well, the algorithm is the same as that used fo rthe IKE SA, the one negotiated in the exchange of SA payloads. The keys are generated as follows:

So, upon decryption of the nonce, it is possible to compute the appropriate symmetric key and decrypt the remainder of the payloads.

The purpose of an aggressive mode exchange is the same as a main mode exchange—the establishment of an authenticated security association, and keys, which IKE can then use to establish security associations for other security protocols. The major difference is that aggressive mode takes half the number of messages as main mode. By limiting the number of messages, aggressive mode also limits its negotiating power and also does not provide identity protection.

In an aggressive mode exchange, the initiator offers a list of protection suites, his Diffie-Hellman public value, his nonce, and his identity, all in the first message. The responder replies with a selected protection suite, his Diffie-Hellman public value, his nonce, his identity, and an authentication payload—for preshared key and encrypted nonce authentication this would be a hash payload, for signature-based authentication it would be a signature payload. The initiator sends his authentication payload as the final message.

The rich negotiation capabilities of IKE are constrained in aggressive mode. This is because the initiator must provide his Diffie-Hellman public value and his nonce in the first message. Obviously, he cannot therefore offer different Diffie-Hellman groups in different protection suites. Also, if he desires to offer authentication based on encrypted nonces this must be his only offer, since the nonce must be encrypted for such an exchange. In addition, if he wishes to do authentication using the revised method of encrypted nonces he cannot offer multiple protection suites with differing encryption or hash algorithm options.

Aggressive mode is decidedly limited! So what use is it then? For remote access situations where the address of the initiator cannot be known by the responder a priori, and both parties desire to use preshared key authentication, this is the only exchange possible to establish the IKE SA. Also, for situations where the initiator knows the policy of the responder, or has a very good idea what that policy is, they may use this exchange to create the IKE SA more quickly. If an employee wishes to remotely access the corporate resources of his company he will most likely know the policies under which access is granted—for example, encryption with AES, hashing with SHA, authentication with RSA signatures using certificates signed by the corporate Certification Authority—and, therefore, the full power of IKE negotiation is not necessary.

Once an IKE SA is established, via a Main Mode or Aggressive Mode exchange, it can be used to generate SAs for other security protocols such as IPSec. These SAs are established via a Quick Mode exchange. A Quick Mode exchange is done under the protection of a previously established IKE SA. Many Quick Modes can be done with a single Main Mode or Aggressive Mode exchange. In fact, simultaneous Quick Modes can be performed under the protection of a single IKE SA!

In a Quick Mode exchange the two peers negotiate the characteristics of, and generate keys for, an IPSec security association. The IKE SA protects a Quick Mode exchange by encrypting it and authenticating the messages. The messages are authenticated via the PRF function, most likely the HMAC version of the negotiated hash function. The SKEYID_a value from the IKE SA state is used as a key to authenticate the entire message of a Quick Mode exchange. This authentication provides data integrity protection as well as data source authentication: Upon receipt we'll know that the message could only have come from our authenticated peer and that the message did not change in transit. Encryption, using SKEYID_e, provides confidentiality to the exchange.

Since multiple Quick Mode exchanges can be performed simultaneously there must be some way to multiplex the IKE messages and determine which message refers to which exchange. The message ID of the ISAKMP header is used for this purpose. Each Quick Mode exchange has a unique message ID which is used with the cookies in the ISAKMP header, to identify the state to which a particular message refers. Also, since all the Quick Mode messages are protected by the same IKE SA, there must be some way to coordinate the initialization vector (IV) for encryption and decryption to prevent two IKE peers from getting out of sync and not being able to decrypt messages the other party encrypted. The message ID is used for this purpose too. Each Quick Mode exchange begins with a unique IV that is derived from the IV from the finished phase one exchange and the message ID of the phase two exchange. The IV for a particular Quick Mode is a running IV similar to that from the phase one exchanges. The initial IV is derived from a deterministic algorithm and subsequent IVs are defined to be the last ciphertext block from the last message. When a Quick Mode exchange is finished, and IPSec SAs have been created, the state—the running IV, the nonces, the Diffie-Hellman values—that was created to handle this exchange can be deleted. Obviously the state created for the IKE SA is not deleted because it is used to protect subsequent Quick Mode messages.

Quick Mode derives the keys used for the IPSec SAs from its SKEYID_d state. That key is used in the pseudo-random function (same one from phase one) with the nonces passed in the exchange and the protocol and SPI from the IPSec SA offers. This guarantees unique keys for each SA: the inbound SA will have a different SPI and therefore a different key than the outbound SA. All IPSec keys are derived from the same source and are therefore all related. If an attacker was able to determine SKEYID_d from the IKE SA he would have an easy time determining all the keys of all the IPSec SAs derived from that SKEYID_d, and all the keys that are derived in the future too! This is a problem. None of the keys have what is referred to as “perfect forward secrecy,” or PFS. Quick Mode has a PFS option to satisfy these concerns.

To provide PFS to a Quick Mode exchange an additional Diffie-Hellman exchange is performed and the resulting shared secret is used in generation of keys for IPSec. Obviously that secret is not retained once the exchange is finished. The memory in which it resides must be zeroed and freed immediately upon completion. Negotiation of the Diffie-Hellman group is not possible in a Quick Mode exchange for the same reason as in an aggressive mode exchange. The initiator must offer his Diffie-Hellman public value derived from the group he is offering. If he offered multiple groups, the responder would have a difficult time correlating public values to SA offers.

In addition to the SA offer(s), the nonce, and the optional Diffie-Hellman public value (if PFS is desired), identity information can also be exchanged by both parties. Both parties have already determined and authenticated each other's identity as part of the phase one exchange, so what are these additional identities for? They're used to exchange selector information that describes the purposes of the SA payloads being established. The IPSec DOI defines identity types and port and protocol fields of the ISAKMP ID payload. Since the DOI deals with phase two exchanges, and, specifically, how to establish SAs for IPSec, these definitions come into effect.

These identities can be a simple address, a range of addresses, or a subnet. Recall in our discussion of IPSec that valid policy could be “all telnet traffic to network 132.239.4.0/255.255.255.0” or “all Web traffic to 132.239.4.24.” Using ID payloads in Quick Mode, it is possible to express this policy to the IKE peer. Selector information, in the form of ID payloads, is sent by the initiator of the Quick Mode along with SA offers to the responder. This selector information refers to all SAs negotiated in the single Quick Mode exchange. The responder can use this information to check his own policy and decide whether the initiator is allowed to establish SAs for this purpose. If this policy check passes, the selector information derived from the ID payloads must be provided to the IPSec SADB along with the specifics of the SA. This information constrains the IPSec SA. The SA can only be used for traffic identified by the ID payloads. If the phase 2 identities indicated that negotiation was for telnet to a particular host, the resulting SAs could not be used for any other traffic. Passing the selector information, derived from the phase 2 identities, to the SADB allows the IPSec processing to determine whether the traffic protected by the particular IPSec SA is allowed. Recall the discussion of AH input processing and ESP input processing.

We've described Quick Mode as a simple request/response exchange, but there is more to it than that. The initiator needs a liveness proof that the responder is on-line and has actually processed his initial Quick Mode message. To accomplish this the responder includes the initiator's nonce and the message ID of the exchange in the authenticating hash payload. This digest now not only provides message integrity and source authentication to the initiator, it also provides a liveness proof.

The responder also needs a liveness proof. The message from the initiator could have been an old message replayed by an adversary. The adversary might not have known the contents of the message but he would know through traffic analysis that it was a Quick Mode message. Replaying that message would result in the unnecessary creation of SAs by the responder. This would be considered a denial of service attack, albeit a mild one, because of the memory and SA management overhead that the responder would unnecessarily expend on this message. To prevent such an attack a third message is added to the Quick Mode exchange. In it the initiator includes both nonces and the exchange's message ID in an authenticating hash payload, proving to the responder that he is a real live and active participant in the exchange. At this point the responder may add the SAs to his IPSec SADB as shown in Figure 7.10.

Where:

HASH1 = PRF(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ] )

HASH2 = PRF(SKEYID_a, M-ID | Ni | SA | Nr [ | KE ] [ | IDci | IDcr ] )

HASH3 = PRF(SKEYID_a, 0 | M-ID | Ni | Nr )

Notice how the initiator has all the information necessary to add his IPSec SAs to his SADB before the responder does. After receiving the responder's only message he knows what the responder chose from his offer; if the exchange had PFS he has the responder's Diffie-Hellman public value, and he has a liveness proof. But the responder must wait until he receives the initiator's final message before he's ready. Because of this, the initiator may begin sending IPSec-protected packets prior to the receipt of his final message. In fact, due to network latencies or processor priorities—the initiator may choose to give IPSec processing a higher priority to IKE processing—the IPSec packets may even arrive at the responder before the final IKE message does! If this happens the responder will drop all the IPSec packets until it is able to process the final IKE message.

Depending on the traffic, this may or may not be a problem. If the traffic is a TCP-based protocol these initial messages would, most likely, be the TCP syn packets and they'll be retransmitted until they're acknowledged. For UDP-based protocols these packets could be irretrievably lost. To prevent this from occurring, IKE uses the commit bit from the ISAKMP header to extend a Quick Mode exchange by one message. Either party can set the commit bit and if one does, the responder must send a final message consisting of an authenticating hash payload followed by a notify payload containing a “connected” message. In this case, the initiator does not add the SAs to his SADB until he receives the “connected” message. This will allow the responder to add his SAs first and be ready when the first IPSec packets begin to flow.

As mentioned earlier, the IKE SA is bidirectional. Either party may initiate a Quick Mode exchange regardless of who initiated the main mode or aggressive mode exchange. When this happens, the roles for phase 2 reverse but the role-specific information from phase 1 does not. The initiator cookie and responder cookie in that order continue to identify the IKE SA used to protect the phase 2 SAs regardless of the role being played in phase 2.

All of the exchanges in IKE described so far have been for the creation of SAs—the phase one exchanges create the IKE SA and the phase two exchange creates IPSec SAs. IKE defines two other exchanges that provide for maintenance of the IKE SA and for negotiation of private Diffie-Hellman groups.

The IKE informational exchange allows IKE peers to send status and error messages to each other. This is not an exchange per se, but just a single message that is not acknowledged nor, due to the UDP-based nature of IKE, guaranteed to arrive. Because of the unreliability of informational exchange messages, they are not mandatory to send. Implementers are strongly encouraged to be “good citizens” and use them, but they should not design their code to expect them. The most common use of the informational exchange is to tell a peer that a particular SA, either the IKE SA or an IPSec SA, has been deleted and to refrain from using it.

Informational exchanges are similar to Quick Mode messages in that they all have a unique message ID and generate a unique IV to use for encrypting the message. They are also authenticated with a hash payload, which is the result of the keyed PRF function taking SKEYID_a as the key and a concatenation of the message ID and the entire notify or delete payload. Since this is a single, unacknowledged message the state associated with this exchange can be freed after sending the message.

Another exchange IKE defines is a new group exchange. IKE defines five Diffie-Hellman groups that peers can use, three groups using exponentiation over a prime modulus, and two groups using elliptic curves. The new group exchange allows peers to negotiate private groups for their use and define a group identifier that they can subsequently use in a later exchange to identify the group. This exchange must be protected by the IKE SA due to the sensitive nature of the data being exchanged. Therefore, a new group exchange, while not strictly being a phase two exchange, must follow a phase one exchange and must be protected by the IKE SA. Similar to a Quick Mode and informational exchange, the protection takes the form of encryption using SKEYID_e and an authenticating hash function keyed with SKEYID_a.

The new group exchange is a request-response exchange in which the initiator sends an SA payload that contains the characteristics of the group being proposed and an identifier out of the range of numbers reserved for private use. For instance, to propose a new group that uses exponentiation over a prime modulus, the initiator would send the prime number and the generator. If this group is acceptable to the responder it responds with an identical response. It is strongly recommended that the responder test the group for strength and not blindly accept any offer. For instance, in an offer of a group using exponentiation over a prime modulus, the modulus offered should be checked for primality. If it is not prime, the offer should be refused.