**3. Additions to PCL and proof methodology**

In modeling the MSA protocol suite in PCL, we found a number of situations for which the current language model had no support. We provide a motivating example from MSA and discuss our proposed additions to the language. None of the additions modify the existing language, so all previous proofs and work should not need re-examination. We also broadened the proof methodology slightly.

Many of the additions can be explained by looking at the abbreviated handshake protocol with a simultaneous open (**SIMO**). The purpose of this protocol is to establish a linkage between two nodes which are already part of a mesh. Therefore, the two nodes already have authenticated to the MKD and need only authenticate to each other and establish a fresh, unknown session key. One possible instantiation of this protocol is presented in Figure 3. Values *x* and *y* are nonces generated by *X* and *Y* respectively. *INFOX* contains additional information about node *X*'s configuration. The *enc* values are broadcast keys encrypted with session keys derived from *x*, *y* and a shared key. The *mic* values provide integrity and authentication verification. We note that the messages labeled "ABBH5" do not have to occur in the listed order. Node *X* can receive message 5 before or after it sends its message 5. Note, too, that *X* might receive its message 5 after it sends its own message 5, even if node *Y* sends its message 5 before *X* does.

The thread for this protocol is symmetric (though it does not have to be) and is presented in Figure 4. Some additions to PCL were used in the thread description, 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 useful in demonstrating the necessity of the additions, as well as providing a sample of how the addition is used in the proof of the MSA proposal.

#### **3.1. Flexible temporal ordering**

The temporal ordering of actions in the original PCL definition is too strict for our applications. In the **SIMO** protocol presented in Figure 4, the order of sending and receiving the message labeled "ABBH5" is nondeterministic. Once the initial messages have been exchanged, the final messages could be sent/received in either order. The change to PCL is realized as an addition to the language. The proposed modification does not change any other aspect of PCL; therefore all previous proofs are still valid.

We add an *action group* and redefine the notion of a strand. We define an action group as: (action group) *g* ::= (*a*;...; *a*), where *a* is an action as defined in [15]. We also redefine a strand as: (strand) *s* ::= [*g*(; or :)...(; or :)*g*]. Thus a strand is now composed of an arbitrary number of action groups separated by colons or semicolons. The idea behind the action group is that the actions in an action group must be done in the order they appear. However, the action groups within a strand separated by a colon (:) can be done in any order and action groups separated by a semicolon (;) must be done in the order they appear. Note that any strand defined previous to this addition to the language can still be defined exactly the same

