Just F**as**t Keying in the Pi CalculusMartín Abadi 1 , Bruno Blanchet 2 , and Cédric Fournet 31 University of California, Santa Cruz2 CNRS, Département d’Informatique, École Normale Supérieure, Parisand Max-Planck-Institut für Informatik, Saarbrücken3 Microsoft ResearchAbstract. JFK is a recent, attractive protocol for f**as**t key establishment **as** partof securing IP communication. In this paper, we analyze it formally in the appliedpi calculus (partly in terms of observational equivalences, partly with the**as**sistance of an automatic protocol verifier). We treat JFK’s core security properties,and also other properties that are rarely articulated and studied rigorously,such **as** resistance to denial-of-service attacks. In the course of this analysis wefound some ambiguities and minor problems, but we mostly obtain positive resultsabout JFK. For this purpose, we develop ide**as** and techniques that should beuseful more generally in the specification and verification of security protocols.1 IntroductionThe design of security mechanisms for the Internet h**as** been the focus of much activity.In particular, IP security h**as** received much attention; in this area, we have seen someprogress but also some disappointment and some controversy. The Internet Key Exchange(IKE) protocol [12], an important method for establishing cryptographic keysfor secure IP communication, h**as** been the subject of considerable and re**as**onable criticisms.Those criticisms tend to concern not the core authenticity and secrecy propertiesthat IKE offers but rather the complexity of IKE, some of its inefficiencies, and its poorresistance against denial-of-service (DOS) attacks. Several recent protocols aim to addressIKE’s shortcomings. These include the JFK protocol [6,5] (for “just f**as**t keying”)and the IKEv2 protocol [13], currently under development.In some respects, IKE and its successors are fairly cl**as**sical security protocols. Theyall employ common pieces in the standard arsenal of modern cryptography, and aimto guarantee the integrity and secrecy of IP communication. They are all subject tocommon efficiency considerations, which limit the use of expensive cryptographic operationsand the number and size of messages. Beyond such b**as**ic **as**pects, however,these protocols—and JFK in particular—exhibit a number of interesting features becausethey address other security objectives. These other objectives are sometimes subtle;they are seldom articulated precisely. Moreover, they give rise to new tensions anddelicate compromises. For instance, in the name of privacy, a protocol may attemptto hide the identities of the participants (that is, to provide identity protection) and toguarantee the plausible deniability of their actions, and may accordingly avoid or delaythe authentication of the participants. On the other hand, strong, early authenticationcan simplify DOS resistance. Of course, such tensions are not unique to JFK and itsclose relatives. Rather, they seem to be incre**as**ingly important in the design of modernsecurity protocols. JFK exemplifies them well and resolves them nicely.In this paper we analyze JFK, relying on the applied pi calculus, an extension of thestandard pi calculus with functions. Specifically, we present a formalization of one ofthe two variants of JFK known **as** JFKr (the one closer to IKEv2). While fairly shortand abstract, our formalization gives a fine level of detail in the modelling of contextsand parallel sessions. It also covers **as**pects of the protocol beyond the “messages on thewire”, such **as** protocol interfaces, the checks performed by the participants, and otherdelicate features such **as** the treatment of duplicate requests.We treat several properties of the protocol, such **as** plausible deniability and DOSresistance. (We consider all the properties with a single model of the protocol: we do notneed to define special, partial models for particular properties.) We also provide proofsfor those properties. Some of the proofs were done by hand, while others were done withan automated protocol verifier, ProVerif [7]. In some c**as**es, there are overlaps betweenthe two kinds of proofs; those overlaps provide extra **as**surance about the correctness ofthe formalization and the proofs. Moreover, while ProVerif can be used for establishingstandard security properties such **as** correspondence **as**sertions, it is still limited when itcomes to subtler properties, which we therefore prove partly by hand.In the course of this analysis, we identified some minor limitations and weaknessesof JFK. In particular, we discovered that JFK does not provide **as** much identity protection**as** one might have expected on the b**as**is of informal descriptions of the protocol.However, we did not discover fatal mistakes. That is comforting but not surprising,since the authors of JFK have substantial experience in protocol design and since JFKbenefited from careful review and prolonged discussion in the IETF context.Beyond observations and results on JFK, this study contributes to the specificationand verification of security protocols in several ways. Our b**as**ic approach and toolscome from recent work; it is ple**as**ing to confirm their effectiveness. On the other hand,the approach to formalizing several of the protocol’s less mundane facets is largelynew, and should be applicable elsewhere. Similarly, the proofs are non-trivial and motivatesome new developments of our techniques. These novelties include a formulationof plausible deniability, a general lemma about state elimination, and extensions inProVerif. The proofs also provide an opportunity for integrating manual and automaticmethods in the applied pi calculus.Contents The next section is a review and informal discussion of JFK. Section 3presents a model of JFKr in the applied pi calculus. Section 4 treats DOS resistance.Section 5 concerns core security properties (secrecy and authenticity). It also brieflyaddresses identity protection. Section 6 mentions some related work and concludes.Because of space constraints, this version of the paper omits much material thatappears in an extended version [3]: a discussion of the ambiguities and minor problemsthat we found, a description and partial analysis of the protocol variant JFKi, a reviewof the applied pi calculus, further material on identity protection and on DOS resistance,a study of plausible deniability, details on our use of ProVerif, and proofs.An earlier version of this paper appears in the proceedings of the 13th European Symposium on Programming.D. A. Schmidt (Ed.): ESOP 2004, LNCS 2986, pp. 340–354. c○ Springer-Verlag Berlin Heidelberg 2004.2

