A Correctness Proof of a Mesh Security Architecture

∗Doug Kuhlman, ∗Ryan Moriarty, Tony Braskich, Steve Emeott, Mahesh TripunitaraMotorola Labs

1301 E. Algonquin Rd.Schaumburg, IL 60196

{doug.kuhlman; tony.braskich; steve.emeott; tripunit}@motorola.com; ryan@cs.ucla.edu

Abstract

The IEEE 802.11s working group is tasked to provideways of establishing and securing a wireless mesh net-work. One proposal establishes a Mesh Security Architec-ture (MSA), with a developed key hierarchy and full pro-tocol definitions. This paper examines the correctness andsecurity of the MSA proposal and its corresponding pro-tocols. We utilize Protocol Composition Logic (PCL) toprove individual protocols secure, as well as their compo-sition. We add to the structure of PCL, generalizing it forpeer-to-peer applications. We also discuss two security is-sues we discovered with original versions of the proposalsand our proposed remedies.

1. Introduction

We discuss our proof of security properties of astandards-track protocol suite for authentication and keyestablishment using a formal verification technique. Ourtechnique is Protocol Composition Logic (PCL) [15] (seeSection 2.1). Our setting is the IEEE 802.11 Mesh Net-working task group, known as 802.11s, which was formedto define extensions to IEEE 802.11 [1] to support wire-less mesh networking [22]. A goal of the task group is tosecure a mesh by utilizing existing IEEE 802.11 securitymechanisms and extensions.

The Mesh Security Architecture (MSA) proposal [4, 5,6, 7] to 802.11s consists of a definition of a key hierar-chy and a suite of protocols to enable security in a wire-less mesh network. The proposal includes detailed infor-mation to implement MSA within the framework definedby 802.11s, including key derivation, protocol execution,and message formatting. The suite of protocols encom-passes all the necessary components to create and main-tain a mesh of nodes.

We have the following three contributions in this paper.

∗principal authors

• We have conducted a comprehensive assessment ofall 10 protocols (averaging 4 messages and 8 compo-nents) of the MSA proposal from a security stand-point and proved its correctness. We present anoverview of the protocol suite and the main insightsfrom the proof. Page restrictions preclude the pre-sentation of all details; a companion technical re-port [25] complements this paper.

As this is one of few instances of the proof of correct-ness of a substantial, standards-track protocol suite ofwhich we are aware, we feel that this is an importantcontribution.

• PCL has been used to prove the correctness of theIEEE 802.11i protocol suite [23]. However, 802.11spresents new challenges that have necessitated exten-sions to PCL for us to be able to carry out our correct-ness proof. We present these extensions and detailsfrom the MSA proposal that illustrate their necessity(see Section 3). We believe that the extensions aregeneral enough to be useful in other work in protocolverification.

• In the course of carrying out our proof, we discov-ered two security issues with protocols in the pro-posal. We discuss these issues and our suggestionsfor changes to address these issues. Our suggestionshave since been incorporated into the proposal. Aswe point out in Section 5, our proof would not havebeen possible without these changes.

The remainder of this paper is organized as follows.Section 2 provides a background on PCL, 802.11s and theMSA proposal. In Section 3 we present our additions toPCL; for each addition we illustrate its need via compo-nents from the protocol suite we have analyzed. We pro-vide an overview of the proof in Section 4. In Section 5we discuss our recommendations for changes to the origi-nal design of the protocol suite in the MSA proposal basedon our proof efforts. We conclude with Section 6.

21st IEEE Computer Security Foundations Symposium

978-0-7695-3182-3/08 $25.00 © 2008 IEEEDOI 10.1109/CSF.2008.23

315

21st IEEE Computer Security Foundations Symposium

978-0-7695-3182-3/08 $25.00 © 2008 IEEEDOI 10.1109/CSF.2008.23

315

21st IEEE Computer Security Foundations Symposium

978-0-7695-3182-3/08 $25.00 © 2008 IEEEDOI 10.1109/CSF.2008.23

315

21st IEEE Computer Security Foundations Symposium

978-0-7695-3182-3/08 $25.00 © 2008 IEEEDOI 10.1109/CSF.2008.23

315

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

2. Preliminaries

In this section, we provide some background and moti-vate our work.

2.1. Overview of Proof Method

We use Protocol Composition Logic (PCL) to prove thecorrectness and security of the Mesh Security Architec-ture. We briefly overview PCL in this section. PCL hasbeen used for a security analysis of 802.11i [23], Kerberos[29], and the Group Domain of Interpretation (GDOI) pro-tocol [26].

2.1.1 Terminology

Protocols in PCL are modeled using a particular syntax.A role specifies a sequence of actions performed by anhonest party. A matching set of roles (two, in this paper)define a protocol. A particular instance of a role run bya specific principal is a thread. Possible actions inside athread include nonce generation, signature creation, en-cryption, hash calculation, network communication, andpattern matching (which includes decryption and signa-ture verification). Each thread consists of a number ofbasic sequences. A basic sequence is a series of actions,which may not include a blocking action (like receive) ex-cept as the first action. Pre- and post-conditions are asser-tions expressed as logic predicates that must be true beforeand after a protocol run respectively.

2.1.2 Notation

We use the following notation in this paper. Our notationis consistent with previous work on PCL except for theextensions that we propose in this paper. (See Section 3for a discussion of the extensions.)

X, Y, Z, . . . are used to denote threads.

X, Y , Z, . . . denote the principals associatedwith the corresponding threads.

send, receive, new, . . . are actions. Actions arethings that principals do in a thread.

MKHSH, TLS:CLNT, 4WAY, . . . denote pro-tocols. We use a mnemonic that follows a ‘:’to denote that the protocol is associated with aparticular role that a principal plays in an in-stance of the protocol; for example, CLNT de-notes that it is the client’s portion of the TLSprotocol.

pmkX,Z , gtkX , . . . denote cryptographic keys.We use subscripts to indicate the principal(s)with whom a key is associated.

θ, Φ, Γ, . . . are used to denote logic formulaethat express pre- or post-conditions, or invari-ants.

Has(), KOHonest(), SafeMsg(), . . . are logicpredicates that are used in assertions (pre- andpost-conditions, and invariants).

Many of the predicates follow a Pred(actor, action)format. Thus, Has(X, m) means that thread X has in-formation m. Similar predicate formats follow for Send,Receive, New , and Computes. Other predicates can bemore complicated. Honest(X) means that the principal(X) running the thread is honest. KOHonest(s,K) es-sentially means that all principals with access to any keyk ∈ K or to the value s are honest. Contains(m, t) isequivalent to t ⊆ m and means that information t is asubterm of m.

2.1.3 Proof Methodology

The proof methodology of PCL is described by Durgin etal. [19, 20] and Datta et al. [11, 16, 12, 13, 14, 15, 23, 29].We use the standard syntax of θ[P ]XΦ. This means thatwith preconditions θ before the run of actions P by threadX , the result (postcondition) Φ is proven to hold. θ isalways used to denote a precondition, Φ a postcondition,and Γ an invariant.

The proof system is built on three fundamental build-ing blocks. The first is a series of first-order logical ax-ioms [15]. A first-order logical axiom is a natural logi-cal assumption (e.g., creation of a value implies posses-sion of that value). The second is a series of crypto-graphic/security axioms [15, 20, 23]. Cryptographic ax-ioms provide formal logic equivalents of standard cryp-tography (e.g., possession of a key and a value providespossession of the encryption of the value with that key).These assume idealized cryptographic functionality whichmost cryptographic primitives do not achieve in practice.For example, the hash of two different values is assumedto never be the same.

The third building block is the fundamental principleof honesty. Honesty imposes certain restrictions on roles– that they follow protocol descriptions correctly and donot send out particular information assigned to that role.Honesty is a special type of rule that allows an instanceof a thread to reason about the actions of another, cor-responding thread that participates in the same protocol.The actions of an attacker are not assumed to be honest.We do, however, assume that the attacker does not violatean assumption, or condition or invariant (e.g., the posses-sion of a private key) that is necessary for a protocol torun to completion. This notion of an attacker model isthe same as that considered in previous work that uses ap-proaches based on mathematical logic to verify protocols

316316316316

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

(c.f. [23]).All but one of the axioms on which we depend have

been proposed previously [11, 15, 16, 23]; space con-straints preclude the presentation of a comprehensive listof all PCL axioms in this paper. We provide a few fre-quently used axioms in Figure 1. We do, however, pointout that we need an additional axiom – a node which gen-erates a signature over some information has that informa-tion and the key with which the signature is generated.

SIG1: Computes(X, SIGk(m)) ⊃Has(X, m) ∧ Has(X, k).

