September 2007
doc.: IEEE 802.11-07/2432r0
Overview of an MSA Security Proof
Date: 2007-09-14
Authors:
Name
Affiliations Address
Steve Emeott
Motorola
Tony Braskich
Motorola
Doug Kuhlman
Motorola
Submission
1301 E. Algonquin Rd.
Schaumburg, IL 60196
1301 E. Algonquin Rd.
Schaumburg, IL 60196
1301 E. Algonquin Rd.
Schaumburg, IL 60196
Slide 1
Phone
email
+1-847-5768268
+1-847-5380760
+1-847-5769675
[email protected]
[email protected]
[email protected]
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
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.
Submission
Slide 2
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
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
Submission
Slide 3
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
Outline
•
•
•
•
•
•
Security Goals
Proof System
Extensions to PCL for MSA
Theorems and proofs
Extensions to PCL for an abbreviated handshake
Abbreviated handshake proof
Submission
Slide 4
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
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
Submission
Slide 5
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
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
Submission
Slide 6
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
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
Submission
Slide 7
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
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
Submission
Slide 8
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
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
Submission
Slide 9
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
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
Submission
Slide 10
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
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
Submission
Slide 11
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
Flexible Temporal Ordering
• Two forms of an exemplary abbreviated handshake are written in
shorthand to demonstrate new PCL features developed for the proof
MP
A
MP
B
MP
A
MP
B
Peer Link Open
Peer Link Open
Peer Link Setup
Peer Link Response
Peer Link Confirm
Peer Link Acknowledge
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
Submission
Slide 12
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
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)
Submission
Slide 13
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
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
Submission
Slide 14
Steve Emeott, Motorola
September 2007
doc.: IEEE 802.11-07/2432r0
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
Submission
Slide 15
Steve Emeott, Motorola