**4. Overview of the proof**

12 Will-be-set-by-IN-TECH

ideal world with no adversary. The peer-to-peer nature of certain protocols such as **SIMO** do not allow pre-defined protocol roles of principals to always allow one principal to make this selection and dictate the choice to the other. The two principals must independently choose

A new construct, *INFO* is used to capture this. The information principal *X* contributes to a protocol is *INFOX*. It contains ordered lists of acceptable selections for one or more fields. The contents of *INFOX* may vary for different protocols. In MSA, the **PLE**, **ABBH**, and **MKHSH**

**The Select() action** We have added a new action, Select(), to PCL. Two principals *X* and *Y* must make identical but independent selections of link and protocol options from exchanged information *INFOX* and *INFOY*. The Select() action deterministically retrieves information from two lists, independent of the order of the lists (i.e., select(*INFOX*, *INFOY*) = select(*INFOY*, *INFOX*)). During Peer Link Establishment and Abbreviated Handshake protocols, Select() determines the key to be used based on information each principal sends about the keys it has cached and whether it is an MA capable of retrieving the key from the MKD. Thus, the function ensures that a key is either locally cached or may be retrieved from the MKD if the protocol is to continue. The Select() action is used in other contexts as well, such as to determine which principal initiates the 4-way handshake, or which pairwise cipher

This level of detail is necessary to provide protection against downgrade attacks (wherein the attacker chooses the protocol selection suite) and other attacks where public information can be subverted by an attacker to weaken the final strength of the protocol. Additionally, modeling the interactions at the lower level, demonstrated in the description of SIMO in Figure 4, allows us to provide additional guarantees against attack vectors which may be

Without modeling at this detailed level, a nearly-equivalent SIMO protocol, which only creates a keyed hash across the information it sends, would appear viable and secure. The cryptographic components would be identical. However, without node *X*ˆ including *INFOY* in its *mic* (and equivalent for *Y*ˆ), attack vectors become possible. In particular, the strong requirement that the messages sent exactly match the messages received no longer holds. This loss directly leads to potential manipulation of the *INFOX* and *INFOY* fields by an attacker. Not only can an attack user such manipulation to mount a straightforward denial-of-service attack, but the attacker could also compromise the selection of the shared cipher suite, a

For many of the protocols in MSA, the protocol may instantiate another protocol partway through its run. This second protocol must complete before the first protocol can continue. For example, in a key exchange protocol such as **SIMO**, if both parties that try to establish a session key do not have the other party's pairwise master key cached locally (e.g., *X* does not have the current *pmkZ*,*X*), then one of the parties must pause its protocol run and run a key

matching values from two lists.

protocols require the use of *INFO*.

suite to use after completing a protocol.

non-obvious to a lay implementer.

dangerous form of a downgrade attack.

**3.3. Calling one protocol in another**

In this section, we provide an overview of our proof efforts by highlighting three aspects of it. In Section 4.1 we discuss our approach to proving key secrecy in the MSA proposal. In Section 4.2 we present additional security goals and a theorem that culminates our proof efforts. Finally, in Section 4.3, we discuss our approach to protocol composition.

## **4.1. Key secrecy in MSA**

Key secrecy is a critical security requirement. Some previous work [26] has proven key secrecy as a protocol postcondition. We show that proving key secrecy as a postcondition is insufficient by providing an example of a protocol which has key secrecy as a postcondition (i.e., upon protocol completion, key secrecy can be proven) but is insecure, because key secrecy can be lost. The Insecure Key Transfer Protocol in Figure 5 illustrates this point. If we assume protocol completion from the point of view of RESP we can prove that the secret key is

#### **Inputs and Parties:**


#### **Insecure Key Transfer Protocol:**


θ*TLS*,*SI*,1 :=

θ4*WAY*,*SI*,1 :=

θ4*WAY*,*SI*,2 :=

θ*PPD*,*SI*,2 :=

θ*PPD*,*SI*,1, *θMKHSH*,*SI*,1 :=

θ*ABBH*,*SI*,1, *θ*4*WAY*,*SI*,3, *θGKH*,*SI*,1 :=

θ*ABBH*,*SI*,2, *θ*4*WAY*,*SI*,4, *θGKH*,*SI*,2 :=

key secrecy is maintained by all protocols in MSA.

MSA protocols.

**Figure 6.** MSA Key Secrecy Conditions

KOHonest(*xxKeyX*, {*privX*, *privT*, *xxKeyX*}) <sup>⊃</sup> Has(*Z*, *xxKeyX*) <sup>⊃</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>X</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>T</sup>*<sup>ˆ</sup>

KOHonest(*pmkX*,*Y*, {*pmkmkdX*, *mptkY*,*T*}) <sup>⊃</sup> Has(*Z*, *pmkX*,*Y*) <sup>⊃</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>X</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>Y</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>T</sup>*<sup>ˆ</sup>

We introduce new notation �*U*. The meaning of *P* �*<sup>U</sup> θ* is that postcondition *θ* must hold at every intermediate point of the relevant protocols in program set *P*. That is, if the terms in *θ*

**Theorem 1.** *Let MSA represent all the protocols in the Mesh Security Architecture and θSI*,*ALL represent all of the key secrecy conditions in Figure 6. Then θSI*,*ALL are satisfied by MSA. That is,*

*MSA* �*<sup>U</sup> θSI*,*ALL*

