Overview of Abbreviated Handshake Protocol June 2007 Overview of Abbreviated Handshake Protocol Date: 2007-06-14 Authors: Meiyuan Zhao, Intel Corp, et al.

June 2007 Abstract This submission summarizes the design of Abbreviated Handshake protocol and the rationale. The Abbreviated Handshake protocol proposes to resolve LB93 comments CIDs 735, 1057, 4763, 4764, and partially resolves CID 4761. Meiyuan Zhao, Intel Corp, et al.

Agenda Protocol Overview Major algorithms and design rationale June 2007 Agenda Protocol Overview Major algorithms and design rationale PMK negotiation Security capability negotiation Key derivation Group key wrapping Meiyuan Zhao, Intel Corp, et al.

Peer Link and Security Handshake June 2007 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, et al.

Peer Link and Security Handshake June 2007 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, et al.

Proposed Abbreviated Security Handshake June 2007 Proposed Abbreviated Security Handshake A B Security Capability Negotiation PMK Usage Negotiation Using Derived Keys Open(ANonce, PMKInfo, Cipher Suite Info, GTK1, MIC) Open(BNonce, PMKInfo, Cipher Suite Info, GTK2, MIC) Confirm(BNonce, ANonce, PMKInfo, Cipher Suite Info, MIC) Confirm(ANonce, BNonce, PMKInfo, Cipher Suite Info, MIC) Meiyuan Zhao, Intel Corp, et al.

Major Functional Components June 2007 Major Functional Components PMK Usage Negotiation Both MPs have established their EMSA key hierarchies Decide the one PMK to use based on local cache information Pairwise Cipher Suite Negotiation AKM shall be “Mesh Abbreviated Handshake” Agree on the group cipher suite Negotiate a pairwise cipher suite from two lists Key Derivation Algorithms Information in Peer Link Open has to be protected Relevant keys should be ready when sending Peer Link Open frames Some keys may not depend upon the nonces Meiyuan Zhao, Intel Corp, et al.

Requirements for PMK Usage Negotiation June 2007 Requirements for PMK Usage Negotiation Negotiate a PMK from two announced lists Due to dynamic network conditions A MP may Authenticate with AAA server multiple times It may have a different valid PMK list from what MKD has The peer MP may also have a different valid PMK list from what MKD or the MP has The MP may have more than two choices Use the chosen PMK to prove possession of the chosen PMK Chosen PMK shall be confirmed by both MPs Performance requirements Efficiency Speed: Completed using at most two messages Resource: Only execute key transport protocol when necessary Minimize the impact by DoS attacks Protocol always succeeds if a shared PMK exists Avoid unnecessary key transport protocol executions Meiyuan Zhao, Intel Corp, et al.

PMK Usage Negotiation Algorithm June 2007 PMK Usage Negotiation Algorithm MP announces the supported PMK-MAs using an ordered list Primary ordering criterion: expiry time (expires last ordered first) Both MPs have the same ordering of the cached PMK-MAs Default choice: first PMK-MA on the list Compute MIC to prove possession of the key Once receive the Open, compare the choices and the lists If one MP initiates the PLM Succeed if responder supports the chosen PMK-MA If both MP initiate the PLM simultaneously Succeed if the chosen PMK-MAs match On negotiation failure, one or both MP may Choose a different PMK-MA and try again Execute the key transport protocol to get a key and try again Fall back to initial handshak Meiyuan Zhao, Intel Corp, et al.

PMK Negotiation Cases Case 1 Case 2 Case 3 Case 4 June 2007 A B A B Peer Link Open (…, {x, y, z}, x, …) A B Peer Link Open (…, {x, a, z}, x, …) Peer Link Open (…, {x, y, z}, x, …) A B B wins A starts over Peer Link Open (…, {y, z}, y, …) Peer Link Open (…, {x, y, z}, x, …) A B Both start over Peer Link Open (…, {p, y, z}, p…) Peer Link Open (…, {x, y, z}, x, …) A B Both start over Peer Link Open (…, {p}, p, …) Meiyuan Zhao, Intel Corp, et al.

Pairwise Cipher Suite Negotiation June 2007 Pairwise Cipher Suite Negotiation MPs announce the supported pairwise cipher suites in Open using a priority list If no overlay, negotiation fails If overlap exists, selector MP’s preferred cipher wins Both MP should confirm the negotiated cipher suite in Confirm frames Terminology: Selector MP (MMP): the MP with higher MAC address Meiyuan Zhao, Intel Corp, et al.

Pairwise Cipher Suite Negotiation (2) June 2007 Pairwise Cipher Suite Negotiation (2) Peer Link Open(…, LA, …) A B Peer Link Open (…, LB, …) Peer Link Confirm (…, C, …) Peer Link Confirm(…, C, …) Higher MAC address Advantage Verifiable negotiation done within 4 messages Negotiation does not rely on beacon/probe response Meiyuan Zhao, Intel Corp, et al.