2 The JFK ProtocolThe JFK protocol h**as** been discussed in a series of five Internet Drafts [6], starting in2001, and it is also described in a conference paper [5]. While our work is b**as**ed onall those documents, we tend to privilege the contents of the conference paper, sinceit should have some permanence. We refer to that paper for additional material on theprotocol and its motivation. As indicated above, we focus on a variant called JFKr.JFKr involves two principals that play the roles of an initiator and a responder. Asin many other protocols, these two principals wish to open a secure communicationchannel, and they attempt to accomplish it by establishing a shared secret. This sharedsecret serves **as** the b**as**is for computing session keys. The two principals should **as**sociatethe shared secret with each other, verify each other’s identities, and also agree onvarious communication parameters (for example, what sort of session keys to employ).Attackers may eavesdrop, delete, and insert messages; they may also attempt to impersonateprincipals [19]. Therefore, the communications between the initiator and theresponder are cryptographically protected. Informally, JFKr consists of the followingfour messages:where:x I = g ˆd IMessage 1 I → R : N I , x IMessage 2 R → I : N I , N R , x R , g R , t RMessage 3 I → R : N I , N R , x I , x R , t R , e I , h IMessage 4 R → I : e R , h RK u = H{x R ˆd I }(N I , N R , u)for u = a, e, vx R = g ˆd Rt R = H{K R }(x R , N R , N I , IP I )e I = E{K e }(ID I , ID ′ R, sa I , s I ) e R = E{K e }(ID R , sa R , s R )h I = H{K a }(i, e I ) h R = H{K a }(r, e R )s I = S{K − I }(N I, N R , x I , x R , g R ) s R = S{K − R }(x R, N R , x I , N I )Figure 1 summarizes the notations of this exchange.The first pair of messages establishes a shared secret via a Diffie-Hellman exchange.Each principal generates and communicates a fresh nonce N z . Each principal also selectsor generates a secret exponent d z , and communicates the corresponding exponentialx z = g ˆd z . Relying on the equation x R ˆd I = x I ˆd R , three independent sharedkeys are derived from nonces and exponentials: K a and K e are used in Messages 3and 4, while K v is returned to each principal **as** the newly-established session secret.The reuse of exponentials is allowed, with a trade-off between forward secrecy and efficiency;in any c**as**e, the freshness of nonces suffices to guarantee that the generatedshared secrets differ for all sessions.Message 2 includes an authenticator cookie t R , keyed with a secret local to theresponder, K R . The responder expects to see this cookie in Message 3, and need notperform any expensive cryptography or allocate resources until such a successful roundtripwith the initiator. Furthermore, after receiving Message 3, the responder can rememberhandling t R , so **as** to avoid expense in the event that t R is replayed.z = I, R one of the two roles in the protocol: initiator or responder.N z random fresh nonce for the session.d z Diffie-Hellman secret exponents.x z = g ˆd z Diffie-Hellman exchange values (g i and g r in [5]).g Diffie-Hellman group (possibly obtained from a previously received g R).g R responder’s choice of group g and cryptographic algorithms (GRPINFO R in [5]).t R authenticator cookie used by the responder against DOS.K R responder’s secret h**as**h key for authenticators t R (HK R in [5]).u = a, e, v one of the three usages for keys: authentication, encryption, and main session secret.K u shared key obtained by a Diffie-Hellman computation, specialized for u.E shared-key encryption function.H keyed h**as**h function for MACs (message authentication codes).e z, h z encrypted payload messages and their MACs (protecting z’s identity and signature).S public-key signature function.s z signed nonces and exponentials.Kz − private signature key for the principal playing role z.ID z identity for the principal playing role z, and its public signature-verification key.ID ′ R “hint” of the responder identity, provided by the initiator.IP I IP source address for the initiator (h**as**hed in t R).sa z additional parameters for setting IP security **as**sociations (sa and sa ′ in [5]).A, B principals, taking part in the protocol (in either or both roles).Fig. 1. Main notationsThe second pair of messages provides authentication. Specifically, Messages 3 and 4include encrypted signatures of the nonces, exponentials, and other material. The encryptionsprotect identity information. The signatures can be interpreted **as** delegationsfrom the principals that control the signature keys (possibly users) to the protocol endpointsthat control the exponents. Only transient protocol data is signed—not identitiesor long-term keys **as**sociated with users. In this respect, the protocol is in tune with concernsabout plausible deniability that have appeared from time to time in this context.The protocol specification, although clear, focuses on the messages exchanged in **as**ingle successful protocol run. It does not say much on the local processing that the partiesperform, on the deployment of the protocol, and other subjects relevant for security.For instance, it does not prescribe how principals should use the protocol (and especiallywhat is the sharing of signing keys and exponentials); how messages should bechecked; and how the responder should manage state in order to resist DOS attacks. Wehave re**as**on to believe that implementations differ in some of these respects, sometimeswith unfortunate consequences. The protocol specification does however state severalsecurity objectives. We discuss them and study them formally below.3 A Model of JFK in the Applied Pi CalculusIn this section, we express JFKr in the applied pi calculus. This calculus is an extensionof the pi calculus with function symbols, for instance for tupling and for encryption,that can be **as**sumed to satisfy particular equations. (We refer to prior work [4] for itssyntax and semantics.) So we first select function symbols and an equational theory34

