The Fourth Puzzle Piece: The Internet Key Exchange (IKE)

No one can truly be called an entomologist, sir; the subject is too vast for any single human intelligence to grasp.

Oliver Wendell Holmes, The Poet at the Breakfast Table So far, we have not addressed the derivation of the symmetric keys used for IPsec encryption and authentication or the mechanism through which the communicating peers agree on the algorithms, key sizes, and other minutiae critical to the successful functioning of the IPsec SAs. Wizardry, extra-sensory perception, and carrier pigeons have their limitations, hence the need for IKE.

5.1 The IKE Two-Step Dance

The goal of any IKE [14] implementation is to negotiate an IPsec SA with a peer. That is accomplished through a two-phase negotiation: Phase 1 estab-lishes an Internet Security Association and Key Management Protocol (ISAKMP) SA [3], which is a secure channel through which the IPsec SA negotiation can take place. Phase 2 establishes the actual IPsec SA or, more precisely, a pair of one-way IPsec SAs: an inbound SA and an outbound SA.

The establishment of the ISAKMP SA can be accomplished through the completion of one of several different phase 1 exchanges, also referred to as modes: Main Mode, Aggressive Mode, or Base Mode. Each mode is defined as a series of messages, which consist of multiple payloads and head-ers. The only phase 2 exchange that has been defined is Quick Mode. In phase 1, each participant assumes a distinct role: The party that sends the first message is called the initiator, and the peer is called the responder. In phase 2 or subsequent negotiations, the roles can be reversed.

Several other exchanges have been defined that perform other IKE-related functions but that do not qualify as either phase 1 or phase 2 exchanges: New Groups Mode, Unacknowledged Notification exchanges, and Acknowledged Notification exchanges. We first describe the basic build-ing blocks and concepts underlybuild-ing IKE and then describe the function of each building block within the compound objects that make up IKE.

5.2 Payloads and Exchanges

Each IKE negotiation is made up of a predefined set of messages that must be exchanged by the peers; the building blocks that make up each message are called payloads. For each message, IKE specifies the mandatory payloads; in general, the ordering of the payloads within the message is not significant, with a few exceptions. In addition to the mandatory payloads, there are a number of optional payloads. In most of the messages, the mandatory pay-loads sent by the initiator, containing initiator-specific information, will be returned by the responder, containing responder-specific information.

Every IKE message is preceded by a standard header; each payload within the message begins with a generic payload header. The contents of those headers are discussed later in this chapter. First, let us address a number of issues and problems that need to be handled by any key negotiation appli-cation, IKEs approach to such matters, and the payloads that carry that information.

5.3 Authentication Methods

In an IKE negotiation, it is essential that each party prove its identity to its peer; this process is called peer authentication. If the peers identity is in doubt or conceivably could be falsified, then the whole SA negotiation process is worthless. Even if it results in an SA through which secure,

IPsec-protected traffic is exchanged, the entity receiving the protected traffic could be the very attacker from whom the traffic needs to be protected!

Three authentication methods are used in IKE: preshared secret key, digital signatures, and public key encryption. Each method hinges on the peers knowledge and use of some form of specialized information; the methods differ in the nature of the information, the way in which that information is obtained, and its use within the IKE negotiation.

Preshared secret key authentication relies on informationthe pre-shared secret keythat is known only to the parties to the negotiation. The method through which the information is exchanged is unspecified but lies outside the realm of the IKE negotiation itself. The exchange method must be secure, however, because knowledge of the preshared secret key is the sole proof of identity. The peers use that information to generate symmetric keys, which are used to encrypt and authenticate the IKE messages. The infor-mation is also used to generate additional keying material that, ultimately, will be used in conjunction with the IPsec SA. The successful encryption and decryption of the IKE messages serve as proof of possession of the preshared secret key. The termpreshared secret keycan be somewhat confusing, but it is a different entity entirely from the symmetric secret keys connected to the eventual IPsec SA.

