Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.: IEEE 802.11-07/2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 1 Protocol Analysis of Abbreviated Handshake Date: 2007-07-11 Authors:

Published byRaymond Gilbert Modified over 8 years ago

Similar presentations

Presentation on theme: "Doc.: IEEE 802.11-07/2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 1 Protocol Analysis of Abbreviated Handshake Date: 2007-07-11 Authors:"— Presentation transcript:

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

2 doc.: IEEE 802.11-07/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.

3 doc.: IEEE 802.11-07/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

4 doc.: IEEE 802.11-07/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)

5 doc.: IEEE 802.11-07/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

6 doc.: IEEE 802.11-07/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

7 doc.: IEEE 802.11-07/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

8 doc.: IEEE 802.11-07/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

9 doc.: IEEE 802.11-07/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

10 doc.: IEEE 802.11-07/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

11 doc.: IEEE 802.11-07/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

12 doc.: IEEE 802.11-07/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

13 doc.: IEEE 802.11-07/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 )

14 doc.: IEEE 802.11-07/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.

15 doc.: IEEE 802.11-07/2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 15 GTK Belongs to Security Session State GTK delivery in 802.11i –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

16 doc.: IEEE 802.11-07/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 ))

17 doc.: IEEE 802.11-07/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

18 doc.: IEEE 802.11-07/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

19 doc.: IEEE 802.11-07/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

20 doc.: IEEE 802.11-07/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 )))

21 doc.: IEEE 802.11-07/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)

22 doc.: IEEE 802.11-07/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

23 doc.: IEEE 802.11-07/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)

24 doc.: IEEE 802.11-07/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”

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

26 doc.: IEEE 802.11-07/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)

27 doc.: IEEE 802.11-07/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

28 doc.: IEEE 802.11-07/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

29 doc.: IEEE 802.11-07/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

30 doc.: IEEE 802.11-07/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

31 doc.: IEEE 802.11-07/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

Download ppt "Doc.: IEEE 802.11-07/2176r0 Submission July 2007 Meiyuan Zhao, Intel Corp.Slide 1 Protocol Analysis of Abbreviated Handshake Date: 2007-07-11 Authors:"

Similar presentations

Doc.: IEEE 802.11-04/1186r0 Submission October 2004 Aboba and HarkinsSlide 1 PEKM (Post-EAP Key Management Protocol) Bernard Aboba, Microsoft Dan Harkins,

Doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 1 PEKM (Post-EAP Key Management Protocol) Bernard Aboba, Microsoft Dan Harkins,
Doc.: IEEE 802.11-08/1263r0 Submission November 2008 Dan Harkins, Aruba NetworksSlide 1 A Modest Proposal…. Date: 2008-11-10 Authors:

Doc.: IEEE /1263r0 Submission November 2008 Dan Harkins, Aruba NetworksSlide 1 A Modest Proposal…. Date: Authors:
Doc.: IEEE 802.11-08/0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 1 Changes to SAE State Machine Date: 2008-07-13 Authors:

Doc.: IEEE /0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 1 Changes to SAE State Machine Date: Authors:
CMSC 414 Computer (and Network) Security Lecture 22 Jonathan Katz.

CMSC 414 Computer (and Network) Security Lecture 22 Jonathan Katz.
Doc.: IEEE 802.11-08-0317r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 1 Authentication and Key Management of MP with multiple radios Date:

Doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 1 Authentication and Key Management of MP with multiple radios Date:
Doc.: IEEE 802.11-09/0283r0 Submission March 2009 Dan Harkins, Aruba NetworksSlide 1 Suggested Changes to the Abbreviated Handshake Date: 2009-03-08 Authors:

Doc.: IEEE /0283r0 Submission March 2009 Dan Harkins, Aruba NetworksSlide 1 Suggested Changes to the Abbreviated Handshake Date: Authors:
SSL CS772 Fall 2011. Secure Socket layer Design Goals: SSLv2) SSL should work well with the main web protocols such as HTTP. Confidentiality is the top.