MSA adopted 802.11i Pairwise Key Hierarchy June 2007 MSA adopted 802.11i Pairwise Key Hierarchy Pairwise Master Key (PMK) : 256 bit Access token Pairwise Transient Key (PTK) = 802.11i-PRF(PMK, min(AP Nonce, STA Nonce) || max(AP nonce, STA Nonce) || min(AP MAC Addr, STA MC Addr) || max(AP MAC Addr, STA MAC Addr)) Analog of the WEP key Key Confirmation Key (KCK) – PTK bits 0–127 Key Encryption Key (KEK) – PTK bits 128–255 Temporal Key – PTK bits 256–n – can have cipher suite specific structure Meiyuan Zhao, Intel Corp, et al.

Motivation for an Updated Key Derivation Algorithm June 2007 Motivation for an Updated Key Derivation Algorithm Peer Link Open frames need protection Security capability negotiation needs protection Correct MIC proves the possession of the chosen PMK GTK distribution should be confirmed When the link established, the MP knows the peer MP receives its GTK correctly Only send encrypted broadcast traffic after then Send GTK in the Peer Link Open frame Peer Link Confirm frame is used as delivery confirmation Need KCK and KEK ready when sending Peer Link Open frame Meiyuan Zhao, Intel Corp, et al.

New Key Derivation Algorithm June 2007 New Key Derivation Algorithm PMK-MA 0x00 localNonce peerNonce temporal key KCK KEK TK  PRF-X(PMK-MA , Max(localNonce, peerNonce) || Min(localNonce, peerNonce) || Max(localMAC, peerMAC) || Min(localMAC, peerMAC)) KEK || KCK  PRF-256(PMK-MA, 0512 || Max(localMAC, peerMAC) || Min(localMAC, peerMAC)) Meiyuan Zhao, Intel Corp, et al.

Key Derivation Analysis June 2007 Key Derivation Analysis KCK can be static to PMK-MA The freshness of the communication is proved by the repetition of random nonce from the received message The MIC is used only for message integrity and proving the possession of the key KEK can be static to PMK-MA Security of GTK wrapping is provided by authenticated encryption algorithm* Freshness of the temporal key is guaranteed by the localNonce and peerNonce Advantage KCK and KEK are generated only once for each PMK-MA AES counter mode is directly applicable to the key derivation function Assumption: A good PMK * P. Rogaway and T. Shrimpton, “Deterministic Authenticated-Encryption: A Provable-Security Treatment of the Key-Wrap Problem”, Eurocrypt 2006. Meiyuan Zhao, Intel Corp, et al.

Cut-and-Paste Attack to GTK Delivery June 2007 Cut-and-Paste Attack to GTK Delivery KEK is static  simple GTK wrapping fails to bind the delivered GTK with Peer Link Open frame in the instance Solution Sender wrap “GTK||localNonce” Receiver unwrap “GTK||localNonce” Verify localNonce Extract GTK Meiyuan Zhao, Intel Corp, et al.

Content of Updated Frames June 2007 Content of Updated Frames Peer Link Open localNonce, PMKID List, Chosen PMK, “Mesh Abbreviated Handshake”, Pairwise Cipher Suite List, Group Cipher Suite, GTK, MIC Peer Link Confirm localNonce, peerNonce, Chosen PMK, “Mesh Abbreviated Handshake”, Chosen Pairwise Cipher Suite, MIC Peer Link Close localNonce, peerNonce, Chosen PMK, “Mesh Abbreviated Handshake”, MIC Meiyuan Zhao, Intel Corp, et al.

Changes to Finite State Machine June 2007 Changes to Finite State Machine Close the session, when PMK negotiation fails Discard the frame if MIC verification fails Close the session, when security capability negotiation fails Close the session, when GTK unwrapping fails Close the session, if security parameters are inconsistent between Open and Confirm frames (but the MIC validation succeeds) Meiyuan Zhao, Intel Corp, et al.

June 2007 Next Steps Proposed normative text will be available tomorrow for review Welcome feedbacks and discussions Security proof of the protocol over the summer Proof model Prove secure, or Fix design flaws, and prove secure, or Not securable Meiyuan Zhao, Intel Corp, et al.

June 2007 Backup Meiyuan Zhao, Intel Corp, et al.

Protocol Requirements June 2007 Protocol Requirements (At least) 3 Classes of Requirements exist: Security requirements Functional requirements Performance requirements Security Requirements Achieve the consistency property both parties must agree on the protocol state, or else the protocol should fail Man-in-the-middle attacks are possible if this is violated Special case 1: Achieve the matching conversation property Both parties demonstrably send and receive the same messages Essential for mutual authentication Provable security impossible without it Alternatives: use the Client/Server model or introduce more messages Meiyuan Zhao, Intel Corp, et al.

Protocol Requirements June 2007 Protocol Requirements Security Requirements (Continued) Special case 2: Bind a fresh security context to the link instance Establish a (statistically) unique instance (session) identifier Demonstrate peer liveness (special case of consistency property) Guarantee a fresh session key and bind it to the communicating MPs Synchronize session key use Make messages fully meaningful within the security context The instance security context should be sufficient to make a message meaningful Messages with incomplete information ignored Maintain secrecy of the link instance key to the communicating MPs Meiyuan Zhao, Intel Corp, et al.