**Proof sketch:** This theorem is proven in two steps. The first step is a massive induction over all the basic sequences of all the protocols that could be run by any participant in a mesh. This induction guarantees that all messages sent are "safe," in that critical information is protected by keys. In the key secrecy goals of Figure 6, the critical information protected is another key, lower in the hierarchy. From this, we argue the invariant nature of multiple SafeNet axioms over the entire MSA protocol suite, limiting various goals to the protocols where the terms are instantiated/defined. Then, we use the **POS** and **POSL** axioms [32] to state who can potentially have access to other keys. By proceeding in this way through the entire key hierarchy, we establish all the necessary key secrecy goals, at any point in a run where the keys may be defined. The full proof is generally unenlightening and we do not provide it. We stress that this proof does not depend on any of the analysis done in proceeding sections. It is simply induction over all basic sequences and application of secrecy axioms. This proves

This theorem guarantees that the parties listed in Figure 6 are the only principals with those keys. This proves that an attacker could not learn any key in the entire hierarchy from the

)

A Correctness Proof of a Mesh Security Architecture 191

KOHonest(*ptkX*,*Y*, {*pmkX*,*Y*, *pmkY*,*X*}) <sup>⊃</sup> Has(*Z*, *ptkX*,*Y*) <sup>⊃</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>X</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>Y</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>T</sup>*<sup>ˆ</sup>

KOHonest(*pmkmkdX*, {*xxKeyX*}) <sup>⊃</sup> Has(*Z*, *pmkmkdX*) <sup>⊃</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>X</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>T</sup>*<sup>ˆ</sup>

KOHonest(*mkdkX*,*T*, {*xxKeyX*}) <sup>⊃</sup> Has(*Z*, *mkdkX*,*T*) <sup>⊃</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>X</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>T</sup>*<sup>ˆ</sup>

KOHonest(*mptkX*,*T*, {*mkdkX*,*T*}) <sup>⊃</sup> Has(*Z*, *mptkX*,*T*) <sup>⊃</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>X</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>T</sup>*<sup>ˆ</sup>