(Computes() and Has() are predicates, ⊃ can be read as“implies,” and ∧ is logical conjunction.)

AA1 φ[a]Xa

AA4 φ[a1; a2; . . . ; ak]Xa1 < a2 ∧ . . . ∧ ak−1 < ak

AN2 φ[New x]XHas(Y, x) ⊃ Y = X

AN3 φ[New x]XFresh(X, x)

ARP Receive(X, p(x))[match q(x)/q(t)]X

Receive(X, p(t))

FS1 Fresh(X, t)[send t′]X

FirstSend(X, t, t′)∀t ⊆ t′

FS2 FirstSend(X, t, t′) ∧ a(Y, t′′) ⊃Send(X, t′) < a(Y, t′′), where X �= Y ∧ t ⊆ t′′

HASH1 Computes(X, HASHK(x)) ⊃Has(X, x) ∧ Has(X, K)

Figure 1. Some PCL Axioms Used in MSAProofs

The methodology of PCL has proven very successfulin dealing with large-scale architectures. A recent paperby Cremers looked at the soundness of the various axiomsof PCL [10]. For the problem of preceding actions, wehave consistently used implicit pre- and post-conditionsat the basic sequence level, leading to a tighter joining ofactions. Another issue arises with the HASH3 axiom. Wepropose a straight-forward generalization of the HASH3axiom, following earlier work on signatures. We define anew axiom, which is sound.

HASH3′: Receive(X, HASHK(x)) ⊃∃Y.Computes(Y, HASHK(x))∧Send(Y, m)∧Contains(m, HASHK(x)).

Most of the remaining issues deal with public-key axiomsnot addressed in this paper or with specific utilizations ofaxioms in other papers.

2.1.4 Composing Proofs

An important feature of PCL is that with it, we can rea-son about how protocols interact. As this paper coversan entire architecture, it is imperative that the large num-ber of individual protocols be proven secure not only in-dependently, but also working together in conjunction asa complete system. To this end, we extensively use themethodology of protocol composition developed by Dattaet al. [15]. We discuss this in Section 4.3.

2.2. Overview of the MSA Proposal for802.11s

The 802.11s task group is working to develop a meshnetworking protocol that sets up auto-configuring, multi-hop paths between wireless stations to support the ex-change of data packets. A goal of the task group is to uti-lize existing IEEE 802.11 security mechanisms [1], withextensions, to secure a mesh in which all the stations arecontrolled by a single logical administrative entity fromthe standpoint of security [22]. The 802.11s task groupcontinues to refine its draft specification through the reso-lution of comments received during a review of the speci-fication that began in late 2006 [4, 5, 6, 7].

A mesh network is a collection of network nodes, eachof which can communicate with the others. Several kindsof nodes are specified in the MSA proposal. One is a MeshPoint (MP); a member of the mesh that can communicatewith other nodes. Each mesh has at least one Mesh KeyDistributor (MKD) which is an MP that is responsible formuch of the key management within its domain (a MKD’sdomain is the set of nodes with which it has a secure con-nection). The MKD also provides a secure link to an exter-nal authentication server (e.g., a RADIUS [27] server). AMesh Authenticator (MA) is an MP which has been autho-rized by the MKD to participate in key distribution withinthe mesh. A Candidate MP is an entity that wishes to jointhe mesh but is not yet an MP.

Differences from 802.11i Part of the MSA proposal isvery similar to the 802.11i protocol suite [1]. In 802.11i,connections are established between authenticators andsupplicants in a server-client topology. An authentica-tor is connected to a backbone infrastructure, and eachsupplicant may use an Extensible Authentication Proto-col (EAP) [3] method such as EAP-TLS [31] to authenti-cate with the infrastructure. Each supplicant then uses afour-message handshake to secure a session with an au-thenticator, allowing subsequent use of its resources. Theauthenticator also maintains a broadcast key that is givento each of its successful supplicants. These protocols wereexamined in [23] and proven to be secure.

317317317317

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

gtkX gtkY1 gtkX gtkYn gtkX gtkY1 gtkX gtkYn

ptkX,Y1{X, Y1, T} ptkX,Yn{X, Yn, T} ptkX,Y1{X, Y1, T} ptkX,Yn{X, Yn, T}�

����

����

����

����

����

����

����

���ABBH or 4WAY or GKH ABBH or 4WAY or GKH

pmkX,Y1{X, Y1, T} pmkX,Yn{X, Yn, T} pmkY1,X{X, Y1, T} pmkYn,X{X, Yn, T}

� � � �ABBH or 4WAY ABBH or 4WAY

mptkX,T{X, T}

mkdkX,T {X, T}

������

�����

�

PUSH or PULL

MKHSH

pmkmkdX{X, T}

xxKeyX{X, T}

�

��

��

���

null

�����������

�����������4WAY

privX{X} privT {T}�����

������TLS TLS

Local MP keys (for X) Peer MP keys (for X)

Figure 2. The key hierarchy of the MSA proposal

In addition to the 802.11i functionality, the MSA pro-posal allows the mesh to be a peer-to-peer network. Nodesin an MSA mesh may play different roles at differenttimes. Thus, the proof of security of the 802.11i 4-wayhandshake [23], which assumes limitations on the mes-sages a node can send, does not hold. The peer-to-peer nature also poses some difficulties with timing. The802.11i proofs adopt matching conversations [2] as the au-thenticity property. As we discuss in Section 3.1.1, thenotion of matching conversations imposes a rather strictordering of messages in a protocol run, and is too rigid forour purposes. In MSA, we must provide for the case thatboth parties simultaneously start instances of a protocoland messages are not necessarily well-ordered. Thus, theproofs from [23] do not carry over directly.

The key hierarchy Each node in Figure 2 represents akey in principal X’s key hierarchy. An edge from keyk1 to k2 shows that k2 is either derived from or deliveredusing k1 (that is, k1 protects k2, as knowledge of k1 isrequired to obtain k2). The edge’s label is the protocolthat is used to derive or deliver the key. The subscript in akey (for example, the subscript X in pmkmkdX {X, T })is used to denote the principal(s) associated with the key.Principals listed in curly brackets are the honest entitiesthat may possess the key. The subscripts are ordered (i. e.,

pmkX,Y is different from pmkY,X).Key derivation (one-way) functions are utilized rather

than key generation for efficiency. The MSA suite’s use ofkey derivation also provides the potential for certain pro-tocols to complete successfully when neither principal hasconnectivity to the rest of the mesh. This results in a keyhierarchy, with each node being associated with severalkeys. The key hierarchy is an excellent avenue for un-derstanding and summarizing the various protocols in theMSA proposal, and for demonstrating which keys protectother keys [6]. The complete descriptions of the proto-cols in PCL and prose are in the companion technical re-port [25].

We start our progression through the key hierarchy andthe protocols at the top of Figure 2. Let X be a CandidateMP and let T be the MKD. The MSA Authentication Pro-tocol allows X to join the mesh and become an MP, andconsists of three stages: Peer Link Establishment (PLE),TLS [17], and a Four-Way Handshake (4WAY). X eitherhas a shared xxKeyX with T or it shares public key cre-dentials with T . If it shares public credentials with T , thenT and X run TLS to derive the xxKeyX ; otherwise, TLSis omitted. To derive the pmkmkdX , X needs a nonce;it is delivered to X from T when X runs 4WAY with anMA (which we denote Y , noting that Y may be T ). Sub-sequently, X can derive the pmkmkdX , pmkX,Z for anyZ and the mkdkX,T . When X completes 4WAY with Y ,

318318318318

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

X will have derived ptkX,Y , received the gtkY from Y ,and delivered gtkX to Y .

At this point, X is a Mesh Point (MP) but is not yetan MA. To become an MA, X needs to run the Mesh KeyHolder Security Handshake (MKHSH) with T , and de-rive the mptkX,T , which is a session key between X andT . This enables X to run the PUSH and PULL proto-cols with T . PUSH is started by T to tell X to retrievepmkZ,X for some Z . PULL is started by X to requestpmkZ,X from T .

The 802.11s task group has expressed interest in devel-oping an Abbreviated Handshake (ABBH) [9, 32]. ABBHis used by an MP or an MA X to derive ptkX,Z , and ex-change gtkX and gtkZ with another MA or MP Z . With-out an ABBH, the method of exchanging these creden-tials is to have the MP or MA run the full MSA Authen-tication Protocol with the other MA or MP. In this pa-per we discuss a candidate ABBH, which has been pre-sented to 802.11s [8], and its proof of security and com-posability with the rest of the MSA architecture. The fullABBH is presented in the full paper [25] and comprisestwo variants. One denoted is ABBH.INIT and the otherABBH.SIMO, depending on the timing of the first mes-sages. We explore ABBH.SIMO, denoted simply SIMO,in more depth in Section 3.

