Fast Just Keying: Key Agreement in a Hostile Internet
WILLIAM AIELLO, STEVEN M. BELLOVIN, MATT BLAZE AT&T Labs Research RAN CANETTI IBM T. J. Watson Research Center JOHN IOANNIDIS AT&T Labs Research ANGELOS D. KEROMYTIS Columbia University and OMER REINGOLD AT&T Labs Research
We describe Just Fast Keying (JFK), a new key-exchange protocol, primarily designed for use in the IP security architecture. It is simple, efcient, and secure; we sketch a proof of the latter property. JFK also has a number of novel engineering parameters that permit a variety of tradeoffs, most notably the ability to balance the need for perfect forward secrecy against susceptibility to denialof-service attacks. Categories and Subject Descriptors: C.2.0 [Security and Protection]: Key Agreement Protocols General Terms: Security, Reliability, Standardization Additional Key Words and Phrases: Cryptography, denial-of-service attacks
1. INTRODUCTION Many public-key-based key-setup and key-agreement protocols already exist and have been implemented for a variety of applications and environments. Several have been proposed for the IPsec protocol suite, and one, internet key exchange (IKE) [Harkins and Carrel 1998], is the current standard.
This work was partially supported by DARPA under contract F39502-99-1-0512-MOD P0001. A previous version of this paper appeared in Aiello et al.[2003]. Authors addresses: William Aiello, Steven M. Bellovin, Matt Blaze, John Ioannidis, Omer Reingold, AT&T Labs Research, email: {aiello,smb,mab,ji,omer}@research.att.com; Ran Canetti, IBM T.J. Watson Research Center, email: [e-mail]; Angelos D. Keromytis, Department of Computer Science, Columbia University, 515 CS Building, 1414 Amsterdam Avenue, New York, NY 10027, email: [e-mail]. Permission to make digital/hard copy of all or part of this material without fee for personal or classroom use provided that the copies are not made or distributed for prot or commercial advantage, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specic permission and/or a fee. C 2004 ACM 1094-9224/04/0500-0242 $5.00
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004, Pages 242273.
Just Fast Keying: Key Agreement in a Hostile Internet
243
IKE has a number of deciencies, the three most important being that the number of rounds is high, that it is vulnerable to denial-of-service (DoS) attacks, and the complexity of the protocol and its specication. This complexity has led to interoperability problemsso much so that, several years after its initial adoption by the IETF, there are still non-interoperating commercial implementations. While it might be possible to patch the IKE protocol to x some of these problems, it may be perferable to construct a new protocol that more narrowly addresses the requirements from the ground up. We set out to engineer a new key-exchange protocol specically for Internet security applications. We call our new protocol JFK, which stands for Just Fast Keying. 1.1 Design Goals We seek a protocol with the following characteristics: Security: No one other than the participants may have access to the generated key. PFS: It must approach Perfect Forward Secrecy. Privacy: It must preserve the privacy of the initiator and/or responder, insofar as possible. Memory-DoS: It must resist memory exhaustion attacks. Computation-DoS: It must resist CPU exhaustion attacks on the responder. Availability: It must protect against easy to mount protocol-specic DoS attacks, for example, in a wireless environment where an attacker can observe everyones transmissions but cannot interfere with the transmitted packets themselves. Efciency: It must be efcient with respect to computation, bandwidth, and number of rounds. Non-negotiated: It must avoid complex negotiations over capabilities. Simplicity: The resulting protocol must be as simple as possible, within the constraints of the requirements. The Security requirement is obvious enough (we use the security model of Canetti and Krawczyk [2001; 2002a]). The rest, however, require some discussion. The PFS property is perhaps the most controversial. (PFS is an attribute of encrypted communications allowing for a long-term key to be compromised without affecting the security of past session keys.) Rather than assert that we must have PFS at all costs, we treat the amount of forward secrecy as an engineering parameter that can be traded off against other necessary functions, such as efciency or resistance to DoS attacks. In fact, this corresponds quite nicely to the reality of todays Internet systems, where a compromise during the existence of a security association (SA) will reveal the plaintext of any ongoing transmissions. Our protocol has a forward secrecy interval; SAs are protected against compromises that occur outside of that interval. Specically, we allow a party to reuse the same secret DifeHellman (DH) exponents for multiple
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
244
W. Aiello et al.
exchanges within a given time period; this may save a large number of costly modular exponentiations. The Privacy property means that the protocol must not reveal the identity of a participant to any unauthorized party, including an active attacker that attempts to act as the peer. Clearly, it is not possible for a protocol to protect both the initator and the responder against an active attacker; one of the participants must always go rst. In general, we believe that the most appropriate choice is to protect the initator, since the initator is typically a relatively anonymous client, while the responders identity may already be known. Conversely, protecting the responders privacy may not be of much value (except perhaps in peer-to-peer communication): in many cases, the responder is a server with a xed address or characteristics (e.g., well-known web server). One approach is to allow for a protocol that allows the two parties to negotiate who needs identity protection. In JFK, we decided against this approach: it is unclear what, if any, metric can be used to determine which party should receive identity protection; furthermore, this negotiation could act as a loophole to make initiators reveal their identity rst. Instead, we propose two alternative protocols: one that protects the initator against an active attack, and another that protects the responder. These two protocols are respectively named JFKi and JFKr. The Memory-DoS and Computation-DoS properties have become more important in the context of recent Internet DoS attacks. Photuris [Karn and Simpson 1999] was the rst published key-management protocol for which DoS resistance was a design consideration; we suggest that these properties are at least as important today. We also extend these properties with a general Availability requirement, by which we mean that the protocol must try to counter attacks that aim to disrupt a legitimate exchange, especially in environments where an attacker may have limited capabilities in terms of packet modication (e.g., a wireless network). The Efciency property is worth discussing. In many protocols, key setup must be performed frequently enough that it can become a bottleneck to communication. The key-exchange protocol must minimize computation as well total bandwidth and round trips. Round trips can be an especially important factor when communicating over unreliable media. Using our protocols, only two round trips are needed to set up a working SA. This is a considerable saving in comparison with existing protocols, such as IKE. The Nonnegotiated property is necessary for several reasons. Negotiations create complexity and round trips, and hence should be avoided. DoS resistance is also relevant here; a partially negotiated SA consumes resources. The Simplicity property is motivated by several factors. Efciency is one; increased likelihood of correctness is another. But our motivation is especially colored by our experience with IKE. Even if the protocol is dened correctly, it must be implemented correctly; as protocols become more complex, implementation and interoperability errors occur more often. This hinders both security and interoperability. Our design follows the traditional design paradigm of successful internetworking protocols: keep individual building blocks as simple as possible; avoid large, complex, monolithic protocols. We have consciously chosen
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
Just Fast Keying: Key Agreement in a Hostile Internet
245
to omit support for certain features when we felt that adding such support would cause an increase in complexity that was disproportional to the benet gained. Protocol design is, to some extent, an engineering activity, and we need to provide for tradeoffs between different types of security. There are tradeoffs that we made during the protocol design, and others, such as that between forward secrecy and computational effort, that are left to the implementation and to the user, for example, selected as parameters during conguration and session negotiation. 2. PROTOCOL DEFINITION We present two variants of the JFK protocol. Both variants take two round trips (i.e., four messages) and both provide the same level of DoS protection. The rst variant, denoted JFKi, provides identity protection for the initiator even against active attacks. The identity of the responder is not protected. This type of protection is appropriate for a clientserver scenario where the initiator (the client) may wish to protect its identity, whereas the identity of the responder (the server) is public. As discussed in Section 4, this protocol uses the basic design of the ISO 9798-3 key-exchange protocol [IEEE 1993; Canetti and Krawczyk 2001], with modications that guarantee the properties discussed in Section 1. The second variant, JFKr, provides identity protection for the responder against active adversaries. Furthermore, it protects both sides identities against passive eavesdroppers. This type of protection is appropriate for a peerto-peer scenario, where the responder may wish to protect its identity. Note that it is considerably easier to mount active identity-probing attacks against the responder than against the initiator. Furthermore, JFKr provides repudiability on the key exchange, since neither side can prove to a third party that their peer in fact participated in the protocol exchange with them. (In contrast, JFKi authentication is nonrepudiable, since each party signs the others identity along with session-specic information such as the nonces.) This protocol uses the basic design of the Sign-and-MAC (SIGMA) protocol from Krawczyk [2002], again with the appropriate modications. 2.1 Notation First, some notation: Hk (M ) Keyed hash (e.g., HMAC [Krawczyk et al. 1997]) of message M using key k. We assume that H is a pseudorandom function. This also implies that H is a secure message authentication (MAC) function. In some places we make a somewhat stronger assumption relating H and discrete logarithms; see more details within. e {M } K a Encryption using symmetric key K e , followed by MAC authentication K with symmetric key K a of message M . The MAC is computed over the ciphertext, prexed with the literal ASCII string "I" or "R", depending on who the message sender is (initiator or responder).
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
246
W. Aiello et al.
Sx [M ] Digital signature of message M with the private key belonging to principal x (initiator or responder). It is assumed to be a non-messagerecovering signature. The message components used in JFK are: Initiators network address. DH exponentials; also identifying the group-ID. Initiators current exponential (mod p). Responders current exponential (mod p). Initiator nonce, a random bit-string. Initiators initial nonce, computed as H(N I ). Responder nonce, a random bit-string. Initiators certicates or public-key identifying information. Responders certicates or public-key identifying information. An indication by the initiator to the responder as to what authentication information (e.g., certicates) the latter should use. HK R A transient hash key private to the responder. sa Cryptographic and service properties of the SA that the initiator wants to establish. It contains a Domain-of-Interpretation, which JFK understands, and an application-specic bit-string. sa SA information the responder may need to give to the initiator (e.g., the responders SPI, in IPsec). K ir Shared key derived from g ir , N I , and N R used for protecting the application (e.g., the IPsec SA). K e , K a Shared keys derived from g ir , N I , and N R , used to encrypt and authenticate messages (3) and (4) of the protocol. grpinfo R All groups supported by the responder, the symmetric algorithms used to protect messages (3) and (4), and the hash function used for key generation. IP I gx gi gr NI NI NR ID I ID R ID R Both parties must pick a fresh nonce at each invocation of the JFK protocol. The nonces are used in the session-key computation, to provide key independence when one or both parties reuse their DH exponential; the session key will be different between independent runs of the protocol, as long as one of the nonces or exponentials changes. HK R is a global parameter for the responderit stays the same between protocol runs, but can change periodically. 2.2 The JFKi Protocol The JFKi protocol consists of four messages (two round trips): I R : N I , g i , ID R R I : N I , N R , g r , grpinfo R , ID R ,
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
(1)
Just Fast Keying: Key Agreement in a Hostile Internet
247
S R [ g r , grpinfo R ], HHK R g r , N R , N I , IP I I R : NI , NR , g i, gr , HHK R g r , N R , N I , IP I ,
e {ID I , sa, S I [N I , N R , g i , g r , ID R , sa]} K a K e R I : {S R [N I , N R , g i , g r , ID I , sa, sa ], sa } K a K
(2)
(3) (4)
The keys K e and K a , used to protect the condentiality and integrity of messages (3) and (4), respectively, are computed as H g ir (N I , N R , "1") and H g ir (N I , N R , "2"), respectively. The session key, K ir , is H g ir (N I , N R , "0"). This key is passed to IPsec or, more generally, to the application that requested keyagreement services. (Note that there may be a difference in the number of bits from the HMAC and the number produced by the raw DH exchange; the 512 least-signicant bits are of g ir are used as the key in that case.) If the key used by IPsec is longer than the output of the HMAC, the key extension method of IKE is used to generate more keying material. Message (1) is straightforward; note that it assumes that the initiator already knows a group and generator that are acceptable to the responder. The initiator can reuse a g i value in multiple instances of the protocol with the responder, or other responders that accept the same group, for as long as she wishes her forward secrecy interval to be. We discuss how the initiator can discover what groups to use in a later section. This message also contains an indication as to which ID the initiator would like the responder to use to authenticate. ID R is sent in the clear; however, the responders ID in message (2) is also sent in the clear, so there is no loss of privacy. Message (2) is more complex. Assuming that the responder accepts the DH group in the initiators message (rejections are discussed in Section 2.5), he replies with a signed copy of his own exponential (in the same group, also (mod p)), information on what secret key algorithms are acceptable for the next message, a random nonce, his identity (certicates or a string identifying his public key), and an authenticator calculated from a secret, HK R , known to the responder; the authenticator is computed over the responders exponential, the two nonces, and the initiators network address. The responders exponential may also be reused; again, it is regenerated according to the responders forward secrecy interval. The signature on the exponential needs to be calculated at the same rate as the responders forward secrecy interval (when the exponential itself changes). Finally, note that the responder does not need to generate any state at this point, and the only cryptographic operation is a MAC calculation. If the responder is not under heavy load, or if PFS is deemed important, the responder may generate a new exponential and corresponding signature for use in this exchange; of course, this would require keeping some state (the secret part of the responders DH computation). Message (3) echoes back the data sent by the responder, including the authenticator. However, instead of the initial nonce, N I , the initiator now sends its
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
248
W. Aiello et al.
source, N I . The authenticator is used by the responder to verify the authenticity of the returned data. The authenticator also conrms that the sender of the message (3) used the same address as in message (1)this can be used to detect and counter a cookie jar DoS attack.1 A valid authenticator indicates to the responder that a round trip has been completed (between messages (1), (2), and (3)). To check the authenticator, the responder must rst compute N I from its source, N I by applying the hash function H. The purpose of this scheme is to avoid a certain attack in environments where an attacker can eavesdrop trafc but cannot modify already transmitted packets, for example, in a wireless network. In such an environment, if N I was used instead of N I , the eavesdropper could construct a valid-looking message (3) (by copying the nonces, exponentials, and the authenticator) that would cause the responder to perform the (expensive) public-key operations, only to then drop the packet because further processing would detect that the message was fake (by failure to decrypt or verify the remainder of the payload, as we shall see shortly). The responder is then left with two options: blacklist the authenticator (causing the exchange with the initiator to fail), or simply discard the packet (thus allowing a computation-based DoS attack). With our approach, however, the eavesdropper cannot produce a valid N I (since that would imply a weak hash function) and thus cannot produce a message (3) that will pass the authenticator verication phase. If the eavesdropper cannot intercept or preempt a valid message (3), as may be the case with some wireless networks, they cannot hijack the initiators response to mount this DoS attack. Note that if a legitimate message (3) is transmitted over the wireless network but is somehow not received by the responder, an eavesdropper can use it to mount the previously described attack. Although the scheme is not foolproof, it signicantly raises the bar against this DoS attack in certain environments, without hindering the exchange under normal circumstances. Message (3) also includes the initiators identity and service request, and a signature computed over the nonces, the responders identity, and the two exponentials. This latter information is all encrypted and authenticated under keys K e and K a , as already described. The encryption and authentication use algorithms specied in grpinfo R . The responder keeps a copy of recently received messages (3), and their corresponding message (4). Receiving a duplicate (or replayed) message (3) causes the responder to simply retransmit the corresponding message (4), without creating new state or invoking IPsec. This cache of messages can be reset as soon as HK R is changed. The responders exponential ( g r ) is re-sent by the initiator because the responder may be generating a new g r for every new JFK protocol run (e.g., if the arrival rate of requests is below some threshold). It is important that the responder deal with repeated messages (3) as described above. Responders that create new state for a repeated message (3) open the door to attacks against the protocol and/or underlying application (IPsec).
1 The
cookie jar DoS attack involves an attacker that is willing to reveal the address of one subverted host so as to acquire a valid cookie (or number of cookies) that can then be used by a large number of other subverted hosts to launch a DDoS attack using the valid cookie(s).
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
Just Fast Keying: Key Agreement in a Hostile Internet
249
Note that the signature is protected by the encryption. This is necessary for identity protection, since everything signed is public except the sa, and that is often guessable. An attacker could verify guesses at identities if the signature were not encrypted. Message (4) contains application-specic information (such as the responders IPsec SPI), and a signature on both nonces, both exponentials, and the initiators identity. Everything is encrypted and authenticated by the same K e and K a used in message (3), which are derived from N I , N R , and g ir . The encryption and authentication algorithms are specied in grpinfo R . 2.3 Discussion The design follows from our requirements. With respect to communication efciency, observe that the protocol requires only two round trips. The protocol is optimized to protect the responder against DoS attacks on state or computation. The initiator bears the initial computational burden and must establish roundtrip communication with the responder before the latter is required to perform expensive operations. At the same time, the protocol is designed to limit the private information revealed by the initiator; she does not reveal her identity until she is sure that only the responder can retrieve it. (An active attacker can replay an old message (2) as a response to the initiators initial message, but he cannot retrieve the initiators identity from message (3) because he cannot complete the DH computation.) The initiators rst message, message (1), is a straightforward DH exponential. Note that this is assumed to be encoded in a self-identifying manner, that is, it contains a tag indicating which modulus and base was used. The nonce N I serves three purposes: rst, it allows the initiator to reuse the same exponential across different sessions (with the same or different responders, within the initiators forward secrecy interval) while ensuring that the resulting session key will be different. Secondly, it can be used to differentiate between different parallel sessions (in any case, we assume that the underlying transport protocol, that is, UDP, can handle the demultiplexing by using different ports at the initiator). Lastly, it allows the responder to distinguish between a valid message (3) and one produced by an eavesdropper, as we discussed in the previous section. Message (2) must require only minimal work for the responder, since at that point he has no idea whether the initiator is a legitimate correspondent or, for example, a forged message from a DoS attack; no round trip has yet occurred with the initiator. Therefore, it is important that the responder not be required at this point to perform expensive calculations or create state. Here, the responders cost will be a single authentication operation, the cost of which (for HMAC) is dominated by two invocations of a cryptographic hash function, plus generation of a random nonce N R . The responder may compute a new exponential g b (mod p) for each interaction. This is an expensive option, however, and at times of high load (or attack) it would be inadvisable. The nonce prevents two successive session keys from being the same, even if both the initiator and the responder are reusing
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
250
W. Aiello et al.
exponentials. One case when both sides may reuse the same exponentials is when the initiator is a low-power device (e.g., a cellphone) and the responder is a busy server. A simple way of addressing DoS is to periodically (e.g., once every 30 s) generate an (r, g r , HHK R ( g r ), S R [ g r ]) tuple and place it in a FIFO queue. As requests arrive (in particular, as valid messages (3) are processed), the rst entry from the FIFO is removed; thus, as long as valid requests arrive at under the generation rate, PFS is provided for all exchanges. If the rate of valid protocol requests exceeds the generating rate, a JFK implementation should reuse the last tuple in the FIFO. Notice that in this scheme, the same g r may be reused in different sessions, if these sessions are interleaved. This does not violate the PFS or other security properties of the protocol. If the responder is willing to accept the group identied in the initiators message, his exponential must be in the same group. Otherwise, he may respond with an exponential from any group of his own choosing. The eld grpinfo R lists what groups the responder nds acceptable, if the initiator should wish to restart the protocol. This provides a simple mechanism for the initiator to discover the groups currently allowed by the responder. That eld also lists what encryption and MAC algorithms are acceptable for the next two messages. This is not negotiated; the responder has the right to decide what strength encryption is necessary to use his services. Note that the responder creates no state when sending this message. If it is fraudulent, that is, if the initiator is nonexistent or intent on perpetrating a DoS attack, the responder will not have committed any storage resources. In message (3), the initiator echoes content from the responders message, including the authenticator. The authenticator allows the responder to verify that he is in round-trip communication with a legitimate potential correspondent. By revealing the source, N I , of the initial nonce, N I , the initiator denies an eavesdropper the ability to disrupt the protocol exchange by transmitting a valid-looking message (3), as discussed above. The initiator also uses the key derived from the two exponentials and the two nonces to encrypt her identity and service request. The initiators nonce is used to ensure that this session key is unique, even if both the initiator and the responder are reusing their exponentials and the responder has forgotten to change nonces. Because the initiator can validate the responders identity before sending her own and because her identifying information (ignoring her public-key signature) is sent encrypted, her privacy is protected from both passive and active attackers. An active attacker can replay an old message (2) as a response to the initiators initial message, but he cannot retrieve the initiators identity from message (3) because he cannot complete the DH computation. The service request is encrypted, too, since its disclosure might identify the requester. The responder may wish to require a certain strength of cryptographic algorithm for selected services. Upon successful receipt and verication of this message, the responder has a shared key with a party known to be the initiator. The responder further knows
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
Just Fast Keying: Key Agreement in a Hostile Internet
251
what service the initiator is requesting. At this point, he may accept or reject the request. The responders processing on receipt of message (3) requires verifying an authenticator and, if that is successful, performing several public-key operations to verify the initiators signature and certicate chain. The authenticator (requiring three hash operations, two for the HMAC computation and one for deriving N I from the received N I ) is sufcient defense against forgery; replays, however, could cause considerable computation. The defense against this is to cache the corresponding message (4); if a duplicate message (3) is seen, the cached response is retransmitted; the responder does not create any new state or notify the application (e.g., IPsec). The key for looking up messages (3) in the cache is the authenticator; this prevents DoS attacks where the attacker randomly modies the encrypted blocks of a valid message, causing a cache miss and thus more processing to be done at the responder. Further, if the authenticator veries but there is some problem with the message (e.g., the certicates do not verify), the responder can cache the authenticator along with an indication as to the failure (or the actual rejection message), to avoid unnecessary processing (which may be part of a DoS attack). This cache of messages (3) and authenticators can be purged as soon as HK R is changed (since the authenticator will no longer pass verication). Caching message (3) and refraining from creating new state for replayed instances of message (3) also serves another security purpose. If the responder were to create a new state and send a new message (4), and a new sa for a replayed message (3), then an attacker who compromised the initiator could replay a recent session with the responder. That is, by replaying message (3) from a recent exchange between the initiator and the responder, the attacker could establish a session with the responder where the session-key would be identical to the key of the previous session (which took place when the initiator was not yet compromised). This could compromise the Forward Security of the initiator. There is a risk, however, in keeping this message cached for too long: if the responders machine is compromised during this period, PFS is compromised. We can tune this by changing the MAC key HK R more frequently. The cache can be reset when a new HK R is chosen. In message (4), the responder sends to the initiator any responder-specic application data (e.g., the responders IPsec SPI), along with a signature on both nonces, both exponentials, and the initiators identity. All the information is encrypted and authenticated using keys derived from the two nonces, N I and N R , and the DH result. The initiator can verify that the responder is present and participating in the session, by decrypting the message and verifying the enclosed signature. 2.4 The JFKr Protocol Using the same notation as in JFKi, the JFKr protocol is I R : NI , g i (1)
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
252
W. Aiello et al.
R I : N I , N R , g r , grpinfo R , HHK R g r , N R , N I , I PI I R : NI , NR , g i, gr , HHK R g r , N R , N I , I PI
e {ID I , ID R , sa, S I [N I , N R , g i , g r , grpinfo R ]} K a K e R I : {ID R , sa , S R [ g r , N R , g i , N I ]} K a K
(2)
(3) (4)
As in JFKi, the keys used to protect messages (3) and (4), K e and K a , are respectively computed as H g ir (N I , N R , "1") and H g ir (N I , N R , "2"). The session key passed to IPsec (or some other application), K ir , is H g ir (N I , N R , "0"). Both parties send their identities encrypted and authenticated under K e and K a , respectively, providing both parties with identity protection against passive eavesdroppers. In addition, the party that rst reveals its identity is the initiator. This way, the responder is required to reveal its identity only after it veries the identity of the initiator. This guarantees active identity protection to the responder. We remark that it is essentially impossible, under current technology assumptions, to have a two-round-trip protocol that provides DoS protection for the responder, passive identity protection for both parties, and active identity protection for the initiator. An informal argument proceeds as follows: If DoS protection is in place, then the responder must be able to send his rst message before he computes any shared key. This is so since computing a shared key is a relatively costly operation in current technology. This means that the responder cannot send his identity in the second message, without compromising his identity protection against passive eavesdroppers. This means that the responders identity must be sent in the fourth (and last) message of the protocol. Consequently, the initiators identity must be sent before the responders identity is sent. 2.5 Rejection Messages Instead of sending messages (2) or (4), the responder can send a rejection instead. For message (2), this rejection can only be on the grounds that he does not accept the group that the initiator has used for her exponential. Accordingly, the reply should indicate what groups are acceptable. Since message (2) already contains the eld grpinfo R (which indicates what groups are acceptable), no explicit rejection message is needed. (For efciencys sake, the group information could also be in the responders long-lived certicate, which the initiator may already have.) Message (4) can be a rejection for several reasons, including lack of authorization for the service requested. But it could also be caused by the initiator requesting cryptographic algorithms that the responder regards as inappropriate, given the requester (initiator), the service requested, and possibly other information available to the responder, such as the time of day or the initiators location as indicated by the network. In these cases, the responders reply should
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
Just Fast Keying: Key Agreement in a Hostile Internet
253
list acceptable cryptographic algorithms, if any. The initiator would then send a new message (3), which the responder would accept anew; again, the responder does not create any state until after a successful message (3) receipt. 3. WHAT JFK AVOIDS By intent, JFK does not do certain things. It is worth enumerating them, if only to stimulate discussion about whether certain protocol features are ever appropriate. In JFK, the missing features were omitted by design, in the interests of simplicity. 3.1 Multiple Authentication Options The most obvious omission is any form of authentication other than by certicate chains trusted by the each party. We make no provisions for shared secrets, token-based authentication, certicate discovery, or explicit cross-certication of PKIs. In our view, these are best accomplished by outboard protocols. Initiators that wish to rely on any form of legacy authentication can use the protocols being dened by the IPSRA [Sheffer et al. 2001] or SACRED [Arsenault and Farrell 2001; Gustafson et al. 2001] IETF working groups. While these mechanisms do add extra round trips, the expense can be amortized across many JFK negotiations. Similarly, certicate chain discovery (beyond the minimal capabilities implicit in ID I and ID R ) should be accomplished by protocols dened for that purpose. By excluding the protocols from JFK, we can exclude them from our security analysis; the only interface between the two is a certicate chain, which by denition is a stand-alone secure object. We also eliminate negotiation generally, in favor of ukases issued by the responder. The responder is providing a service; it is entitled to set its own requirements for that service. Any cryptographic primitive mentioned by the responder is acceptable; the initiator can choose any it wishes. We thus eliminate complex rules for selecting the best choice from two different sets. We also eliminate the need that state be kept by the responder; the initiator can either accept the responders desires or restart the protocol. 3.2 Phase II and Lack Thereof JFK rejects the notion of two different phases. As will be discussed in Section 5, the practical benets of quick mode are limited. Furthermore, we do not agree that frequent rekeying is necessary. If the underlying block cipher is sufciently limited as to bar long-term use of any one key, the proper solution is to replace that cipher. For example, 3DES is inadequate for protection of very high-speed transmissions, because the probability of collision in CBC mode becomes too high after encryption of 232 plaintext blocks. Using AES instead of 3DES solves that problem without complicating the key exchange. Phase II of IKE is used for several things; we do not regard any of them as necessary. One is generating the actual keying material used for SAs. It is expected that this will be done several times, to amortize the expense of the Phase I negotiation. A second reason for this is to permit very frequent rekeying. Finally, it permits several separate SAs to be set up, with different parameters.
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
254
W. Aiello et al.
We do not think these apply. First, with modern ciphers such as AES, there is no need for frequent key changes. AES keys are long enough that brute-force attacks are infeasible. Its longer block size protects against CBC limitations when encrypting many blocks. We also feel that JFK is efcient enough that avoiding the overhead of a full key exchange is not required. Rather than adding new SAs to an existing Phase I SA, we suggest that a full JFK exchange be initiated instead. We note that the initiator can also choose to reuse its exponential, it if wishes to trade PFS for computation time. If state already exists between the initiator and the responder, they can simply check that the DH exponentials are the same; if so, the result of the previous exponentiation can be reused. As long as one of the two parties uses a fresh nonce in the new protocol exchange, the resulting cryptographic keys will be fresh and not subject to a related key (or other, similar) attack. As we discuss in Section 3.3, a similar performance optimization can be used on the certicate-chain validation. A second major reason for Phase II is dead-peer detection. IPsec gateways often need to know if the other end of a SA is dead, both to free up resources and to avoid black holes. In JFK, this is done by noting the time of the last packet received. A peer that wishes to elicit a packet may send a ping. Such hosts may decline any proposed SAs that do not permit such ping packets. A third reason for Phase II is general SA control, and in particular SA deletion. While such a desire is not wrong, we prefer not to burden the basic keyexchange mechanism with extra complexity. There are a number of possible approaches. Ours requires that JFK endpoints implement the following rule: a new negotiation that species an SPD identical to the SPD of an existing SA overwrites it. To some extent, this removes any need to delete an SA if black hole avoidance is the concern; simply negotiate a new SA. To delete an SA without replacing it, negotiate a new SA with a null ciphersuite. 3.3 Rekeying When a negotiated SA expires (or shortly before it does), the JFK protocol is run again. It is up to the application to select the appropriate SA to use among many valid ones. In the case of IPsec, implementations should switch to using the new SA for outgoing trafc, but would still accept trafc on the old SA (as long as that SA has not expired). To address performance considerations, we should point out that, properly implemented, rekeying only requires one signature and one verication operation in each direction, if both parties use the same DH exponentials (in which case, the cached result can be reused) and certicates: the receiver of an ID payload compares its hash with those of any cached ID payloads received from the same peer. While this is an implementation detail, a natural location to cache past ID payloads is along with already established SAs (a convenient fact, as rekeying will likely occur before existing SAs are allowed to expire, so the ID information will be readily available). If a match is found and the result has not expired yet, then we do not need to revalidate the certicate chain. A previously veried certicate chain is considered valid for the shortest of its CRL
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
Just Fast Keying: Key Agreement in a Hostile Internet
255
revalidate time, certicate expiration time, OCSP result validity time, and so on. For each certicate chain, there is one such value associated (the time when one of its components becomes invalid or needs to be checked again). Notice that an implementation does not need to cache the actual ID payloads; all that is needed is the hash and the expiration time. That said, if for some reason fast rekeying is needed for some application domain, it should be done by a separate protocol. 4. DISCUSSION OF THE SECURITY ANALYSIS Detailed formal denitions and proofs of security of the JFK protocols are beyond the scope of this paper. Nonetheless, below we sketch the main ideas of the analysis, with emphasis on those that require extending the existing techniques for key-agreement protocols. There are currently two main approaches to analyzing the security of protocols: the formal-methods approach and the cryptographic reduction approach. In the former, the cryptographic components of a protocol are modeled by ideal boxes. Then automatic theorem-verication tools are applied to the protocol. In this approach, if the verication returns a failure, the protocol has a serious aw (and the aw is typically explicitly presented). However, even if the verication procedure does not return a aw, it still does not follow that the protocol is resistant to all feasible attacks. This is due to the idealized modeling of the cryptographic primitives. The cryptographic reduction approach provides a less abstract treatment of the security of protocols, taking into account the imperfections of the underlying cryptographic primitives. Specically, the underlying cryptographic primitives are assumed to be resistant with high probability to all attacks that consume a given amount of resources. The probability and resource amounts are treated as parameters. For this exposition we denote the tuple of parameters the security level. A proof of security in this approach derives the security level for the protocol essentially as a function of the security levels of the underlying primitives. Intuitively, a protocol is secure if the security level of the protocol are not much smaller than the security levels of the underlying primitives. As in the formal-methods approach, a proof of security in the cryptographic reduction approach does not imply that the protocol is resistant to all feasible attacks. However, it does imply that any efcient attack on the protocol can be converted into an efcient attack on one of the underlying primitives. Essentially a proof in the cryptographic reduction approach shows that the intractability of attacking the protocol follows if the underlying cryptographic primitives are assumed to be intractable to break. The security of the protocol thus rests solely on the security assumptions on the primitives and not on any implicit or hidden assumptions. The formal-methods approach, being automatable, has the advantage that it is less susceptible to human errors and oversights in analysis. However, when veriable proofs are attainable via the cryptographic reduction approach they provide more quantitative information about the relationship between the security of the cryptographic primitives and the security of the protocols. This
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
256
W. Aiello et al.
quantitative information is often very important when determining the operating parameters of the protocol. We stress that neither approach provides full analysis of an implementation of the protocol. In particular, issues like coding errors, buffer overows, and the like are not treated. These should be dealt with carefully, using different tools, on an implementation-by-implementation basis. Our analysis follows the cryptographic reduction approach. We welcome any additional analysis. In particular, analysis based on formal methods would be a useful complement. We separate the analysis of the core security of the protocol from the analysis of added security features such as DoS protection and identity protection. We discuss rst the core security. 4.1 Security of Key-Agreement Protocols JFK was designed for application environments, such as IPsec, in which many sessions of the same protocol may be active in a given host concurrently. In such a setting the protocol in each host must have a method of multiplexing among various active concurrent sessions. For simplicity, here we assume that each ow has an implicit or explicit session identier of the initiators, denoted sI , which is unique among all active sessions in host I , and that each ow, except perhaps the rst, has an implicit or explicit session identier of the responders, denoted sR , which is unique among all active sessions in host R. And we denote the session id s as the pair (sI , sR ). The cryptographic security issues for concurrent sessions of key-agreement protocols were rst formalized by Bellare and Rogaway [1993]. The starting point for our treatment and analysis is based on that of Canetti and Krawczyk [2001], which in turn is based on Bellare and Rogaway [1993]. See these papers for more references and comparisons with other analytical work. We briey sketch the security model below which we denote the SK-security model [Canetti and Krawczyk 2001]. Very roughly, the core security of a key-exchange protocol boils down to two requirements, correctness and pseudorandomness, which may be summarized as follows. Session-Key-Agreement Requirements: If party A generates a key K A associated with a session-identier s and peer identity B, and party B generates a key K B associated with the same session identier s and peer A, then (1) Correctness: K A must be equal to K B . (2) Pseudorandomness: K A must be indistinguishable from a truly random string to all parties except A, and B, and those parties that have broken into A or B or have compromised that session of A or B. These requirements must remain true even in the presence of adversaries. There are two essential ideas in modeling the adversary in the SK-security model. The rst is to model the network as a star with the adversary at the hub. All messages sent from one host intended for another host rst go to the adversary. Furthermore, the adversary can modify, reroute, stall, reorder, inject, and/or drop any and all messages. This captures the adversarys ability to
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
Just Fast Keying: Key Agreement in a Hostile Internet
257
mount man-in-the-middle attacks, as well as eavesdropping on packets before sending them on their way to the intended recipient. The second modication is to allow the adversary to control the timing of events and thus, for example, to control the interleaving of sessions made possible by the concurrent capability of the protocol. In this model the protocol is event/message driven. In particular, a protocol session in a host may be initiated by an initiate-session event in the host itself, in which case the host is the initiator in that protocol session. Such an event species the intended responder for that session. A protocol session in a host may also be initiated by the receipt of a message from the adversary (i.e., ostensibly from another host), in which case the host is the responder in that protocol session. The adversary is given the power to issue initiate-session events to hosts in any fashion it sees t. Recall the adversary also controls the timing of the sending and receiving of all messages. The adversary can thus create arbitrary interleavings of messages of multiple sessions within the same host. As alluded to above, a key-agreement protocol is said to be SK-secure if it meets the security requirements above even in the face of an adversary with the above powers that runs in a feasible amount of time. But to be a bit more precise we need to expand on the pseudorandomness requirement, which is to say we need to describe the meaning of pseudorandomness in our context, and the capabilities given to the adversary in its attempt to distinguish a session key from a truly random string. In addition to dynamically initiating sessions and controlling the timing/content of all received messages, the adversary is allowed to make session-key queries. That is, it is allowed to dynamically query a host of its choosing and receive the session key of its choosing of any thus-far completed sessions of that host. (This models compromise of a key by some other protocol that uses the key and perhaps leaks information about it.) The adversary is also allowed to make session-state queries and long-term key queries (which model different levels of break-ins to the parties). That is, it is allowed to dynamically query and receive the internal information the of session and the long-term keys of the hosts of its choosing. Note that after the adversary has received the long-term keys of a host, all of the session keys subsequently agreed to with that host will be known to the adversary. The adversary must at some point ask for a challenge query. That is, it dynamically chooses a host and a thus-far completed session as the test session. It receives in response a challenge string that is either the session key of the test session or a random string of the same length with equal probability. The adversary may continue to query and receive session keys or long-term keys after it has made its challenge query. Eventually, the adversary must output an answer that is either random string or session key. The goal of an adversary is for its probability of being correct to exceed 1/2 by as much as possible. The session keys of a protocol meet the pseudorandom requirement as long as the probability that any feasible adversary is correct is at most 1/2 plus a negligible amount. The alert reader will notice that the adversary can always win the above game with probability 1 unless some additional restrictions are imposed. In particular, the adversary is not allowed to have queried at any time either endpoint host of the test session for the session key of that session or for the
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
258
W. Aiello et al.
long-term keys of that host. But these are the only restrictions placed on the behavior of the adversary. Note that a protocol that is secure in this sense is very robust. For example, if an adversary, even one that sees every message between every host, breaks into one session, the rest of the session keys agreed to by the various hosts do not become compromised in any discernible way. In a very strong sense the session keys among all of the sessions behave as independent random strings in terms of computational distinguishability. There is no discernible correlation even between session keys of concurrent sessions in the same host. In fact, as was shown in Canetti and Krawczyk [2002b], this notion of security guarantees strong secure composability properties. We stress that this is only a rough sketch of the requirement. For full details see Canetti and Krawczyk [2001, 2002a]. We rst discuss the protocols in the restricted case where the parties do not reuse the private DH exponents for multiple sessions. 4.1.1 The Core Cryptographic Protocol of JFKi. The basic cryptographic core of this protocol is the same as the ISO 9798-3 protocol. This protocol can be briey summarized as below. For subsequent discussion, B plays the role of the initiator and A plays the role of responder. We call this protocol JFKi A B : N B , B, g b A B : N A , N B , A, g a , S A [N A , N B , g a , g b, B] A B : N A , N B , S B [N A , N B , g a , g b, A] (1) (2) (3)
A salient point about this protocol is that each party signs, in addition to the nonces and the two public DH exponents, the identity of the peer. If the peers identity is not signed then the protocol is completely broken. JFKi inherits the same basic core security. In addition, JFKi adds a preliminary cookie mechanism for DoS protection (which results in adding one ow to the protocol and having the responder in JFKi play the role of A), and encrypts the last two messages in order to provide identity protection for the initiator. We will discuss these additions further below. The session key for JFKi is derived from a pseudorandom function H with key g ab and input N A , N B and output of the appropriate length for the subsequent session. The JFKi protocol was analyzed and proven secure in Canetti and Krawczyk [2001]. That is, Canetti and Krawczyk [2001] show that the protocol is SKsecure if the signature scheme is secure, the pseudorandom function H is secure, and the decisional DifeHellman (DDH) assumption holds. As we later will need to strengthen this latter assumption we discuss it briey below. The DDH problem for the cyclic group G is as follows. With equal probability the input is either a DH tuple ( g , g a , g b, g ab) or a random tuple ( g , g a , g b, g r ), where g is a generator of G, and where a, b, and r are random in {1, 2, . . . , |G|}. The output is a declaration saying that the input is a DH tuple or that the input is a random tuple. The DDH assumption holds for a group G if for all feasible algorithms the probability that the algorithm is correct at most 1/2 plus a negligible amount.
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
Just Fast Keying: Key Agreement in a Hostile Internet
259
4.1.2 The core cryptographic protocol of JFKr. The basic cryptographic core of JFKr follows the design of the SIGMA protocol [Krawczyk 2002] (which also serves as the basis to the signature mode of IKE). SIGMA was analyzed and proven secure in Canetti and Krawczyk [2002a]. This basic protocol, called JFKr for in the ensuing discussion, can be briey summarized as follows: A B : NB, g b A B : N A , N B , A, g a , S A [N A , N B , g a , g b], HK a ( N A , N B , A) A B : N A , N B , B, S B [N A , N B , g a , g b], HK a ( N A , N B , B) (1) (2) (3)
Here, neither party signs the identity of its peer. Instead, each party includes a MAC applied to its own identity (concatenated with N A and N B ). The key for the MAC and the session key are derived as in JFKr from a pseudorandom function H with key g ab and inputs N A , N B , 2 and N A , N B , 0, respectively. The proof of security of JFKr [Canetti and Krawczyk 2002a] assumes that the signature scheme is secure, that H is a secure MAC, that H used for key derivation is a secure pseudorandom function, and that the DDH assumption holds. Note that the function used for the MAC on the wire need not be the same as the function used for key derivation. For protocol simplicity we have assumed they are the same. In the next section, we discuss the security implications of the encryption of the third and fourth ows in the JFK protocols. In the subsequent section, we dene a formal model of identity protection and discuss how it is achieved by virtue of the security of the encryption. Finally, we discuss the security implications of the DoS protection mechanisms employed in the JFK protocols. 4.2 Adding Encryption to the Protocols In this section, we discuss the security issues associated encrypting and MACing the last two ows. The impetus for adding encryption to the third and fourth ows of the JFK protocols is identity protection which we will discuss more formally in the next section. And proving that these ows actually enjoy the appropriate encryption property is an important step in proving identity protection, as we will discuss below. But the parties may want other information, such as policy information, to remain condential in these ows as well. Thus, the condentiality property of these ows is important in its own right. In both JFKi and JFKr, the third and fourth ows are encrypted and then MACed. The encryption is assumed to be secure against adaptive chosen plaintext attacks (CPA encryption). If the keys for the encryption and the MAC can be shown to be pseudorandom then CPA encryption followed by a secure MAC yields a condentiality scheme that is secure against adaptive chosen ciphertexts attacks. Thus the condentiality property of these ows rests on the pseudorandomness of the encryption and MAC keys. Recall that the keys for the encryption and the MAC are derived by H g ir (N I , N R , 1) and H g ir (N I , N R , 2) whereas the session key is derived
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
260
W. Aiello et al.
by H g ir (N I , N R , 0). The pseudorandomness of these values depends on the pseudorandomness of the DH value g ir , which in turn depends on the DDH assumption. It is tempting to conclude that since the session key has been proven to be pseudorandom for protocols essentially identical to JFKi and JFKr except that the encryption and MACing are not present, that the encryption and MAC keys are also pseudorandom given that they are derived in the same manner. It is also tempting to conclude that since the security of the session keys of, say, JFKi and JFKr are secure that this immediately implies that the session keys of JFKi and JFKr are secure. Unfortunately, given the details of the model described above, this does not follow. The essential reasons are as follows. In the standard SK-security model described above, the adversary only queries for the session key in a host if that session is completed in that host. But the adversary may attempt to break the condentiality of, say, the third ow without allowing the session to complete. Moreover, in JFKi and JFKr more artifacts of g ir (i.e., the encryptions and MACs using keys derived from g ir ) are available to the adversary than in JFKi and JFKr . Intuitively, these artifacts seem to be computationally useless to the adversary. Indeed, they would be if g ir were pseudorandom but this is what we are trying to prove in the rst place. To break this circular reasoning, we must prove something stronger than what is proven in the SK-security model of Canetti and Krawczyk [2001]. We must effectively show that g ir is pseudorandom in a well-dened sense before it is used to derive the encryption and MAC keys. Intuitively, this guarantees that the encryptions and MACs thus leak no discernible information about g ir for the remainder of the session. Thus, g ir remains pseudorandom until the end of the session and the hosts can use it to derive a pseudorandom session key. In such a case, we would have the simultaneous pseudorandomness of all of the keys. More formally, we augment the SK-security model beyond that in Canetti and Krawczyk [2001] as follows. For JFKi and JFKr we allow the adversary to make a session-symmetric-keys query for K a and K e of a session after either the initiator has sent the third ow or after the responder has received the third ow. We also allow the adversary to ask for a session-symmetric-keys test for a host and session of its choosing in which it is presented with equal probability either the K a and K e of that session or a random string of the same length. As with the session-symmetric-keys query, the test is either after the initiator has sent the third ow or the responder has received the third ow. After asking for the test, the adversary may continue to make sessionsymmetric-keys queries, session-key queries, and long-term key queries. The adversary must eventually output an answer that is either random string or session symmetric keys. The goal of an adversary is for its probability of being correct to exceed 1/2 by as much as possible. The encryption and MAC keys of our protocols are pseudorandom as long as the probability that any feasible adversary is correct exceeds 1/2 by only a negligible amount. The only restriction is that the adversary may not make session-symmetric-keys queries or long-term key queries of the matching host of the session-symmetric-keys test. This restriction can be described precisely but we omit the details here.
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
Just Fast Keying: Key Agreement in a Hostile Internet
261
We can prove the simultaneous pseudorandomness of the encryption keys, the MAC keys, and the security of the session keys (i.e., correctness and pseudorandomness) for both JFKi and JFKr. The proof of security assumes that the signature scheme is secure, that H is a secure MAC, that the encryption scheme is secure against adaptive plaintext attacks, that the H used for key derivation is a secure pseudorandom function, and that the DDH assumption holds. The security of the encryption and MACs of the JFK protocols goes most of the way toward providing identity protection. Nonetheless, there are some additional subtitles that are useful to formalize and we do so below. Using the security of the encryption and MAC of the JFK protocols the following can be shown to follow. Both JFKi and JFKr provide identity protection against passive adversaries. Furthermore, JFKr provides identity protection against active adversaries for the responder and JFKi provides identity protection against active adversaries for the initiator. 4.3 DoS Protection There are two elements to the DoS protection in JFKi and JFKr. The rst is the cookie in the responders rst reply that enables the responder to not have to store any per session state. The addition of this cookie to the core cryptographic protocols above does not reduce the security. That is, an adversary that breaks the protocol with the cookie can be used to create an adversary that breaks the protocol without the cookie. This reduction is straightforward and the details are omitted here. We thus consider below the variants of JFKi and JFKr, which do not include these cookies. The second element of DoS protection is to not require the responder to perform any public-key operations in its rst reply. To achieve this we do two things. First we add an extra ow at the beginning of the protocol that effectively reverses the roles of A and B in JFKi and JFKr above. In particular, the responder does not have to produce a fresh signature for each of its rst replies as in JFKi and JFKr . Second, we allow the responder (and initiator) to reuse a DH value as often as it sees t before erasing it and using a new DH value. The addition of the extra round does not affect the security analysis for the session keys beyond that of, say, JFKi and JFKr above. However, allowing the reuse of DH values creates two main difculties. The rst requires further changes to the security model above and the second requires a stronger assumption on the cryptographic primitives. We will discuss these issues in turn below. 4.3.1 PFS and Adaptive Forward Secrecy. A standard security require ment for a secret key-agreement protocol is PFS [Gunther 1989; Dife et al. 1992a]. Intuitively, PFS guarantees that compromises of a host at time t do not allow an adversary to determine session keys that have been generated and subsequently erased before time t. The models discussed above capture this property, in part. Specically, even if an adversary sees all of the session keys generated by a host after it chooses a test session in that host, the session key of the test session is still indistinguishable from random for an SK-secure protocol.
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
262
W. Aiello et al.
In the case when the hosts always use a fresh, random DH value for each session, the models are easily modied to capture all of the PFS requirement. All that is necessary is the partial removal of a restriction placed on the adversary. In the models above, the adversary is not allowed to have made a long-term key query of either of the hosts of the completed test session, either before it made the test session or after. To model PFS, the adversary is allowed to make long-term key queries (in addition to the session-key queries that it is already allowed) of the hosts of a test session after the session is complete (but it is still not allowed to have made a long-term key query of either of the hosts of the test session before the test session is begun). A protocol achieves PFS security if it is secure against this more powerful adversary. Assuming that all hosts delete g ir as soon as possible, JFKi and JFKr achieve PFS when they use fresh, random DH values for each session. We now discuss the security of JFKi and JFKr in the case that hosts reuse their DH exponent and value over multiple KE-sessions within a given time period. This provides some measure of protection against DoS attacks. But it comes at the price of slightly weakening the PFS. To see this suppose that the test session of the adversary involves a responder that was using the DH exponent and value r and g r , respectively, for that session. Suppose that the responder continues to use these values and the adversary subsequently breaks into this host. In this case the adversary can clearly compromise the test session key. In spite of this, the JFK protocols with DH reuse still enjoy an intermediate level of forward secrecy, which we call adaptive forward secrecy (AFS). The intuition is as follows. We consider that the DH exponent and value are used in phases by a host. During a phase, a single DH exponent and value are used for all sessions that are initiated in that phase. A host may choose new DH values and begin a new phase at any time, and it may make that decision to start a new phase in an adaptive manner. (We assume here that when a new phase starts, the DH values of the previous stage are erased and any received messages generated by sessions started with previous DH values receive a failure reply. We can also model protocols that keep several DH values in memory for received messages but for simplicity we do not consider that here.) Clearly, with such a protocol, if an adversary breaks into a host even at the end of a phase, all of the session keys generated during that phase would be compromised. But some protocols may have the property that even if a host is broken into during a phase, all session keys generated during all previous phases remain secure. Protocols with this property are said to have AFS. To formalize AFS, we modify the basic denition of SK-security yet again (this modication comes instead of the modication leading to the denition of PFS). The modication is as follows. On top of its usual capabilities in the SK model, we provide the adversary with a new capability: At any time during the computation, the adversary can activate a new AFS phase in a host of its choosing. In response, the protocol may instruct the host to perform some protocol steps. The distinguishing game for the adversary is the same as in the rst SK security denition but with a new restriction on the adversarys long-term key
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
Just Fast Keying: Key Agreement in a Hostile Internet
263
queries. There cannot be a long-term key query of either host of the test session at any time during either AFS phase in which the test session was initiated and completed. A natural four round variant of JFKr and JFKi without the encryption and MACing for identity protection but with DH reuse can be shown to have AFS security under the DDH assumption. However, as we will discuss below, the DDH assumption is not sufcient for AFS security or identity protection when the third and fourth ows of the JFK protocols are encrypted and MACed. 4.3.2 The Malleability of DH Values. Reusing the DH values for multiple sessions may potentially cause another problem, which is unrelated to forward secrecy, and has to do with the core security of the protocol. Let us sketch this potential problem and the way we deal with it in the analysis. Consider the following scenario in JFKi. The adversary starts a new AFS phase in hosts I and R and records an entire session-key protocol, where I and R play the role of the initiator and responder, respectively. The adversary subsequently gives an initiate-session event to I with responder R. The adversary receives the rst ow from I but does not pass it on to R. Instead, it sends back to I a replay of Rs previous ow 2 but with I s new nonce and a new DH value, say, g 2r . Note that the adversary can easily compute this given just the g r it saw in the rst complete session. I receives this message, calculates new encryption and MAC keys using H with function key g 2ir , and sends ow 3 to the adversary. This is precisely where a problem occurs with the standard security assumptions of our the cryptographic primitives. The security of a pseudorandom function such as H assumes that the function keys used by H are random and independent. But here the adversary has induced I to compute H using a pair of function keys that are random but not independent. In fact, the dependence is set by the adversary. This is an example of the malleability of the DH key exchange. In this example one function key is the square of the other. To achieve a proof of AFS security and identity protection when DH values are reused in the JFK protocols we require stronger assumptions on our cryptographic primitives. Rather than using the standard pseudorandom function security assumption for H and the standard DDH assumption, we use what we call the combined H/DDH security assumption. Roughly, this assumption is as follows. An adversary is given g , g r , and g i , for random i and r, and in addition is given H g ir (x) for a known x potentially of its choosing. Combined H/DDH security requires that this value remains computationally indistinguishable from a random value even when the adversary queries for and is given the values of Hk ( y) for ys of its choosing and ks of the form ur or vi , for u or v of its choosing in G. The only restriction is that it may not choose y = x and u = g i or y = x and v = g r since in these cases the query would return the value H g ir (x) itself. As an example, since the adversary knows g i , it can compute a u of the form ik g for a k of its choosing. It can subsequently query H with key g ikr . While the exact value of the two keys remains unknown to the adversary, it does know that the second key is a kth power of the original DH key.
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
264
W. Aiello et al.
Fig. 1. Four-message StS key-agreement protocol.
Using this combined H/DDH assumption, in concert with secure signatures, encryption, and MACS, we can show that the JFK protocols with DH reuse achieve AFS security and identity protection. 5. RELATED WORK The basis for most key-agreement protocols based on public-key signatures has been the Station-to-Station (StS) [Dife et al. 1992a] protocol. In its simplest form, shown in Figure 1, this consists of a DH exchange, followed by a public-key signature authentication step, typically using the RSA algorithm in conjunction with some certicate scheme such as X.509. In most implementations, the second message is used to piggy-back the responders authentication information, resulting in a three-message protocol, shown in Figure 2. Other forms of authentication may be used instead of public-key signatures (e.g., Kerberos[Miller et al. 1987] tickets, or preshared secrets), but these are typically applicable in more constrained environments. While the short version of the protocol has been proven to be the most efcient [Gong 1995] in terms of messages and computation, it suffers from some obvious DoS vulnerabilities. 5.1 Internet Key Exchange (IKE) The Internet key-exchange (IKE) protocol [Harkins and Carrel 1998] is the current IETF standard for key establishment and SA parameter negotiation. IKE is based on the ISAKMP [Maughan et al. 1998] framework, which provides encoding and processing rules for a set of payloads commonly used by security protocols, and the Oakley protocol, which describes an adaptation of the StS protocol for use with IPsec.2 The public-key encryption modes of IKE are based on SKEME [Krawczyk 1996].
2 We
remark, however, that the actual cryptographic core of IKEs signature mode is somewhat different than Oakley. In Oakley the peer authentication is guaranteed by having each party explicitly
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
Just Fast Keying: Key Agreement in a Hostile Internet
265
Fig. 2. Three-message StS key-agreement protocol.
IKE is a two-phase protocol: during the rst phase, a secure channel between the two key-management daemons is established. Parameters such as an authentication method, encryption/hash algorithms, and a DH group are negotiated at this point. This set of parameters is called a Phase I SA. Using this information, the peers authenticate each other and compute key material using the DH algorithm. Authentication can be based on public-key signatures, public-key encryption, or preshared passphrases. There are efforts to extend this to support Kerberos tickets [Miller et al. 1987] and handheld authenticators. It should also be noted that IKE can support other key establishment mechanisms (besides DH), although none has been proposed yet.3 Furthermore, there are two variations of the Phase I message exchange, called main mode and aggressive mode. Main mode provides identity protection, by transmitting the identities of the peers encrypted, at the cost of three message round trips (see Figure 3). Aggressive mode provides somewhat weaker guarantees, but requires only three messages (see Figure 4). As a result, aggressive mode is very susceptible to untraceable4 DoS attacks against both computational and memory resources [Simpson 1999]. Main mode is also susceptible to untraceable memory exhaustion DoS attacks, which must be compensated for in the implementation using heuristics for detection and avoidance. To wit: The responder has to create state upon receiving the rst message from the initiator, since the Phase I SA information is exchanged at that point. This allows for a DoS attack on the responders memory, using random source-IP addresses to send a ood of requests. To counter this, the responder could
sign the peer identity. In contrast, IKE guarantees peer authentication by having each party MAC its own identity using a key derived from the agreed DH secret. This method of peer authentication is based on the SIGMA design [Krawczyk 2002]. 3 There is ongoing work (still in its early stages) in the IETF to use IKE as a transport mechanism for Kerberos tickets, for use in protecting IPsec trafc. 4 The attacker can use a forged address when sending the rst message in the exchange.
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
266
W. Aiello et al.
Fig. 3. IKE main mode exchange with certicates.
Fig. 4. IKE aggressive mode exchange with certicates.
employ mechanisms similar to those employed in countering TCP SYN attacks [Heberlein and Bishop 1996; CERT 1996; Schuba et al. 1997]. JFK maintains no state at all after receiving the rst message. An initiator who is willing to go through the rst message round trip (and thus identify her address) can cause the responder to do a DH exponential generation as well as the secret key computation on reception of the third message of the protocol. The initiator could do the same with the fth message of the protocol, by including a large number of bogus certicates, if the responder blindly veries all signatures. JFK mitigates the effects of this attack by reusing the same exponential across different sessions.
ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004.
Just Fast Keying: Key Agreement in a Hostile Internet
267
The second phase of the IKE protocol is commonly called quick mode and results in IPsec SAs being established between the two negotiating parties, through a three-message exchange. Parameters such as the IP security protocol to use (ESP/AH), security algorithms, the type of trafc that will be protected, and so on, are negotiated at this stage. Since the two parties have authenticated each other and established a shared key during Phase I, quick mode messages are encrypted and authenticated using that information. Furthermore, it is possible to derive the IPsec SA keying material from the shared key established during the Phase I DH exchange. To the extent that multiple IPsec SAs between the same two hosts are needed, this two-phase approach results in faster and more lightweight negotiations (since the same authentication information and keying material is reused). Unfortunately, two hosts typically establish SAs protecting all the trafc between them, limiting the benets of the two-phase protocol to lightweight rekeying. If PFS is desired, this benet is further diluted. Another problem of the two-phase nature of IKE manifests itself when IPsec is used for ne-grained access control to network services. In such a mode, credentials exchanged in the IKE protocol are used to authorize users when connecting to specic services. Here, a complete Phase I & Phase II exchange will have to be done for each connection (or, more generally, trafc class) to be protected, since credentials, such as public-key certicates, are only exchanged during Phase I. IKE protects the identities of the initiator and responder from eavesdroppers.5 The identities include public keys, certicates, and other information that would allow an eavesdropper to determine which principals are trying to communicate. These identities can be independent of the IP addresses of the IKE daemons that are negotiating (e.g., temporary addresses acquired via DHCP, public workstations with smartcard dongles, and so on). However, since the initiator reveals her identity rst (in message (5) of Main Mode), an attacker can pose as the responder until that point in the protocol. The attackers cannot complete the protocol (since they do not possess the responders private key), but they can determine the initiators identity. This attack is not possible on the responder, since she can verify the identity of the initiator before revealing her identity (in message (6) of Main Mode). However, since most responders would correspond to servers (rewalls, web servers, an...