1. Overview of an MSA Security Proof
September 2007
doc.: IEEE /2432r0
September 2007
Overview of an MSA Security Proof
Date:
Authors:
Steve Emeott, Motorola
Steve Emeott, Motorola

2. September 2007
doc.: IEEE /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

3. 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 s
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

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

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

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

7. Proof System Proof constructed in PCL
September 2007
Proof System
Proof constructed in PCL
PCL has been used for a security analysis of i and IPv6
PCL is being used for a security analysis of r (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

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

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

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

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

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

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

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

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