Additional MSA protocols include the Group KeyHandshake (GKH) and the DELete protocol (for keymanagement). GKH is used by X to update its groupkey (gtkX ) at Z . The protocol only works with nodeswith which X maintains a security association (i.e., sharesptkX,Z ). DEL is started by T to tell X to delete a partic-ular pmkZ,X .

3. Additions to PCL and Proof Methodology

In modeling the MSA protocol suite in PCL, we founda number of situations for which the current languagemodel has no support. We provide a motivating exam-ple from MSA and discuss our proposed additions to thelanguage. None of the additions modify the existing lan-guage, so all previous proofs and work should not needre-examination. We also broadened the proof methodol-ogy slightly.

Many of the additions can be explained by looking atthe abbreviated handshake protocol with a simultaneousopen (SIMO). The purpose of this protocol is to estab-lish a linkage between two nodes which are already partof a mesh. Therefore, the two nodes already have authen-ticated to the MKD and need only authenticate to eachother and establish a fresh, unknown session key. Onepossible instantiation of this protocol is presented in Fig-ure 3. Values x and y are nonces generated by X andY respectively. INFOX contains additional information

X Y

xINFOXY X ,,ΑΒΒΗ1"" ,ˆ,ˆ

yINFOYX Y ,,ΑΒΒΗ1"" ,ˆ,ˆ

11,,,,,ΑΒΒΗ5"" ,ˆ,ˆ micencxyINFOYX Y

00,,,,,ΑΒΒΗ5"" ,ˆ,ˆ micencyxINFOXY X

Figure 3. A SIMO Abbreviated Handshake

about node X’s configuration. The enc values are broad-cast keys encrypted with session keys derived from x, yand a shared key. The mic values provide integrity andauthentication verification. We note that the messages la-beled “ABBH5” do not have to occur in the listed order.Node X can receive message 5 before or after it sends itsmessage 5. Note, too, that X might receive its message 5after it sends its own message 5, even if node Y sends itsmessage 5 before X does.

The thread for this protocol is symmetric (though itdoes not have to be) and is presented in Figure 4.Some additions to PCL were used in the thread descrip-tion, which are fully described below. The preconditionθABBH,1, invariant ΓABBH,1 and a sample security goalΦSIMO,AUTH are also presented. This protocol is usefulin demonstrating the necessity of the additions, as well asproviding a sample of how the addition is used in the proofof the MSA proposal.

3.1. Flexible Temporal Ordering

The temporal ordering of actions in the original PCLdefinition is too strict for our applications. In the SIMOprotocol presented in Figure 4, the order of sending andreceiving the message labeled “ABBH5” is nondetermin-istic. Once the initial messages have been exchanged, thefinal messages could be sent/received in either order. Thechange to PCL is realized as an addition to the language.The proposed modification does not change any other as-pect of PCL; therefore all previous proofs are still valid.

We add an action group and redefine the notion of astrand. We define an action group as: (action group) g ::=(a; . . . ; a), where a is an action as defined in [15]. We alsoredefine a strand as: (strand) s ::= [g(; or :) . . . (; or :)g].Thus a strand is now composed of an arbitrary numberof action groups separated by colons or semicolons. Theidea behind the action group is that the actions in an actiongroup must be done in the order they appear. However,

319319319319

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

ABBH.SIMO = (X, Y , INFOX , gtkX)

[New x; send Y , X, “ABBH1”, INFOX , x;

receive X, Y , “ABBH1”, INFOY , y;match select(INFOX , INFOY )/CS, pmkN ;match retrieve(pmkN)/pmk;match HASHpmk(x, y)/ptkX,Y ;(match ENCptkX,Y

(gtkX)/enc0;

match HASHptkX,Y(

Y , X, “ABBH5”, INFOX , x, y, enc0, INFOY )/mic0;

send Y , X, “ABBH5”, INFOX , x, y, enc0, mic0) :

(receive X, Y , “ABBH5”, INFOY , y, x, enc1, mic1;match enc1/ENCptkX,Y

(gtkY ); match mic1/HASHptkX,Y(

X, Y , “ABBH5”, INFOY , y, x, enc1, INFOX))]X

θABBH,1 := Has(X, pmkX,Y ) ∧ Has(Y, pmkY,X)∧ (Has(X, mptkX,T ) ∨ Has(Y,mptkX,T ))

ΓABBH,1 := Honest(X) ∧ Send(X, m)∧(Contains(m, Hashptk((“ABBH2”, Y , Z)))∨Contains(m, Hashptk((“ABBH3”, Y , Z)))∨Contains(m, Hashptk((“ABBH4”, Y , Z)))∨Contains(m, Hashptk((“ABBH5”, Y , Z)))) ⊃Z = X