M, T, U, V ::= TermsN, K, k, x, y, z variablec, n, s nameg, U ˆV Diffie-Hellman group and exponentialE{U}(T ), D{U}(T )shared-key encryption and decryptionS{U}(T ), V{U, V }(T ), truepublic-key signature and verificationPk(U)public key (and identity) from private keyH{U}(T )keyed cryptographic h**as**h functione, a, v, i, r constant tags for keyed-h**as**h specializationcons(V 1, V 2), 1(V 1, V 2), . . . , 4(V 1, V 2) constructors for pairs and formatted messagesF cons1 (T ), F cons2 (T ), F 1 1(T ), . . . , F 4 2(T ) selectors for pairs and formatted messages∅, U.V empty set and set extensionRecoverKey(V ), RecoverText(V ) additional functions for the attacker(g ˆy) ˆz = (g ˆz) ˆy Diffie-HellmanV{Pk(k), S{k}(x)}(x) = true public-key signature verificationD{k}(E{k}(x)) = xshared-key decryptionF n i(n(x 1, . . . , x i, . . . )) = x i projections for tuples (n = cons, 1, 2, 3, 4)(∅.x).x = ∅.x idempotence of set extension(x.y).z = (x.z).y commutativity of set extensionRecoverKey(S{k}(x)) = Pk(k) public key recovery from a signature (attacker)RecoverText(S{k}(x)) = xsigned text recovery from a signature (attacker)Fig. 2. Grammar and equational theory for JFKfor modelling the messages of JFKr, then we discuss our representations for the IPnetwork, attackers, and principals, and **as**semble processes that represent configurationsof principals. We also outline how we program these processes in ProVerif.An Equational Theory We use the grammar for terms and the equations of Figure 2.These deal both with cryptographic operations and with auxiliary functions for constructingtags, pairs, formatted messages, and sets. (We have functions for constructingsets, but not a set membership relation; instead, we let U ∈ V abbreviate V.U = V .)The equations embody our (fairly standard) hypotheses on the primitives introducedin Section 2. For instance, the keyed h**as**h function H{ }( ) does not appear in anyequation, and in particular h**as** no inverse; thus it represents a perfect one-way function.More interestingly, exponentiation ˆ h**as** no inverse, but an equation accounts for thecommutativity property used for establishing a shared secret. Some of the functionsand equations are not needed in the protocol itself, but may (in principle) weaken theprotocol for the benefit of an attacker: RecoverKey( ) and RecoverText( ) can be usedto extract information from signatures. We could further refine our theory by reflectingknown weaknesses of the underlying cryptographic algorithms or their interactions.Syntax and Informal Semantics for Processes We recall the main notations for processesin the applied pi calculus : 0 does nothing (and we typically omit it); P | Q is theparallel composition of P and Q; !P behaves **as** an infinite number of copies of P runningin parallel; νn.P makes a new name n then behaves **as** P ; if U = V then P else Qis standard, with U = V depending on the equational theory. The input process c(x).Pis ready to input a message on channel c, then to run P with the actual message replacedfor the formal parameter x, while the output process c〈V 〉.P is ready to output messageV on channel c, then to run P . The process let {x 1 = V 1 } | . . . | {x n = V n } in Pis P with local variables x 1 , . . . , x n bound to V 1 , . . . , V n , respectively. The active substitution{x 1 = V 1 } | . . . | {x n = V n } similarly defines x 1 , . . . , x n , but does not restricttheir scope; hence, the environment can use x 1 , . . . , x n **as** ali**as**es for V 1 , . . . , V n in itscomputations. A context C[ ] is a process with a hole, and C[P ] is the result of fillingC[ ]’s hole with P ; when is not under a guard, C[ ] is an evaluation context.Labelled transitions P −−−→ a(V )Q and P −−−−−→ νũ.a〈V 〉Q represent interactions with theenvironment—inputs and outputs, respectively. In both, a is a communication channeland V a message. Transitions P → Q represent internal computation steps.Syntactic Sugar We write if M then P instead of if M = true then P . We omit pairconstructors and parentheses for nested pairs, writing for instance H{K}(x R , N R , N I )for H{K}(cons(x R , cons(N R , N I ))). We use pattern matching on tuples **as** syntacticsugar for the corresponding selectors, writing for instance c(1(=N I , x I )).P insteadof c(z).let {x I = F 1 2(z)} in if z = 1(N I , x I ) then P for some fresh variable z; thisprocess receives a message on channel c, matches it with 1(N I , T ) for some subterm T ,then runs P with T substituted for x I . We also define syntax for filtering duplicatemessages: !a(X)\V.C[if T fresh then P ] stands forνf. ( f〈V 〉 | !a(X).C[f(s).(f〈s.T 〉 | if T /∈ s then P )] )where C[ ] is a context, X is a pattern, f is a fresh channel name, and s is a freshvariable. We use the local channel f for maintaining a set V of previous values for theterm T . The arrival of a message may cause the addition of a particular T (which maydepend on variables bound in X) to this set, and the execution of P .The Network and the Attacker In our model, all IP messages are transmitted on a freepi calculus communication channel, c, which represents a public IP network in whichmessage contents serve for differentiating traffic flows. An arbitrary environment (anarbitrary evaluation context) represents the attacker. This environment can interact withother principals by inputs and outputs on any free channel, including c.As a special c**as**e, we sometimes model a weaker, p**as**sive attacker that only eavesdropson messages but does not modify them. An attack step against a process P consistsin eavesdropping on a message sent by P , and amounts to a message interception(formally, with an output label νũ.c〈V 〉) followed by a re-emission of the same message(with an input label c(V )). We write P νũ.c[V −−−−→ ]P ′ **as** a shorthand for the twotransitions P −−−−−→ νũ.c〈V 〉−−−→ c(V )P ′ .Configurations of Principals Our model allows an arbitrary number of principals. Eachprincipal may run any number of sessions, **as** initiator and **as** responder, and may performother operations after session establishment or even independently of the protocol.Only some of these principals follow the protocol. We are interested in the securityproperties that hold for them.56