The biggest drawback to preshared secret key authentication is the lack of a secure and scalable method of exchanging preshared secret keys. It is usable in a small-scale environment with a moderate number of systems in which the set of peers is known in advance. However, if a preshared secret key is compromised, there is no universal method of notifying the peer and establishing a replacement.

The other two authentication methods, digital signatures and public key encryption (introduced in Chapter 4), can potentially remedy that draw-back. These methods require each peer to possess a public-private key pair.

Each party uses its private key to sign or decrypt information; the other party uses the corresponding public key to verify or encrypt the information, thus authenticating the peers identity. If the public keys are retrievable from a secure repository (more on that in Chapter 10), keys can be readily accessed and updated. In addition, any peers whose keys reside on the same reposi-tory or who trust each others repositories (that, too, will be discussed in Chapter 10) can freely initiate IKE exchanges using these authentication methods with no prior special arrangement.

IKE peer authentication via public key encryption, as originally defined, requires each peer to perform two separate public key encryptions and decryptions. A revised mode of public key authentication was proposed

that replaces two of the public key operations performed by each party (one encryption and one decryption) with symmetric key operations, which are computationally less demanding. Why are both methods still part of IKE?

The answer lies in ancient IPsec history. Because the original public key authentication method was already in use in operational IPsec implementa-tions, it was retained but the revised method was also adopted.

The two public keybased authentication methods, digital signature and public key encryption, use different public key operations to assert and verify the peers identity. The first employs digital signature (with the peers private key) and verification (with the peers public key). The second uses public key encryption (with the peers public key) and decryption (with the peers private key). The content, order, and usage of the IKE payloads also dictate another difference. For digital signature authentication, the certifi-cates containing the peers public keys can be exchanged as part of the IKE negotiation. For public key authentication, the certificates must be obtained prior to the IKE exchange. That can be accomplished via retrieval from a public key infrastructure (PKI), as part of another IKE exchange, or by some other method. Until Chapter 10, a PKI will remain a murky creature that lurks somewhere on the Internet. For our purposes here, this chapter consid-ers a PKI to be an entity that can generate certificates, store them in a secure manner, and vouch for their authenticity and timeliness.

5.4 Proposals and Counterproposals

The concept of proposing and selecting the protection suites that constitute an SA is straightforward, but the IKE terminology is full of terms that are used in multiple contexts, some of which are counterintuitive. In both phase 1 and phase 2, the SAs potential characteristics are described in an SA pay-load. The SA payload is a multilayered payload that contains one or more proposal payloads, each of which contains one or more transform payloads.

Each transform payload defines the specific algorithms, negotiation mecha-nisms, and policy that characterize the SA; each entity contained within the transform payload is called anattribute. The totality of the SA payload sent by the initiator is a series of alternative combinations of the attributes to be negotiated. Each series of attributes collectively characterizes the operation and longevity of a particular proposed SA.

In phase 1, the initiator proposes one or more alternative collections of attributes. This takes the form of a single SA payload, containing a single proposal payload, which in turn contains one or more transform payloads.

Here is where the terminology confusion sets in. The proposal payload con-tains one or more proposals that define the different forms of ISAKMP SA that the initiator is willing to negotiate. However, each proposal is contained within a single transform payload. Figure 5.1 shows the attributes that might appear in a sample initiator proposal. Each row of the table constitutes a pro-posal. The responder selects one of the rows and sends that proposal back to the initiator. The responders SA payload will contain an SA payload, con-taining a single proposal payload, which contains a single transform payload, a copy of one of the transform payloads that was sent by the initiator. This is the method used by the responder to indicate which of the initiators propos-als is preferable; the chosen one then becomes the basis for the ISAKMP SA negotiated in phase 1. The phase 1 attributes that are open to negotiation are as follows.

• Encryption algorithm (and key length). The algorithm to be used to encrypt all IKE messages once the secret key is established. The mandatory-to-implement algorithm is DES_CBC. If an encryption algorithm with a variable length key (e.g., BLOWFISH) is selected, then the key length must also be negotiated.