ΦSIMO,AUTH :=KOHonest(ptkX,Y , {pmkX,Y , pmkY,X}) ⊃(Send(X, SIMO1X) < Receive(Y, SIMO1X))∧(Send(Y, SIMO1Y) < Receive(X, SIMO1Y))∧(Send(Y, SIMO5Y) < Receive(X, SIMO5Y))∧(Send(X, SIMO1X) < Receive(X, SIMO1Y) <(Send(X, SIMO5X) ∧ Receive(X, SIMO5Y))∧(Send(Y, SIMO1Y) < Receive(Y, SIMO1X) <Send(Y, SIMO5Y))

Figure 4. Protocol Description of the Abbre-viated Handshake Simultaneous Case

the action groups within a strand separated by a colon (:)can be done in any order and action groups separated bya semicolon (;) must be done in the order they appear.Note that any strand defined previous to this addition tothe language can still be defined exactly the same way bydefining each action group to be one action and by settingall the separators inside a strand to ‘;’.

We update Axiom AA4 [15] to reflect this addi-tion to the language. The original version is AA4:�[a; . . . ; b]Xa < b. We redefine it to be AA4: �[a :b; . . . ; c : d]Xa ∧ b < c ∧ d, where a, b, c and d are ac-tion groups. Thus nothing about the temporal order of acompared to b or c compared to d is indicated. We alsoinclude a new axiom AA5: �[(a; . . . ; b)]Xa < b, wherea and b are actions, to deal with the temporal ordering of

action groups. If each action group is exactly one actionand only semicolons are used in the new strands our AA4becomes exactly the AA4 previously defined and AA5 isredundant.

A consequence of the above addition is that protocolswhose definition includes ‘:’ add an additional complica-tion in the determination of basic sequences. Recall that abasic sequence is defined as any actions before a receive.With the : notation, two different sets of actions may occurbefore a receive, corresponding to the potential temporalordering of the action groups. Thus we must ensure thatinvariants and preconditions hold over all possible basicsequence orderings and compositions.

3.1.1 Generalized Matching Conversations and Gen-eralized Mutual Authentication

The proofs of mutual authentication used in many pre-vious work that use PCL for protocol verification haveadopted the notion of matching conversations [2] for theauthenticity property. This is natural as these protocolsare “turn-by-turn protocols” in which one a participant re-ceives a message and then responds to the message, whichis received by the other party who responds to it, and soon. However, some of the peer-to-peer protocols in thispaper can never correspond to matching conversations asthe order in which messages are sent and received is flex-ible, as a functional requirement. We generalize the prop-erties of matching conversations and define two new no-tions which we call maximal conversations and general-ized matching conversations. We feel these definitions areof general interest beyond this work. Recall the defini-tions of conversation and matching conversation from [2].

We define the maximal conversation for a participantA. We first determine the maximal possible temporal or-dering. To do this we consider all legal orderings in anideal world (one with no adversarial interference) from theview of a participant A in a protocol. Given this maximaltemporal ordering, we note the existence of messages forwhich A can never confirm reception. We take the maxi-mal temporal ordering and remove any send or receive forwhich A cannot confirm reception in the ideal world – theremaining actions represent the maximal conversation forparticipant A.

We now define generalized matching conversations fora participant A. We say A has generalized matching con-versations, if in every run of the system, every action in themaximal conversation for participant A has a correspond-ing action at participant A (e.g., A does all its actions)and at the appropriate other participant in the system. Fortwo-participant protocols (like all those in this paper), thismeans that the maximal conversation for participant A hasmessages exactly matching the other participant’s maxi-mal conversation, with the strictest time ordering possible.

320320320320

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

We now define generalized mutual authentication. Ina world in which an adversary has access to every mes-sage and can act on them within the restraints of the proofsystem (symbolic or computational), generalized mutualauthentication means that generalized matching conversa-tions for every participant implies acceptance and accep-tance implies generalized matching conversations for ev-ery participant. For the purpose of this paper we wish tokeep the definition of generalized mutual authenticationgeneral. We explore all these definitions in detail in sepa-rate work.

When our definition is applied to a “turn-by-turn” two-party protocol it becomes exactly the definition from [2].In every other instance our definition requires that the or-dering of actions be maximal with respect to what is possi-ble in the ideal world. As this definition imposes maximaltemporal ordering on a protocol, this definition is at leastsufficient for mutual authentication. Most protocols in theMSA are turn-by-turn and thus the [2] definition sufficesfor those cases. The three exceptions are SIMO (whichis a peer-to-peer protocol and has some timing flexibil-ity), PLE (which is not a cryptographic protocol in itselfand requires no temporal ordering), and PUSH which is acomposition of two protocols.

We note that the generalized matching conversationsproperty encompasses the matching record of runs prop-erty [18]. Also, this property guarantees all desired prop-erties from [24] and implies all the possible authenticationdefinitions in [21].

3.1.2 Generalized Matching Conversations ForABBH.SIMO

We apply the generalized matching conversations defini-tion to SIMO, which is a protocol for establishing a secureconnection between two nodes already in a mesh.

Let X be the principal from whose view we seek to es-tablish the proof of generalized matching conversation andY be the other principal. SIMO1X and SIMO5X representX’s messages, and similarly for Y ’s messages. We need todetermine the maximal timing relations in the ideal world(no adversaries) when only SIMO is run. X cannot con-firm whether Y has received SIMO5X even in the idealworld, because it may be the last message sent. There-fore, SIMO5X is not part of X’s maximal conversation.Note that every message must be sent by the correct partybefore it is received by the other party in an ideal world.Now we simply list what actions must happen after otheractions and omit receives after sends that are irrelevant(e.g., Send(X, SIMO1X) < Receive(Y, SIMO1X)).

Send(X, SIMO1X) < Receive(X, SIMO1Y) <(Send(X, SIMO5X) ∧ Receive(X, SIMO5Y))

Send(Y, SIMO1Y) < Receive(Y, SIMO1X) <Send(Y, SIMO5Y)

This temporal ordering is inherently maximal for X’sview of an arbitrary run of SIMO, so it satisfies the def-inition of generalized matching conversations for X (Y ’sview is similar). The enforcement of the order of thesend messages within a node can be accomplished bywaiting for acknowledgements from the MAC layer be-fore proceeding. If X has not sent its message 1, it ini-tiates the corresponding thread for ABBH.INIT, not forABBH.SIMO, so this ordering is maximal.

3.2. Modeling Information Exchange

In the full paper [25], we provide detailed PCL equiva-lents of the protocols presented in the MSA submissions.Such detailed examinations are necessary to prove proto-col correctness. For example, the presence of INFOY

in mic0 in SIMO (Figure 4) is not intuitively obvious butis essential to the security of the protocol. Modeling theprotocol at a higher level of abstraction would have missedthis subtle requirement.

Real protocol implementations such as MSA requiremore than simple key agreement. Additional informationmust be exchanged and agreed on before secure communi-cation can happen. Examples of information of this typeare basic network functions (e.g., bandwidth selections)and security information (e.g., cipher suite selection). Thetwo principals in the protocol must agree in each case,and an attacker must not be able to influence the selec-tion. That is, the agreed-upon value in all protocol runsmust match the agreed-upon value in an ideal world withno adversary. The peer-to-peer nature of certain protocolssuch as SIMO do not allow pre-defined protocol roles ofprincipals to always allow one principal to make this se-lection and dictate the choice to the other. The two prin-cipals must independently choose matching values fromtwo lists.

A new construct, INFO is used to capture this. Theinformation principal X contributes to a protocol isINFOX . It contains ordered lists of acceptable selectionsfor one or more fields. The contents of INFOX may varyfor different protocols. In MSA, the PLE, ABBH, andMKHSH protocols require the use of INFO.

The select action We have added a new action, se-lect, to PCL. Two principals X and Y must makeidentical but independent selections of link and pro-tocol options from exchanged information INFOX

and INFOY . The select action deterministically re-trieves information from two lists, independent of theorder of the lists (i.e., select(INFOX , INFOY ) =select(INFOY , INFOX)).

Without modeling at this detailed level, a nearly-equivalent SIMO protocol, which only creates a keyed

321321321321

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

hash across the information it sends, would appear vi-able and secure. The cryptographic components would beidentical. However, without node X including INFOY

in its mic (and equivalent for Y ), attack vectors becomepossible. In particular, the strong requirement that themessages sent exactly match the messages received nolonger holds. This leads to potential manipulation of theINFOX and INFOY fields by an attacker. This leads toeasy denial-of-service attacks but would also compromisethe selection of shared cipher suite, leading to a potentialdowngrade attack.

3.3. Calling One Protocol in Another

For many of the protocols in MSA, the protocol mayinstantiate another protocol partway through its run. Thissecond protocol must complete before the first protocolcan continue. For example, in a key exchange proto-col such as SIMO, if both parties that try to establish asession key do not have the other party’s pairwise mas-ter key cached locally (e.g., X does not have the currentpmkZ,X ), then one of the parties must pause its protocolrun and run a key pull protocol. Furthermore, the secondprotocol could potentially be triggered in the middle of abasic sequence.

This is new ground for PCL and we have devised a sys-tem and proof (see section 4.3) that enables us to framethis complex action in PCL and develop sound proofs. Es-sentially, we define the inception of functions that mayneed to run a separate protocol to be basic sequences, asthey may involve blocking actions (like receive). Then,before and after these actions we define basic sequencepre- and post-conditions that must be satisfied for a suc-cessful completion of the protocols. The idea of basic se-quence pre and post conditions were give in [23] to enablestaged composition and remain standard in the language[15], although they have not been previously used in thisway to enable mid-protocol composition.

The retrieve action We have added a new action, re-trieve, to PCL. The retrieve action provides the key to thestrand, after key selection is complete. The retrieve ac-tion takes a key name (pmkN , corresponding to a specificpmk) as its input. If the principal that executes the func-tion does not have the key locally cached on disk, but is anMA (and has a connection with the MKD), retrieve initi-ates the PULL protocol. If the key is not on disk and theprincipal is not an MA, retrieve fails and the protocol thatcalled it aborts. As the retrieve action may or may not per-form a key pull, we create a break in the basic sequencedirectly before and directly after the retrieve.

The retrieve action has inherent pre- and post-conditions as it is a series of one or more basic se-quences (e.g., a protocol). As a precondition, retrieve

must have the pmk cached locally or it must have themptkX,T . Thus the precondition is Has(X, mptkX,T ) ∨Has(X, pmk) where pmk matches the input pmkN . Thepostcondition is simply Has(X, pmk). The retrieve func-tion itself has security requirements only if the principalmust perform a key pull, when it inherits the requirementsof the PULL protocol.

In Figure 4, retrieve is used to get the selected pmk .This provides two potential paths of execution through theprotocol, one which runs a key pull mid-protocol and onewhich simply fetches some stored memory (equivalent toa match action).

4. Overview of the Proof

In this section, we provide an overview of our proof ef-forts by highlighting three aspects of it. In Section 4.1 wediscuss our approach to proving key secrecy in the MSAproposal. In Section 4.2 we present additional securitygoals and a theorem that culminates our proof efforts. Fi-nally, in Section 4.3, we discuss our approach to protocolcomposition.

4.1. Key Secrecy in MSA

Inputs and Parties:Two parties: INIT and RESP. Shared input: confirmation key(ck). INIT private input: INIT public key (PKINIT ). RESPprivate input: secret key (sk).Goal: Has(Z, sk) ⊃ Z = INIT ∨ Z = RESP

Insecure Key Transfer Protocol:

1. INIT sends PKINIT to RESP.

2. RESP receives PKINIT ; encrypts sk under PKINIT ,computes the keyed hash of the encryption with keyck; and sends ({sk}PKINIT , HASHck({sk}PKINIT ))to INIT.

3. INIT receives ({sk}PKINIT , HASHck({sk}PKINIT )),verifies the keyed hash; decrypts sk; computes thekeyed hash of sk and PKINIT with the ck and sendsHASHck(sk, PKINIT ) to RESP.

4. RESP verifies the signature.

Figure 5. Insecure Key Transfer

Key secrecy is a critical security requirement. Someprevious work [23] has proven key secrecy as a proto-col postcondition. We show that proving key secrecy asa postcondition is insufficient by providing an example ofa protocol which has key secrecy as a postcondition (i.e.,upon protocol completion, key secrecy can be proven) but

322322322322

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

is insecure, because key secrecy can be lost. The InsecureKey Transfer Protocol in Figure 5 illustrates this point. Ifwe assume protocol completion from the point of view ofRESP we can prove that the secret key is distributed cor-rectly, as the validity of INIT’s public key is establishedonce RESP receives the third message. However RESPuses the public key in the second message before the va-lidity of the public key can be established. Thus if theprotocol aborts after the RESP sends the second message,it may be the case that the public key sent in message 1 isan adversary’s public key. It is therefore possible for theadversary to intercept the secret key. While this protocol iscontrived, in larger protocols with complex security goals,it may be the case that a subtle insecurity such as this goesunnoticed.

We prove the security of MSA’s key hierarchy usingthe work of Roy et al. [29, 28, 30]. We present the keysecrecy postconditions relevant to the MSA key hierarchyin Figure 6. We prove that these conditions hold at everypoint during any protocol execution of MSA, as long asthe indicated principals are honest. We also claim a newaxiom SAF5: SafeMsg(HASHs(M), s,K)). Informally,this states that a keyed hash of a message does not revealthe key.

