1 / 25

Updates on Abbreviated Handshake

Updates on Abbreviated Handshake. Date: 2007-09-19. Authors:. Abstract. This submission reports the progress we made on improving the Abbreviate Handshake protocol since July 2007 and on evaluating the protocol.

jill
Download Presentation

Updates on Abbreviated Handshake

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Updates on Abbreviated Handshake Date: 2007-09-19 Authors: Meiyuan Zhao, Intel Corp.

  2. Meiyuan Zhao, Intel Corp.

  3. Abstract This submission reports the progress we made on improving the Abbreviate Handshake protocol since July 2007 and on evaluating the protocol. Updated protocol specification and informative rationale explanation are in 11-07/1999r4. Meiyuan Zhao, Intel Corp.

  4. Agenda • Overview of Abbreviated Handshake • Updates on protocol design • Updates on normative text • Preliminary protocol analysis • Conclusion Meiyuan Zhao, Intel Corp.

  5. Peer Link and Security Handshake Peer Link Establishment Peer Link Establishment Abbreviated Security Handshake Authentication 4-Way Handshake 4-Way Handshake Meiyuan Zhao, Intel Corp.

  6. Peer Link and Security Handshake Peer Link Establishment Peer Link Open (…,RSNIE, MSAIE) Authentication Peer Link Confirm (…,RSNIE, MSAIE) 4-Way Handshake Meiyuan Zhao, Intel Corp.

  7. Development History • Under development while designing PLM protocol • Nov 06: made publicly available (11-06/1844r0) • Feb 07: Protocol requirements analysis (11-07/237r0) • Jun 07: Overview of the protocol and updates(11-07/1998r0) • Jun 07: Design updates (11-07/2036r0) • Jul 07: Design rationale analysis and updates (11-07/2176r0) • Protocol evolves based on comments and protocol analysis • We have been trying to stay synchronization Meiyuan Zhao, Intel Corp.

  8. Security Goals • 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 party but 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 Meiyuan Zhao, Intel Corp.

  9. System Model A B MACA RA LAKM-A LPMK-A LPC-A GCA GTKA MACB RB LAKM-B LPMK-B LPC-B GCB GTKB Meiyuan Zhao, Intel Corp.

  10. System Model A B <MACA, MACB, RA, RB> PMK→KCK, KEK, TK AKM Suite Pairwise Cipher Suite Group Cipher Suite GTKA, GTKB Mutual authentication Session Key Secrecy Consistency Meiyuan Zhao, Intel Corp.

  11. Design Evolution Basic peer link establishment (PLM) • Instance identifier agreement • Delivering the group keys • Deriving session keys • Session pairwise cipher suite selection • AKM suite selection • Instance PMK selection Abbreviated Handshake Informative text in T.8 in 11-07/1999r4 Meiyuan Zhao, Intel Corp.

  12. Summary of Updates • Updates on protocol design • Relaxation of GTK unwrapping rules • Updated AKM selection and key derivation function selection • Co-existence with MSA authentication • Updates on normative text • Text re-organization to achieve consistency with Draft 1.06. • Dedicated clauses specifying how to construct Peer Link Management frames • Rename keys and functions Abbreviated Handshake • KEK, KCK  AKEK, AKCK • “Negotiation”  “selection” • Miscellaneous minor changes Meiyuan Zhao, Intel Corp.

  13. Relaxation of Unwrapping GTK Rules • Received comment: it is not necessary to unwrap GTK immediately once receiving it via Peer Link Open frame • Rationale • Need to maintain consistency: A knows B correctly received GTKA A sent for the link instance, and vise versa • Actual key unwrapping performed within the link instance, but not necessary to take place before sending a Peer Link Confirm frame • Solution • Receiver sends back the same wrapped GTK to the sender • Sender verifies the consistency of the data • Key unwrapping failures triggers a link tear down Meiyuan Zhao, Intel Corp.

  14. Updated GTK Distribution • Example: Deliver GTKA Open(…, E(AKEK, GTKA || MACB || KeyRSCA || ExpireTime(GTKA)), …, MIC) B A Confirm(…, E(AKEK, GTKA || MACB || KeyRSCA || ExpireTime(GTKA)), …, MIC) • A verifies that B receives the same data that it sent • A knows that B acknowledged all necessary and correct material to unwrap GTKA • A verifies MIC on Confirm to verify confirmation comes from the node who knows AKEK and for the current link instance • If not, the link instance is torn down with reason code “MESH-MISMATCH-GTK” • B unwraps GTKA during the life time of the link instance • If operation fails, B sends Close to tear down the link Meiyuan Zhao, Intel Corp.

  15. KDF-AKM Inter-Dependency Problem • AKM suite selection should change key derivation to avoid key reuse attacks • AKCK || AKEK ← kdf(PMK, 0n || AKM-ID || min(MACA, MACB) || max(MACA, MACB)) • Problem • KDF belongs to AKM suite in 11i model • kdf(…, …AKM-ID…) • Separate key space required for different AKM suites • However introduces a loop • Solution • Separate KDF from AKM suites that support Abbreviated Handshake • Define KDF selector • Announce KDF selector in Peer Link Management frames • Selection algorithm: same as group cipher suite selection • Failures if announcements are different • Default kdf: specified in Clause 11A.4.3.6 Meiyuan Zhao, Intel Corp.

  16. Protocol Co-Existence • Received comment—Abbreviated Handshake should not be specified as the replacement for MSA authentication where initial authentication is executed. • Rationale • Valid concern. Even with the cached PMK-MAs, the MSA authentication may still be a good approach to establish the link in some cases • The security architecture should provide such flexibility • Solution • Allow co-existence under the MSA security framework Meiyuan Zhao, Intel Corp.

  17. Updates on Normative Text • Reflect updates on protocol design • Change word “negotiation/negotiate” to “selection/select” • Rename keys (AKEK, AKCK) • Added clauses to specify constructing Peer Link Management frames for Abbreviated Handshake • Eliminate references to FSM before clause 11A.4.3.10 • Text clean up Meiyuan Zhao, Intel Corp.

  18. Protocol Properties • We believe the current protocol design has achieved desirable protocol and security properties • Consistency property within the link instance • Mutual authentication • Session key secrecy • Bound failure variance • Support simultaneity in P2P environment • Verifiable parameter negotiation • Simplicity • Efficiency • Properties that haven’t been achieved • Consistency property across multiple link instances Meiyuan Zhao, Intel Corp.

  19. An Attack on PMK Selection Procedure A E B Open(A,B,…, {PMK1, …, PMKn}, PMK1, …MIC) • Reported by Steve Emeott and Tony Braskich (thanks guys!) • Protocol selects a different PMK when the adversary is present • But attacker still can’t get parties to use unauthorized keys • Not a violation of consistency within a link instance • However, cannot provide consistency property across sessions Open(B,A,…, {PMKe, PMKn}, PMKe, …MIC) Open(A,B,…, {PMKn}, PMKn, …MIC) Confirm(B,A,…, PMKn, …MIC) Meiyuan Zhao, Intel Corp.

  20. Attack Analysis • PMKn is still a valid key to be used for the session • Except it may has shorter remaining lifetime than that key parties would select without this attack • The impact is similar to DoS • AKM Suite Selection is vulnerable to the same attack • Since E doesn’t have a valid PMK to use, it cannot trick A to accept an AKM that B does not support • Many other protocols have the same problem (e.g., 802.11i 4-Way handshake,…) • We are working on solutions and considering options • Update the protocol to 6-message exchange if the first two fails • Do nothing, since the impact is no worse than DoS • Overall, we believe Abbreviated Handshake is a sound protocol • Historically, protocol designs are typically much less mature when first adopted by the standards Meiyuan Zhao, Intel Corp.

  21. Further Updates on Protocol Evaluation • Formal security proof • Phil Rogaway’s student Till Stegers has formulated a definition of mutual authentication for the P2P environment in the computational complexity model • Expect to quantify the amount of security we can get • We are working with Rogaway and Till towards a proof of mutual authentication security, but work is still on-going • Performance evaluation of PLM and Abbr HS • Have some preliminary results • Collaboration welcome • Other efforts to optimize Abbr HS in some execution scenarios (e.g., Doc.:11-07/2535r0) • We are happy to collaborate and work toward solutions that are acceptable by TGs Meiyuan Zhao, Intel Corp.

  22. Conclusions • Abbreviated Handshake protocol design has been improved based on received feedbacks • Working on more thorough protocol analysis • Ready for TGs to consider adoption of this proposal Meiyuan Zhao, Intel Corp.

  23. References • “Abbreviated Handshake for Authenticated Peer Link Establishment” (text, doc.:11-07/1999r4 ) • “Abbreviated Security Handshake” doc.:11-06/1844r0 • “PLE Protocol Requirements” doc.:11-07/0237r0 • “Overview of Abbreviated Handshake Protocol” doc.:11-07/1998r0 • “Updates on Abbreviated Handshake” doc.:11-07/2036r0 • “Abbreviated Handshake Updates and Design Rationale” doc.:11-07/2176r0 Meiyuan Zhao, Intel Corp.

  24. Backup Meiyuan Zhao, Intel Corp.

  25. 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 Meiyuan Zhao, Intel Corp.

More Related