KOHonest(*gtkX*, {*ptkX*,*Y*<sup>1</sup> ,... *ptkX*,*Yn* }) ⊃ Has(*Z*, *gtkX*) ⊃ Has(*Z*, *ptkX*,*Yi*

are defined and bound at the end of a basic sequence in *P*, then *θ* holds.


#### **Figure 5.** Insecure Key Transfer

distributed correctly, as the validity of INIT's public key is established once RESP receives the third message. However RESP uses the public key in the second message before the validity of the public key can be established. Thus if the protocol aborts after the RESP sends the second message, it may be the case that the public key sent in message 1 is an adversary's public key. It is therefore possible for the adversary to intercept the secret key. While this protocol is contrived, in larger protocols with complex security goals, it may be the case that a subtle insecurity such as this goes unnoticed. Thus, for certain assertions related to secrecy, we advocate showing that they hold at every critical point in a protocol.

We prove the security of MSA's key hierarchy using the work of Roy et al. [31–33]. We present the key secrecy postconditions relevant to the MSA key hierarchy in Figure 6. We prove that these conditions hold at every point during any protocol execution of MSA, as long as the indicated principals are honest. We also claim the new axiom

**SAF5**: SafeMsg(*HASHs*(*M*),*s*, K)

Informally, this states that a keyed hash of a message does not reveal the key.

It seems natural to prove key secrecy in an inductive manner, locally for each thread and role. But that's not sufficient in the proposed MSA system, because key information is not generally held purely locally and other nodes with the information may be abusing it. Key secrecy must be maintained locally, of course, but it requires a global proof.

The techniques of [32] would note the deficiencies of the protocol in Figure 5, because the first message sent by RESP could not be proven to be a SafeMsg, inductively. We utilize this notion and extend the SafeNet concept across the entire suite of MSA protocols, to show that no protocol violates the key secrecy of any other protocol. Doing this step before examining other desired protocol security goals (postconditions) provides for more elegance and correctness in the other proofs.

θ*TLS*,*SI*,1 := KOHonest(*xxKeyX*, {*privX*, *privT*, *xxKeyX*}) <sup>⊃</sup> Has(*Z*, *xxKeyX*) <sup>⊃</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>X</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>T</sup>*<sup>ˆ</sup> θ4*WAY*,*SI*,1 := KOHonest(*pmkmkdX*, {*xxKeyX*}) <sup>⊃</sup> Has(*Z*, *pmkmkdX*) <sup>⊃</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>X</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>T</sup>*<sup>ˆ</sup> θ4*WAY*,*SI*,2 := KOHonest(*mkdkX*,*T*, {*xxKeyX*}) <sup>⊃</sup> Has(*Z*, *mkdkX*,*T*) <sup>⊃</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>X</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>T</sup>*<sup>ˆ</sup> θ*PPD*,*SI*,1, *θMKHSH*,*SI*,1 := KOHonest(*mptkX*,*T*, {*mkdkX*,*T*}) <sup>⊃</sup> Has(*Z*, *mptkX*,*T*) <sup>⊃</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>X</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>T</sup>*<sup>ˆ</sup> θ*PPD*,*SI*,2 := KOHonest(*pmkX*,*Y*, {*pmkmkdX*, *mptkY*,*T*}) <sup>⊃</sup> Has(*Z*, *pmkX*,*Y*) <sup>⊃</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>X</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>Y</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>T</sup>*<sup>ˆ</sup> θ*ABBH*,*SI*,1, *θ*4*WAY*,*SI*,3, *θGKH*,*SI*,1 := KOHonest(*ptkX*,*Y*, {*pmkX*,*Y*, *pmkY*,*X*}) <sup>⊃</sup> Has(*Z*, *ptkX*,*Y*) <sup>⊃</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>X</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>Y</sup>*<sup>ˆ</sup> <sup>∨</sup> *<sup>Z</sup>*<sup>ˆ</sup> <sup>=</sup> *<sup>T</sup>*<sup>ˆ</sup> θ*ABBH*,*SI*,2, *θ*4*WAY*,*SI*,4, *θGKH*,*SI*,2 := KOHonest(*gtkX*, {*ptkX*,*Y*<sup>1</sup> ,... *ptkX*,*Yn* }) ⊃ Has(*Z*, *gtkX*) ⊃ Has(*Z*, *ptkX*,*Yi* )

**Figure 6.** MSA Key Secrecy Conditions

14 Will-be-set-by-IN-TECH

2. RESP receives *PKINIT*; encrypts *sk* under *PKINIT*, computes the keyed hash of the encryption with

3. INIT receives ({*sk*}*PKINIT*, *HASHck*({*sk*}*PKINIT*)), verifies the keyed hash; decrypts *sk*; computes the

distributed correctly, as the validity of INIT's public key is established once RESP receives the third message. However RESP uses the public key in the second message before the validity of the public key can be established. Thus if the protocol aborts after the RESP sends the second message, it may be the case that the public key sent in message 1 is an adversary's public key. It is therefore possible for the adversary to intercept the secret key. While this protocol is contrived, in larger protocols with complex security goals, it may be the case that a subtle insecurity such as this goes unnoticed. Thus, for certain assertions related to secrecy,

We prove the security of MSA's key hierarchy using the work of Roy et al. [31–33]. We present the key secrecy postconditions relevant to the MSA key hierarchy in Figure 6. We prove that these conditions hold at every point during any protocol execution of MSA, as long as the

It seems natural to prove key secrecy in an inductive manner, locally for each thread and role. But that's not sufficient in the proposed MSA system, because key information is not generally held purely locally and other nodes with the information may be abusing it. Key secrecy must

The techniques of [32] would note the deficiencies of the protocol in Figure 5, because the first message sent by RESP could not be proven to be a SafeMsg, inductively. We utilize this notion and extend the SafeNet concept across the entire suite of MSA protocols, to show that no protocol violates the key secrecy of any other protocol. Doing this step before examining other desired protocol security goals (postconditions) provides for more elegance and correctness

keyed hash of *sk* and *PKINIT* with the *ck* and sends *HASHck*(*sk*, *PKINIT*) to RESP.

we advocate showing that they hold at every critical point in a protocol.

Informally, this states that a keyed hash of a message does not reveal the key.

indicated principals are honest. We also claim the new axiom

be maintained locally, of course, but it requires a global proof.

**SAF5**: SafeMsg(*HASHs*(*M*),*s*, K)

in the other proofs.

**Inputs and Parties:**



**Insecure Key Transfer Protocol:** 1. INIT sends *PKINIT* to RESP.

4. RESP verifies the signature.

**Figure 5.** Insecure Key Transfer


key *ck*; and sends ({*sk*}*PKINIT*, *HASHck*({*sk*}*PKINIT*)) to INIT.

We introduce new notation �*U*. The meaning of *P* �*<sup>U</sup> θ* is that postcondition *θ* must hold at every intermediate point of the relevant protocols in program set *P*. That is, if the terms in *θ* are defined and bound at the end of a basic sequence in *P*, then *θ* holds.

**Theorem 1.** *Let MSA represent all the protocols in the Mesh Security Architecture and θSI*,*ALL represent all of the key secrecy conditions in Figure 6. Then θSI*,*ALL are satisfied by MSA. That is,*

$$MSA \vdash\_{II} \theta\_{SI,ALL}$$

**Proof sketch:** This theorem is proven in two steps. The first step is a massive induction over all the basic sequences of all the protocols that could be run by any participant in a mesh. This induction guarantees that all messages sent are "safe," in that critical information is protected by keys. In the key secrecy goals of Figure 6, the critical information protected is another key, lower in the hierarchy. From this, we argue the invariant nature of multiple SafeNet axioms over the entire MSA protocol suite, limiting various goals to the protocols where the terms are instantiated/defined. Then, we use the **POS** and **POSL** axioms [32] to state who can potentially have access to other keys. By proceeding in this way through the entire key hierarchy, we establish all the necessary key secrecy goals, at any point in a run where the keys may be defined. The full proof is generally unenlightening and we do not provide it. We stress that this proof does not depend on any of the analysis done in proceeding sections. It is simply induction over all basic sequences and application of secrecy axioms. This proves key secrecy is maintained by all protocols in MSA.

This theorem guarantees that the parties listed in Figure 6 are the only principals with those keys. This proves that an attacker could not learn any key in the entire hierarchy from the MSA protocols.

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

#### **4.2. Goals and correctness result**

We present important security postconditions (goals) below. For each goal, we point out the kinds of protocols to which it applies. Goals are customized for each protocol; formal instances of each kind of goal we discuss below are in Appendix 6. We keep our discussions in this section more informal for clarity.

particular to **TLS**. Similar expansions have been made for each protocol and the details are in

A Correctness Proof of a Mesh Security Architecture 193

With the changes that we discuss in Section 5, we are able to prove the component-wise

This theorem was one of the major driving forces behind the work. It asserts that the full protocol suite in the MSA proposal, with a rather complex key hierarchy, is secure. Each protocol achieves the maximal security goals for its type. Appendix 6 contains a proof of part of (viii) and provides a feel for the proof methodology. The proof of Theorem 2 depends on

The MSA architecture allows for significant variation in how protocols compose together [4]. Once an established state is reached, many protocols (which may have been run previously to reach the established state) may be chosen. Reaching an established state may take a variety of paths, depending on the authentication mechanism (TLS or pre-shared key) used. Error-handling strategies will cause protocols to restart, or, potentially, different protocols to

While *staged composition* proofs have been presented previously [26, 31], the presentation in each case has differed. Staged composition allows arbitrary back arrows and paths through possible protocol execution paths. This allows for protocol restarts, lost connections, and other real-world considerations about the order in which protocols are run. We provide a slightly different presentation of similar ideas in Section 4.3.1. Readers primarily interested in the proof of MSA may skip this section and proceed to Section 4.3.2 where the overall MSA

The concept of branches within protocols or between protocols has not been explicitly mentioned in previous PCL composition theorems. We require this functionality, to denote how a particular staging can be accomplished within the MSA framework. One of our motivations is to allow such possibilities as are represented in Figure 7. After basic sequence A, either sequence B or sequence C may follow. Sequence D follows C and both B and D lead to E. The consistent composition theorem provides the requirements under which such

be run. This introduces a complex state diagram and complexities of composition.

correctness of each of the protocols of the MSA proposal.

**Theorem 2.** *The following are true, with the notation described above.*

our full paper [28].

*(i) TLS AUTH*, *KD*

*(iv) GKH AUTH*, *KD (v) PUSH AUTH*, *KD (vi) PULL AUTH*, *KD (vii) DEL AUTH*

the PCL additions of Section 3.

security theorem is presented.

*4.3.1. Consistent composition*

**4.3. Composition**

*(ii)* 4*WAY AUTH*, *KF*,*KA*,*KD*, *INFO (iii) MKHSH AUTH*, *KF*,*KA*,*KD*, *INFO*

*(viii)ABBH AUTH*, *KF*,*KA*,*KD*, *INFO*

*AUTH***:** Authentication as realized by the generalized matching conversations property (see Section 3.1.1). In practice, this confirms peer liveness and peer possession of a particular key. This goal applies to all protocols in the MSA proposal. This goal is expressed as:

<sup>Φ</sup>*AUTH* :<sup>=</sup> <sup>∃</sup>*Y*.*ActionsInOrder*(Send(*X*, *<sup>X</sup>*<sup>ˆ</sup> ,*Y*ˆ, *msg*1), Receive(*Y*, *<sup>X</sup>*<sup>ˆ</sup> ,*Y*ˆ, *msg*1), Send(*Y*,*Y*ˆ, *<sup>X</sup>*<sup>ˆ</sup> , *msg*2), ··· , Receive(*X*,*Y*ˆ, *<sup>X</sup>*<sup>ˆ</sup> , *msgn*))

*KF***:** Key freshness as realized by a freshly-generated nonce from each party as a term in the agreed-upon key. This goal applies only to protocols which create a joint (session) key.

<sup>Φ</sup>*KF* :<sup>=</sup> KOHonest(*k*, <sup>K</sup>) <sup>⊃</sup> (New (*X*<sup>ˆ</sup> , *<sup>x</sup>*) <sup>∧</sup> *<sup>x</sup>* <sup>⊆</sup> *<sup>k</sup>* <sup>∧</sup> New (*Y*ˆ, *<sup>y</sup>*) <sup>∧</sup> *<sup>y</sup>* <sup>⊆</sup> *<sup>k</sup>*) <sup>∧</sup> FirstSend(*X*, *<sup>x</sup>*, *<sup>X</sup>*<sup>ˆ</sup> , *<sup>x</sup>*, *<sup>m</sup>*) <sup>∧</sup> FirstSend(*Y*, *<sup>y</sup>*,*Y*ˆ, *<sup>y</sup>*, *<sup>m</sup>*)

*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 establish a session key.

$$\Phi\_{\mathsf{K}\mathcal{A}} := \mathsf{K}\mathsf{OHomest}(k,\mathsf{K}) \supset \mathsf{Has}(X,k) \land \mathsf{Has}(Y,k)$$

*KD***:** Transfer of secret information (key delivery) as realized by the key secrecy goals and the Has predicate. This applies only to those protocols which transmit keys (either a group transfer key (*gtk*) or a pairwise master key (*pmk*)).

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

*INFO***:** Authentic exchange of non-secret information and authenticated selection of sub-elements as realized in detailed protocol description and validated return information. This applies only to protocols which must exchange non-security information and agree 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 goals adopted by He et al. [26], which in turn are adapted from the list of desired security properties for 802.11i [1]. No security goals have been explicitly specified for the general 802.11s protocol suite; however, we anticipate that the security goals for 802.11i are meaningful for 802.11s as well, provided they are adapted appropriately. Furthermore, we feel that the goals we present above have intrinsic intuitive appeal. We recommend that these goals, in addition to the key secrecy goals discussed in Section 4.1, be formally adopted by the 802.11s task group.

In the following Theorem, we introduce some notation () for ease of exposition. *TLS AUTH*, *KD* means <sup>Γ</sup>**TLS**,{1,2,} � *<sup>θ</sup>***TLS**[**TLS** : **CLNT**]*X*Φ**TLS**,{*AUTH*,*KD*},*CLNT* and the corresponding goal for the other node, namely <sup>Γ</sup>**TLS**,{1,2,} � *<sup>θ</sup>***TLS**[**TLS** : **SRVR**]*X*Φ**TLS**,{*AUTH*,*KD*},*SRVR*. These state that, with the proper invariants, the protocol from each perspective provably satisfies the security goals *AUTH* and *KD* , particular to **TLS**. Similar expansions have been made for each protocol and the details are in our full paper [28].

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

**Theorem 2.** *The following are true, with the notation described above.*

*(i) TLS AUTH*, *KD (ii)* 4*WAY 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 behind the work. It asserts that the full protocol suite in the MSA proposal, with a rather complex key hierarchy, is secure. Each protocol achieves the maximal security goals for its type. Appendix 6 contains a proof of part of (viii) and provides a feel for the proof methodology. The proof of Theorem 2 depends on the PCL additions of Section 3.

#### **4.3. Composition**

16 Will-be-set-by-IN-TECH

We present important security postconditions (goals) below. For each goal, we point out the kinds of protocols to which it applies. Goals are customized for each protocol; formal instances of each kind of goal we discuss below are in Appendix 6. We keep our discussions

*AUTH***:** Authentication as realized by the generalized matching conversations property (see Section 3.1.1). In practice, this confirms peer liveness and peer possession of a particular key. This goal applies to all protocols in the MSA proposal. This goal is expressed as:

*KF***:** Key freshness as realized by a freshly-generated nonce from each party as a term in the agreed-upon key. This goal applies only to protocols which create a joint (session) key.

*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 establish a session key.

*KD***:** Transfer of secret information (key delivery) as realized by the key secrecy goals and the Has predicate. This applies only to those protocols which transmit keys (either a group

*INFO***:** Authentic exchange of non-secret information and authenticated selection of sub-elements as realized in detailed protocol description and validated return information. This applies only to protocols which must exchange non-security information and agree on

Our goals are extensions and clarifications of the goals adopted by He et al. [26], which in turn are adapted from the list of desired security properties for 802.11i [1]. No security goals have been explicitly specified for the general 802.11s protocol suite; however, we anticipate that the security goals for 802.11i are meaningful for 802.11s as well, provided they are adapted appropriately. Furthermore, we feel that the goals we present above have intrinsic intuitive appeal. We recommend that these goals, in addition to the key secrecy goals discussed in

In the following Theorem, we introduce some notation () for ease of exposition. *TLS AUTH*, *KD* means <sup>Γ</sup>**TLS**,{1,2,} � *<sup>θ</sup>***TLS**[**TLS** : **CLNT**]*X*Φ**TLS**,{*AUTH*,*KD*},*CLNT* and the corresponding goal for the other node, namely <sup>Γ</sup>**TLS**,{1,2,} � *<sup>θ</sup>***TLS**[**TLS** : **SRVR**]*X*Φ**TLS**,{*AUTH*,*KD*},*SRVR*. These state that, with the proper invariants, the protocol from each perspective provably satisfies the security goals *AUTH* and *KD* ,

<sup>Φ</sup>*AUTH* :<sup>=</sup> <sup>∃</sup>*Y*.*ActionsInOrder*(Send(*X*, *<sup>X</sup>*<sup>ˆ</sup> ,*Y*ˆ, *msg*1), Receive(*Y*, *<sup>X</sup>*<sup>ˆ</sup> ,*Y*ˆ, *msg*1),

<sup>Φ</sup>*KF* :<sup>=</sup> KOHonest(*k*, <sup>K</sup>) <sup>⊃</sup> (New (*X*<sup>ˆ</sup> , *<sup>x</sup>*) <sup>∧</sup> *<sup>x</sup>* <sup>⊆</sup> *<sup>k</sup>* <sup>∧</sup> New (*Y*ˆ, *<sup>y</sup>*) <sup>∧</sup> *<sup>y</sup>* <sup>⊆</sup> *<sup>k</sup>*) <sup>∧</sup>

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

Send(*Y*,*Y*ˆ, *<sup>X</sup>*<sup>ˆ</sup> , *msg*2), ··· , Receive(*X*,*Y*ˆ, *<sup>X</sup>*<sup>ˆ</sup> , *msgn*))

FirstSend(*X*, *<sup>x</sup>*, *<sup>X</sup>*<sup>ˆ</sup> , *<sup>x</sup>*, *<sup>m</sup>*) <sup>∧</sup> FirstSend(*Y*, *<sup>y</sup>*,*Y*ˆ, *<sup>y</sup>*, *<sup>m</sup>*)

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

transfer key (*gtk*) or a pairwise master key (*pmk*)). Φ*KD* := KOHonest(*k*, K) ⊃ Has(*X*, *k*) ∧ Has(*Y*, *k*)

Has(*X*, *CS*, *pmkN*) ∧ Has(*Y*,*CS*, *pmkN*)

Section 4.1, be formally adopted by the 802.11s task group.

parameters.

**4.2. Goals and correctness result**

in this section more informal for clarity.

The MSA architecture allows for significant variation in how protocols compose together [4]. Once an established state is reached, many protocols (which may have been run previously to reach the established state) may be chosen. Reaching an established state may take a variety of paths, depending on the authentication mechanism (TLS or pre-shared key) used. Error-handling strategies will cause protocols to restart, or, potentially, different protocols to be run. This introduces a complex state diagram and complexities of composition.

While *staged composition* proofs have been presented previously [26, 31], the presentation in each case has differed. Staged composition allows arbitrary back arrows and paths through possible protocol execution paths. This allows for protocol restarts, lost connections, and other real-world considerations about the order in which protocols are run. We provide a slightly different presentation of similar ideas in Section 4.3.1. Readers primarily interested in the proof of MSA may skip this section and proceed to Section 4.3.2 where the overall MSA security theorem is presented.

#### *4.3.1. Consistent composition*

The concept of branches within protocols or between protocols has not been explicitly mentioned in previous PCL composition theorems. We require this functionality, to denote how a particular staging can be accomplished within the MSA framework. One of our motivations is to allow such possibilities as are represented in Figure 7. After basic sequence A, either sequence B or sequence C may follow. Sequence D follows C and both B and D lead to E. The consistent composition theorem provides the requirements under which such

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

branches will still compose. This also provides for all manner of if/then functionality within PCL, if it can be properly created in semantics and the various results of the if/then statement are properly modeled in terms of basic sequence breaks. We believe this fills a gap in the span of PCL.

the system, are not critical. In particular, the *Qi*'s could be single basic sequences and the entire theorem still holds. This allows us to model at the level of basic sequences. This level

A Correctness Proof of a Mesh Security Architecture 195

This allows, for example, the behavior of the retrieve action that we discuss Section 3.3. Retrieve allows two different paths through a larger staged composition. In one path, a locally stored value is returned. In the other path, an entire protocol is run. As protocols compose consistently at the granularity of basic sequences in the initial protocol, retrieve fundamentally denotes alternate methods of staging the composition. In all protocols that use retrieve, the invariants and various preconditions in the protocol are proven against all possible stagings

We wish to apply Theorem 3 to the protocols of the MSA proposal. We view the protocols of staged composition as the protocols given previously. As mentioned, we consider arbitrary breaks at the basic sequence level, for mid-protocol composition as well as overall composition. We need to prove that all protocols within MSA (comprising **PLE**, **TLS**, **4WAY**, **MKHSH**, **GKH**, **PULL**, **PUSH**, **DEL**, and **ABBH**, (both **ABBH.INIT** and **ABBH.SIMO**) satisfy

**Theorem 4.** *Let Q be a specific composition of protocols from MSA and RComp*(�*P*1, *P*2,..., *Pn*�) ∈

Proving that all the protocols securely compose is a lengthy induction process, which we omit owing to space constraints. We briefly discuss the meaning of the various subpoints. No portion of any protocol in MSA violates the invariants (*i*) or changes the preconditions (*iii*) of any MSA protocol. All nodes in a mesh start with the correct information, by assumption (*iv*). Point (*ii*) gives the protocols which guarantee certain subsequent protocols can be completed

This theorem states that, given any MSA protocol, if the MKD and the players in the protocol are honest (that is, they conform to the protocol specification), then the security of that protocol is ensured, regardless of what other protocols may be running in the system. By extension, a mesh of honest nodes guarantees our security goals; the Mesh Security Architecture is sound.

Our analysis of the protocols and key hierarchy of the MSA proposal indicate that it was largely well-designed. We have two recommendations that have been incorporated into the

*Q and* <sup>Γ</sup> <sup>=</sup> <sup>Γ</sup>*TLS*,{1,2} <sup>∧</sup> <sup>Γ</sup>4*WAY*,1 <sup>∧</sup> <sup>Γ</sup>*MKHSH*,1 <sup>∧</sup> <sup>Γ</sup>*GKH*,{1,2} <sup>∧</sup> <sup>Γ</sup>*PPD*,{1,2} <sup>∧</sup> <sup>Γ</sup>*ABBH*,1*. Then:*

of granularity has been suggested before [26], but we make it explicit.

of the retrieve action.

*4.3.2. Composition in MSA*

the necessary conditions for composition.

Φ*MKHSH* � *θPUSH* ∧ *θPULL* ∧ *θDEL*

*<sup>j</sup>*≥*<sup>i</sup> BS*(*Pj*).*θPi*

[*S*]*XθPi*

with other legitimate nodes, via pre and post condition matching.

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

> Φ*MKHSH* � *θABBH* Φ*ABBH* � *θGKH*

**5. Modifications to MSA**

*(iii)*∀*i*.∀*<sup>S</sup>* ∈

*(iv)θP*<sup>1</sup>

**Figure 7.** Branches in PCL

We utilize the definitions of role-prefix, staged role, and staged composition from [26], suitably augmented for the retrieve action. Informally, role-prefix defines which sets of basic sequences can lead to a particular basic sequence. A staged role is a particular, legitimate sequence of basic sequences leading to a particular execution point. And staged composition allows for sequential implementation with arbitrary returns to earlier execution points, with the branching of retrieve potentially following different paths on each iteration.

We use *θPi* to indicate the precondition for basic sequence *Pi*. Additionally, to add simplicity to our exposition, we use Γ to denote the conjunction of all invariants within a staged composition of protocols. That is, Γ is the totality of all the invariants from each of the protocols *Qi* that make up a composition of protocols *Q*. This allows us to state the following theorem succinctly.

**Theorem 3.** *Let Q be a staged composition of protocols Q*1, *Q*2,..., *Qn and P*; *Pi* ∈ *SComp*(�*Q*1, *Q*2,..., *Qn*�) *and Pi* ∈ *Qi. Then Q* � *θP*<sup>0</sup> [*P*; *Pi*]*XθPi*<sup>+</sup><sup>1</sup> *, if for all RComp*(�*P*1, *P*2,..., *Pn*�) ∈ *Q, all of the following hold:*

*(Invariants) (i)* ∀*i*.∀*S* ∈ *BS*(*Qi*). � *θPi* ∧ Γ[*S*]*X*Γ *(Preconditions) (ii) Q*<sup>1</sup> ⊗ *Q*<sup>2</sup> ⊗···⊗ *Qn* � ∀*i*.*θPi* [*Pi*]*XθPi*<sup>+</sup><sup>1</sup> *(iii)*∀*i*.∀*<sup>S</sup>* ∈ *<sup>j</sup>*≥*<sup>i</sup> BS*(*Pj*).*θPi* [*S*]*XθPi (iv) Q*<sup>1</sup> ⊗ *Q*<sup>2</sup> ⊗···⊗ *Qn* � *Start*(*X*) ⊃ *θP*<sup>1</sup>

Theorem 3 states the conditions under which a particular run through a set of actions reaches its ultimate goal. The "Invariants" condition requires that no basic sequence violate any invariant of any basic sequence, with its proper preconditions, and invariants holding before the basic sequence. The "Preconditions" conditions require that each basic sequence's postconditions imply the next basic sequence's preconditions, that no basic sequence ever violate any preceding basic sequence's preconditions, and that the start state is valid.

We point out that Theorem 3 is dependent on basic sequences as its fundamental building block. The protocols themselves, while useful distinctions in understanding and modeling the system, are not critical. In particular, the *Qi*'s could be single basic sequences and the entire theorem still holds. This allows us to model at the level of basic sequences. This level of granularity has been suggested before [26], but we make it explicit.

This allows, for example, the behavior of the retrieve action that we discuss Section 3.3. Retrieve allows two different paths through a larger staged composition. In one path, a locally stored value is returned. In the other path, an entire protocol is run. As protocols compose consistently at the granularity of basic sequences in the initial protocol, retrieve fundamentally denotes alternate methods of staging the composition. In all protocols that use retrieve, the invariants and various preconditions in the protocol are proven against all possible stagings of the retrieve action.

#### *4.3.2. Composition in MSA*

18 Will-be-set-by-IN-TECH

branches will still compose. This also provides for all manner of if/then functionality within PCL, if it can be properly created in semantics and the various results of the if/then statement are properly modeled in terms of basic sequence breaks. We believe this fills a gap in the span

C

D

We utilize the definitions of role-prefix, staged role, and staged composition from [26], suitably augmented for the retrieve action. Informally, role-prefix defines which sets of basic sequences can lead to a particular basic sequence. A staged role is a particular, legitimate sequence of basic sequences leading to a particular execution point. And staged composition allows for sequential implementation with arbitrary returns to earlier execution points, with the

We use *θPi* to indicate the precondition for basic sequence *Pi*. Additionally, to add simplicity to our exposition, we use Γ to denote the conjunction of all invariants within a staged composition of protocols. That is, Γ is the totality of all the invariants from each of the protocols *Qi* that make up a composition of protocols *Q*. This allows us to state the following

**Theorem 3.** *Let Q be a staged composition of protocols Q*1, *Q*2,..., *Qn and P*; *Pi* ∈ *SComp*(�*Q*1, *Q*2,..., *Qn*�) *and Pi* ∈ *Qi. Then Q* � *θP*<sup>0</sup> [*P*; *Pi*]*XθPi*<sup>+</sup><sup>1</sup> *, if for all*

Theorem 3 states the conditions under which a particular run through a set of actions reaches its ultimate goal. The "Invariants" condition requires that no basic sequence violate any invariant of any basic sequence, with its proper preconditions, and invariants holding before the basic sequence. The "Preconditions" conditions require that each basic sequence's postconditions imply the next basic sequence's preconditions, that no basic sequence ever

We point out that Theorem 3 is dependent on basic sequences as its fundamental building block. The protocols themselves, while useful distinctions in understanding and modeling

violate any preceding basic sequence's preconditions, and that the start state is valid.

❄

A

✏✏ ✏✮✏

E

branching of retrieve potentially following different paths on each iteration.

[*Pi*]*XθPi*<sup>+</sup><sup>1</sup>

[*S*]*XθPi*

B

**Figure 7.** Branches in PCL

theorem succinctly.

*(Invariants)*

*(Preconditions)*

*(iii)*∀*i*.∀*<sup>S</sup>* ∈

✚✚✚✚❂

❩❩❩❩⑦

*RComp*(�*P*1, *P*2,..., *Pn*�) ∈ *Q, all of the following hold:*

*(i)* ∀*i*.∀*S* ∈ *BS*(*Qi*). � *θPi* ∧ Γ[*S*]*X*Γ

*<sup>j</sup>*≥*<sup>i</sup> BS*(*Pj*).*θPi*

*(iv) Q*<sup>1</sup> ⊗ *Q*<sup>2</sup> ⊗···⊗ *Qn* � *Start*(*X*) ⊃ *θP*<sup>1</sup>

*(ii) Q*<sup>1</sup> ⊗ *Q*<sup>2</sup> ⊗···⊗ *Qn* � ∀*i*.*θPi*

of PCL.

We wish to apply Theorem 3 to the protocols of the MSA proposal. We view the protocols of staged composition as the protocols given previously. As mentioned, we consider arbitrary breaks at the basic sequence level, for mid-protocol composition as well as overall composition. We need to prove that all protocols within MSA (comprising **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 protocols from MSA and RComp*(�*P*1, *P*2,..., *Pn*�) ∈ *Q and* <sup>Γ</sup> <sup>=</sup> <sup>Γ</sup>*TLS*,{1,2} <sup>∧</sup> <sup>Γ</sup>4*WAY*,1 <sup>∧</sup> <sup>Γ</sup>*MKHSH*,1 <sup>∧</sup> <sup>Γ</sup>*GKH*,{1,2} <sup>∧</sup> <sup>Γ</sup>*PPD*,{1,2} <sup>∧</sup> <sup>Γ</sup>*ABBH*,1*. Then:*

*(i)* ∀*i*.∀*S* ∈ *BS*(*Qi*). � *θPi* ∧ Γ[*S*]*X*Γ *(ii)* Φ4*WAY* � *θMKHSH* ∧ *θGKH* Φ*MKHSH* � *θPUSH* ∧ *θPULL* ∧ *θDEL* Φ*MKHSH* � *θABBH* Φ*ABBH* � *θGKH (iii)*∀*i*.∀*<sup>S</sup>* ∈ *<sup>j</sup>*≥*<sup>i</sup> BS*(*Pj*).*θPi* [*S*]*XθPi (iv)θP*<sup>1</sup>

Proving that all the protocols securely compose is a lengthy induction process, which we omit owing to space constraints. We briefly discuss the meaning of the various subpoints. No portion of any protocol in MSA violates the invariants (*i*) or changes the preconditions (*iii*) of any MSA protocol. All nodes in a mesh start with the correct information, by assumption (*iv*). Point (*ii*) gives the protocols which guarantee certain subsequent protocols can be completed with other legitimate nodes, via pre and post condition matching.

This theorem states that, given any MSA protocol, if the MKD and the players in the protocol are honest (that is, they conform to the protocol specification), then the security of that protocol is ensured, regardless of what other protocols may be running in the system. By extension, a mesh of honest nodes guarantees our security goals; the Mesh Security Architecture is sound.

#### **5. Modifications to MSA**

Our analysis of the protocols and key hierarchy of the MSA proposal indicate that it was largely well-designed. We have two recommendations that have been incorporated into the

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

802.11s draft (as of March 2008) and are necessary for Theorem 2 to hold; otherwise, the protocols are insecure.

The proposed modification includes the explicit identification of sender and receiver in the protected portion of the message, and updates the processing of **GKH** messages to verify this information upon reception. This prevents the replay attack because the sender and receiver

A Correctness Proof of a Mesh Security Architecture 197

We have proven the security of the MSA, under standard assumptions. We provided and justified a few recommendations that were incorporated (as of March 2008) into the 802.11s draft standard, which is still being developed. We also hope that providing a security proof during the design and review process will lead to additional efforts in that regard. We feel that protocol design is important and an analysis of a system should be done before implementation, not after. In the process of this analysis, we made a number of contributions

The most important contribution, from our perspective, is the ability to handle simultaneity, with the introduction of action groups and associated axioms and proof techniques. The definition of generalized authentication using generalized matching conversations is also required for simultaneous peer-to-peer protocols. The select and retrieve actions were also

This chapter also takes a deeper dive into the details of the protocols than is often undertaken. While examining only the security components (nonces, keys, etc.) simplifies analysis, it also leaves a gap. Our experience leads us to believe that gaps in analysis are often dangerous, as they lead to assumptions about security, implementation difficulties, and unforeseen attack vectors. Some level of abstraction is necessary, but adding a model for authenticated

This chapter opens opportunities for applying PCL to other peer-to-peer protocols, where ordering may not be as strict as in server-client models. Other protocol systems, particularly

Finally, we provide a new, more general composition theorem, which explicitly allows for mid-protocol composition and branching. As it is not unusual for protocols to intermix, explicitly allowing multiple potential paths through basic sequences is important, and should

The authors would like to thank Anupam Datta and Arnab Roy for their helpful comments

those on standard-track, would be natural candidates for additional analysis.

MAC addresses would not match if a reflection attack is attempted.

designed to extend naturally to examinations of other architectures.

information exchange is critical for many applications.

*Motorola Mobility 600 US Hwy 45 E1-40Y Libertyville, IL 60048*

naturally extend to other situations.

**Acknowledgements**

and suggestions.

**Author details**

Doug Kuhlman

**6. Conclusions and future work**

to PCL.

#### **5.1. Include mesh nonce in 4WAY**

**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.

The draft specification of **4WAY** during MSA authentication does not properly provide key freshness. The proposal has the key generation nonce (*MKDnonce*) provided by the MKD used both to derive the *pmkmkd* (see Figure 2) and as the nonce to derive the session key (*ptk*). This is shown in Figure 8.

This enables an attack that proceeds as follows. At some point, a legitimate node (*X*) disconnects from the mesh. The attacker then starts MSA authentication with the same MA with which *X* connected before. The rogue node does **PLE** (claiming to be *X*) and then continues to the **4WAY** protocol, where the *MKDnonce* is the same. The rogue node re-uses the nonce *X* used and now the same *ptk* is derived. The attacker may then utilize some information recorded from the legitimate conversation or otherwise 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 the derivation of *pmkmkd* so that it does not require an *MKDnonce*, so that 4WAY is responsible only for transporting nonces used to derive the *ptk*. The *MKDnonce* was removed as it did not provide significant benefit to the architecture and was not required for our key freshness goal. At this point, key freshness (for the *ptk*) can be proven and the attack outlined above is thwarted.

#### **5.2. Include MAC address in the Group Key Handshake protocol (GKH)**

In the original proposal, **GKH** does not provide authentication. Recall from section 4.2 that the *AUTH* goal requires matching conversations between two different nodes. In the proof of this property, it became apparent to us that the proposal did not protect against a reflection attack.

MAC addresses were contained in the **GKH** message headers (to facilitate transport of the messages) but were not incorporated in the calculation of the message integrity code (mic) included in each **GKH** message. **GKH** messages are protected using the *ptk*, a pairwise key known only to two parties, but either party may initiate the **GKH**. Owing to this symmetry, the first **GKH** message could be reflected back to the sender, and would be accepted as valid because of the presence of a valid mic. This reflection attack could change the security state at the MP that sends the first message of **GKH**, such as by installing a stale *gtk* or installing its own *gtk* as if it were its neighbor's *gtk*.

The proposed modification includes the explicit identification of sender and receiver in the protected portion of the message, and updates the processing of **GKH** messages to verify this information upon reception. This prevents the replay attack because the sender and receiver MAC addresses would not match if a reflection attack is attempted.
