doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 1 Protocol Analysis of Abbreviated Handshake Date: Authors:

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 2 Abstract This submission explains the design rationale behind the Abbreviated Handshake. The security goals and protocol requirements are presented and the function design rationale is explained in terms of how to satisfy the security goals. And updates of the protocol specified is presented in the end. Updated protocol specification and informative rationale explanation are in 11-07/1999r1.

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 3 Peer Link and Security Handshake Peer Link Establishment Authentication 4-Way Handshake Peer Link Establishment 4-Way Handshake Abbreviated Security Handshake

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 4 Peer Link and Security Handshake Peer Link Establishment Authentication 4-Way Handshake Peer Link Open (…,RSNIE, MSAIE) Peer Link Confirm (…,RSNIE, MSAIE)

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 5 Summary of Updates Major changes in 11-07/1999r1 –GTK wrapping* –MIC protection on Peer Link Close frame* –Updated FSM: deal with NOKEY_RJCT event* –Updated parameter negotiation* –Added text to clarify relationships between MSA authentication and Abbreviated Handshake* –Added text to explain protocol design rationale –Misc minor changes Focus: design rationale * Note: see backup slides

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 6 Peer Link Establishment in P2P Model Nature of networking –Nodes have only local knowledge regarding the network state –Nodes either execute the protocol spontaneously or follow a predefined protocol execution sequence PLM design choice –Both MPs can initiate the protocol any time, and does NOT know if the peer is initiating –Both MPs can respond any time after receiving a request, and cannot assume the peer is doing the same thing –Peer link is established when both MP have sent and received both request and confirm messages Benefits –Maximize flexibility of protocol execution –Bound failure variance Alternative: lock-step –Modify the model using pre-defined ordering –But, hard to control the failure variance Unnecessary protocol stalls

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 7 Mutual authentication –Client/Server model: classically defined as matching conversation (Bellare&Rogaway)—both parties perceive the same sequence of message exchange –Peer2peer model: classical model can’t apply, because no deterministic message sequence –Design based on the Conjecture: matching conversation means the same set of messages sent by one party is received by the other Secrecy of session key –No other party than the peers authenticated in an Abbreviated Handshake session should learn any information about the resultant session key Consistency property –Upon completion, both parties know that they share the same set of security session state, S –For each s  S, the value of s is confirmed to the peer –Otherwise, various mis-binding attacks are possible Man-in-the-middle attacks, triangle attacks, etc. Security Goals

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 8 System Model AB MAC A R A L AKM-A L PMK-A L PC-A GC A GTK A MAC B R B L AKM-B L PMK-B L PC-B GC B GTK B

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 9 System Model AB PMK→KCK, KEK, TK AKM Suite Pairwise Cipher Suite Group Cipher Suite GTK A, GTK B Mutual authentication Session Key Secrecy Consistency

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 10 Design Evolution Basic peer link establishment (PLM) –Instance identifier agreement –Delivering the group keys –Deriving session keys –Negotiate session cipher suites –Negotiate AKM suite –Negotiate instance PMK Abbreviated Handshake Informative text in T.8 in 11-07/1999r1

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 11 Instance Identifier Agreement Security Goals –Mutual Authentication –Consistency of link instance identifier Assumptions –KCK only known to A and B –MAC A and MAC B as node identifier –Use rand to generate random numbers Instance identifier – AB Open( A, B, R A, …, MIC ) Open (B, A, R B, …, MIC) Confirm ( B, A, R B, R A, …, MIC ) Confirm ( A, B, R A, R B, …, MIC ) Generate R A Generate R B

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 12 Rationale: Instance Identifier Agreement Consistency on link instance identifier –Nonces (random numbers) are assumed to be unpredictable –MIC binds the node identifiers to the nonces Confirm sent AFTER Open received Only sent by the KCK holder –Confirm commits MAC A, MAC B, R A, and R B Mutual authentication –Consistency of instance identifier –A and B sent and received the same set of messages Note: MIC on Open helps –Consistency establishment of other parameters –Defend against flooding attacks

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 13 Delivery GTK A and GTK B Security goal –Consistency: both MPs agree that A uses GTK B to decrypt broadcast data by B, and B uses GTK A to decrypt broadcast data by A Assumption –GTK is associated with counter and expiry time –GTK has enough Cryptographic entropy –“Authenticated” KEK is used to wrap GTK Example: Deliver GTK-A A B Open(…, E(KEK, GTK A || MAC B || KeyRSC A || ExpireTime(GTK A )), …, MIC ) Confirm(…, MIC )

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 14 Rationale: GTK Delivery Consistency of GTK A delivery: A knows that B correctly receives the GTK A that A sent for the instance –B checks MIC on Open to verify E(…) comes from the node who knows KEK* –B verifies “unwrap” correctly, or no Confirm Yield correct IV Yield correct context “MAC B ” –A verifies MIC on Confirm to verify confirmation comes from the node who knows KEK *Note: Unprotected Open requires the same E(…) sent in Confirm. This enables other potential failures.

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 15 GTK Belongs to Security Session State GTK delivery in i –Failure of confirming the delivery → de-authenticate the client 4-Way Handshake –GTK is delivered and confirm when 4-Way HS completes Alternative: separate GTK deliveries –Leads to more severe race condition at the receiver: can’t decrypt broadcast traffic even after secure link is up –Performance implication (at least) 4 messages by Abbr HS 2 messages to deliver GTK A 2 messages to deliver GTK B

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 16 Deriving Session Keys Security goal –Secrecy of derived keys Assumptions of PMK –Secrecy –Ephemeral –Sufficient entropy Approach –KCK || KEK ← kdf(PMK, 0 n || min(MAC A, MAC B ) || max(MAC A, MAC B )) –TK ← kdf(PMK, min(R A, R B ) || max(R A, R B ) || min(MAC A, MAC B ) || max(MAC A, MAC B ))

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 17 Rationale: Key Derivation Secrecy of derived KCK, KEK, and TK –Assuming secrecy of PMK and enough entropy –KCK and KEK are long-lived, but bound to the PMK Appropriate for dealing with frequent dynamics of links –TK are bound to the protocol instance (PMK + Nonces) Key derivation does not affect security of GTK delivery or the freshness of communication –GTK, not KEK, provides randomness of GTK wrapping for security –Random numbers R A and R B, not KCK, provide freshness of the communication

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 18 Negotiating Instance Ciphersuite Security Goal –Consistency of instance ciphersuite Approach –Announce choices in priority –Decide the Ciphersuite from the overlap Example: A B Open(…, Ciphersuites A, …, MIC ) Confirm(…, Ciphersuite, …, MIC ) Open(…, Ciphersuites B, …, MIC ) Ciphersuite ← B’s most preferred one in the Ciphersuites A ∩ Ciphersuites B Higher MAC address

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 19 Rationale: Ciphersuite Negotiation Consistency of negotiated ciphersuite: A knows that B has agreed to the Ciphersuite, and vise versa. –Ciphersuites A protected by R A and MIC in Open message A knows Ciphersuites A is sent only by the MP who knows KCK –Both parties use the same rule to break the tie –Ciphersuite binding with R A, R B, and MIC Ciphersuite is sent by the MP who knows KCK and for this instance

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 20 Negotiate AKM Suite Security goal: consistency property of negotiated AKM Suite Motivation –Flexibility, default: Mesh Abbreviated Handshake –Need to prematurely commit to the AKM Suite Approach –Announce the priority list, and commit to the first AKM on the list –Abandon the instance started with “wrong” AKM –Start a new instance with the “right” AKM –Should bind AKM with key derivation—different keys for different AKM KCK || KEK ← kdf(PMK, 0 n || AKM-ID || min(MAC A, MAC B ) || max(MAC A, MAC B )) TK ← kdf(PMK, min(R A, R B ) || max(R A ), R B ) || AKM-ID || min(MAC A, MAC B ) || max(MAC A, MAC B )))

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 21 Rationale: AKM Negotiation Execution cases: 1.Commitments match: succeed; confirm the agreement 2.Overlap is non-empty, but mismatched commitments 1.Discard the Open frame 2.Decide the temporary AKM—the MP with higher MAC has preference 3.The MP (or the MPs) with “wrong” AKM commitment may start over with a “right” list and commitment 3.Overlap is empty—NOAKM_RJCT Consistency of Negotiated AKM: A knows that B has reached the agreement of AKM for the instance, and vise versa –MIC protected Open proves “right” commitment of AKM –AKM is negotiated using the same rule –Protected Confirm frame—binding the negotiated AKM with the instance (R A, R B, and MIC)

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 22 Instance PMK Negotiation Security goal –Consistency of negotiated instance PMK Assumptions –Secrecy of PMKs: authenticate the peer MP –PMKs have expiry times Additional complication: Require premature commitment of PMK before successful negotiation –Used to prove possession of the key: Open frames are the replays at the best –Unprotected Open with disagreed security parameters: unnecessary tear down may be caused by simple forgery –Used to deliver GTK and achieve its consistency Approach: choose the one expires last in the overlap set

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 23 Rationale: Instance PMK Negotiation If committed to a PMK leading to disagreement –Case 1: No possible choice—NOKEY_RJCT –Case 2: Peer made a right choice—May fetch the key and initiate a new instance for the alternative choice Note: this suggest > 0 Abbreviated Handshake retries may yield better robustness, because the negotiation winner needs to retry Consistency of Negotiated PMK: A knows that B has reached the agreement of PMK for the instance, and vise versa –Open frames are MIC protected to prove that B knows the chosen PMK Forgeries can’t proceed beyond LISTEN –PMK lists are ordered the same way by A and B –PMK is negotiated using the same rule –Protected Confirm frame—binding the chosen PMK with the instance (R A, R B, and MIC)

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 24 References 11-07/1998r0, “Overview of Abbreviated Handshake Protocol” 11-07/2036r0, “Updates on Abreviated Handshake” 11-07/1999r1, “Abbreviated Handshake for Authenticated Peer Link Establishment”

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 25 Backup

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 26 System Model Two mesh points to establish a secure peer link A PMK shared between the two parties, assuming –PMK is ephemeral; has expiration time –Secrecy of PMK to the two parties –Sufficient entropy Each MP has local knowledge of –Identifier, e.g., MAC address –Nonce –AKM policy –Supported pairwise cipher suites, associated preference –Its GTK, associated KeyRSC, expiration time, and cipher suite –Shared PMKs, associated with expiration times Security session state –Unique session identifier <MAC A, MAC B, Nonce A, Nonce B ) –AKM, pairwise cipher suite, group cipher suite –PMK, KCK, KEK, TK –(GTK1, GTK2)

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 27 Update: GTK Wrapping Wrap GTK with the receiver’s MAC address Wrap GTK together with {Key RSC || ExpiryTime} We considered wrapping localNonce, but does not provide context binding since it might be replayed

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 28 Update: MIC Protection for Close frames Previous design choice: protect Close frames using TK –Uniform approach to protect Close frame before AND after peer link establishment –11w uses TK to protect management frames New design: protect Close frames using KCK –Uniform approach is important –Management frames for link management require authenticity –Other management frames require confidentiality –TK usage dilemma: Send Close when ciphersuite negotiation fails But TK is not available

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 29 Update: FSM NOKEY_RJCT event –LISTEN  IDLE At least on MP need to refresh the committed PMKs –OPN_SNT  HOLDING No Close frame is sent PMK negotiation may still succeed when receiving frames while in HOLDING state: send Close when negotiation succeeds NOAKM_RJCT event –LISTEN  IDLE –OPN_SNT  HOLDING No Close frame is sent AKM negotiation may still succeed when receiving frames whilein HOLDING state: send Close when PMK and AKM negotiation succeeds

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 30 Update: Parameter Negotiation Lists are not repeated in Confirm frames –Separate functionality provided by Open and Confirm –Open is used to commit to the choices of the parameter –Confirm is used to commit to the agreement of the parameter Negotiation using Confirm and/or Close is simplified Add text to negotiate AKM suite Future: –Prove security –Then, potential optimization

doc.: IEEE /2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 31 Update: Clarify Abbreviated Handshake Invocation Abbreviated Handshake is designed to replace MSA authentication that does not require initial authentication When expect to share a PMK with the peer, invoke Abbreviated Handshake Alternative: keep MSA Authentication and Abbreviated MSA Authentication