• Hash algorithm. The keyed hash algorithm to be used in some of the IKE calculations; if no pseudo-random function (PRF) is negoti-ated, the HMAC form of the hash algorithm is also used to generate the key material and to authenticate all IKE messages once the secret key is established. The mandatory-to-implement hash algorithms are MD5 and SHA-1.

• Authentication method. The method through which the peers mutu-ally authenticate each others identity (preshared key, digital signa-tures, public key original mode, or public key revised mode). The mandatory-to-implement authentication method is preshared key.

Proposal

Figure 5.1 Sample phase 1 initiator proposal.

• Group description, type, prime, generator(s), curve(s), order, field size.

The values that define the specifics of the Diffie-Hellman exchange that will establish the shared secret used in the generation of the key material. The mandatory-to-implement group (group 1) is a modu-lar exponentiation (MODP) group with a generator of 2 and the following prime:

2⁷⁶⁸−2⁷⁰⁴−1+2⁶⁴∗[(2⁶³⁸p)+149686]

There are three other predefined groups: another MODP group (group 2) with a different prime and two elliptic curve groups (groups 3 and 4). The group-description attribute is used to specify which of the four groups will be used. It is recommended that implementations support group 2. In practice, that is the default group for most implementations.

It also is possible to negotiate groups with different defining characteristics. In that case, the group-type attribute is used to spec-ify whether the group is an MODP group or an elliptic curve group. The group-prime and group-generator attributes are used to define a new MODP group; the group-prime, group-generator, group-curve, group-order, and field-size attributes are used to define a new elliptic curve group.

• Life type, life duration. Attributes that specify whether the duration of the phase 1 SA will be measured in seconds or kilobytes and that give the numeric value of the SAs duration in the specified measure (seconds or kilobytes). There are no default values for life type and life duration. Life type can be specified as both seconds and kilo-bytes for a single SA, in which case the SA expires when either one of the lifetimes is reached. An SA that is authenticated through the use of a certificate should not last beyond the certificates expiration date or, possibly, beyond the time the next certificate revocation list (CRL) is issued.

• PRF. Keyed pseudo-random function used to generate the key material and to authenticate all IKE messages once the secret key is established. There is no mandatory-to-implement PRF and no pre-defined values for this attribute; unless the peers agree to a privately defined PRF, the default PRF is the HMAC version of the negoti-ated hash function.

In phase 2, the SA proposals can be more complex, because the initiator needs to be able to propose an SA bundle in situations where more than one SA (e.g., an AH SA and an ESP SA) is required to protect the same traffic.

An initiators phase 2 SA payload can contain one or more proposal pay-loads, each of which contains one or more transform payloads. When multi-ple proposal payloads are identified by the same proposal number, they represent a single SA bundle, which results in the negotiation of multiple IPsec SA pairs. When multiple proposal payloads are identified by different proposal numbers, they represent a series of alternative proposals for a single SA, which results in the negotiation of a single IPsec SA pair. If any proposal contains more than one transform payload, these always represent alterna-tives. The responder then selects one proposal (to negotiate a single pair of IPsec SAs) or one proposal group (to negotiate an SA bundle). Within each proposal, the responder selects the single transform payload that con-tains its preferred combination of attributes. The following phase 2 attributes are open to negotiation.

• Life type, life duration:Attributes that specify whether the duration of the phase 2 SA will be measured in seconds or kilobytes and the SAs duration in the specified measure (seconds or kilobytes). There are no default values for these attributes. Life type can be specified as both seconds and kilobytes for a single SA, in which case the SA expires when either one of the lifetimes is reached.

• Group description:A value that defines the specifics of the optional phase 2 Diffie-Hellman exchange that will establish the shared secret(s) used in the generation of the key material if perfect forward secrecy (PFS) of keys is desired. PFS is a guarantee that only one key has been generated from a single Diffie-Hellman exchange and that that key has no relationship to any other keys used between the peers. The predefined groups are the same as those used for phase 1.