θTLS,SI,1 :=KOHonest(xxKeyX, {privX , privT , xxKeyX}) ⊃Has(Z, xxKeyX) ⊃ Z = X ∨ Z = T

θ4WAY,SI,1 :=KOHonest(pmkmkdX , {xxKeyX}) ⊃Has(Z, pmkmkdX) ⊃ Z = X ∨ Z = T

θ4WAY,SI,2 :=KOHonest(mkdkX,T , {xxKeyX}) ⊃Has(Z, mkdkX,T ) ⊃ Z = X ∨ Z = T

θPPD,SI,1, θMKHSH,SI,1 :=KOHonest(mptkX,T , {mkdkX,T }) ⊃Has(Z, mptkX,T ) ⊃ Z = X ∨ Z = T

θPPD,SI,2 :=KOHonest(pmkX,Y , {pmkmkdX , mptkY,T }) ⊃Has(Z, pmkX,Y ) ⊃ Z = X ∨ Z = Y ∨ Z = T

θABBH,SI,1, θ4WAY,SI,3, θGKH,SI,1 :=KOHonest(ptkX,Y , {pmkX,Y , pmkY,X}) ⊃Has(Z, ptkX,Y ) ⊃ Z = X ∨ Z = Y ∨ Z = T

θABBH,SI,2, θ4WAY,SI,4, θGKH,SI,2 :=KOHonest(gtkX , {ptkX,Y1 , . . . ptkX,Yn}) ⊃Has(Z, gtkX) ⊃ Has(Z, ptkX,Yi)

Figure 6. MSA Key Secrecy Conditions

Ideally, we would like to eliminate this potential prob-

lem by proving key secrecy in an inductive manner, locallyfor each thread and role. But that’s not possible, becausekey information is not generally held purely locally andother nodes with the information may be abusing it. Keysecrecy must be maintained locally, of course, but it re-quires a global proof.

The techniques of [29] would note the deficiencies ofthe protocol in Figure 5, because the first message sentby RESP could not be proven to be a SafeMsg, induc-tively. We utilize this notion and extend the SafeNet con-cept across the entire suite of MSA protocols, to show thatno protocol violates the key secrecy of any other protocol.Doing this step before examining other desired protocolsecurity goals (postconditions) provides for more eleganceand correctness in the other proofs.

We introduce new notation �U . The meaning of P �U

θ is that postcondition θ must hold at every intermediatepoint of the relevant protocols in program set P . That is, ifthe terms in θ are defined and bound at the end of a basicsequence in P , then θ holds.

Theorem 1. Let MSA represent all the protocols in theMesh Security Architecture and θSI,ALL represent all ofthe key secrecy conditions in Figure 6. Then θSI,ALL aresatisfied by MSA. That is,

MSA �U θSI,ALL

Proof sketch: This theorem is proven in two steps. Thefirst step is a massive induction over all the basic se-quences of all the protocols that could be run by any par-ticipant in a mesh. This induction guarantees that all mes-sages sent are “safe,” in that critical information is pro-tected by keys. In the key secrecy goals of Figure 6, thecritical information protected is another key, lower in thehierarchy. From this, we argue the invariant nature of mul-tiple SafeNet axioms over the entire MSA protocol suite,limiting various goals to the protocols where the terms areinstantiated/defined. Then, we use the POS and POSLaxioms [29] to state who can potentially have access toother keys. By proceeding in this way through the entirekey hierarchy, we establish all the necessary key secrecygoals, at any point in a run where the keys may be defined.This proves key secrecy is maintained by all protocols inMSA.

This theorem guarantees that the parties listed in Figure6 are the only principals with those keys. This proves thatan attacker could not learn any key in the entire hierarchyfrom the MSA protocols.

4.2. Goals and Correctness Result

We present important security postconditions (goals)below. For each goal, we point out the kinds of proto-cols to which it applies. Goals are customized for each

323323323323

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

protocol; formal instances of each kind of goal we discussbelow are in Appendix A.1. We keep our discussions inthis section more informal for clarity.

AUTH : Authentication as realized by the generalizedmatching conversations property (see Section 3.1.1).In practice, this confirms peer liveness and peer pos-session of a particular key. This goal applies to allprotocols in the MSA proposal. This goal is ex-pressed as:

ΦAUTH := ∃Y.ActionsInOrder(Send(X, X, Y , msg1),Receive(Y, X, Y , msg1),Send(Y, Y , X, msg2), · · · ,

Receive(X, Y , X, msgn))

KF : Key freshness as realized by a freshly-generatednonce from each party as a term in the agreed-uponkey. This goal applies only to protocols which createa joint (session) key.

ΦKF := KOHonest(k,K) ⊃ (New (X, x)∧x ⊆ k ∧ New (Y , y) ∧ y ⊆ k) ∧FirstSend(X, x, X, x, m)∧FirstSend(Y, y, Y , y, m)

KA: Key agreement as realized by the Has predicate.This ensures that both parties have the session key.This goal applies to only those protocols that estab-lish a session key.

ΦKA := KOHonest(k,K) ⊃Has(X, k) ∧ Has(Y, k)

KD: Transfer of secret information (key delivery) as real-ized by the key secrecy goals and the Has predicate.This applies only to those protocols which transmitkeys (either a group transfer key (gtk) or a pairwisemaster key (pmk )).

ΦKD := KOHonest(k,K) ⊃Has(X, k) ∧ Has(Y, k)

INFO: Authentic exchange of non-secret informationand authenticated selection of sub-elements as real-ized in detailed protocol description and validatedreturn information. This applies only to protocolswhich must exchange non-security information andagree on parameters.

ΦINFO := KOHonest(k,K) ⊃Select(INFOX , INFOY ) = CS, pmkN ∧Has(X, CS, pmkN) ∧ Has(Y, CS, pmkN)

Our goals are extensions and clarifications of the goalsadopted by He et al. [23], which in turn are adapted fromthe list of desired security properties for 802.11i [1]. No

security goals have been explicitly specified for the gen-eral 802.11s protocol suite; however, we anticipate thatthe security goals for 802.11i are meaningful for 802.11sas well, provided they are adapted appropriately. Further-more, we feel that the goals we present above have intrin-sic intuitive appeal. We recommend that these goals, inaddition to the key secrecy goals discussed in Section 4.1,be formally adopted by the 802.11s task group.

In the following Theorem, we introducesome notation (�) for ease of exposition.TLS � AUTH ,KD means ΓTLS,{1,2,} �θTLS[TLS : CLNT]XΦTLS,{AUTH ,KD},CLNT

and the corresponding goal for theother node, namely ΓTLS,{1,2,} �θTLS[TLS : SRVR]XΦTLS,{AUTH ,KD},SRV R. Thesestate that, with the proper invariants, the protocol fromeach perspective provably satisfies the security goalsAUTH and KD , particular to TLS. Similar expansionshave been made for each protocol and the details are inour full paper [25].

With the changes that we discuss in Section 5, we areable to prove the component-wise correctness of each ofthe protocols of the MSA proposal.

Theorem 2. The following are true, with the notation de-scribed above.

(i) TLS � AUTH, KD(ii) 4WAY � AUTH, KF, KA, KD, INFO(iii) MKHSH � AUTH, KF, KA, KD, INFO(iv) GKH � AUTH, KD(v) PUSH � AUTH, KD(vi) PULL� AUTH, KD(vii) DEL� AUTH(viii)ABBH � AUTH, KF, KA, KD, INFO

This theorem was one of the major driving forces be-hind the work. It asserts that the full protocol suite in theMSA proposal, with a rather complex key hierarchy, is se-cure. Each protocol achieves the maximal security goalsfor its type. Appendix A contains a proof of part of (viii)and provides a feel for the proof methodology. The proofof Theorem 2 depends on the PCL additions of Section 3.

