**2. Preliminaries**

In this section, we provide some background and motivations for our work.

## **2.1. Overview of proof method**

We use Protocol Composition Logic (PCL) to prove the correctness and security of the Mesh Security Architecture. We provide a brief overview of PCL in this section. PCL has been used for a security analysis of 802.11i [26], Kerberos [32], and the Group Domain of Interpretation (GDOI) protocol [29].

#### *2.1.1. Terminology*

Protocols in PCL are modeled using a particular syntax. A *role* specifies a sequence of actions performed by an honest party. A matching set of roles (two, in this chapter) define a *protocol*. A particular instance of a role run by a specific principal is a *thread*. Possible actions inside a thread include nonce generation, signature creation, encryption, hash calculation, network communication, and pattern matching (which includes decryption and signature verification). Each thread consists of a number of *basic sequences*, each of which has pre- and post-conditions. A basic sequence is a series of actions, which may not include a blocking action (like receive) except as the first action. Pre- and post-conditions are assertions expressed as logic predicates that must be true before and after a protocol run, respectively. Each basic sequence may have pre- and post-conditions as well, allowing for additional reasoning about certain actions.

#### *2.1.2. Notation*

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

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

*X*ˆ ,*Y*ˆ, *Z*ˆ, . . . denote the principals associated with the corresponding threads. send, receive, new, . . . are *actions*. Actions are things that principals do in a thread. **MKHSH**, **TLS:CLNT**, **4WAY**, . . . denote protocols. We use the convention of protocol:role to note both the protocol and the associated role that a principal plays in an instance of the protocol; for example, in **TLS:CLNT**, **CLNT** denotes that it is the client's portion of the **TLS** protocol.

*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 formulae that express pre- or post-conditions, or *invariants*.

Has(), KOHonest(), SafeMsg(), . . . are logic predicates that are used in assertions (preand post-conditions, and invariants).

Many of the predicates follow a *Pred*(*actor*, *action*)format. Thus, Has(*X*, *m*) means that thread *X* has information *m*. Similar predicate formats follow for Send, Receive, New, and Computes. Other predicates can be more complicated. Honest(*X*ˆ) means that the principal (*X*ˆ ) running the thread is honest. KOHonest(*s*, K) essentially means that all principals with access to any key *k* ∈ K or to the value *s* are honest. Contains(*m*, *t*) is equivalent to *t* ⊆ *m* and means that information *t* is a subterm of *m*.

#### *2.1.3. Proof methodology*

2 Will-be-set-by-IN-TECH

• In the course of carrying out our proof, we discovered two security issues with protocols in the proposal. We discuss these issues and our suggestions for changes to address them. Our suggestions have since been incorporated into the proposal. As we point out in

The remainder of this chapter is organized as follows. In Section 2, we provide a background on PCL, 802.11s and the MSA proposal. In Section 3 we present our additions to PCL; for each addition we illustrate its need via components from the protocol suite we have analyzed. We provide an overview of the proof in Section 4. In Section 5, we discuss our recommendations for changes to the original design of the protocol suite in the MSA proposal based on our proof

We use Protocol Composition Logic (PCL) to prove the correctness and security of the Mesh Security Architecture. We provide a brief overview of PCL in this section. PCL has been used for a security analysis of 802.11i [26], Kerberos [32], and the Group Domain of Interpretation

Protocols in PCL are modeled using a particular syntax. A *role* specifies a sequence of actions performed by an honest party. A matching set of roles (two, in this chapter) define a *protocol*. A particular instance of a role run by a specific principal is a *thread*. Possible actions inside a thread include nonce generation, signature creation, encryption, hash calculation, network communication, and pattern matching (which includes decryption and signature verification). Each thread consists of a number of *basic sequences*, each of which has pre- and post-conditions. A basic sequence is a series of actions, which may not include a blocking action (like receive) except as the first action. Pre- and post-conditions are assertions expressed as logic predicates that must be true before and after a protocol run, respectively. Each basic sequence may have pre- and post-conditions as well, allowing for additional reasoning about certain actions.