For the present purposes, the essence of a principal lies in its ability to producesignatures verifiable with its public key. Accordingly, we refer to each principal byits public key, using variables ID A , ID B ,. . . for both identities and public keys. Wealso **as**sociate the context P K A [ ] of Figure 3 with every principal A. This contextrestricts the use of the signing key K − Ato the process in the context and it exports thecorresponding verification key ID A . Whenever we put a process R in this context, ourintent is that R never communicates K − Ato the environment.We let C range over sets of compliant principals—that is, principals that entirely delegatethe use of their signing keys to JFKr. While some properties will obviously holdonly for compliant principals, the initiator and responder code do not **as**sume knowledgeof C: indeed, compliant and non-compliant principals can attempt to establish sessions.Our representation of a compliant principal A h**as** two parts: an implementation ofJFKr, written S, and a “user process”, written P A . The user process defines any additionalbehavior, such **as** when protocol runs are initiated and what happens to the sharedsecret K v after each session establishment. While we define S below, we treat P A **as**an abstract parameter, in the context that encloses S, possibly under the control of theattacker. The user process interacts with S through the following control interface:As initiator: P A sends a message init A 〈ID ′ R, sa I 〉 to initiate a new session, with responderhint ID ′ R and security **as**sociation sa I . When the protocol completes successfully,S sends connect A 〈ID B , ID ′ R, sa I , sa R , K v 〉 to notify P A that the sessionh**as** been accepted, and that A now shares K v with a principal with identifier ID B .As responder: S sends accept A 〈ID B , ID ′ R, sa I , sa R , K v 〉 to notify P A that it h**as** accepteda session initiated by a principal with identifier ID B , parameters ID ′ R, sa I ,sa R and shared secret K v . To control who can initiate a session with A, S is parameterizedby a set SIA of acceptable initiator identities. (We do not need a set such **as**SIA at the initiator: after completion of the protocol, the initiator’s user process candecide what to do with the new session depending on the responder identity in theconnect message.) For simplicity, SIA and sa R are fixed.Thus, the interface between each principal A and JFKr consists of three communicationchannels init A , accept A , connect A plus a set of identities SI A . These channels can berestricted (with ν) in order to hide the interface from the environment. For instance, aprincipal A that does not play the role of an initiator can be modelled e**as**ily by restrictingcommunication on init A .The Protocol Figure 3 shows our implementation of JFKr in the applied pi calculus.It includes definitions of processes for each role: a single process (I A 0 ) for the initiator,and two processes (R A 1 , R A 3 ) that do not share session state for the responder. For eachprincipal A, these replicated processes detail the tests performed on incoming messages,interleaved with the computations on outgoing messages. The figure also includes thedefinition of a configuration S: an **as**sembly of an arbitrary but fixed set of compliantprincipals C that potentially share an arbitrary but fixed pool of exponentials X.The design of JFK allows reusing Diffie-Hellman exponents for several sessions,principals, and roles, and does not impose a particular policy for changing them. Foreach exponent, one can decide when to stop using that exponent in new sessions. ForI0 A = !init A (ID ′ R, sa I). Initiator for each message initνN I.create a fresh noncec〈1(N I, x I)〉. send Message 1c(2(=N I, N R, x R, g R, t R)). wait for Message 2let κ I incompute DH shared keys (see below)let {s I = S{K − A}(NI, NR, xI, xR, gR)} in signlet {e I = E{K e}(ID A, ID ′ R, sa I, s I)} in encryptlet {h I = H{K a}(i, e I)} incompute MACc〈3(N I, N R, x I, x R, t R, e I, h I)〉. send Message 3c(4(e R, h R)). wait for Message 4if H{K a}(r, e R) = h R thencheck MAClet {ID R, sa R, s R = D{K e}(e R)} in decryptif V{ID R, s R}(N I, N R, x I, x R) then check signatureconnect A 〈ID R, ID ′ R, sa I, sa R, K v〉 complete keyingR1 A = !c(1(N I, x I)). Responder for each Message 1νN R.create a fresh noncelet {t R = H{K R}(x R, N R, N I)} in compute anti-DOS tokenc〈2(N I, N R, x R, g R, t R)〉 send Message 2signR3 A = !c(3(N I, N R, x I, x R, t R, e I, h I))\∅. Responder for each Message 3if t R = H{K R}(x R, N R, N I) then check anti-DOS tokenif∏t R fresh thenaccept token only oncex∈Xif x = xR thenbranch on DH exponentiallet κ R incompute DH shared keys (see below)if H{K a}(i, e I) = h I thencheck MAClet {ID I, ID ′ R, sa I, s I = D{K e}(e I)} in decryptif ID I ∈ SI A then authorizeif V{ID I, s I}(N I, N R, x I, x R, g R) then check signatureaccept A 〈ID I, ID ′ R, sa I, sa R, K v〉.accept the sessionlet {s R = S{K − A}(NI, NR, xI, xR)} inlet {e R = E{K e}(ID A, sa R, s R)} in encryptlet {h R = H{K a}(r, e R)} incompute MACc〈4(e R, h R)〉 send Message 4S = D X[∏A∈C P KA [ I A |R A]] Compliant principal configurationI A = ∏ x I ∈X IA 0A **as** initiatorR A = νK ∏ R.(x R ∈X RA 1 | R3 A ) A **as** responderP K A [ ] = νK − A .({IDA = Pk(K− A)} | [ ])D x[ ] = νd x.({x = g ˆd x} | [ ])D X[ ] = D x1 [. . . D xn [ ]] where X = {x 1, . . . , x n}κ I = ∏ u=a,e,v {Ku = H{xR ˆdx I}(NI, NR, u)}κ R = ∏ u=a,e,v {Ku = H{xI ˆdx R}(NI, NR, u)}Fig. 3. JFKr in the applied pi calculusA’s signing and verification keysDH secret d and exchange value xshared exponentialskey computations for Ikey computations for R78

