1. Updates on Abbreviated Handshake
June 2007
Updates on Abbreviated Handshake
Date:
Authors:
Meiyuan Zhao, Intel Corp.

2. June 2007
Abstract
This submission summarize the Abbreviated Handshake protocol and the updates on the protocol design, specified in 11-07/1999r0. Details of the original design are presented in 11-07/1998r0.
Meiyuan Zhao, Intel Corp.

3. 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.

4. 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.

5. Major Functions in Abbreviated Handshake
June 2007
Major Functions in Abbreviated Handshake A B
Security Capability Negotiation
PMK Negotiation
Group Key Distribution
Open(ANonce, PMKInfo, Cipher Suite Info, GTK1, MIC)
Open(BNonce, PMKInfo, Cipher Suite Info, GTK2, MIC)
Key Derivation Algorithm
Confirm(BNonce, ANonce, PMKInfo, Cipher Suite Info, GTK1, MIC)
Confirm(ANonce, BNonce, PMKInfo, Cipher Suite Info, GTK2, MIC)
Meiyuan Zhao, Intel Corp.

6. Major Functional Components
June 2007
Major Functional Components
PMK Usage Negotiation
MP has a list of PMK-MAs that it shares with a peer MP
Decide the one PMK to use based on both lists
Prove possession of the key
Security Capability Negotiation
AKM shall be “Mesh Abbreviated Handshake”
Agree on the group cipher suite
Negotiate a pairwise cipher suite from two lists
GTK distribution
GTKs are distributed using Abbreviated Handshake
Confirm successful delivery for the link instance
Key Derivation Algorithms
KCK and KEK are ready early for frame protection and GTK distribution
KCK and KEK are not depend upon the nonces
Meiyuan Zhao, Intel Corp.

7. June 2007
Current Status
Overview of Abbreviated Handshake was presented in 11-07/1998r0 during Hillsboro ad hoc meeting
Detailed protocol specified in 11-07/1999r0
Updates since ad hoc meeting
GTK wrapping and distribution
Peer Link Close protection
Misc: changes in frame formats and FSM
Meiyuan Zhao, Intel Corp.

8. Group Key Distribution (Updated)
June 2007
Group Key Distribution (Updated)
Received comment: is it critical to delivery GTK using Abbreviated Handshake?
GTK considered a part of security states for the link instance
802.11i: failure of GTK distribution leads to de-authentication the STA
802.11i: first GTK distribution included in 4-Way HS
Include GTK delivery in Abbreviated Handshake
Bind security states
Avoid race conditions caused by key distribution and key usage
When the protocol completes, each MP knows that the sent GTK is installed by the peer MP correctly
Additional advantages
Efficiency: 4 messages vs. 8 messages
Meiyuan Zhao, Intel Corp.

9. Group Key Distribution (Updated)
June 2007
Group Key Distribution (Updated)
Received comment: Is it useful to wrap localNonce with GTK to defend against mismatch attacks?
Respond: NO. If the attacker can insert a mismatched GTK, it can certainly insert the corresponding localNonce in the same frame
Updated solution
Sender wrap {GTK||localNonce||peerMAC} to specify the context of GTK distribution
localNonce as the identifier of the instance
peerMAC as the MAC address of the intended receiver
Receiver
Unwrap the GTK
Verify the context
Confirm GTK by sending H({GTK||localNonce||peerNonce||localMAC||peerMAC})
Note: not specified in 11-07/1999r0
Meiyuan Zhao, Intel Corp.

10. June 2007
Updated Key Usage
Original design: all peer link mangement frames are protected by MIC computed by KCK
Update: Protection of Peer Link Close is provided by TK, instead of KCK
Rationale
TK is ready when Peer Link Close is sent
Management frame protection by 11w uses TK
Advantages
No need to distinguish Peer Link Close frames sent before/after peer link establishment
Unify two key derivation approaches for pairwise key hierarchy
Meiyuan Zhao, Intel Corp.

11. References 11-07/1998r0, “Overview of Abbreviated Handshake Protocol”
June 2007
References
11-07/1998r0, “Overview of Abbreviated Handshake Protocol”
11-07/1999r0, “Abbreviated Handshake for Authenticated Peer Link Establishment”
Meiyuan Zhao, Intel Corp.

12. June 2007
Backup
Meiyuan Zhao, Intel Corp.

13. Additional Contents of Frames (Updated)
June 2007
Additional Contents of Frames (Updated)
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,
PMKID List
Chosen PMK,
“Mesh Abbreviated Handshake”,
Pairwise Cipher Suite List
Chosen Pairwise Cipher Suite,
GTK
MIC
Peer Link Close
localNonce,
peerNonce,
“Mesh Abbreviated Handshake”,
Chosen PMK,
MIC
Meiyuan Zhao, Intel Corp.

14. Changes to Finite State Machine (Updated)
June 2007
Changes to Finite State Machine (Updated)
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)
New event: TOR3
RetryTimer timeout, reach MAX-RETRIES, but no PMK negotiated
Should close the instance directly
Meiyuan Zhao, Intel Corp.

15. 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
Should 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.

16. 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/Confirm, 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.

17. PMK Negotiation Cases Case 1 Case 2 Case 3 Case 4 June 2007 A B A B A
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 may start a new FSM using “y”
Peer Link Open (…, {y, z}, y, …)
Peer Link Open (…, {x, y, z}, x, …)
Both may start a new FSM using “y” A B
Peer Link Open (…, {p, y, z}, p…)
Peer Link Open (…, {x, y, z}, x, …)
A and B negotiate the next step:
A/B to fetch a key
Execute initial authentication A B
Peer Link Open (…, {p}, p, …)
Meiyuan Zhao, Intel Corp.

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

19. 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.

20. MSA adopted 802.11i Pairwise Key Hierarchy
June 2007
MSA adopted i Pairwise Key Hierarchy
Pairwise Master Key (PMK) : 256 bit Access token
Pairwise Transient Key (PTK) = i-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))
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.

21. New Key Derivation Motivations
June 2007
New Key Derivation Motivations
Motivations:
All Peer Link Management frames should be protected
Otherwise, subject to forgery, flooding, and MITM attacks
Authenticated PMK negotiation
Demonstrate key possession: use the key
GTK distribution
Send GTK in Open, confirm distribution in Confirm
Conclusion: Need KCK and KEK ready whenever sending a Peer Link Management frame, especially for Peer Link Open frames
Meiyuan Zhao, Intel Corp.

22. 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.

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29. 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.

30. 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.

31. 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.

32. 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.

33. 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.

34. 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.