We use the following notation in this chapter. Our notation is consistent with previous work on PCL except for the extensions that we propose in this chapter (see Section 3 for a discussion

*X*ˆ ,*Y*ˆ, *Z*ˆ, . . . denote the principals associated with the corresponding threads.

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

Section 5, our proof would not have been possible without these changes.

efforts. We conclude with future work and general conclusions in Section 6.

In this section, we provide some background and motivations for our work.

**2. Preliminaries**

(GDOI) protocol [29].

*2.1.1. Terminology*

*2.1.2. Notation*

of the extensions).

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

**2.1. Overview of proof method**

The proof methodology of PCL is described by Durgin et al. [21, 22] and Datta et al. [12–18, 26, 32]. We use the standard syntax of *θ*[*P*]*X*Φ. This means that with preconditions *θ* before the run of actions *P* by thread *X*, the result (postcondition) Φ is proven to hold. *θ* is always used to denote a precondition, Φ a postcondition, and Γ an invariant.

The proof system is built on three fundamental building blocks. The first is a series of first-order logical axioms [15]. A first-order logical axiom is a natural logical assumption (e.g., creation of a value implies possession of that value). The second is a series of cryptographic/security axioms [15, 22, 26]. Cryptographic axioms provide formal logic equivalents of standard cryptography (e.g., possession of a key and a value provides possession of the encryption of the value with that key). These assume idealized cryptographic functionality which most cryptographic primitives do not achieve in practice. For example, the hash of two different values is assumed to never be the same.

The third building block is the fundamental principle of *honesty*. Honesty imposes certain restrictions on roles – that they follow protocol descriptions correctly and do not send out particular information assigned to that role. Honesty is a special type of rule that allows an instance of a thread to reason about the actions of another, corresponding 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 violate an assumption, condition or invariant (e.g., the possession of a private key) that is necessary for a protocol to run to completion. This notion of an attacker model is the same as that considered in previous work that uses approaches based on mathematical logic to verify protocols (c.f. [26]).

All but one of the axioms on which we depend have been proposed previously [12, 15, 16, 26]; space constraints preclude the presentation of a comprehensive list of all PCL axioms in this chapter. We provide a few frequently used axioms in Figure 1. We do, however, point out that we need an additional axiom: a node which generates a signature over some (previously-defined) information has that information and the key with which the signature is generated. The existence of information *m* outside of the computation is important to eliminate concerns about existential signature forgery.

**2.2. Overview of the MSA proposal for 802.11s**

of the specification that began in late 2006 [4–7].

join the mesh but is not yet an MP.

(i.e., *pmkX*,*<sup>Y</sup>* is different from *pmkY*,*X*).

The 802.11s task group is working to develop a mesh networking protocol that sets up auto-configuring, multi-hop paths between wireless stations to support the exchange of data packets. A goal of the task group is to utilize existing IEEE 802.11 security mechanisms [1], with extensions, to secure a mesh in which all the stations are controlled by a single logical administrative entity from the standpoint of security [25]. The 802.11s task group continues to refine its draft specification through the resolution of comments received during a review

A Correctness Proof of a Mesh Security Architecture 181