instance, an exponent may expire once the first session established using that exponentterminates, so that discarding session keys prevents their later compromise. In ourmodel, all compliant principals may use any number of shared exponentials, in bothroles, for any number of parallel sessions. Results for configurations with less sharingare immediate corollaries of ours.The context D x [ ] represents a Diffie-Hellman party, d x the corresponding secretexponent, x the derived exchange value (the exponential), and g the group (the sameone for all compliant principals). The set X contains the exponentials shared by thecompliant principals. The context D X [ ] consists of contexts D x [ ] for each x ∈ X. Forsimplicity, according to the code, compliant principals never disclose exponents.In contr**as**t with actual implementations of JFK, our model treats abstractly several**as**pects of the protocol. In particular, it uses an unambiguous format for all messages,thereby **as**suming, for instance, that the wire format for messages does not leak additionalinformation, and that ill-formed messages are safely ignored. Furthermore, itdoes not cover IP addressing, routing, and fragmentation concerns, the contents of thesecurity-**as**sociation parameters sa z , the handling of ID ′ R, the potential usage of severalgroups g, **as**pects of caching, and error messages. We made such simplifications partlyby choice, partly by necessity; the resulting model remains quite informative and rich.Script for Proof Automation We rely at le**as**t partially on ProVerif in most proofs. Forthat purpose, we code JFK configurations (S in Figure 3) in the input syntax of ProVerif(which is an ASCII syntax for the applied pi calculus), specify the properties to prove,and simply run ProVerif. The correctness of these proofs relies on the theory developedin prior work ([7,1] for secrecy, [8] for correspondence **as**sertions, [2] for someextensions). Additional details on ProVerif and our script appear in the full paper [3].The script differs superficially from S in that it gives an interface to the adversary thatenables the creation of compliant principals (and provides their identities and controlinterfaces) and of shared exponents (and provides their exponentials). These unfoldingsare best omitted in the statements of theorems. For a given configuration S, one can applyan evaluation context to the process defined in the script so that the resulting processbecomes observationally equivalent to S after exporting the exponentials, the principalidentities, and the control channels init A , accept A , and connect A .4 Resistance to Denial-of-Service AttacksWe first consider the security mechanisms at the early stages of the protocol, beforemutual authentication. These mechanisms aim at hardening JFK against certain DOSattacks relevant in IP security. Our formal analysis relies on an understanding of thecosts incurred at these stages: we characterize the occurrences of operations deemedexpensive, without a formal me**as**ure of their cost.In JFK, protocol-b**as**ed DOS is a concern mostly for the responder. By design, untilthe computation of κ R , the processing of Messages 1 and 3 is f**as**t and involves almostno state. From this point, the protocol performs CPU-intensive operations (includinga Diffie-Hellman exponentiation and two public-key operations), and allocates somesession state.Since in general, in any protocol, the processing of a message depends on the contentsof previously received messages, each principal may maintain some local state foreach session of a protocol. This state can be problematic for servers that are willing tostart a session whenever they receive a first message, before adequate authentication.Indeed, an attacker may send (or redirect) first-message traffic to the server, filling itsbuffers, and eventually causing valid session attempts to be dropped. This concern motivatesa common protocol transformation: instead of keeping state for every session inprogress, one or both parties MAC (or encrypt) the state, append the result to outgoingmessages, and check (or decrypt) the corresponding values in later incoming messagesbefore processing them. Next, we show that this transformation is correct (i.e., preservesequivalence) for a general cl**as**s of protocols coded **as** processes.We relate a sequential implementation of a protocol to a more complex but statelessimplementation, using the observational-equivalence relation, ≈. This relation is closedby application of evaluation contexts, which can represent active attackers.Lemma 1. Let C[ ] be a context that binds at most the variables ˜x 2 , let K be a freshname, let P = !c(x 3 ), andR ◦ 2 = νN.νt.c〈M 2 〉.?c(3(=t, =N, =˜x 2 , ˜x 3 )).R 4R 2 = νN.let {t = H{K}(N, ˜x 2 )} in c〈M 2 〉R 3 = !c(3(t, N, ˜x 2 , ˜x 3 ))\ ∅.if t = H{K}(N, ˜x 2 ) then if t fresh then R 4We have C[R ◦ 2] | P ≈ νK.(C[R 2 ] | R 3 ) | P .In R ◦ 2, we rely on syntactic sugar for pattern-matching with a retry until a messagethat matches the pattern X is received, writing ?c(X).R for νl.(l〈〉 | !c(X).l().R).(In our automated proofs, we need to use an equivalent but more verbose encoding:νl.(!c(X).l〈˜x〉 | l(˜x).R), where ˜x collects the variables bound in X.)Informally, N, ˜x 2 represents the state of the protocol at the end of R 2 that is usedlater in R 4 , M 2 represents a message carrying (at le**as**t) N and t, and ˜x 3 representsnew data received in Message 3. The presence of the same state N, ˜x 2 in the messagereceived in R 3 is checked using the authenticator t. The inclusion of a fresh nonce Nguarantees that all generated authenticators are different. (In R ◦ 2, the generation of afresh t and the matching =t do not serve any functional purpose; they are performedonly so that the two implementations of the protocol behave similarly.) The additionalprocess P is necessary to account for the possibility of receiving a message x 3 anddiscarding it after a failed test. The lemma is reminiscent of cl**as**sical replication laws inprocess calculi, such **as** !(Q 2 | !Q 3 ) ≈ !Q 2 | !Q 3 , since R ◦ 2 and R 3 contain replicationsand C[ ] typically will.The next lemma applies this protocol transformation to JFKr. It relates our mainmodel S (see Figure 3), which features a stateless responder till reception of a Message3 with a valid token, to a simplified, linear model S ◦ . The lemma enables us toprove properties of JFKr preserved by ≈ (such **as** trace properties) on S ◦ instead of S.910

