14.5 KEY MANAGEMENT PROTOCOLS

Team-Fly

The IP security architecture mandates support for both manual and automated SA and key management (using a key management protocol, such as IKE). For several years, the IETF IPSEC WG had been struggling with competing proposals for an automated SA and key management protocol:

IBM proposed a Modular Key Management Protocol (MKMP) for its IP Secure Tunnel Protocol (IPST) [28].
Sun Microsystems proposed and is using its Simple Key-Management for Internet Protocols (SKIP) [29].
Phil Karn from Qualcomm originally proposed and prototyped a Photuris Key Management Protocol^[11] [30, 31] that is conceptually similar to the Station-to-Station (STS) protocol originally proposed in [32]. The Photuris protocol combines an ephemeral Diffie-Hellman key exchange with a subsequent authentication step to protect against man-in-the-middle attacks. To protect the participanting peers against resource clogging attacks, the Photuris protocol introduced a cookie exchange [33].
Hugo Krawczyk from IBM proposed a variation and generalization of the Photuris protocol, called Photuris Plus or SKEME [34].
Because of the fact that Bill Simpson (one of the coauthors of the latest Photuris Key Management Protocol specification) refused to make changes to protocol specification in accordance to suggestions provided by the IETF IPSEC WG chairs, the Photuris Key Management Protocol was dropped from consideration and Hilaire Orman from the University of Arizona drafted a version of the Photuris and SKEME protocols that was called OAKLEY Key Determination Protocol [35]. In this protocol, several parameters are negotiable, including, for example, the mathematical structure in which the Diffie-Hellman key exchange is supposed to take place and the authentication method that is being used.
A group of researchers from the NSA Office of INFOSEC Computer Science proposed a general Internet Security Association and Key Management Protocol (ISAKMP).

The protocol proposals and their tradeoffs are overviewed and fully discussed in the first edition of this book. In the first half of the 1990s, the developers of the various key management protocols competed with one another within the IETF IPSEC WG. There were basically two groups: SKIP and the group of Photuris-like protocols, including, for example, the OAKLEY Key Determination Protocol. Also, because of the fact that SKIP does not make use of SAs at all, the ISAKMP is useful only for the second group of protocols. Consequently, the two major contenders were SKIP and ISAKMP/OAKLEY.

In September 1996, the IETF Security Area Director^[12] posted a document to the Internet to end the controversy. In this document, the two contenders (i.e., SKIP and ISAKMP/OAKLEY) were reviewed, and it was concluded that ISAKMP/OAKLEY should be the way to go and become the mandatory standard. The following three major arguments were used to explain this decision:

ISAKMP/OAKLEY provides perfect forward secrecy (PFS),^[13] whereas SKIP—at least in its native form—is not able to provide PFS.
Given an arbitrarily chosen pair of hosts, it is likelier that ISAKMP/OAKLEY results in a working SA than in SKIP.
The ISAKMP/OAKLEY approach seems to more closely follow the goals defined in the charter of the key management part of the IETF IPSEC WG.

This line of arguments is not very convincing. As explained later, SKIP can easily be modified to provide PFS. Also, SKIP is not good in establishing SAs because it does not use SAs at all. Finally, the third argument looks a bit arbitrary and is not well justified.

There are, however, good reasons to use ISAKMP/OAKLEY instead of SKIP. For example, SKIP does not rely on SAs, and as such, it incurs greater per-packet overhead. This is potentially advantageous for purely connectionless applications (because it avoids the need to create a session for a short-lived communication), but it is a serious disadvantage for connection-oriented applications. The vast majority of Internet applications are still connection-oriented, which favors the ISAKMP/OAKLEY-style approach. Also, over time we have added a number of parameters to the SA establishment procedure, which would also not have been possible using SKIP.

In either case, moving ISAKMP/OAKLEY forward on the Internet standards track was an important step (because it finished the struggle between the promoters of SKIP and the promoters of ISAKMP/OAKLEY). Finally, it was agreed that ISAKMP/OAKLEY would become the mandatory key management standard for the Internet (named IKE), and that SKIP could still become an elective standard for the Internet. As such, Sun Microsystems has continued to promote and market the SKIP technology. SKIP and IKE are overviewed and briefly discussed next.

14.5.1 SKIP