4.3. Composition

The MSA architecture allows for significant variationin how protocols compose together [4]. Once an estab-lished state is reached, many protocols (which may havebeen run previously to reach the established state) may bechosen. Reaching an established state may take a vari-ety of paths, depending on the authentication mechanism(TLS or pre-shared key) used. Error-handling strategieswill cause protocols to restart, or, potentially, differentprotocols to be run. This introduces a complex state di-agram and complexities of composition.

324324324324

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

While staged composition proofs have been presentedpreviously [28, 23], the presentation in each case has dif-fered. Staged composition allows arbitrary back arrowsand paths through possible protocol execution paths. Thisallows for protocol restarts, lost connections, and otherreal-world considerations about the order in which proto-cols are run. We provide a slightly different presentationof similar ideas in Section 4.3.1. Readers primarily in-terested in the proof of MSA may skip this section andproceed to Section 4.3.2 where the overall MSA securitytheorem is presented.

4.3.1 Consistent Composition

The concept of branches within protocols or betweenprotocols has not been explicitly mentioned in previousPCL composition theorems. We require this functionality,to denote how a particular staging can be accomplishedwithin the MSA framework. One of our motivations isto allow such possibilities as are represented in Figure 7.After basic sequence A, either sequence B or sequence Cmay follow. Sequence D follows C and both B and D leadto E. The consistent composition theorem provides the re-quirements under which such branches will still compose.This also provides for all manner of if/then functionalitywithin PCL, if it can be properly created in semantics andthe various results of the if/then statement are properlymodeled in terms of basic sequence breaks. We believethis fills a gap in the span of PCL.

A

B

E

C

D

��

���

��

���

�����

�

�����

Figure 7. Branches in PCL

We utilize the definitions of role-prefix, staged role,and staged composition from [23], suitably augmented forthe retrieve action. Informally, role-prefix defines whichsets of basic sequences can lead to a particular basic se-quence. A staged role is a particular, legitimate sequenceof basic sequences leading to a particular execution point.And staged composition allows for sequential implemen-tation with arbitrary returns to earlier execution points,with the branching of retrieve potentially following dif-ferent paths on each iteration.

We use θPi to indicate the precondition for basic se-quence Pi. Additionally, to add simplicity to our exposi-tion, we use Γ to denote the conjunction of all invariants

within a staged composition of protocols. That is, Γ is thetotality of all the invariants from each of the protocols Qi

that make up a composition of protocols Q. This allowsus to state the following theorem succinctly.

Theorem 3. Let Q be a staged composi-tion of protocols Q1, Q2, . . . , Qn and P ; Pi ∈SComp(〈Q1, Q2, . . . , Qn〉) and Pi ∈ Qi. Then Q �θP0 [P ; Pi]XθPi+1 , if for all RComp(〈P1, P2, . . . , Pn〉) ∈Q, all of the following hold:

(Invariants)(i) ∀i.∀S ∈ BS(Qi). � θPi ∧ Γ[S]XΓ(Preconditions)(ii) Q1 ⊗ Q2 ⊗ · · · ⊗ Qn � ∀i.θPi [Pi]XθPi+1

(iii)∀i.∀S ∈ ⋃j≥i BS(Pj).θPi [S]XθPi

(iv) Q1 ⊗ Q2 ⊗ · · · ⊗ Qn � Start(X) ⊃ θP1

Theorem 3 states the conditions under which a partic-ular run through a set of actions reaches its ultimate goal.The “Invariants” condition requires that no basic sequenceviolate any invariant of any basic sequence, with its properpreconditions, and invariants holding before the basic se-quence. The “Preconditions” conditions require that eachbasic sequence’s postconditions imply the next basic se-quence’s preconditions, that no basic sequence ever vi-olate any preceding basic sequence’s preconditions, andthat the start state is valid.

We point out that Theorem 3 is dependent on basic se-quences as its fundamental building block. The protocolsthemselves, while useful distinctions in understanding andmodeling the system, are not critical. In particular, theQi’s could be single basic sequences and the entire the-orem still holds. This allows us to model at the level ofbasic sequences. This level of granularity has been sug-gested before [23], but we make it explicit.

This allows, for example, the behavior of the retrieveaction that we discuss Section 3.3. Retrieve allows twodifferent paths through a larger staged composition. Inone path, a locally stored value is returned. In the otherpath, an entire protocol is run. As protocols compose con-sistently at the granularity of basic sequences in the initialprotocol, retrieve fundamentally denotes alternate meth-ods of staging the composition. In all protocols that useretrieve, the invariants and various preconditions in theprotocol are proven against all possible stagings of the re-trieve action.

4.3.2 Composition in MSA

We wish to apply Theorem 3 to the protocols of the MSAproposal. We view the protocols of staged compositionas the protocols given previously. As mentioned, we con-sider arbitrary breaks at the basic sequence level, for mid-protocol composition as well as overall composition. We

325325325325

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