Lemma 2. We have S ◦ ≈ S, where S ◦ is S after replacing R1A | R3 A in each R A byR ◦A1 = !c(1(N I , x I )).νN R , t R .c〈2(N I , N R , x R , g R , t R )〉.?c(3(=N I , =N R , x I , =x R , =t R , e I , h I )).let κ R in . . . (**as** in R A 3 )Our next theorem expresses that the responder commits session-specific resourcesonly once an initiator h**as** established round-trip communication, that is, sent a Message1, received a Message 2, and returned a Message 3 with matching nonces. Thisproperty helps because the responder controls the emission of tokens and can cheaplyinvalidate old ones by rekeying K R , and because a “blind” attacker (weaker than a typicalNeedham-Schroeder attacker [19]) may send Messages 1 with fake IP addresses,but then may not be able to eavesdrop on the corresponding Messages 2.Theorem 1 (Protection from DOS). Let A ∈ C, and let S $ be S with an additionaloutput $〈N I , N R 〉 before the Diffie-Hellman computation κ R in R A 3 . For any traceS $η−→ S ′ , for each output $〈N I , N R 〉, there are distinct, successive actions c(1(N I , )),c〈2(N I , N R , , , )〉, and c(3(N I , N R , , , , , )).The additional output on $ serves **as** a marker for the start of expensive processing(public-key operations and session-state allocation). The theorem formulates “roundtripauthentication” **as** an injective correspondence between actions. The correspondencedepends on the authenticator; we prove it by applying a variant of Lemma 2 toobtain an equivalent, linear protocol, and invoking ProVerif on that protocol. In incorrectinterpretations of JFKr, Theorem 1 is false, and many Messages 3 may be processedfor the same authenticator [3].5 Core Security: Secrecy and AuthenticityNext, we consider session-key secrecy and mutual authentication. Let S be a JFKr configurationwith compliant principals C sharing exponentials X. We study arbitrary runsof the protocol by examining transitions S η −→ S ′ , where η is an arbitrary sequence oflabels. In these labelled transitions, we omit internal steps →. Informally, S ′ representsany reachable state of the configuration in the presence of an attacker that controls boththe low-level IP network (c) and the control interfaces for the principals in C.The following theorem characterizes runs of the protocol that involve two compliantprincipals, A and B, in terms of what can be observed by an eavesdropper. We write[1,2,3]−−−−→ for the eavesdropped communicationsand [4]νN I .[1(N I ,x I )]νNR tR.[2(NI ,NR,xR,gR,tR)]νeI hI .[3(NI ,NR,xI ,xR,tR,eI ,hI )]−−−−−−−−−→ −−−−−−−−−−−−−−−−−−→ −−−−−−−−−−−−−−−−−−−−−→νeR hR.[4(eR,hR)]−→ for −−−−−−−−−−−→. We also write ϕ 3 and ϕ 4 for the frames that map the variablesN I , N R , t R , e I , h I and N I , N R , t R , e I , h I , e R , h R , K v , respectively, to distinctrestricted names. (A frame is b**as**ically an active substitution with restricted names.)These frames represent the simplified “net effect” of the runs −−−−→ [1,2,3]and −−−−→ [1,2,3]−→[4](including the p**as**sing of K v ). Next we examine sessions between compliant principalsstarting from any reachable state S ′ of the protocol.Theorem 2 (Secrecy for Complete Sessions). Assume S −→ η S ′ . For any principalsA, B ∈ C, exponentials x I , x R ∈ X, and terms ID ′ R, sa I , there exists S 3 such thatand either (i) ID A ∈ S B IS 3andνK v.accept B 〈ID A,ID ′ R ,saI ,saR,Kv〉−−−−−−−−−−−−−−−−−−−−−→ [4]or (ii) ID A ∉ S B I and S 3 ≈ S ′ | ϕ 3 .S ′ init A (ID ′ R−−−−−−−−→ ,saI )−−−−→ [1,2,3]S 3−→ connectA 〈ID B,ID ′ R ,saI ,saR,Kv〉−−−−−−−−−−−−−−−−−−→≈ S ′ | ϕ 4This theorem first expresses the functioning of the protocol, with two normal outcomesdepending on ID A ∈ SI B ; the first disjunct is for acceptance, the second for rejection.It also uses observational equivalence to give a simple, abstract characterization of theprotocol outcomes: we are (apparently) back to the state of the protocol just before thesession began, S ′ , except for ϕ 3 and ϕ 4 which export variables bound to plain names(νN.{x = N}), our representation of independent, fresh values in the pi calculus. Fromthe viewpoint of an attacker that can eavesdrop on c and communicate on control interfaces,the intercepted message fields and the session key appear to be fresh, independentnames, rather than computed values. In particular, the attacker can learn K vonly through the control interfaces, and e I and e R leak nothing about their encryptedcontents. Furthermore, the equivalences ensure that the session does not depend on (oraffect) any other session in S ′ . Although the statement of the theorem deals only with a(temporarily) p**as**sive attacker, its combination with Theorem 4 (below) does cover allc**as**es of complete sessions.We also have complementary authentication properties, expressed **as** correspondenceproperties on control actions (that is, messages on the control interfaces), with anactive attacker.Theorem 3 (Authenticity for Control Actions). Assume S −→ η S ′ . The actions in ηhave the following properties:1. For each accept B 〈ID A , ID ′ R, sa I , sa R , K v 〉, we have ID A ∈ S B I and, if A ∈ C,there is a distinct init A (ID ′ R, sa I ).2. For each connect A 〈ID B , ID ′ R, sa I , sa R , K v 〉 there is a distinct init A (ID ′ R, sa I ) and,if B ∈ C, there is a distinct accept B 〈ID A , ID ′ R, sa I , sa R , K v 〉.The proof of these properties relies on ProVerif. For Property 1, we analyze the linearvariant of JFKr, then extend the result to JFKr by Lemma 2; in contr**as**t, the directautomated analysis of JFKr yields only a weaker, non-injective correspondence, becauseProVerif does not keep track of the linearity enforced by the authenticator cache.ProVerif also yields proofs of these properties for variants of the protocol—with orwithout sharing of exponentials, for JFKr and for JFKi.The next theorem also deals with an active attacker. It says that, whenever a traceincludes a control message connect A 〈ID B , . . . 〉 for some A, B ∈ C, the trace essentiallycontains a normal successful run of the protocol with an eavesdropper, **as** describedin Theorem 2. The hypotheses exclude internal communication on c; this **as**sumptionmeans that the attacker sees all messages on c, and is convenient but not essential.1112