A mesh network is a collection of network nodes, each of which can communicate with the others. Several kinds of nodes are specified in the MSA proposal. One is a *Mesh Point* (MP), a member of the mesh that can communicate with other nodes. Each mesh has at least one *Mesh Key Distributor* (MKD) which is an MP that is responsible for much of the key management within its *domain* (a MKD's domain is the set of nodes with which it has a secure connection). The MKD also provides a secure link to an external authentication server (e.g., a RADIUS [30] server). A *Mesh Authenticator* (MA) is an MP which has been authorized by the MKD to participate in key distribution within the mesh. A *Candidate MP* is an entity that wishes to

**Differences from 802.11i** Part of the MSA proposal is very similar to the 802.11i protocol suite [1]. In 802.11i, connections are established between authenticators and supplicants in a server-client topology. An authenticator is connected to a backbone infrastructure, and each supplicant may use an Extensible Authentication Protocol (EAP) [3] method such as EAP-TLS [34] to authenticate with the infrastructure. Each supplicant then uses a four-message handshake to secure a session with an authenticator, allowing subsequent use of its resources. The authenticator also maintains a broadcast key that is given to each of its successful supplicants. These protocols were examined in [26] and proven to be secure.

In addition to the 802.11i functionality, the MSA proposal allows the mesh to be a peer-to-peer network. Nodes in an MSA mesh may play different roles at different times. Thus, the proof of security of the 802.11i 4-way handshake [26], which assumes limitations on the messages a node can send, does not hold. The peer-to-peer nature also poses some difficulties with timing. The 802.11i proofs adopt *matching conversations* [2] as the authenticity property. As we discuss in Section 3.1.1, the notion of matching conversations imposes a rather strict ordering of messages in a protocol run, and is too rigid for our purposes. In MSA, we must provide for the case that both parties simultaneously start instances of a protocol and messages are not

**The key hierarchy** Each node in Figure 2 represents a key in principal *X*'s key hierarchy. An edge from key *k*<sup>1</sup> to *k*<sup>2</sup> shows that *k*<sup>2</sup> is either derived from or delivered using *k*<sup>1</sup> (that is, *k*<sup>1</sup> *protects k*2, as knowledge of *k*<sup>1</sup> is required to obtain *k*2). The edge's label is the protocol that is used to derive or deliver the key. The subscript in a key (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 entities that may possess the key. The subscripts are ordered

necessarily well-ordered. Thus, the proofs from [26] do not carry over directly.

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

(Computes() and Has() are predicates, ⊃ can be read as "implies," ∧ is logical conjunction and *a* < *b* indicates *a* occurred temporally before *b*.)


#### **Figure 1.** Some PCL Axioms Used in MSA Proofs

The methodology of PCL has proven very successful in dealing with large-scale architectures. A recent paper by Cremers looked at the soundness of the various axioms of PCL [11]. For the problem of preceding actions, we have consistently used implicit pre- and post-conditions at the basic sequence level, leading to a tighter joining of actions. Another issue arises with the **HASH3** axiom. We propose a straight-forward generalization of the **HASH3** axiom, following earlier work on signatures. We define a new axiom, which is sound.

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

#### *2.1.4. Composing proofs*

An important feature of PCL is that with it, we can reason about how protocols interact. As this chapter covers an entire architecture, it is imperative that the large number of individual protocols be proven secure not only independently, but also working together in conjunction as a complete system. To this end, we extensively use the methodology of protocol composition developed by Datta et al. [15]. We discuss this in Section 4.3. Alternate composition methods are available, in certain circumstances [10].

#### **2.2. Overview of the MSA proposal for 802.11s**

4 Will-be-set-by-IN-TECH

this chapter. We provide a few frequently used axioms in Figure 1. We do, however, point out that we need an additional axiom: a node which generates a signature over some (previously-defined) information has that information and the key with which the signature is generated. The existence of information *m* outside of the computation is important to

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

��) ⊃ Send(*X*, *t*

The methodology of PCL has proven very successful in dealing with large-scale architectures. A recent paper by Cremers looked at the soundness of the various axioms of PCL [11]. For the problem of preceding actions, we have consistently used implicit pre- and post-conditions at the basic sequence level, leading to a tighter joining of actions. Another issue arises with the **HASH3** axiom. We propose a straight-forward generalization of the **HASH3** axiom, following

An important feature of PCL is that with it, we can reason about how protocols interact. As this chapter covers an entire architecture, it is imperative that the large number of individual protocols be proven secure not only independently, but also working together in conjunction as a complete system. To this end, we extensively use the methodology of protocol composition developed by Datta et al. [15]. We discuss this in Section 4.3. Alternate

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

� ) < a(*Y*, *t*

��), where *X* �= *Y* ∧ *t* ⊆ *t*

��

eliminate concerns about existential signature forgery.

*a* < *b* indicates *a* occurred temporally before *b*.)

**AA1** *φ*[*a*]*X*a

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

**AA4** *φ*[*a*1; *a*2;...; *ak* ]*X*a<sup>1</sup> < a<sup>2</sup> ∧ ... ∧ a*k*−<sup>1</sup> < a*<sup>k</sup>*

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

Receive(*X*, *p*(*t*))