Protocol Requirements June 2007 Protocol Requirements Functional requirements Handle simultaneity Either party should be able to initiate a new link instance at any time Verifiable parameter negotiation Protect discovery and negotiation from Downgrade attack Unverifiable parameters enable man-in-the-middle attacks, and slow recovery from protocol failures Simplicity Utilize local resource whenever possible; Invoke external protocol only when it’s necessary Performance requirements Efficiency Use as few messages as possible Minimize communication overhead Failure cases should not impose undue delay Meiyuan Zhao, Intel Corp, et al.

Design features meet requirements June 2007 At this point in our analysis, we believe the proposal satisfies all protocol requirements for secure peer link maintenance Security Requirements Achieve the consistency property Both MPs reaches established state when both send and receive (process) both peer link open and confirm messages When the link is established, both MPs agree on protocol states, or there’s no security Both MPs agree on the same Group Cipher Suite Both MPs agree on the same Pairwise Cipher Suite Both MPs agree on the PMK-MA to be used for key management Both MPs agree on Mesh Capability configuration parameters Both MPs derive the same session key Both MPs receive the confirm that the peer MP has installed the GTK correctly Meiyuan Zhao, Intel Corp, et al.

Design features meet requirements – cont. June 2007 Design features meet requirements – cont. Security Requirements Achieve the matching conversation property Sent messages by MP A matches received messages by MP B We don’t have the proof yet It’s the prerequisite to provable security Bind a fresh security context to the link instance Protocol establishes (statistically) unique security context for the link localNonce and peerNonce contribute to a (statistically) unique instance identifier Session key is freshly generated using localNonce and peerNonce Confirm messages contains peerNonce received in an earlier Open message – demonstrate liveness of peer MP Open messages are protected by MIC demonstrate the possession of the PMK by the peer MP Defend against man-in-the-middle attack; bind session key to the communicating MPs All keys are properly installed when transitioning to established state Knows when the GTK is installed by the peer MP; therefore when to start using the GTK GTK is wrapped with localNonce to defend against cut-and-paste attack Meiyuan Zhao, Intel Corp, et al.

Design features meet requirements – cont. June 2007 Design features meet requirements – cont. Security Requirements The design maintains the session key as a secret between the peers only Messages are fully meaningful to the security context Open messages are protected by MIC computed using KCK derived from the decided PMK in the context Confirm messages are protected by MIC, and specifies localNonce and peerNonce in the context Close messages are protected by the MIC, and specifies localNonce and peerNonce in the context MIC computation specifies the message sending direction – against reflection attack Messages with incorrect MIC are ignored – they are considered as forgery Messages with incomplete info can’t be interpreted correctly – they don’t belong to the security context and should be ignored Meiyuan Zhao, Intel Corp, et al.

Design features meet requirements – cont. June 2007 Design features meet requirements – cont. Functional Requirements Handle simultaneity Both parties can initiate the protocol No pre-determined roles Verifiable security parameter negotiation Both MPs verify that announced pairwise cipher suite list is used for policy negotiation Changes of parameters (from beacon/probe response) are made by authentic peer MP – messages are all MIC-protected Meiyuan Zhao, Intel Corp, et al.

Design features meet requirements – cont. June 2007 Design features meet requirements – cont. Functional Requirements Simplicity Whenever there is a shared PMK, the MPs can use it No need to execute extra protocol No need to switch roles (roles are not defined; they are only for client/server model) Complexity is only necessary when it comes tie-breaking Execute key transport protocol or authentication protocol only when there’s no shared PMK available No need to enforce repetition of info in RSNIE or MKDDIE; changed info are protected by MIC Meiyuan Zhao, Intel Corp, et al.

Design features meet requirements – cont. June 2007 Design features meet requirements – cont. Performance Requirements Efficiency Protocol initiation is not delayed by the beacons / probe responses Establish the secure link using 4 messages Messages only repeat info when it’s necessary No addition protocols are invoked unless it’s necessary Only generate and send meaningful messages in the security context (messages with incomplete info are ignored) Failure cases do not impose undue delay All parameters are verified, so failure to deliver a message does not cause one end to wait indefinitely after the other peer has decided the protocol has completed successfully Meiyuan Zhao, Intel Corp, et al.

Instance Identifier in Abbreviated Handshake June 2007 Instance Identifier in Abbreviated Handshake <max(localMAC, peerMAC), min(localMAC, peerMAC), max(localNonce||localLinkID, peerNonce||peerLinkID), max(localNonce||localLinkID, peerNonce||peerLinkID)> In the MSA initial authentication, the instance identifier may be updated Meiyuan Zhao, Intel Corp, et al.

Detail: MIC Computation June 2007 Detail: MIC Computation What if A reflect a message sent by B to A earlier? Message should provide some information indicating direction of the message Solution: MIC = HMAC(KCK, senderMAC||receiverMAC||contents) Meiyuan Zhao, Intel Corp, et al.