need to prove that all protocols within MSA (compris-ing PLE, TLS, 4WAY, MKHSH, GKH, PULL, PUSH,DEL, and ABBH, (both ABBH.INIT and ABBH.SIMO)satisfy the necessary conditions for composition.

Theorem 4. Let Q be a specific composition of proto-cols from MSA and RComp(〈P1, P2, . . . , Pn〉) ∈ Q andΓ = ΓTLS,{1,2}∧Γ4WAY,1∧ΓMKHSH,1∧ΓGKH,{1,2}∧ΓPPD,{1,2} ∧ ΓABBH,1. Then:

(i) ∀i.∀S ∈ BS(Qi). � θPi ∧ Γ[S]XΓ(ii) Φ4WAY � θMKHSH ∧ θGKH

ΦMKHSH � θPUSH ∧ θPULL ∧ θDEL

ΦMKHSH � θABBH

ΦABBH � θGKH

(iii)∀i.∀S ∈ ⋃j≥i BS(Pj).θPi [S]XθPi

(iv)θP1

Proving that all the protocols securely compose is alengthy induction process, which we omit owing to spaceconstraints. We briefly discuss the meaning of the varioussubpoints. No portion of any protocol in MSA violatesthe invariants (i) or changes the preconditions (iii) of anyMSA protocol. All nodes in a mesh start with the correctinformation, by assumption (iv). Point (ii) gives the pro-tocols which guarantee certain subsequent protocols canbe completed with other legitimate nodes, via pre and postcondition matching.

This theorem states that, given any MSA protocol, ifthe MKD and the players in the protocol are honest (thatis, they conform to the protocol specification), then the se-curity of that protocol is ensured, regardless of what otherprotocols may be running in the system. By extension, amesh of honest nodes guarantees our security goals; theMesh Security Architecture is sound.

5. Modifications to MSA

Our analysis of the protocols and key hierarchy of theMSA proposal indicate that it was largely well-designed.We have two recommendations that have been incorpo-rated into the 802.11s draft (as of March 2008) and arenecessary for Theorem 2 to hold; otherwise, the protocolsare insecure.

5.1. Include Mesh Nonce in 4WAY

The draft specification of 4WAY during MSA authen-tication does not properly provide key freshness. The pro-posal has the key generation nonce (MKDnonce) providedby the MKD used both to derive the pmkmkd (see Figure2) and as the nonce to derive the session key (ptk ). This isshown in Figure 8.

This enables an attack that proceeds as follows. Atsome point, a legitimate node (X) disconnects from the

mesh. The attacker then starts MSA authentication withthe same MA with which X connected before. The roguenode does PLE (claiming to be X) and then continues tothe 4WAY protocol, where the MKDnonce is the same.The rogue node re-uses the nonce X used and now thesame ptk is derived. The attacker may then utilize someinformation recorded from the legitimate conversation orotherwise abuse the mesh. If TLS is used and not a pre-shared key, then this particular attack no longer works.

The solution adopted by 802.11s is to modify thederivation of pmkmkd so that it does not require an MKD-nonce, so that 4WAY is responsible only for transportingnonces used to derive the ptk. The MKDnonce was re-moved as it did not provide significant benefit to the archi-tecture and was not required for our key freshness goal. Atthis point, key freshness (for the ptk ) can be proven andthe attack outlined above is thwarted.

5.2. Include MAC Address in the GroupKey Handshake protocol (GKH)

In the original proposal, GKH does not provide au-thentication. Recall from section 4.2 that the AUTHgoal requires matching conversations between two differ-ent nodes. In the proof of this property, it became apparentto us that the proposal did not protect against a reflectionattack.

MAC addresses were contained in the GKH messageheaders (to facilitate transport of the messages) but werenot incorporated in the calculation of the message integritycode (mic) included in each GKH message. GKH mes-sages are protected using the ptk, a pairwise key knownonly to two parties, but either party may initiate the GKH.Owing to this symmetry, the first GKH message couldbe reflected back to the sender, and would be accepted asvalid because of the presence of a valid mic. This reflec-tion attack could change the security state at the MP thatsends the first message of GKH, such as by installing astale gtk or installing its own gtk as if it were its neigh-bor’s gtk.

The proposed modification includes the explicit iden-tification of sender and receiver in the protected portionof the message, and updates the processing of GKH mes-sages to verify this information upon reception. This pre-vents the replay attack because the sender and receiverMAC addresses would not match if a reflection attack isattempted.

6. Conclusions and Future Work

We have proven the security of the MSA, under stan-dard assumptions. We provided and justified a few rec-ommendations that were incorporated (as of March 2008)

326326326326

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

X Y TPLE

PULL��

��MKDnonce�

4WAY ��MKDnonce�

x, hashptk = mic �

Figure 8. MSA Authentication. The text above a double-headed arrow (e.g., 4WAY) is a protocol, and text below (e.g.,MKDnonce) is some data that is sent as part of the protocol.

into the 802.11s draft standard, which is still being devel-oped. We also hope that providing a security proof dur-ing the design and review process will lead to additionalefforts in that regard. We feel that protocol design is im-portant and an analysis of a system should be done beforeimplementation, not after. In the process of this analysis,we made a number of contributions to PCL.

The most important contribution, from our perspective,is the ability to handle simultaneity, with the introductionof action groups and associated axioms and proof tech-niques. The definition of generalized authentication usinggeneralized matching conversations is also required for si-multaneous peer-to-peer protocols. The select and retrieveactions were also designed to extend naturally to examina-tions of other architectures.

This paper also takes a deeper dive into the details ofthe protocols than is often undertaken. While examiningonly the security components (nonces, keys, etc.) simpli-fies analysis, it also leaves a gap. Our experience leadsus to believe that gaps in analysis are often dangerous, asthey lead to assumptions about security, implementationdifficulties, and unforeseen attack vectors. Some level ofabstraction is necessary, but adding a model for authenti-cated information exchange is critical for many applica-tions.

This paper opens opportunities for applying PCL toother peer-to-peer protocols, where ordering may not beas strict as in server-client models. Other protocol sys-tems, particularly those on standard-track, would be natu-ral candidates for additional analysis.

Finally, we provide a new, more general compositiontheorem, which explicitly allows for mid-protocol com-position and branching. As it is not unusual for protocolsto intermix, explicitly allowing multiple potential pathsthrough basic sequences is important, and should naturallyextend to other situations.

Acknowledgements

The authors would like to thank Anupam Datta and ArnabRoy for their helpful comments and suggestions. The au-thors would also like to thank the anonymous referees fortheir comments.

References

[1] IEEE Standard 802.11-2007. Local and metropoli-tan area networks – specific requirements – part 11:Wireless LAN medium access control and physicallayer specifications, 2007.

[2] M. Bellare and P. Rogaway. Entity authenticationand key distribution. In CRYPTO, pages 232–249,1993.

[3] L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson, andH. Levkowetz. Extensible authentication proto-col (EAP). http://tools.ietf.org/html/draft-ietf-eap-rfc2284bis-09, 2004.

[4] T. Braskich and S. Emeott. Clarification and up-date of MSA overview and MKD functionalitytext. https://mentor.ieee.org/802.11/documents doc11-07/2119r1, July 18 2007.

[5] T. Braskich and S. Emeott. Ini-tial MSA comment resolution.https://mentor.ieee.org/802.11/documents doc11-07/0564r2, May 16 2007.

[6] T. Braskich and S. Emeott. Key dis-tribution for MSA comment resolution.https://mentor.ieee.org/802.11/documents doc11-07/0618r0, May 14 2007.

[7] T. Braskich and S. Emeott. Meshkey holder protocol improvements.https://mentor.ieee.org/802.11/documents doc11-07/1987r1, June 27 2007.

[8] T. Braskich, S. Emeott, C. Barker, andG. Strutt. An abbreviated handshakewith sequential and simultaneous forms.https://mentor.ieee.org/802.11/documents doc11-07/2535r0, Sept. 19 2007.

[9] T. Braskich, S. Emeott, and D. Kuhlman. Secu-rity requirements for an abbreviated MSA hand-shake. https://mentor.ieee.org/802.11/documentsdoc 11-07/0770r0, May 15 2007.

327327327327

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

[10] C. Cremers. On the protocol composition logic PCL.In Proc. of the Third ACM Symposium on Infor-mation, Computer & Communication Security (ASI-ACCS ’08), Tokyo, 2008. ACM Press. To appear.

[11] A. Datta, A. Derek, J.C.Mitchell, and B.Warinschi.Computationally sound compositional logic for keyexchange protocols. In Proceedings of 19th IEEEComputer Security Foundations Workshop, pages321–334, 2006.

[12] A. Datta, A. Derek, J. Mitchell, and D. Pavlovic. Aderivation system for security protocols and its log-ical formalization. In 16th IEEE Computer SecurityFoundations Workshop (CWFW-16), pages 109–125,2003.

[13] A. Datta, A. Derek, J. C. Mitchell, and D. Pavlovic.Secure protocol composition. In FMSE, pages 11–23, 2003.

[14] A. Datta, A. Derek, J. C. Mitchell, and D. Pavlovic.A derivation system and compositional logic for se-curity protocols. J. Comput. Secur., 13(3):423–482,2005.

[15] A. Datta, A. Derek, J. C. Mitchell, and A. Roy. Pro-tocol composition logic (PCL). Electr. Notes Theor.Comput. Sci., 172:311–358, 2007.

[16] A. Datta, A. Derek, J. C. Mitchell, and B. Warinschi.Key exchange protocols: Security definition, proofmethod and applications.

[17] T. Dierks and E. Rescorla. The Transport LayerSecurity (TLS) Protocol, version 1.1 – RFC 4346.http://tools.ietf.org/html/rfc4346, April 2006.

[18] W. Diffie, P. C. van Oorschot, and M. J. Wiener. Au-thentication and authenticated key exchanges. Des.Codes Cryptography, 2(2):107–125, 1992.

[19] N. Durgin, J. Mitchell, and D. Pavlovic. A composi-tional logic for proving security properties of proto-cols. In Proceedings of 14th IEEE Computer Secu-rity Foundations Workshop, pages 241–255, 2001.

[20] N. Durgin, J. Mitchell, and D. Pavlovic. A composi-tional logic for proving security properties of proto-cols. J. Comput. Secur., 11(4):677–721, 2004.

[21] D. Gollmann. What do we mean by entity authen-tication? In SP ’96: Proceedings of the 1996 IEEESymposium on Security and Privacy, page 46, Wash-ington, DC, USA, 1996. IEEE Computer Society.

[22] J. Haasz and S. Hampton.Amendment: Mesh networking.

http://standards.ieee.org/board/nes/projects/802-11s.pdf, 2006.

[23] C. He, M. Sundararajan, A. Datta, A. Derek, andJ. C. Mitchell. A modular correctness proof of IEEE802.11i and TLS. In ACM Conference on Computerand Communications Security, pages 2–15, 2005.

[24] H. Krawczyk. SIGMA: The ‘SIGn-and-MAc’ ap-proach to authenticated diffie-hellman and its usein the IKE-protocols. In CRYPTO, pages 400–425,2003.

[25] D. Kuhlman, R. Moriarty, T. Braskich,S. Emeott, and M. Tripunitara. A proofof security of a mesh security architecture.http://eprint.iacr.org/2007/364.pdf, 2007.

[26] C. Meadows and D. Pavlovic. Deriving, attackingand defending the GDOI protocol. In ESORICS,pages 53–72, 2004.

[27] C. Rigney, S. Willens, A. Rubens, andW. Simpson. Remote Authentication DialIn User Service (RADIUS) – RFC 2865.http://tools.ietf.org/html/rfc2865, June 2000.

[28] A. Roy, A. Datta, A. Derek, and J. C. Mitchell. In-ductive proof method for computational secrecy. InProceedings of 12th European Symposium On Re-search In Computer Security, 2007.

[29] A. Roy, A. Datta, A. Derek, J. C. Mitchell, and J-P. Seifert. Secrecy analysis in protocol compositionlogic. In Proceedings of 11th Annual Asian Comput-ing Science Conference, 2006.

[30] A. Roy, A. Datta, A. Derek, J. C. Mitchell, and J-P. Seifert. Secrecy analysis in protocol compositionlogic. In Formal Logical Methods for System Secu-rity and Correctness. IOS Press, 2008.

[31] D. Simon, B. Aboba, and R. Hurst.The EAP TLS authentication protocol.http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-11.txt, 2007.

[32] M. Zhao, J. Walker, and W. Steven Con-ner. Overview of abbreviated handshake proto-col. https://mentor.ieee.org/802.11/documents doc11-07/1998r01, June 14 2007.

A. SIMO Security

A.1. Security Goals for SIMO

Here we detail the five PCL security goals for the SIMO abbreviatedhandshake protocol (the AUTH goal was presented in Figure 4 and is

328328328328

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

repeated here). These directly correspond to the security goals detailedin Section 4.2. Unlike the generic goals presented there, these are thespecific instances for the SIMO protocol.

Goals SIMO:ΦSIMO,AUTH := KOHonest(ptkX,Y , {pmkX,Y , pmkY,X}) ⊃(Send(X, SIMO1X) < Receive(Y, SIMO1X))∧(Send(Y, SIMO1Y) < Receive(X, SIMO1Y))∧(Send(Y, SIMO5Y) < Receive(X, SIMO5Y))∧(Send(X, SIMO1X) < Receive(X, SIMO1Y) <(Send(X, SIMO5X) ∧ Receive(X, SIMO5Y))∧(Send(Y, SIMO1Y) < Receive(Y, SIMO1X) <Send(Y, SIMO5Y))

ΦSIMO,KF :=KOHonest(ptkX,Y , {pmkX,Y , pmkY,X}) ⊃(New (X, x) ∧ x ⊆ ptkX,Y ∧ New (Y , y) ∧ y ⊆ ptkX,Y )∧FirstSend(X, x, X, x, SIMO1X)∧FirstSend(Y, y, Y , y, SIMO1Y)

ΦSIMO,KA :=KOHonest(ptkX,Y , {pmkX,Y , pmkY,X}) ⊃Has(X, ptkX,Y ) ∧ Has(Y, ptkX,Y )

ΦSIMO,KD :=KOHonest(ptkX,Y , {pmkX,Y , pmkY,X})∧Receive(Y, SIMOX5) ⊃Has(X, gtkY ) ∧ Has(Y, gtkX)

ΦSIMO,INFO :=KOHonest(ptkX,Y , {pmkX,Y , pmkY,X}) ⊃SELECT (INFOX , INFOY ) = CS, pmkN∧Has(X, CS, pmkN) ∧ Has(Y, CS, pmkN)

A.2. Proof Security Goals, SIMO

Proof Sketch Generalized Authentication, SIMO Weonly need to show the proof from a single point of view as the rolesare symmetric. Let principal X be the principal from whose view weare establishing the proof from and let Y be the other principal. As theproof assumes X has completed the protocol successfully, we know thatSIMO1X was sent before SIMO5X and SIMO1Y was received beforeSIMO5Y. Thus to complete the proof we must show that Y sent exactlySIMO1Y before SIMO5Y and received exactly SIMO1X before sendingSIMO5Y. We can determine the MIC in SIMO5Y could have only beensent by Y if X, Y and T are honest. Since all the variables used in theprotocol are contained in the MIC of SIMO5Y, we know that X and Yshare identical variables. Now using the honesty of Y we are sure that Ysent SIMO1Y and received SIMO1X before sending SIMO5Y and thatit was sent exactly as X received it. Again if Y is honest since X and Yshare variables, then Y must have received SIMO1X exactly as X hadsent it. This gives us generalized authentication.

Generalized Authentication:AA1,ARP, AA4, θABBH,1

[ABBH : SIMO]X

Send(X, Y , X, “ABBH1”, INFOX , x) <

Receive(X, X, Y , “ABBH1”, INFOY , y) <

(Receive(X, X, Y , “ABBH5”, INFOY , y, x, enc1, mic1)∧Send(X, Y , X, “ABBH5”, INFOX , x, y, enc0, mic0)) (1)

ARP, HASH3′, θABBH,1

[ABBH : SIMO]X

Receive(X, X, Y , “ABBH5”, INFOY , y, x, enc1, mic1) ⊃∃Z.Computes(Z, HASHptkX,Y

(

X, Y , “ABBH5”, INFOY , y, x, enc1, INFOX))∧

Sends(Z, HASHptkX,Y(

X, Y , “ABBH5”, INFOY , y, x, enc1, INFOX)) <

Receive(X, X, Y , “ABBH5”, INFOY , y, x, enc1, mic1) (2)

θABBH,SI,1,HASH1KOHonest(ptkX,Y , {pmkX,Y , pmkY,X}) ⊃Computes(Z, HASHptkX,Y

(

X, Y , “ABBH5”, INFOY , y, x, enc1, INFOX)) ⊃Has(Z, ptkX,Y ) ⊃ Z = X ∨ Z = Y ∨ Z = T (3)

2,3,AA1,ΓABBH,1, θABBH,1

[ABBH : SIMO]XKOHonest(ptkX,Y , {pmkX,Y , pmkY,X}) ⊃Send(Z, HASHptkX,Y

(

X, Y , “ABBH5”, INFOY , y, x, enc1, INFOX)) ⊃ Z = Y(4)

2,4, θABBH,1

[ABBH : SIMO]XKOHonest(ptkX,Y , {pmkX,Y , pmkY,X}) ⊃Computes(Y, HASHptkX,Y

(

X, Y , “ABBH5”, INFOY , y, x, enc1, INFOX))∧Send(Y, HASHptkX,Y

(

X, Y , “ABBH5”, INFOY , y, x, enc1, INFOX)) (5)

5,HASH1, θABBH,1

[ABBH : SIMO]XHas(Y, ptkX,Y )∧Has(Y, X, Y , “ABBH5”, INFOY , y, x, enc1, mic1) (6)

5,6, φHONESTY, θABBH,1

[ABBH : SIMO]XKOHonest(ptkX,Y , {pmkX,Y , pmkY,X}) ⊃Send(Y, X, Y , “ABBH1”, INFOY , y) <

Receive(Y, Y , X, “ABBH1”, INFOX , x) <

Send(Y, X, Y , “ABBH5”, INFOY , y, x, enc1, mic1) (7)

2,7, θABBH,1

[ABBH : SIMO]XKOHonest(ptkX,Y , {pmkX,Y , pmkY,X}) ⊃Send(Y, X, Y , “ABBH5”, INFOY , y, x, enc1, mic1) <

Receive(X, X, Y , “ABBH5”, INFOY , y, x, enc1, mic1) (8)

FS1,AN3, θABBH,1

[ABBH : SIMO]X

FirstSend(X, x, Y , X, “ABBH1”, INFOX , x) (9)

9,FS2, θABBH,1

[ABBH : SIMO]X

Send(X, Y , X, “ABBH1”, INFOX , x) <

Receive(Y, Y , X, “ABBH1”, INFOX , x) (10)

FS1,AN3, θABBH,1

[ABBH : SIMO]XHonest(Y ) ⊃FirstSend(Y, y, X, Y , “ABBH1”, INFOY , y) (11)

7,11,FS2, θABBH,1

[ABBH : SIMO]XKOHonest(ptkX,Y , {pmkX,Y , pmkY,X}) ⊃

329329329329

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.

Send(Y, X, Y , “ABBH1”, INFOY , y) <

Receive(Y, X, Y , “ABBH1”, INFOY , y) (12)

1,7,8,10,12, θABBH,1

[ABBH : SIMO]XKOHonest(ptkX,Y , {pmkX,Y , pmkY,X}) ⊃(Send(X, Y , X, “ABBH1”, INFOX , x) <

Receive(Y, Y , X, “ABBH1”, INFOX , x))∧(Send(Y, X, Y , “ABBH1”, INFOY , y) <

Receive(Y, X, Y , “ABBH1”, INFOY , y))∧(Send(Y, X, Y , “ABBH5”, INFOY , y, x, enc1, mic1) <

Receive(X, X, Y , “ABBH5”, INFOY , y, x, enc1, mic1))∧(Send(X, Y , X, “ABBH1”, INFOX , x) <

Receive(X, X, Y , “ABBH1”, INFOY , y) <

(Receive(X, X, Y , “ABBH5”, INFOY , y, x, enc1, mic1)∧Send(X, Y , X, “ABBH5”, INFOX , x, y, enc0, mic0)))∧(Send(Y, X, Y , “ABBH1”, INFOY , y) <

Receive(Y, Y , X, “ABBH1”, INFOX , x) <

Send(Y, X, Y , “ABBH5”, INFOY , y, x, enc1, mic1)) (13)

330330330330

Authorized licensed use limited to: University of Waterloo. Downloaded on February 9, 2009 at 13:21 from IEEE Xplore. Restrictions apply.