**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 HASH*pmk*(*x*, *y*)/*ptkX*,*Y*; (match ENC*ptkX*,*<sup>Y</sup>* (*gtkX*)/*enc*0; match HASH*ptkX*,*<sup>Y</sup>* (*Y*ˆ, *<sup>X</sup>*ˆ, "ABBH5", *INFOX*, *<sup>x</sup>*, *<sup>y</sup>*,*enc*0, *INFOY*)/*mic*0; send *Y*ˆ, *X*ˆ , "ABBH5", *INFOX*, *x*, *y*,*enc*0, *mic*0) : (receive *X*ˆ ,*Y*ˆ, "ABBH5", *INFOY*, *y*, *x*,*enc*1, *mic*1; 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>* θ**ABBH**,**<sup>1</sup>** := Has(*X*, *pmkX*,*Y*) ∧ Has(*Y*, *pmkY*,*X*) ∧ (Has(*X*, *mptkX*,*T*) ∨ Has(*Y*, *mptkX*,*T*)) **<sup>Γ</sup>ABBH**,**<sup>1</sup>** :<sup>=</sup> Honest(*X*ˆ) <sup>∧</sup> Send(*X*, *<sup>m</sup>*)<sup>∧</sup> (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> *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 Abbreviated Handshake Simultaneous Case

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

We update Axiom **AA4** [15] to reflect this addition 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 action groups. Thus nothing about the temporal order of *a* compared to *b* or *c* compared to *d* is indicated. We also include a new axiom

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

8 Will-be-set-by-IN-TECH

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

In modeling the MSA protocol suite in PCL, we found a number of situations for which the current language model had no support. We provide a motivating example from MSA and discuss our proposed additions to the language. None of the additions modify the existing language, so all previous proofs and work should not need re-examination. We also

Many of the additions can be explained by looking at the abbreviated handshake protocol with a simultaneous open (**SIMO**). The purpose of this protocol is to establish a linkage between two nodes which are already part of a mesh. Therefore, the two nodes already have authenticated to the MKD and need only authenticate to each other and establish a fresh, unknown session key. One possible instantiation of this protocol is presented in Figure 3. Values *x* and *y* are nonces generated by *X* and *Y* respectively. *INFOX* contains additional information about node *X*'s configuration. The *enc* values are broadcast keys encrypted with session keys derived from *x*, *y* and a shared key. The *mic* values provide integrity and authentication verification. We note that the messages labeled "ABBH5" do not have to occur in the listed order. Node *X* can receive message 5 before or after it sends its message 5. Note, too, that *X* might receive its message 5 after it sends its own message 5, even if node *Y* sends

The thread for this protocol is symmetric (though it does not have to be) and is presented in Figure 4. Some additions to PCL were used in the thread description, 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 useful in demonstrating the necessity of the additions, as well as providing a sample of how the addition is used in the proof of the MSA proposal.

The temporal ordering of actions in the original PCL definition is too strict for our applications. In the **SIMO** protocol presented in Figure 4, the order of sending and receiving the message labeled "ABBH5" is nondeterministic. Once the initial messages have been exchanged, the final messages could be sent/received in either order. The change to PCL is realized as an addition to the language. The proposed modification does not change any

We add an *action group* and redefine the notion of a strand. We define an action group as: (action group) *g* ::= (*a*;...; *a*), where *a* is an action as defined in [15]. We also redefine a strand as: (strand) *s* ::= [*g*(; or :)...(; or :)*g*]. Thus a strand is now composed of an arbitrary number of action groups separated by colons or semicolons. The idea behind the action group is that the actions in an action group must be done in the order they appear. However, the action groups within a strand separated by a colon (:) can be done in any order and action groups separated by a semicolon (;) must be done in the order they appear. Note that any strand defined previous to this addition to the language can still be defined exactly the same

other aspect of PCL; therefore all previous proofs are still valid.

additional details.

**3. Additions to PCL and proof methodology**

broadened the proof methodology slightly.

its message 5 before *X* does.

**3.1. Flexible temporal ordering**

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 exactly the **AA4** previously defined and **AA5** is redundant.

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

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

occur before a receive, corresponding to the potential temporal ordering of the action groups. Thus we must ensure that invariants and preconditions hold over all possible basic sequence orderings and compositions.

suffices for those cases. The three exceptions are **SIMO** (which is a peer-to-peer protocol and has some timing flexibility), **PLE** (which is not a cryptographic protocol in itself and requires

A Correctness Proof of a Mesh Security Architecture 187

We note that the generalized matching conversations property encompasses the matching record of runs property [20]. Also, this property guarantees all desired properties from [27]

We apply the generalized matching conversations definition to **SIMO**, which is a protocol for

Let *X* be the principal from whose view we seek to establish the proof of generalized matching conversation and *Y* be the other principal. SIMO1X and SIMO5X represent *X*'s messages, and similarly for *Y*'s messages. We need to determine the maximal timing relations in the ideal world (no adversaries) when only **SIMO** is run. *X* cannot confirm whether *Y* has received SIMO5X even in the ideal world, because it may be the last message sent. Therefore, SIMO5X is not part of *X*'s maximal conversation. Note that every message must be sent by the correct party before it is received by the other party in an ideal world. Now we simply list what actions must happen after other actions and omit receives after sends that are irrelevant (e.g.,

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

This temporal ordering is inherently maximal for *X*'s view of an arbitrary run of **SIMO**, so it satisfies the definition of generalized matching conversations for *X* (*Y*'s view is similar). The enforcement of the order of the send messages within a node can be accomplished by waiting for acknowledgements from the MAC layer before proceeding. If *X* has not sent its message 1, it initiates the corresponding thread for **ABBH.INIT**, not for **ABBH.SIMO**, so this ordering

In the full paper [28], we provide detailed PCL equivalents of the protocols presented in the MSA submissions. Such detailed examinations are necessary to prove protocol correctness. For example, the presence of *INFOY* in *mic*<sup>0</sup> in **SIMO** (Figure 4) is not intuitively obvious but is essential to the security of the protocol. Modeling the protocol at a higher level of

Real protocol implementations such as MSA require more than simple key agreement. Additional information must be exchanged and agreed on before secure communication can happen. Examples of information of this type are basic network functions (e.g., bandwidth selections) and security information (e.g., cipher suite selection). The two principals in the protocol must agree in each case, and an attacker must not be able to influence the selection. That is, the agreed-upon value in all protocol runs must match the agreed-upon value in an

no temporal ordering), and **PUSH** (which is a composition of two protocols).

and implies all the possible authentication definitions in [24].

establishing a secure connection between two nodes already in a mesh.

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

*3.1.2. Generalized matching conversations For ABBH.SIMO*

Send(*X*, SIMO1X) < Receive(*Y*, SIMO1X)).

**3.2. Modeling information exchange**

abstraction would have missed this subtle requirement.

is maximal.

#### *3.1.1. Generalized matching conversations and generalized mutual authentication*

The proofs of mutual authentication used in many previous work that use PCL for protocol verification have adopted the notion of matching conversations [2] for the authenticity property. This is natural as these protocols are "turn-by-turn" protocols in which one a participant receives a message and then responds to the message, which is received by the other party who responds to it, and so on. However, some of the peer-to-peer protocols analyzed in this chapter can never correspond to matching conversations as the order in which messages are sent and received is flexible, as a functional requirement. We generalize the properties of matching conversations and define two new notions which we call maximal conversations and generalized matching conversations. We feel these definitions are of general interest beyond this work. Recall the definitions of conversation and matching conversation from [2].

We define the *maximal conversation* for a participant *A*. We first determine the maximal possible temporal ordering. To do this we consider all legal orderings in an ideal world (one with no adversarial interference) from the view of a participant *A* in a protocol. Given this maximal temporal ordering, we note the existence of messages for which *A* can never confirm reception. We take the maximal temporal ordering and remove any send or receive for which *A* cannot confirm reception in the ideal world – the remaining actions represent the maximal conversation for participant *A*.

We now define *generalized matching conversations* for a participant *A*. We say *A* has generalized matching conversations, if in every run of the system, every action in the maximal conversation for participant *A* has a corresponding action at participant *A* (e.g., *A* does all its actions) and at the appropriate other participant in the system. For two-participant protocols (like all those in this chapter), this means that the maximal conversation for participant *A* has messages exactly matching the other participant's maximal conversation, with the strictest time ordering possible.

We now define *generalized mutual authentication*. In a world in which an adversary has access to every message and can act on them within the restraints of the proof system (symbolic or computational), generalized mutual authentication means that generalized matching conversations for every participant implies acceptance and acceptance implies generalized matching conversations for every participant. For the purpose of this chapter we wish to keep the definition of generalized mutual authentication general. We explore all these definitions in detail in separate 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 ordering of actions be maximal with respect to what is possible in the ideal world. As this definition imposes maximal temporal ordering on a protocol, this definition is at least sufficient for mutual authentication. Most protocols in the MSA are turn-by-turn and thus the [2] definition suffices for those cases. The three exceptions are **SIMO** (which is a peer-to-peer protocol and has some timing flexibility), **PLE** (which is not a cryptographic protocol in itself and requires no temporal ordering), and **PUSH** (which is a composition of two protocols).

We note that the generalized matching conversations property encompasses the matching record of runs property [20]. Also, this property guarantees all desired properties from [27] and implies all the possible authentication definitions in [24].

### *3.1.2. Generalized matching conversations For ABBH.SIMO*

10 Will-be-set-by-IN-TECH

occur before a receive, corresponding to the potential temporal ordering of the action groups. Thus we must ensure that invariants and preconditions hold over all possible basic sequence

The proofs of mutual authentication used in many previous work that use PCL for protocol verification have adopted the notion of matching conversations [2] for the authenticity property. This is natural as these protocols are "turn-by-turn" protocols in which one a participant receives a message and then responds to the message, which is received by the other party who responds to it, and so on. However, some of the peer-to-peer protocols analyzed in this chapter can never correspond to matching conversations as the order in which messages are sent and received is flexible, as a functional requirement. We generalize the properties of matching conversations and define two new notions which we call maximal conversations and generalized matching conversations. We feel these definitions are of general interest beyond this work. Recall the definitions of conversation and matching

We define the *maximal conversation* for a participant *A*. We first determine the maximal possible temporal ordering. To do this we consider all legal orderings in an ideal world (one with no adversarial interference) from the view of a participant *A* in a protocol. Given this maximal temporal ordering, we note the existence of messages for which *A* can never confirm reception. We take the maximal temporal ordering and remove any send or receive for which *A* cannot confirm reception in the ideal world – the remaining actions represent the maximal

We now define *generalized matching conversations* for a participant *A*. We say *A* has generalized matching conversations, if in every run of the system, every action in the maximal conversation for participant *A* has a corresponding action at participant *A* (e.g., *A* does all its actions) and at the appropriate other participant in the system. For two-participant protocols (like all those in this chapter), this means that the maximal conversation for participant *A* has messages exactly matching the other participant's maximal conversation, with the strictest

We now define *generalized mutual authentication*. In a world in which an adversary has access to every message and can act on them within the restraints of the proof system (symbolic or computational), generalized mutual authentication means that generalized matching conversations for every participant implies acceptance and acceptance implies generalized matching conversations for every participant. For the purpose of this chapter we wish to keep the definition of generalized mutual authentication general. We explore all these definitions

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 ordering of actions be maximal with respect to what is possible in the ideal world. As this definition imposes maximal temporal ordering on a protocol, this definition is at least sufficient for mutual authentication. Most protocols in the MSA are turn-by-turn and thus the [2] definition

*3.1.1. Generalized matching conversations and generalized mutual authentication*

orderings and compositions.

conversation from [2].

conversation for participant *A*.

time ordering possible.

in detail in separate work.

We apply the generalized matching conversations definition to **SIMO**, which is a protocol for establishing a secure connection between two nodes already in a mesh.

Let *X* be the principal from whose view we seek to establish the proof of generalized matching conversation and *Y* be the other principal. SIMO1X and SIMO5X represent *X*'s messages, and similarly for *Y*'s messages. We need to determine the maximal timing relations in the ideal world (no adversaries) when only **SIMO** is run. *X* cannot confirm whether *Y* has received SIMO5X even in the ideal world, because it may be the last message sent. Therefore, SIMO5X is not part of *X*'s maximal conversation. Note that every message must be sent by the correct party before it is received by the other party in an ideal world. Now we simply list what actions must happen after other actions 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*'s view of an arbitrary run of **SIMO**, so it satisfies the definition of generalized matching conversations for *X* (*Y*'s view is similar). The enforcement of the order of the send messages within a node can be accomplished by waiting for acknowledgements from the MAC layer before proceeding. If *X* has not sent its message 1, it initiates the corresponding thread for **ABBH.INIT**, not for **ABBH.SIMO**, so this ordering is maximal.

#### **3.2. Modeling information exchange**

In the full paper [28], we provide detailed PCL equivalents of the protocols presented in the MSA submissions. Such detailed examinations are necessary to prove protocol correctness. For example, the presence of *INFOY* in *mic*<sup>0</sup> in **SIMO** (Figure 4) is not intuitively obvious but is essential to the security of the protocol. Modeling the protocol at a higher level of abstraction would have missed this subtle requirement.

Real protocol implementations such as MSA require more than simple key agreement. Additional information must be exchanged and agreed on before secure communication can happen. Examples of information of this type are basic network functions (e.g., bandwidth selections) and security information (e.g., cipher suite selection). The two principals in the protocol must agree in each case, and an attacker must not be able to influence the selection. That is, the agreed-upon value in all protocol runs must match the agreed-upon value in an

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

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 matching values from two lists.

pull protocol. Furthermore, the second protocol could potentially be triggered in the middle

A Correctness Proof of a Mesh Security Architecture 189

This is new ground for PCL and we have devised a system and proof (see section 4.3) that enables us to frame this complex action in PCL and develop sound proofs. Essentially, we define the inception of functions that may need to run a separate protocol to be basic sequences, as they may involve blocking actions (like receive). Then, before and after these actions we define basic sequence pre- and post-conditions that must be satisfied for a successful completion of the protocols. The idea of basic sequence pre- and post-conditions were give in [26] to enable staged composition and remain standard in the language [15], although they have not been previously used in this way to enable mid-protocol composition. **The retrieve action** We have added a new action, retrieve, to PCL. The retrieve action provides the key to the strand, after key selection is complete. The retrieve action takes a key name (*pmkN*, corresponding to a specific *pmk*) as its input. If the principal that executes the function does not have the key locally cached on disk, but is an MA (and has a connection with the MKD), retrieve initiates the **PULL** protocol. If the key is not on disk and the principal is not an MA, retrieve fails and the protocol that called it aborts. As the retrieve action may or may not perform a key pull, we create a break in the basic sequence directly before and directly after

The retrieve action has inherent pre- and post-conditions as it is a series of one or more basic sequences (e.g., a protocol). As a precondition, retrieve must have the *pmk* cached locally or it must have the *mptkX*,*T*. Thus the precondition is Has(*X*, *mptkX*,*T*) ∨ Has(*X*, *pmk*) where *pmk* matches the input *pmkN*. The postcondition is simply Has(*X*, *pmk*). The retrieve function itself has security requirements only if the principal must perform a key pull, when it inherits

In Figure 4, retrieve is used to get the selected *pmk*. This provides two potential paths of execution through the protocol, one which runs a key pull mid-protocol and one which simply

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

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

efforts. Finally, in Section 4.3, we discuss our approach to protocol composition.

of a basic sequence.

the retrieve.

the requirements of the **PULL** protocol.

**4. Overview of the proof**

**4.1. Key secrecy in MSA**

fetches some stored memory (equivalent to a match action).

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** protocols require the use of *INFO*.

**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 suite to use after completing a protocol.

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 non-obvious to a lay implementer.

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 dangerous form of a downgrade attack.

#### **3.3. Calling one protocol in another**

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 pull protocol. Furthermore, the second protocol could potentially be triggered in the middle of a basic sequence.

This is new ground for PCL and we have devised a system and proof (see section 4.3) that enables us to frame this complex action in PCL and develop sound proofs. Essentially, we define the inception of functions that may need to run a separate protocol to be basic sequences, as they may involve blocking actions (like receive). Then, before and after these actions we define basic sequence pre- and post-conditions that must be satisfied for a successful completion of the protocols. The idea of basic sequence pre- and post-conditions were give in [26] to enable staged composition and remain standard in the language [15], although they have not been previously used in this way to enable mid-protocol composition.

**The retrieve action** We have added a new action, retrieve, to PCL. The retrieve action provides the key to the strand, after key selection is complete. The retrieve action takes a key name (*pmkN*, corresponding to a specific *pmk*) as its input. If the principal that executes the function does not have the key locally cached on disk, but is an MA (and has a connection with the MKD), retrieve initiates the **PULL** protocol. If the key is not on disk and the principal is not an MA, retrieve fails and the protocol that called it aborts. As the retrieve action may or may not perform a key pull, we create a break in the basic sequence directly 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 sequences (e.g., a protocol). As a precondition, retrieve must have the *pmk* cached locally or it must have the *mptkX*,*T*. Thus the precondition is Has(*X*, *mptkX*,*T*) ∨ Has(*X*, *pmk*) where *pmk* matches the input *pmkN*. The postcondition is simply Has(*X*, *pmk*). The retrieve function itself has security requirements only if the principal must perform a key pull, when it inherits the requirements of the **PULL** protocol.

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