SSL CS772 Fall Secure Socket layer Design Goals: SSLv2) SSL should work well with the main web protocols such as HTTP. Confidentiality is the top.
IEEE 802.11i IT443 Broadband Communications Philip MacCabe October 5, 2005

IEEE i IT443 Broadband Communications Philip MacCabe October 5, 2005
Analysis and Improvements over DoS Attacks against IEEE 802.11i Standard Networks Security, Wireless Communications and Trusted Computing(NSWCTC), 2010.

Analysis and Improvements over DoS Attacks against IEEE i Standard Networks Security, Wireless Communications and Trusted Computing(NSWCTC), 2010.
Wireless Security Ryan Hayles Jonathan Hawes. Introduction  WEP –Protocol Basics –Vulnerability –Attacks –Video  WPA –Overview –Key Hierarchy –Encryption/Decryption.

Wireless Security Ryan Hayles Jonathan Hawes. Introduction  WEP –Protocol Basics –Vulnerability –Attacks –Video  WPA –Overview –Key Hierarchy –Encryption/Decryption.
Semester 4 - Chapter 4 – PPP WAN connections are controlled by protocols In a LAN environment, in order to move data between any two nodes or routers two.

Semester 4 - Chapter 4 – PPP WAN connections are controlled by protocols In a LAN environment, in order to move data between any two nodes or routers two.
CSE331: Introduction to Networks and Security Lecture 24 Fall 2002.

CSE331: Introduction to Networks and Security Lecture 24 Fall 2002.
CMSC 414 Computer and Network Security Lecture 13 Jonathan Katz.

CMSC 414 Computer and Network Security Lecture 13 Jonathan Katz.
Lecture 14 ISAKMP / IKE Internet Security Association and Key Management Protocol / Internet Key Exchange CIS 4362 - CIS 5357 Network Security.

Lecture 14 ISAKMP / IKE Internet Security Association and Key Management Protocol / Internet Key Exchange CIS CIS 5357 Network Security.
Doc.: IEEE 802.11-04/0476r3 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 1 Pre-Keying Jesse Walker and Emily Qi Intel Corporation.

Doc.: IEEE /0476r3 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 1 Pre-Keying Jesse Walker and Emily Qi Intel Corporation.
Doc.: IEEE 802.11-11/1429r2 Submission January 2012 Dan Harkins, Aruba NetworksSlide 1 A Protocol for FILS Authentication Date: 2012-01-09 Authors:

Doc.: IEEE /1429r2 Submission January 2012 Dan Harkins, Aruba NetworksSlide 1 A Protocol for FILS Authentication Date: Authors:
Doc.: IEEE 802.11-04/0476r2 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 1 Pre-Keying Jesse Walker and Emily Qi Intel Corporation.

Doc.: IEEE /0476r2 Submission May 2004 Jesse Walker and Emily Qi, Intel CorporationSlide 1 Pre-Keying Jesse Walker and Emily Qi Intel Corporation.
Wireless LAN Security. Security Basics Three basic tools – Hash function. SHA-1, SHA-2, MD5… – Block Cipher. AES, RC4,… – Public key / Private key. RSA.

Wireless LAN Security. Security Basics Three basic tools – Hash function. SHA-1, SHA-2, MD5… – Block Cipher. AES, RC4,… – Public key / Private key. RSA.
Doc.: IEEE 802.11-01/495r1 Submission July 2001 Jon Edney, NokiaSlide 1 Ad-Hoc Group Requirements Report Group met twice - total 5 hours Group size ranged.

Doc.: IEEE /495r1 Submission July 2001 Jon Edney, NokiaSlide 1 Ad-Hoc Group Requirements Report Group met twice - total 5 hours Group size ranged.
Lecture 16: Security CDK4: Chapter 7 CDK5: Chapter 11 TvS: Chapter 9.

Lecture 16: Security CDK4: Chapter 7 CDK5: Chapter 11 TvS: Chapter 9.

Similar presentations

Ads by Google