Overview of an MSA Security Proof September 2007 doc.: IEEE 802.11-07/2432r0 September 2007 Overview of an MSA Security Proof Date: 2007-09-14 Authors: Steve Emeott, Motorola Steve Emeott, Motorola

September 2007 doc.: IEEE 802.11-07/2432r0 September 2007 Abstract This submission provides a general overview of a security proof for Mesh Security Association (MSA) services currently specified in the TGs draft. This presentation partially addresses letter ballot comments requesting a security analysis of MSA. Steve Emeott, Motorola Steve Emeott, Motorola

September 2007 Background In 11-07/770r0, we started talking about utilizing Protocol Composition Logic (PCL) to construct a security proof for the security protocols defined in 802.11s Since then, we have been working through the details of a proof for the mesh security architecture A paper presenting a security proof for MSA in PCL has been developed. This presentation provides an introduction to the security proof and to the extensions proposed to PCL for the proof Steve Emeott, Motorola

Outline Security Goals Proof System Extensions to PCL for MSA September 2007 Outline Security Goals Proof System Extensions to PCL for MSA Theorems and proofs Extensions to PCL for an abbreviated handshake Abbreviated handshake proof Steve Emeott, Motorola

Proposed Mesh Security Goals September 2007 Proposed Mesh Security Goals Mutual Authentication Key Secrecy Session keys, node-to-node and node-to-MKD Broadcast keys, for each node Other key material Session Key Freshness Cipher Suite Selection Not Compromised Authenticated Exchange of Information Composability Protocols all work together in a safe manner Steve Emeott, Motorola

September 2007 Model of an Adversary An adversary is modeled as an active (“man-in-the-middle”) attacker with full control of the links between parties An adversary can intercept messages, delay or prevent their delivery, modify them at will, inject its own messages, interleave messages from different sessions [Krawczyk] read the messages produced by the parties, provide messages of her own to them, modify messages before they reach their destination, and delay messages or replay them.  Most importantly, the adversary can start up entirely new ‘instances’ of any of the parties, modeling the ability of communicating agents to simultaneously engage in many sessions at once [Bellare-Rogaway] The presence of a powerful adversary, such as the one modeled, can make it difficult for a protocol to achieve the desired goals Steve Emeott, Motorola

Proof System Proof constructed in PCL September 2007 Proof System Proof constructed in PCL PCL has been used for a security analysis of 802.11i and IPv6 PCL is being used for a security analysis of 802.11r (07/2293r0) A core feature of PCL is its ability to reason about how protocols interact Its important that individual protocols be proven secure not only individually but also working together Steve Emeott, Motorola

Extension to Proof System for MSA September 2007 Extension to Proof System for MSA Key secrecy invariant Instead of proving key secrecy at protocol completion, this property is proven at every step. We must ensure key secrecy even if the protocol fails. Mid-protocol composition A protocol may instantiate another protocol partway through its run (e.g. running a key pull protocol) Authentic exchange of information E.g. identifiers for cached keys, supported cipher suites, an identifier of a security domain, authentication method, etc. New PCL functions Select() – used when two parties must simultaneously chose between link and protocol options from exchanged information Retrieve() – gets a key to a strand, after the selection of which key will be used Steve Emeott, Motorola

Overview of Theorems in Proof September 2007 Overview of Theorems in Proof Key Secrecy (Hierarchy) Theorem Every step of every MSA protocol preserves limits on which node or nodes have access to particular keys No node, except the targeted node(s), gains access to a particular key via any specified protocol Prevents all key disclosure attacks Protocol-Level Theorems Each protocol (MSA Authentication (including Peer Link Establishment, EAP-TLS, and the 4-Way Handshake), Mesh Key Holder Security Handshake, Key Push, Key Pull, Key Delete, Group Key Handshake) meets all the security goals (see slide 5). Eliminates many attacks – all spoofing, replay, reflection, impersonation, delay, and cipher suite downgrade attacks System-Level Theorems All protocols behave properly together Eliminates more attacks – all interleaving, de-syncing, and multiple protocol running type attacks Steve Emeott, Motorola

September 2007 Proving the Theorems First, prove key secrecy, throughout the hierarchy Start with assumptions on key possession E.g., only the MKD has its private key Prove possession of other keys based on original key possessions E.g., deriving the ptk requires knowledge of the pmk-ma and only these two nodes can know the pmk-ma, so only these two can know the pmk-ma Second, prove each protocol secure Utilizes key secrecy properties already proven Shows the adversary had to have done nothing but read messages, if the protocol completes successfully Third, prove the system as a whole is secure Prove each protocol composes in parallel with every protocol E.g., Key Pull can be run while a Group Key Handshake is occurring Prove some protocols compose in sequence E.g., completing MKHSH allows Key Pull to follow Steve Emeott, Motorola

Extension to Proof System for the Abbreviated Handshake September 2007 Extension to Proof System for the Abbreviated Handshake Flexible temporal ordering Protocols we wish to analyze include threads where the order in which certain messages sent or received does not need to be strict (e.g. simultaneous open case of an abbreviated handshake) We propose to define a PCL action groups, and permit actions within certain action groups to be done in any order Generalized matching conversations Version of matching conversations property defined for protocols where the order in which messages are sent and received is necessarily flexible, as a functional requirement Steve Emeott, Motorola

Flexible Temporal Ordering September 2007 Flexible Temporal Ordering Two forms of an exemplary abbreviated handshake are written in shorthand to demonstrate new PCL features developed for the proof A B ABBH:SIMO = tx1; rx2; tx3; rx4 ABBH:INIT = tx1; rx1; (tx5 : rx5) Traditional PCL description, which reads - PLO is transmitted before PLS is received at A PLS is received before PLR is transmitted by A And so on … Extension to PCL, which reads - PLOA is transmitted before PLOB is received at A PLOA is transmitted before PLCA is transmitted by A A may transmit PLCA before or after receiving PLCB Steve Emeott, Motorola

Generalized Matching Conversation September 2007 Generalized Matching Conversation GMC is how we propose mutual authentication be proven e.g. mutual authentication means that the generalized matching conversations (GMC) property can be proven (Informal) definition of generalized matching conversations e.g. GMC means, in a two-participant protocol, that for every run of the protocol each participant transmits and receives every message it ideally should have transmitted and received, with the strictest time ordering possible. Then the GMC property means that if the protocol runs nicely as seen by the two participants (e.g. a generalized matching conversation occurs), then each participant can conclude the other was authentic, and vice versa. Proof is completed when It can be inferred, simply based upon the messages sent and received, that a protocol successfully completes only in the absence of adversarial interference (e.g. any interference other than passing the actual messages sent by each party) Steve Emeott, Motorola

Overview of Exemplary Abbreviated Handshake Proof September 2007 Overview of Exemplary Abbreviated Handshake Proof Examine each (in this case both) of the protocol forms independently Prove each meets the desired security properties independently Examine the two possibilities together Prove the two forms of the protocol are well-defined I.e.., the two forms can both be implemented on the same device and still have a deterministic result given specific conditions Prove composability with each other (and all other protocols in the MSA system) E.g., running the two in any combination won’t cause a loss of security Steve Emeott, Motorola

September 2007 Next Steps Please see 11-07/2436r0 for the proof paper. The authors would be happy to hear comments or questions. Planning to prepare submissions addressing the couple of issues identified during proof construction e.g., Group key reflection attack issue e.g., Initial mesh 4-way message should contain an additional nonce Suggesting a completed security proof might be a basis upon which to accept letter ballot comments requesting a security analysis be completed on MSA Steve Emeott, Motorola