Theorem 4 (Authenticity for Complete Sessions). Let A, B ∈ C and **as**sumeS −→ η connectA 〈ID B,ID ′ R ,saI ,saR,Kv〉−−−−−−−−−−−−−−−−−−→ S ′without internal communication steps on c, and with fresh, distinct exported variables.η1. −→ contains a series of transitions that matchinit A (ID ′ R−−−−−−−−→ ,saI )−−−−→ [1,2,3] νKv.acceptB 〈ID A,ID ′ R ,saI ,saR,Kv〉−−−−−−−−−−−−−−−−−−−−−→ −→[4]in the same order, except possibly for argument x I in the first input on c and forargument t R in the second input and third output on c.2. Let η ′ ηbe η after er**as**ure of these transitions. We have S | ϕ ′4 −→≈ S ′ .We use ProVerif to show the first point of this theorem, via Lemma 2.Theorem 3 is simpler and more abstract than Theorem 4, **as** it deals with the interfaceof the protocol, through control actions. Theorem 4 is more complex, **as** it expressesproperties on both control actions and lower-level IP messages exchanged by theprotocol. These properties imply that certain protocol inputs match previous protocoloutputs, so these inputs are authentic. In general, we would not expect an exact matchof all message fields (even if such matches facilitate a formal analysis): some fields arenot authenticated. Here, the absence of authentication of x I in the first message weakensidentity protection [3]. The absence of authentication of t R by the initiator seemsharmless, in**as**much **as** t R is used only by R.Perfect Forward Secrecy As a corollary of Theorems 4 and 2, the session key K v , exportedin the control actions, is equivalent to a variable bound to a fresh, independentname, since ϕ 4 contains νN.{K v = N}. Hence, up to observational equivalence, K vis syntactically independent from S and the values intercepted by the attacker. As previouslydiscussed [4], this provides a characterization of perfect forward secrecy for thesession key. We obtain this property even with our liberal reuse of exponentials. Wealso derive a more specific (but still comforting) property that K v is distinct from anykey established in another session of the protocol.Independently, ProVerif also shows that the key K v exchanged between two compliantprincipals remains secret—that is, here, the adversary cannot compute it—evenif we give the long-term secret keys K − Aof all principals to the attacker after the end ofthe protocol run. (Similarly, ProVerif presupposes, then verifies, that the environmentnever obtains signing keys K − A for A ∈ C or Diffie-Hellman secrets d x for x ∈ X.)Identity Protection We can rely on observational equivalence also for identity protection.The intercepted variables defined by ϕ 3 and ϕ 4 are independent from ID A , ID ′ R,and ID B ; this property is a strong privacy guarantee for sessions between compliantprincipals. Further guarantees can be obtained with particular hypotheses (see [11]).For instance, if all identities in SIB are of the form ID A for some A ∈ C (that is, B doesnot accept sessions with the attacker) and there is no input on init B (that is, B is only aresponder) then, using Theorems 4 and 2, we e**as**ily check that the identity ID B occursonly in outputs on connect A and otherwise cannot be observed by an active attacker.We can prove additional identity-protection properties, in some c**as**es with ProVerif; onthe other hand, we have also found some limitations in identity protection [3].6 ConclusionDespite a substantial body of work on the formal analysis of security protocols, anddespite much interest in IKE and related protocols, it seems that neither IKE nor its successorsh**as** been the subject of an exhaustive analysis until now. The paper that presentsJFK argues informally about some of its core properties, and calls for a formal analysis.Recent work by Datta et al. explores how the STS protocol, two JFK variants, and thecore of IKE can be derived by successive refinements [9,10]. In particular, it isolatesthe usage of authenticators and discusses the properties of JFKr (without however preciseclaims or proofs). Further afield, the literature contains partial but useful machine**as**sistedverifications of IKE and Skeme (a protocol that influenced IKE) [17,7,8], and aframework for the study of DOS [18]. More broadly, the literature contains several formaltechniques for protocol analysis and many examples (e.g., [14,16,20,21,15]). Whilea number of those techniques could potentially yield at le**as**t partial results on JFK, webelieve that the use of the applied pi calculus is particularly appropriate. It permits arich formalization of the protocol, with a re**as**onable effort; the formulation of someof its properties via process equivalences and others in terms of behaviors; and proofs(sometimes automatic ones) that rely on language-b**as**ed methods.We regard the present analysis of JFK **as** an important c**as**e study that goes beyondwhat we have previously attempted, first because JFK is an attractive and intricate“state-of-the-art” protocol of possible practical impact (through its influence on IKEv2and other protocols), because JFK tightly packages many ide**as** that appear elsewherein the field, and also because our analysis explores properties that are central to JFKbut that are not often, if ever, explained rigorously. Furthermore, **as** noted in the introduction,this c**as**e study contributes to the development of ide**as** and results for thespecification and verification of security protocols that should be useful beyond theanalysis of JFK.An obvious next problem is the analysis of IKEv2. We have not undertaken it (insteador in addition to the analysis of JFK) because IKEv2 is relatively recent and, at thetime of this writing, it continues to evolve, with influence from JFK and other sources.At present, JFK and its specification seem inherently more self-contained and interestingthan IKEv2. On the other hand, there seems to be substantial awareness of thebenefits of formal analysis in and around the IETF, so one may look forward to rigorousstudies of IKEv2 and other significant protocols.Acknowledgments We are grateful to Ran Canetti and Angelos Keromytis for informationon JFK, to John Mitchell for information on his research on refinement, toVéronique Cortier for comments on a draft of this paper, and to Michael Roe and DieterGollmann for early discussions on this work. Martín Abadi’s work w**as** partly done atMicrosoft Research, Silicon Valley, and it w**as** also partly supported by the NationalScience Foundation under Grants CCR-0204162 and CCR-0208800.References1. M. Abadi and B. Blanchet. Analyzing security protocols with secrecy types and logic programs.In 29th ACM SIGPLAN - SIGACT Symposium on Principles of Programming Lan-1314