FirstSend(*X*, *t*, *t*

**ARP** Receive(*X*, *p*(*x*))[match *q*(*x*)/*q*(*t*)]*<sup>X</sup>*

� ]*X*

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

� )∀*t* ⊆ *t* �

� ) ∧ a(*Y*, *t*

earlier work on signatures. We define a new axiom, which is sound.

composition methods are available, in certain circumstances [10].

**AN3** *φ*[New *x*]*X*Fresh(*X*, *x*)

**FS1** Fresh(*X*, *t*)[send *t*

**FS2** FirstSend(*X*, *t*, *t*

**Figure 1.** Some PCL Axioms Used in MSA Proofs

**HASH3**�

*2.1.4. Composing proofs*

Contains(*m*, *HASHK*(*x*)).

The 802.11s task group is working to develop a mesh networking protocol that sets up auto-configuring, multi-hop paths between wireless stations to support the exchange of data packets. A goal of the task group is to utilize existing IEEE 802.11 security mechanisms [1], with extensions, to secure a mesh in which all the stations are controlled by a single logical administrative entity from the standpoint of security [25]. The 802.11s task group continues to refine its draft specification through the resolution of comments received during a review of the specification that began in late 2006 [4–7].

A mesh network is a collection of network nodes, each of which can communicate with the others. Several kinds of nodes are specified in the MSA proposal. One is a *Mesh Point* (MP), a member of the mesh that can communicate with other nodes. Each mesh has at least one *Mesh Key Distributor* (MKD) which is an MP that is responsible for much of the key management within its *domain* (a MKD's domain is the set of nodes with which it has a secure connection). The MKD also provides a secure link to an external authentication server (e.g., a RADIUS [30] server). A *Mesh Authenticator* (MA) is an MP which has been authorized by the MKD to participate in key distribution within the mesh. A *Candidate MP* is an entity that wishes to join the mesh but is not yet an MP.

**Differences from 802.11i** Part of the MSA proposal is very similar to the 802.11i protocol suite [1]. In 802.11i, connections are established between authenticators and supplicants in a server-client topology. An authenticator is connected to a backbone infrastructure, and each supplicant may use an Extensible Authentication Protocol (EAP) [3] method such as EAP-TLS [34] to authenticate with the infrastructure. Each supplicant then uses a four-message handshake to secure a session with an authenticator, allowing subsequent use of its resources. The authenticator also maintains a broadcast key that is given to each of its successful supplicants. These protocols were examined in [26] and proven to be secure.

In addition to the 802.11i functionality, the MSA proposal allows the mesh to be a peer-to-peer network. Nodes in an MSA mesh may play different roles at different times. Thus, the proof of security of the 802.11i 4-way handshake [26], which assumes limitations on the messages a node can send, does not hold. The peer-to-peer nature also poses some difficulties with timing. The 802.11i proofs adopt *matching conversations* [2] as the authenticity property. As we discuss in Section 3.1.1, the notion of matching conversations imposes a rather strict ordering of messages in a protocol run, and is too rigid for our purposes. In MSA, we must provide for the case that both parties simultaneously start instances of a protocol and messages are not necessarily well-ordered. Thus, the proofs from [26] do not carry over directly.

**The key hierarchy** Each node in Figure 2 represents a key in principal *X*'s key hierarchy. An edge from key *k*<sup>1</sup> to *k*<sup>2</sup> shows that *k*<sup>2</sup> is either derived from or delivered using *k*<sup>1</sup> (that is, *k*<sup>1</sup> *protects k*2, as knowledge of *k*<sup>1</sup> is required to obtain *k*2). The edge's label is the protocol that is used to derive or deliver the key. The subscript in a key (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 entities that may possess the key. The subscripts are ordered (i.e., *pmkX*,*<sup>Y</sup>* is different from *pmkY*,*X*).

6 Will-be-set-by-IN-TECH 182 Wireless Mesh Networks – Effi cient Link Scheduling, Channel Assignment and Network Planning Strategies A Correctness Proof of a Mesh Security Architecture <sup>7</sup>

**PULL** protocols with *T*. **PUSH** is started by *T* to tell *X* to retrieve *pmkZ*,*<sup>X</sup>* for some *Z*. **PULL** is

A Correctness Proof of a Mesh Security Architecture 183

The 802.11s task group has expressed interest in developing an Abbreviated Handshake (**ABBH**) [9, 35]. **ABBH** is used by an MP or an MA *X* to derive *ptkX*,*Z*, and exchange *gtkX* and *gtkZ* with another MA or MP *Z*. Without an **ABBH**, the method of exchanging these credentials is to have the MP or MA run the full MSA Authentication Protocol with the other MA or MP. In this chapter we discuss a candidate **ABBH**, which has been presented to 802.11s [8], and its proof of security and composability with the rest of the MSA architecture. The full **ABBH** is presented in the full paper [28] and comprises two variants. One denoted is **ABBH.INIT** and the other **ABBH.SIMO**, depending on the timing of the first messages. We explore **ABBH.SIMO**, denoted simply **SIMO**, in more depth in Section 3. The **ABBH.INIT** protocol follows more conventional timing rules, but as seen in Figure 2, the **ABBH.SIMO**

Additional MSA protocols include the *Group Key Handshake* (**GKH**) and the **DEL**ete protocol (for key management). **GKH** is used by *X* to update its group key (*gtkX*) at *Z*. The protocol only works with nodes with which *X* maintains a security association (i.e., shares *ptkX*,*Z*). **DEL**

We note that each protocol message has a unique identifier. These identifiers must be unique amongst all protocols at a node, so that no other protocol at a node can use those unique

started by *X* to request *pmkZ*,*<sup>X</sup>* from *T*.

allows more complication.

A SIMO Abbreviated Handshake

is started by *T* to tell *X* to delete a particular *pmkZ*,*X*.

identifiers.

**Figure 2.** The key hierarchy of the MSA proposal

Key derivation (one-way) functions are utilized rather than key generation for efficiency. The MSA suite's use of key derivation also provides the potential for certain protocols to complete successfully when neither principal has connectivity to the rest of the mesh. This results in a key hierarchy, with each node being associated with several keys. The key hierarchy is an excellent avenue for understanding and summarizing the various protocols in the MSA proposal, and for demonstrating which keys protect other keys [6]. The complete descriptions of the protocols in PCL and prose are in the companion technical report [28].

We start our progression through the key hierarchy and the protocols at the top of Figure 2. Let *X* be a Candidate MP and let *T* be the MKD. The *MSA Authentication Protocol* allows *X* to join the mesh and become an MP, and consists of three stages: *Peer Link Establishment* (**PLE**), **TLS** [19], and a *Four-Way Handshake* (**4WAY**). *X* either has a shared *xxKeyX* with *T* or it shares public key credentials with *T*. If it shares public credentials with *T*, then *T* and *X* run **TLS** to derive the *xxKeyX*; otherwise, **TLS** is omitted. To derive the *pmkmkdX*, *X* needs a nonce; it is delivered to *X* from *T* when *X* runs **4WAY** with an MA (which we denote *Y*, noting that *Y* may be *T*). Subsequently, *X* can derive the *pmkmkdX*, *pmkX*,*<sup>Z</sup>* for any *Z* and the *mkdkX*,*T*. When X completes **4WAY** with *Y*, *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 yet a Mesh Authenticator (MA). To become an MA, *X* needs to run the *Mesh Key Holder Security Handshake* (**MKHSH**) with *T*, and derive the *mptkX*,*T*, which is a session key between *X* and *T*. This enables *X* to run the **PUSH** and **PULL** protocols with *T*. **PUSH** is started by *T* to tell *X* to retrieve *pmkZ*,*<sup>X</sup>* for some *Z*. **PULL** is started by *X* to request *pmkZ*,*<sup>X</sup>* from *T*.

The 802.11s task group has expressed interest in developing an Abbreviated Handshake (**ABBH**) [9, 35]. **ABBH** is used by an MP or an MA *X* to derive *ptkX*,*Z*, and exchange *gtkX* and *gtkZ* with another MA or MP *Z*. Without an **ABBH**, the method of exchanging these credentials is to have the MP or MA run the full MSA Authentication Protocol with the other MA or MP. In this chapter we discuss a candidate **ABBH**, which has been presented to 802.11s [8], and its proof of security and composability with the rest of the MSA architecture. The full **ABBH** is presented in the full paper [28] and comprises two variants. One denoted is **ABBH.INIT** and the other **ABBH.SIMO**, depending on the timing of the first messages. We explore **ABBH.SIMO**, denoted simply **SIMO**, in more depth in Section 3. The **ABBH.INIT** protocol follows more conventional timing rules, but as seen in Figure 2, the **ABBH.SIMO** allows more complication.

A SIMO Abbreviated Handshake

6 Will-be-set-by-IN-TECH

*privX*{*X*} *privT*{*T*}

**TLS TLS**

*xxKeyX*{*X*, *T*}

❳❳❳❳❳❳❳❳③ **4WAY**

✟ ✟✟ ✟✙

✘✘

✘✘✘

❍❍❍❍❥

✘✾✘✘

*gtkX gtkY*<sup>1</sup> *gtkX gtkYn gtkX gtkY*<sup>1</sup> *gtkX gtkYn*

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

Key derivation (one-way) functions are utilized rather than key generation for efficiency. The MSA suite's use of key derivation also provides the potential for certain protocols to complete successfully when neither principal has connectivity to the rest of the mesh. This results in a key hierarchy, with each node being associated with several keys. The key hierarchy is an excellent avenue for understanding and summarizing the various protocols in the MSA proposal, and for demonstrating which keys protect other keys [6]. The complete descriptions

We start our progression through the key hierarchy and the protocols at the top of Figure 2. Let *X* be a Candidate MP and let *T* be the MKD. The *MSA Authentication Protocol* allows *X* to join the mesh and become an MP, and consists of three stages: *Peer Link Establishment* (**PLE**), **TLS** [19], and a *Four-Way Handshake* (**4WAY**). *X* either has a shared *xxKeyX* with *T* or it shares public key credentials with *T*. If it shares public credentials with *T*, then *T* and *X* run **TLS** to derive the *xxKeyX*; otherwise, **TLS** is omitted. To derive the *pmkmkdX*, *X* needs a nonce; it is delivered to *X* from *T* when *X* runs **4WAY** with an MA (which we denote *Y*, noting that *Y* may be *T*). Subsequently, *X* can derive the *pmkmkdX*, *pmkX*,*<sup>Z</sup>* for any *Z* and the *mkdkX*,*T*. When X completes **4WAY** with *Y*, *X* will have derived *ptkX*,*Y*, received the *gtkY* from *Y*, and

At this point, *X* is a Mesh Point (MP) but is not yet a Mesh Authenticator (MA). To become an MA, *X* needs to run the *Mesh Key Holder Security Handshake* (**MKHSH**) with *T*, and derive the *mptkX*,*T*, which is a session key between *X* and *T*. This enables *X* to run the **PUSH** and

*ptkX*,*Y*<sup>1</sup> {*X*, *Y*1, *T*} *ptkX*,*Yn* {*X*, *Yn*, *T*} *ptkX*,*Y*<sup>1</sup> {*X*,*Y*1, *T*} *ptkX*,*Yn* {*X*,*Yn*, *T*}

❄ ❄ ❄ ❄ **ABBH** or **4WAY ABBH** or **4WAY**

*pmkX*,*Y*<sup>1</sup> {*X*,*Y*1, *T*} *pmkX*,*Yn* {*X*,*Yn*, *T*} *pmkY*1,*X*{*X*, *Y*1, *T*} *pmkYn*,*X*{*X*,*Yn*, *T*}

❅❅❘ **ABBH** or **4WAY** or **GKH ABBH** or **4WAY** or **GKH**

 ✠

❅❅❘

*mptkX*,*T*{*X*, *T*}

**PUSH** or **PULL**

❄

❍❍❍❍❥

✟✟

✟✙✟

*mkdkX*,*T*{*X*, *T*}

**MKHSH**

 ✠

 ✠

❅❅❘

of the protocols in PCL and prose are in the companion technical report [28].

 ✠

delivered *gtkX* to *Y*.

❅❅❘

*pmkmkdX*{*X*, *T*}

null

**Figure 2.** The key hierarchy of the MSA proposal

❙ ❙ ❙ ❙ ❙❙✇

✓ ✓ ✓ ✓ ✓✓✴

> Additional MSA protocols include the *Group Key Handshake* (**GKH**) and the **DEL**ete protocol (for key management). **GKH** is used by *X* to update its group key (*gtkX*) at *Z*. The protocol only works with nodes with which *X* maintains a security association (i.e., shares *ptkX*,*Z*). **DEL** is started by *T* to tell *X* to delete a particular *pmkZ*,*X*.

> We note that each protocol message has a unique identifier. These identifiers must be unique amongst all protocols at a node, so that no other protocol at a node can use those unique identifiers.

Further work has been done on the security of the 802.11s suite of protocols. See [23] for additional details.

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

match retrieve(*pmkN*)/*pmk*; match HASH*pmk*(*x*, *y*)/*ptkX*,*Y*; (match ENC*ptkX*,*<sup>Y</sup>* (*gtkX*)/*enc*0;

**<sup>Γ</sup>ABBH**,**<sup>1</sup>** :<sup>=</sup> Honest(*X*ˆ) <sup>∧</sup> Send(*X*, *<sup>m</sup>*)<sup>∧</sup>

KOHonest(*ptkX*,*Y*, {*pmkX*,*Y*, *pmkY*,*X*}) ⊃

**AA4**: �[*a*;...; *b*]*Xa* < *b*. We redefine it to be

**AA4**: �[*a* : *b*;...; *c* : *d*]*Xa* ∧ *b* < *c* ∧ *d*

**AA5**: �[(*a*;...; *b*)]*Xa* < *b*

*Z*ˆ = *X*ˆ **ΦSIMO**,**AUTH** :=

strand to ';'.

Send(*Y*, SIMO5Y))

[New *x*; send *Y*ˆ, *X*ˆ , "ABBH1", *INFOX*, *x*; receive *X*ˆ, *Y*ˆ, "ABBH1", *INFOY*, *y*; match select(*INFOX*, *INFOY*)/*CS*, *pmkN*;

send *Y*ˆ, *X*ˆ , "ABBH5", *INFOX*, *x*, *y*,*enc*0, *mic*0) : (receive *X*ˆ ,*Y*ˆ, "ABBH5", *INFOY*, *y*, *x*,*enc*1, *mic*1;

match HASH*ptkX*,*<sup>Y</sup>* (*Y*ˆ, *<sup>X</sup>*ˆ, "ABBH5", *INFOX*, *<sup>x</sup>*, *<sup>y</sup>*,*enc*0, *INFOY*)/*mic*0;

θ**ABBH**,**<sup>1</sup>** := Has(*X*, *pmkX*,*Y*) ∧ Has(*Y*, *pmkY*,*X*) ∧ (Has(*X*, *mptkX*,*T*) ∨ Has(*Y*, *mptkX*,*T*))

**Figure 4.** Protocol Description of the Abbreviated Handshake Simultaneous Case

*b* or *c* compared to *d* is indicated. We also include a new axiom

exactly the **AA4** previously defined and **AA5** is redundant.

(Contains(*m*, Hash*ptk*(("ABBH2", *<sup>Y</sup>*ˆ, *<sup>Z</sup>*ˆ))) <sup>∨</sup> Contains(*m*, Hash*ptk*(("ABBH3", *<sup>Y</sup>*ˆ, *<sup>Z</sup>*ˆ)))<sup>∨</sup> Contains(*m*, Hash*ptk*(("ABBH4",*Y*ˆ, *<sup>Z</sup>*ˆ))) <sup>∨</sup> Contains(*m*, Hash*ptk*(("ABBH5",*Y*ˆ, *<sup>Z</sup>*ˆ)))) <sup>⊃</sup>

(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) <

way by defining each action group to be one action and by setting all the separators inside a

We update Axiom **AA4** [15] to reflect this addition to the language. The original version is

where *a*, *b*, *c* and *d* are action groups. Thus nothing about the temporal order of *a* compared to

where *a* and *b* are actions, to deal with the temporal ordering of action groups. If each action group is exactly one action and only semicolons are used in the new strands our **AA4** becomes

A consequence of the above addition is that protocols whose definition includes ':' have an additional complication in the determination of basic sequences. Recall that a basic sequence is defined as any actions before a receive. With the : notation, two different sets of actions may

match *enc*1/ENC*ptkX*,*<sup>Y</sup>* (*gtkY*); match *mic*1/HASH*ptkX*,*<sup>Y</sup>* (*X*ˆ, *<sup>Y</sup>*ˆ, "ABBH5", *INFOY*, *<sup>y</sup>*, *<sup>x</sup>*,*enc*1, *INFOX*))]*<sup>X</sup>*

A Correctness Proof of a Mesh Security Architecture 185