Most key distribution and management schemes and protocols are session-oriented, meaning that they establish and maintain an SA that lasts at least a certain amount of time. In contrast, many network and Internet layer protocols, such as IP and CLNP, are connectionless in nature and provide a connectionless datagram delivery service. To use a session-oriented key distribution scheme with IP, one has to create and implement a pseudosession layer underneath IP for the establishment and updating of IP traffic authentication and encryption keys. In fact, this layer is represented by the SA. While this is possible, it may be far less cumbersome to use a scheme that does not entail the overhead of such a pseudosession layer.

Against this background, Ashar Aziz from Sun Microsystems developed, proposed, and patented^[14] a key distribution and management scheme and protocol that is not session-oriented, meaning that it does not make use of SAs, in the early 1990s. As mentioned, the resulting key distribution and management scheme and protocol was named SKIP and is being marketed by Sun Microsystems. You may refer to the SKIP home page^[15] to learn about the availability of SKIP products and their interoperability with other VPN products.

Contrary to most other key distribution and management schemes and protocols that have been submitted to the IETF IPSEC WG, SKIP is not session-oriented. Instead of having the communicating peers establish and maintain an SA, SKIP uses packet-specific encryption keys that are communicated inband with the IP packets (in cryptographically protected form). More specifically, SKIP uses predistributed and authenticated Diffie-Hellman public keys to have two entities share an implicit master key from which a key encryption key (KEK) may be derived. The KEK, in turn, is used to encrypt a randomly chosen packet key and the packet key is used to encrypt the IP packet. Finally, the encrypted packet key is prepended to the encrypted IP packet.

