Security Requirements for an Abbreviated MSA Handshake May 2007 doc.: IEEE 802.11-07/0770r0 May 2007 Security Requirements for an Abbreviated MSA Handshake Date: 2007-05-15 Authors: Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// 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 stuart@ok-brit.com 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Steve Emeott, Motorola Steve Emeott, Motorola

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

May 2007 Motivation Some figures of “goodness” are needed to guide the design and standardization of an abbreviated handshake for 802.11s 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

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 802.11i and TLS” from CCS’05 If the protocol does not complete, no results are implied Steve Emeott, Motorola

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

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

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

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

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

#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

#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

#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

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

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

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