It also is possible to negotiate groups with different defining charac-teristics. If a New Group Mode exchange previously has occurred between the peers, that newly defined group may be used.

• Encapsulation Mode. Describes whether the SA will be a Transport Mode SA or a Tunnel Mode SA.

• Authentication algorithm. The keyed hash algorithm to be used if the SA is to provide authentication. This is mandatory for an AH SA or an ESP SA whose encryption algorithm is ESP_NULL but optional for an ESP SA whose encryption algorithm is not ESP_NULL. The

mandatory-to-implement authentication algorithms are HMAC-MD5 and HMAC-SHA.

• Key length. An attribute that must be negotiated for an ESP SA whose encryption algorithm takes a variable length key (e.g., Blow-fish).

• Key rounds. For an ESP SA whose encryption algorithm key can be calculated with a variable number of rounds, the number of key rounds must be negotiated.

• Compress dictionary size. If the SA is to provide traffic compression, the maximum dictionary size must be negotiated.

• Compress private algorithm. If the SA is to provide traffic compres-sion, the compression algorithm must be negotiated.

Proposals are always sent as part of an SA payload. The SA payload generally is required to be the first message payload. Phase 2 messages always begin with an authenticating hash payload; in this case, the SA payload is the first payload following the hash payload.

5.5 Cookies

During the course of a phase 1 negotiation, the peers conduct a Diffie-Hellman exchange, resulting in the calculation of a shared secret (a totally different kind of beast from the similarly named preshared secret key), which is used to calculate shared symmetric keys. It is prudent to verify, prior to performing the Diffie-Hellman calculations, that the peer actually exists and is interested in conducting an IKE exchange. In some of the IKE exchanges, verification is accomplished through the exchange of cookies. Each peer generates a unique, possibly pseudo-random value and sends it to the other party. Once the cookie exchange has taken place, each party is assured that the other party exists and is willing to respond. The cookie pair (the initiator cookie and the responder cookie) incorporates part of the ISAKMP header attached to almost every message. The only exception is the first phase 1 mes-sage, which contains only the initiator cookie, since the responder cookie has not yet been received.

An effective denial-of-service attack is one in which the attacker spoofs a variety of source addresses and sends multiple IKE negotiation requests to the victim. If the victim were to begin churning away at Diffie-Hellman cal-culations in response to each such request, without any sort of verification of

the attackers existence and intentions, the victims system would quickly be swamped with those expensive calculations and unable to perform other, more useful work. The cookie calculations require less computational energy than the Diffie-Hellman calculations, preventing this type of denial-of-service attack. Of course, the responder still needs to exercise care, since a large enough number of cookie calculations also could overwhelm a system.

If the cookies contain a time-dependent value, they can be used to pre-vent replay attacks, in which the attacker attempts to resend messages from previously negotiated SAs.

The chief virtue of a cookie exchange is also its downside: the necessity to exchange two full messages prior to the Diffie-Hellman exchange. In IKE, that is mitigated in two ways. The two cookies, the initiators cookie and the responders cookie, are used as the identifying index of the phase 1 SA (analogous to the SPI of an IPsec SA), both during the SA negotiation and once the SA has been established. In addition, the messages that constitute the cookie exchange are used to negotiate the particulars of the SA itself.

5.6 The Security Association Payload The SA payload itself contains the following fields:

• Domain of interpretation(DOI). The content, format, and interpre-tation of several types of data (e.g., addresses) are dependent on the DOI for those data. Currently, the IPsec DOI is the only DOI other than the generic ISAKMP DOI that has been specified. A phase 1 SA whose DOI is generic ISAKMP can be used to negotiate phase 2 SAs for any other DOI; a phase 1 SA whose DOI is IPsec can be used only to negotiate phase 2 IPsec SAs. A phase 2 IPsec SA always

Dans le document Demystifying the IPsec Puzzle (Page 107-149)