**6. Conclusions and future work**

20 Will-be-set-by-IN-TECH

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

X Y T

**Figure 8.** MSA Authentication. The text above a double-headed arrow (e.g., **4WAY**) is a protocol, and

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

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

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

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

**PULL** *MKDnonce*

protocols are insecure.

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

*x*, *hashptk* = *mic*

This is shown in Figure 8.

attack.

own *gtk* as if it were its neighbor's *gtk*.

**PLE**

**4WAY** *MKDnonce*

text below (e.g., *MKDnonce*) is some data that is sent as part of the protocol.

used and not a pre-shared key, then this particular attack no longer works.

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

the *ptk*) can be proven and the attack outlined above is thwarted.

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 to PCL.

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 designed to extend naturally to examinations of other architectures.

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 information exchange is critical for many applications.

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 those on standard-track, would be natural candidates for additional analysis.

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 naturally extend to other situations.