guages (POPL’02), pages 33–44, Jan. 2002.2. M. Abadi and B. Blanchet. Computer-**as**sisted verification of a protocol for certified email.In Static Analysis, 10th International Symposium (SAS’03), volume 2694 of LNCS, pages316–335. Springer-Verlag, June 2003.3. M. Abadi, B. Blanchet, and C. Fournet. Just f**as**t keying in the pi calculus. Manuscript, availablefrom http://www.di.ens.fr/ ∼ blanchet/crypto/jfk.html, Dec. 2003.4. M. Abadi and C. Fournet. Mobile values, new names, and secure communication. In 28thACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL’01),pages 104–115, Jan. 2001.5. W. Aiello, S. Bellovin, M. Blaze, R. Canetti, J. Ionnidis, A. Keromytis, and O. Reingold.Efficient, DoS-resistant, secure key exchange for internet protocols. In 9th ACM Conferenceon Computer and Communications Security (CCS’02), pages 48–58, Nov. 2002.6. W. Aiello, S. Bellovin, M. Blaze, R. Canetti, J. Ionnidis, A. Keromytis, and O. Reingold. Justf**as**t keying (JFK). IETF Internet Draft draft-ietf-ipsec-jfk-04.txt, July 2002.7. B. Blanchet. An efficient cryptographic protocol verifier b**as**ed on Prolog rules. In 14th IEEEComputer Security Foundations Workshop (CSFW-14), pages 82–96, June 2001.8. B. Blanchet. From secrecy to authenticity in security protocols. In Static Analysis, 9thInternational Symposium (SAS’02), volume 2477 of LNCS, pages 342–359. Springer-Verlag,Sept. 2002.9. A. Datta, A. Derek, J. C. Mitchell, and D. Pavlovic. A derivation system for security protocolsand its logical formalization. In 16th IEEE Computer Security Foundations Workshop(CSFW-16), pages 109–125, July 2003.10. A. Datta, J. C. Mitchell, and D. Pavlovic. Derivation of the JFK protocol. http://www.stanford.edu/ ∼ danupam/composition.ps, 2002.11. C. Fournet and M. Abadi. Hiding names: Private authentication in the applied pi calculus.In Software Security – Theories and Systems. Mext-NSF-JSPS International Symposium(ISSS’02), volume 2609 of LNCS, pages 317–338. Springer-Verlag, Jan. 2003.12. D. Harkins and D. Carrel. RFC 2409: The Internet Key Exchange (IKE). http://www.ietf.org/rfc/rfc2409.txt, Nov. 1998.13. Internet Key Exchange (IKEv2) Protocol. IETF Internet Draft at http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-11.txt, Oct. 2003.14. R. Kemmerer, C. Meadows, and J. Millen. Three systems for cryptographic protocol analysis.Journal of Cryptology, 7(2):79–130, Spring 1994.15. P. Lincoln, J. Mitchell, M. Mitchell, and A. Scedrov. A probabilistic poly-time frameworkfor protocol analysis. In Fifth ACM Conference on Computer and Communications Security(CCS’98), pages 112–121, 1998.16. G. Lowe. Breaking and fixing the Needham-Schroeder public-key protocol using FDR. InTools and Algorithms for the Construction and Analysis of Systems, volume 1055 of LNCS,pages 147–166. Springer-Verlag, 1996.17. C. Meadows. Analysis of the Internet Key Exchange protocol using the NRL protocol analyzer.In IEEE Symposium on Security and Privacy, pages 216–231, May 1999.18. C. Meadows. A cost-b**as**ed framework for analysis of denial of service networks. Journal ofComputer Security, 9(1/2):143–164, 2001.19. R. M. Needham and M. D. Schroeder. Using encryption for authentication in large networksof computers. Communications of the ACM, 21(12):993–999, Dec. 1978.20. L. C. Paulson. The inductive approach to verifying cryptographic protocols. Journal ofComputer Security, 6(1–2):85–128, 1998.21. F. J. Thayer Fábrega, J. C. Herzog, and J. D. Guttman. Strand spaces: Why is a securityprotocol correct? In IEEE Symposium on Security and Privacy, pages 160–171, May 1998.15