1. Security Requirements for an Abbreviated MSA Handshake
May 2007
doc.: IEEE /0770r0
May 2007
Security Requirements for an Abbreviated MSA Handshake
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Steve Emeott, Motorola
Steve Emeott, Motorola

2. May 2007
Abstract
This submissions proposes a set of security requirements for an s abbreviated handshake. The proposed set was chosen to emphasize those requirements essential to constructing a security proof.
Steve Emeott, Motorola

3. May 2007
Motivation
Some figures of “goodness” are needed to guide the design and standardization of an abbreviated handshake for s
About 10 comments were submitted to LB93 requesting an abbreviated handshake (please see document 07/263r0, slide 9)
A safe place to start is with a set of security requirements needed to construct a security proof
Steve Emeott, Motorola

4. How will requirements be used?
May 2007
How will requirements be used?
An exemplary step by step process for constructing a security proof could involve:
Step 1: Taking text security requirements and translating them into formal logic
Step 2: Presenting protocol in the same logic
Step 3: Proving protocol completion implies desired security requirements
Overall: If the proof is decomposed into a set of proofs, pre-, post-conditions and invariants are clearly stated
An example of a proof using this approach:
He, et al. “A Modular Correctness Proof of IEEE i and TLS” from CCS’05
If the protocol does not complete, no results are implied
Steve Emeott, Motorola

5. Proposed Requirements List
May 2007
Proposed Requirements List
The following slides list 5 security requirements and 1 procedural requirement
Key Secrecy
Key Freshness
Mutual Authentication
Cipher Suite Selection Not Compromised
Authenticated Exchange of Information
Composability (procedural requirement)
Hypothesis: Any abbreviated handshake proven to meet these requirements is secure
Steve Emeott, Motorola

6. May 2007
#1 Key Secrecy
Generate a session key known only to the participants in the session (and maybe a (trusted) third party)
Both X and Y have the new session key (ptk-ma)
Any entity that has the new session key (ptk-ma) is either X or Y (or trusted third party)
Steve Emeott, Motorola

7. PCL (Protocol Composition Logic) for Key Secrecy
May 2007
PCL (Protocol Composition Logic) for Key Secrecy
X-hat and Y-hat are the two legitimate nodes
engaging in an abbreviated handshake
Reads “Honest X-hat and Y-hat implies that X-hat has the ptk (the session key) and Y-hat has the ptk and if Z-hat has the ptk, Z-hat is either Y-hat or X-hat”
Means both parties in the protocol have the session key
Any adversary can’t have the session key (any entity with the session key is one of the two legitimate nodes)
Steve Emeott, Motorola

8. May 2007
#2 Key Freshness
The generated session key shall be fresh (provably so by each of the participants)
New session key (ptk-ma) is fresh to both X and Y
Assumes the pmk-ma is not compromised
Defined as some newly-generated value from each of X and Y is used in the generation of the ptk-ma
Steve Emeott, Motorola

9. PCL for Key Freshness May 2007
Reads “Honest X-hat and Y-hat implies X-hat created a new value (nonce) x and x is a subterm of the ptk and Y-hat created a new value y and y is a subterm of the ptk”
Shows both parties contributed something new to the session key, so the key is fresh
Steve Emeott, Motorola

10. #3 Mutual Authentication
May 2007
#3 Mutual Authentication
Successful protocol completion if and only if each message sent during the protocol was received by the other party, exactly as sent
Must show that two different parties were involved in the protocol (i.e., X ≠ Y)
Note: This property implies both existence of PMK-MA at the peer and peer liveness
Steve Emeott, Motorola

11. #4 Cipher Suite Selection Not Compromised
May 2007
#4 Cipher Suite Selection Not Compromised
The cipher suite chosen shall be agreed on by both parties X and Y
Both parties agree on the same pairwise cipher suite at protocol end
The pairwise cipher suite shall be in the intersection of allowed cipher suites
Either X or Y shall have chosen the pairwise cipher suite
The cipher suite selection must not be affected by the adversary
Steve Emeott, Motorola

12. #5 Authenticated Exchange of Information
May 2007
#5 Authenticated Exchange of Information
Each party shall receive additional information from the other party
This information shall include:
Each party’s encrypted GTK
Each party’s group cipher suite
More information potentially here
The information shall be verified (Note: This comes as a consequence of the definition of mutual authentication)
Steve Emeott, Motorola

13. May 2007
#6 Composability
If the analysis is decomposed into a set of proofs, strict pre-, post-conditions, and invariants shall be clearly stated
Pre-conditions: Starting state for X, Y (explicit)
Post-conditions: State of X, Y after protocol completion (explicit)
Invariants: Laws that must be obeyed by all honest parties who use any element (generally a key) of the protocol (explicit)
Allows proof of security of abbreviated handshake to more easily extend to overall security proof
Steve Emeott, Motorola

14. May 2007
Summary
Proposed list identifies a set requirements needed for provable security
Most were obtained from i and i security proof
Based on our analysis, the list should be comprehensive
Discussion?
Steve Emeott, Motorola

15. References IEEE 802.11i Standard
May 2007
References
IEEE i Standard
He, Sundararajan, Datta, Derek, and Mitchell, “A Modular Correctness Proof of IEEE i and TLS”
Gollman, “What Do We Mean By Entity Authentication?”
Bellare, Rogaway “Entity Authentication and Key Distribution”
Steve Emeott, Motorola