Let us assume that all SKIP entities share a large prime p and a generator g of Z_p*. We further assume that principal A has a private Diffie-Hellman key x_A and a corresponding public key y_A = g^xA (mod p), and that principal B has another private key x_B and a corresponding public key y_B = g^xB(mod p). Both public keys are distributed in the form of public key certificates and retrieved using a protocol, such as the Certificate Discovery Protocol (CDP), specified for SKIP. According to the Diffie-Hellman key exchange, A and B then share the secret key K′_AB = g^xAxB (mod p). This key is implicit and does not need to be communicated explicitly to either entity (i.e., each entity can compute the shared secret based on knowledge of the other entity's identity and public key certificate). This mutually authenticated long-term secret key K′_AB can be used to derive a master key or KEK K_AB to provide IP-packet-based authentication and encryption. K_AB can be derived, for example, by taking the low-order key size bits of K′_AB. However, there are at least two reasons for updating the KEK periodically:

It minimizes the exposure of any given KEK, making cryptanalysis more difficult.
Updating the KEK prevents the reuse of compromised packet keys.

The KEK is updated by sending in the packet a counter n that only increments and is never decremented. K_AB then becomes a function of this counter n as follows: K_ABn = h(K′_AB,n). Again, h refers to a one-way hash function, such as MD5, SHA-1, or RIPEM. A simple and stateless way of implementing n is to let n be equal to the number of time units since the more recent of A's or B's certificates. In the absence of a clock, n can be constructed simply by using a counter.

To encrypt an individual IP packet, A randomly generates a packet key K_p and digitally envelopes the packet with this key and the KEK that he or she implicitly shares with the recipient B. More accurately, A encrypts both the packet with K_p and K_p with K_AB, and encapsulates both ciphertexts in a new IP packet. Note that because K_AB can be cached for efficiency, it allows packet keys to be modified very rapidly without incurring the computational overhead of public key operations. The packet keys can be changed as frequently as desired in line with a key management policy. If necessary, packet keys can be changed on a per-packet basis. When B receives the encrypted packet, he or she looks up A's certificate (using, for example, the SKIP CDP). Using the corresponding long-term public key and his or her own long-term private key, B can compute K′_AB and hence K_AB. Using K_AB, B can finally decrypt both K_p and the entire IP packet.

Figure 14.6 illustrates the use of SKIP to encrypt unicast and multicast IP packets. The use of SKIP to encrypt unicast packets has been described. The traditional approach for key distribution in a multicast environment is to set up and run a KDC that distributes the traffic keys to the legitimate and authorized members of a group. This one shared key is then used by the group members to encrypt and decrypt data. There are at least two problems related to this approach:

Key change cannot be done efficiently and does not scale well to large groups. Key change policies need to be a function of the amount of data encrypted with a given key, and not merely a function of time alone. This means that for highspeed data transmission links the keys must be updated far more frequently than for slower links, for the same key change policy. For a large number of members in a multicast group, however, it may become increasingly difficult or prohibitive for a multicast KDC to be rapidly supplying updated keys to all group members.
Use of the same key by all members of a multicast group precludes the use of certain stream ciphers. This is because using the same key will result in the same key stream being used to encrypt different plaintexts. Because key stream reuse is catastrophic to the security of some stream ciphers, it should be avoided generally. Nevertheless, it is important to allow stream ciphers to be used in conjunction with IP multicast. A common use of IP multicast is videoconferencing. Because video is a demanding application in terms of speed and throughput, it is important to allow the use of ciphers that can be efficiently implemented in software. Some of the most widely used and efficient ciphers are stream ciphers such as RC4. Because of key stream reuse issues, it is not possible to use a stream cipher like RC4 for IP multicast if all members of the multicast group use the same traffic key.

click to expand
Figure 14.6: The use of SKIP to encrypt unicast and multicast IP packets.

A simple modification of the basic SKIP protocol solves both problems. Instead of distributing a traffic key to the group members, a group owner may distribute a group interchange key (GIK) to them. As illustrated in Figure 14.6, the GIK can then be used to encrypt multicast IP packets (the GIK plays the role of the KEK for unicast traffic). To send encrypted data to a multicast group, a member first has to request the GIK from the group owner. The group owner's identity has to be known to the requesting principal. The request is made using the unicast SKIP protocol. Once the group owner determines that the requesting principal is on the group's access control list (ACL), it will provide the GIK to him or her. The requesting principal then encrypts the multicast traffic using one (or more) randomly generated packet keys. The packet keys are in turn encrypted using the GIK, and sent in-line with the corresponding IP packets. Note that changing the multicast traffic encryption key is simple. Each source can do this by randomly generating a new traffic key and communicating it in-line with the multicast IP packets (encrypted using the GIK). Multicast traffic encryption keys can be updated rapidly, even every packet if so desired, with no further communications overhead. Also note that because each source of encrypted traffic generates random traffic keys, all sources of encrypted traffic naturally use different keys. This allows any kind of stream cipher to be used for multicast traffic encryption as well.

Contrary to most other key distribution and management schemes and protocols that have been submitted to the IETF IPSEC WG, the original form of SKIP did not provide PFS. There is, however, a simple solution for this problem. In fact, it is possible to use a simple handshake that implements an additional ephemeral Diffie-Hellman key exchange to provide PFS. The ephemeral Diffie-Hellman key exchange, in turn, is authenticated using the KEK K_AB. Note, however, that any ephemeral Diffie-Hellman key exchange introduces greater bilateral state and overhead than is present in the base SKIP protocol. Consequently, when using SKIP PFS, certain features of the base SKIP protocol that rely on its statelessness become unavailable. In general, there is an interesting tradeoff between the statelessness of a key management protocol and its ability to provide PFS [36]. This tradeoff has not been investigated sufficiently and is not well understood today.

14.5.2 IKE

Contrary to SKIP and similar to most other key distribution and management schemes and protocols that have been submitted to the IETF IPSEC WG, the IKE protocol is session-oriented, meaning that it is used to establish and maintain SAs. If no SA is available for an inbound or outbound IP packet, the IKE protocol is first used to establish one. In fact, the whole purpose of the IKE protocol is to establish shared security parameters and authenticated keys—in other words, SAs—among communicating IPsec modules.

IKE refers to a combination of ISAKMP and OAKLEY. In short, ISAKMP defines how two peers communicate, how the messages they use to communicate are constructed, and through which state transitions they go to secure their communications. 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 the establishment of SAs. These issues are left to a specific key exchange protocol, such as OAKLEY. As such, ISAKMP is a general-purpose security exchange protocol that may be used for policy negotiation and establishment of keying material for a variety of needs. The specification of what IKE is being used for is done in a domain of interpretation (DOI). The IP security DOI for ISAKMP is specified in RFC 2407 [21]. More specifically, RFC 2407 defines how ISAKMP can be used to negotiate IKE and IPsec SAs. If and when IKE is used by other protocols, they will each have to define their own DOI.^[16] In other words, ISAKMP defines the language to establish authenticated session keys, whereas OAKLEY defines the steps two peers must actually take to establish the keys.

The IKE protocol is a request-response type of protocol with an initiator and a responder. The IKE initiator is the party that is instructed by its IPsec module to establish an SA or an SA bundle as a result of an outbound packet matching an SPD entry. The SPD of IPsec is used to instruct IKE what to establish but does not instruct IKE how to do so. In fact, how IKE establishes the IPsec SAs is based on its own policy settings. IKE defines policy in terms of protection suites. Each protection suite must define at least the encryption algorithm, the hash algorithm, the Diffie-Hellman group, and the method of authentication used. IKE's policy database then is the list of all protection suites weighted in order of preference.

The establishment of an IPsec SA (or an SA bundle) using IKE is a two-phase process:

In phase one, an IKE SA is established. The IKE SA defines the way in which the two peers communicate, for example, which algorithm to use to encrypt IKE traffic, how to authenticate the remote peer, and so on.
In phase two, the IKE SA is used to establish any given number of IPsec SAs between the communicating peers. The IPsec SAs established by IKE may optionally have PFS of the keys and, if desired, also of the peer identity.

Phase One: Establishing an IKE SA

The establishment of an IKE SA basically consists of three steps and corresponding exchanges:

A cookie exchange;
A value exchange;
An authentication exchange.

In short, the cookie exchange protects the responder from simple resource clogging attacks. Once initiator and responder cookies have been established, a value exchange and a subsequent authentication exchange are used to implement an authenticated Diffie-Hellman key exchange, and to provide the initiator and responder with an authenticated shared secret accordingly.

Cookie Exchange To protect the responder from simple resource clogging attacks, the initiator must provide a valid cookie whenever he or she wants to enter a value exchange and initiate a computationally expensive Diffie-Hellman key exchange accordingly. A valid cookie, in turn, is a value that can be computed and verified only by the responder. For example, it can be a keyed one-way hash value of the initiator's and responder's IP addresses and port numbers. In this case, the key must be known only to the responder. The cookie exchange and the rationale behind it are beyond the scope of this book. Refer to [33] for a more detailed explanation and analysis.

Value Exchange A value exchange establishes a shared secret key between the communicating peers. In general, there is more than one way to establish a key, but IKE always uses a Diffie-Hellman key exchange. Consequently, the act of doing a Diffie-Hellman key exchange is not negotiable, but the parameters to use are. In fact, IKE borrows five groups from the OAKLEY specification; three are traditional exchanges doing exponentiation modulo a large prime, and two are elliptic curve groups. Upon completion of the value exchange, the two peers share a key and this key still needs to be authenticated.

Authentication Exchange In a final step, the Diffie-Hellman key and, therefore, the IKE SA must be authenticated. There are five methods of authentication defined in IKE: preshared keys, digital signature using DSS, digital signature using RSA, and two methods that use an encrypted nonce exchange with RSA.

There are basically two modes and corresponding exchanges that can be used in phase one: a main mode exchange and an aggressive mode exchange.

In a main mode exchange, the request and response messages for each of the three exchanges are sent and received one after the other, totaling six messages.
Contrary to that, some of the messages are sent together in an aggressive mode exchange, totaling three messages. Most important, an aggressive mode exchange cannot use cookies to protect against resource clogging attacks.

In short, aggressive mode is faster but main mode is more flexible. Once phase one is completed, phase two may commence and the required IPsec SAs may be created.

Phase Two: Establishing IPsec SAs

Contrary to phase one, there is a single phase two exchange, and this exchange has been named quick mode exchange. This exchange negotiates IPsec SAs under the protection of the IKE SA, which was created in phase one. The keys used for the IPsec SAs are, by default, derived from the IKE secret state. Pseudorandom nonces are exchanged in quick mode and hashed with the secret state to generate keys and guarantee that all SAs have unique keys. All such keys do not have the property of PFS as they are all derived from the same root key (i.e., the IKE shared secret). To provide PFS, Diffie-Hellman public values, and the group from which they are derived, are exchanged along the nonces and IPsec SA negotiation parameters. The resulting secret is used to generate the IPsecSA keys to guarantee PFS.

^[11]Phil Karn was later joined by Bill Simpson to write the experimental Photuris protocol specifications.

^[12]The IETF Security Area Director was (and still is) Jeffrey Schiller from MIT.

^[13]In short, PFS refers to the property of a key establishment protocol that the compromise of a long-term secret does not necessarily reveal all session keys that have been or will be established in the past (future). For all practical purposes, PFS requires a key agreement protocol, such as a Diffie-Hellman key exchange.

^[14]The relevant patents for SKIP are U.S. Patent 5,588,060, "Method and Apparatus for a Key-Management Scheme for Internet Protocols" and U.S. Patent 5,548,646, "System for Signatureless Transmission and Reception of Data Packets Between Computer Networks."

^[15]http://skip.incog.com

^[16]At the time of this writing, no other DOI is available.

Team-Fly