1. Secure Peer Link Establishment (Abbreviated Security Handshake)
November 2006
Secure Peer Link Establishment (Abbreviated Security Handshake)
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Meiyuan Zhao, Intel Corp, et al.

2. November 2006
Abstract
This presentation describes an ongoing work on abbreviated security handshake. The protocol improves the performance of setting up a secure peer link when a cached PMK is used.
We welcome comments, suggestions, and collaborations to improve the protocol.
Meiyuan Zhao, Intel Corp, et al.

3. Agenda Problem statement Previous protocols Proposed protocol
November 2006
Agenda
Problem statement
Previous protocols
Proposed protocol
Meiyuan Zhao, Intel Corp, et al.

4. Secure Peer Link Establishment Requirements
November 2006
Secure Peer Link Establishment Requirements
Mesh network formation and operation requires continuous discovery and link set-up/teardown
Teardown is often unwanted and forced by the environment
Discovery only delivers “candidate peers”
Bounded link establishment variance
Deal with failure cases
Rapid convergence
Achieve security in peer-to-peer environment
Key freshness, binding, and synchronization
Protect the Discovery and Negotiation from the downgrade attacks
Link establishment need to be reliable
Streaming applications like voice and video are broken by long “re-connection” timings
Handle peer-to-peer communication
Handle unreliable transmission
Robust again race conditions
Meiyuan Zhao, Intel Corp, et al.

5. Process of Establishing a Secure Peer Link in EMSA-LE proposal
November 2006
Process of Establishing a Secure Peer Link in EMSA-LE proposal
Initial Handshake
Subsequent Handshake
Peer Link Establishment
Peer Link Establishment
Authentication &
Key Hierarchy Generation
Key Transport Pull Protocol
Key Management
Key Management
Mesh Authenticator
Handshake
Meiyuan Zhao, Intel Corp, et al.

6. Subsequent EMSA Handshake
November 2006
Subsequent EMSA Handshake
Peer Link Open A B
Peer Link Open
Peer Link Confirm
Peer Link Confirm
4-Way Handshake Message 1
4-Way Handshake Message 2
4-Way Handshake Message 3
4-Way Handshake Message 4
Meiyuan Zhao, Intel Corp, et al.

7. Design Issues Opportunity Challenges
November 2006
Design Issues
Opportunity
Overlay security handshake with the basic peer link establishment protocol
Better efficiency—less than 8 messages to establish a secure peer link between MPs
Challenges
Design a most efficient protocol
Maintain the robustness of peer link establishment
Maintain the security of peer MP authentication and key management
Meiyuan Zhao, Intel Corp, et al.

8. Abbreviated Security Handshake Requirements
November 2006
Abbreviated Security Handshake Requirements
Handle peer-to-peer situations
Allow either or both peers initiate the protocol
Handle out-of-order messages
Guarantee liveness of peers
Handle race conditions
Guarantee security of key management
A secure peer link
Both peers have sent and received both Open and Confirm messages
The security policy is correctly negotiated
The session key is freshly generated and has a (statiscally) unique identifier: <A, B, ANonce, BNonce>
The GTKs are securely distributed and the delivery is confirmed
The key usage is synchronized
Handshake messages are protected by MIC
Meiyuan Zhao, Intel Corp, et al.

9. November 2006
Peer Link Messages
Peer Link Open(myId, peerId, ANonce, PMK, Ciphersuite, GTK, MIC)
Peer Link Confirm(myId, peerId, ANonce, BNonce, PMK, Ciphersuite, GTK, MIC)
Peer Link Close(myId, peerId, ANonce, BNonce, MIC)
Meiyuan Zhao, Intel Corp, et al.

10. Proposed Abbreviated Security Handshake
November 2006
Proposed Abbreviated Security Handshake
Beacon/Probe Response A
Beacon/Probe Response B
Cipher Suite 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, GTK2, MIC)
Confirm(ANonce, BNonce, PMKInfo, Cipher Suite Info, GTK1, MIC)
Meiyuan Zhao, Intel Corp, et al.

11. Major Function Components
November 2006
Major Function Components
PMK Usage Negotiation
Both MPs have established their EMSA key hierarchies
Decide the one PMK to use based on local cache information
Key transport protocol may be executed
Pairwise Cipher Suite Negotiation
Decide the pairwise cipher suite supported by both MPs
Key Derivation Algorithms
Information in Peer Link Open has to be protected
Relevant keys should be ready when sending Peer Link Open message
Some keys may not depend upon the nonces
Meiyuan Zhao, Intel Corp, et al.

12. PMK Usage Negotiation (1)
November 2006
PMK Usage Negotiation (1)
PMK Negotiation is needed
Both MPs have their own key hierarchy
Both, one, or neither of them has the peer MP’s PMK-MA
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.

13. PMK Usage Negotiation (2)
November 2006
PMK Usage Negotiation (2)
MPs announce their PMK-MKDName in the beacons and probe responses
Rule: Try the peer MP’s PMK-MA
Peer Link Open message contains the corresponding PMK-MAName
MIC is computed to prove the knowledge of the chosen PMK
KCK is derived from the chosen PMK-MA
Peer Link Open(…, PMK-MAName1, …) A B
Peer Link Open (…, PMK-MAName2, …)
Meiyuan Zhao, Intel Corp, et al.

14. PMK Negotiation Cases Case 1 Case 2 Case 3 November 2006 A B A B A B ?
Peer Link Open (…, PMKA, …) ? A B ?
Peer Link Open (…, PMKB, …)
Peer Link Open (…, PMKB, …)
PMKB A B ?
Peer Link Open (…, PMKB, …)
Peer Link Open (…, PMKB, …)
PMKB A B
PMKA
Peer Link Open (…, PMKA, …)
Peer Link Open (…, PMKA, …)
Higher MAC address
Meiyuan Zhao, Intel Corp, et al.

15. Pairwise Cipher Suite Negotiation (1)
November 2006
Pairwise Cipher Suite Negotiation (1)
MPs announce the supported pairwise cipher suites in beacons and probe responses
The master MP makes the choice (if more than one choices available)
Both MP should confirm the pairwise cipher suite list heard from the peer MP
Protect against RSN IE forgery attack
Default definitions:
Master MP (MMP): the MP with higher MAC address
Slave MP (SMP): the MP with lower MAC address
Meiyuan Zhao, Intel Corp, et al.

16. Pairwise Cipher Suite Negotiation (2)
November 2006
Pairwise Cipher Suite Negotiation (2) A B
Peer Link Open(…, C, LLA, PLA, …)
Peer Link Open (…, _, LLB, PLB, …)
Peer Link Confirm (…, C, LLB, PLB, …)
Peer Link Confirm(…, C, LLA, PLA, …)
The protocol proceeds iff
Meiyuan Zhao, Intel Corp, et al.

17. Motivation for an Updated Key Derivation Algorithm
November 2006
Motivation for an Updated Key Derivation Algorithm
Peer Link Open messages need protection
It is used for PMK negotiation
It is used for Security Policy negotiation (prevent the discovery and negotiation from downgrade attack)
GTK delivery should be confirmed
Only send encrypted broadcast traffic after the MP has received a confirm that the GTK is delivered to the neighbor MP
Send GTK in the Peer Link Open message
Peer Link Confirm message is used as delivery confirmation
Against replay attack: GTK is sent in both Open and Confirm messages
Need KCK and KEK ready when sending Peer Link Open message
Meiyuan Zhao, Intel Corp, et al.

18. Peer Link Key Derivation
November 2006
Peer Link Key Derivation
PMK-MA
0x00, PMK-MA
0x01, PMK-MA
KCK
KEK
KTK
MNonce
SNonce
KCK || KEK = KDF-256(PMK-MA, “Mesh KECK derivation”,
0x00 || MMP-ID || SMP-ID || PMK-MAName)
temporal key
KTK = KDF-256(PMK-MA, “Mesh KTK derivation”,
0x01 || MMP-ID || SMP-ID || PMK-MAName)
Temporal key = KDF-TKlength(KTK, “Mesh TK derivation”,
MNonce || SNonce || MMP-ID || SMP-ID || PMK-MAName)
Meiyuan Zhao, Intel Corp, et al.

19. Key Derivation Analysis
November 2006
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
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 MNonce and SNonce
Advantage
KCK and KEK are generated only once for each PMK-MA
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.

20. Changes to Finite State Machine
November 2006
Changes to Finite State Machine
Verify the MIC first, before processing the message
Silently drop the message if MIC failure
Close the session, when security policy negotiation fails
Close the session, when PMK negotiation fails
Close the session, if security parameters mismatch in Peer Link Open and Peer Link Confirm messages (but the MIC validation succeeds)
Meiyuan Zhao, Intel Corp, et al.

21. November 2006
Conclusion
A new abbreviated security handshake: integrates the peer link establishment with security handshake
There are three major new components
PMK Usage Negotiation
Security Policy Negotiation
Key Derivation Algorithm
Work in progress
Proving security
Bellare & Rogaway or Canetti & Krawczyk model
Welcome comments and suggestions to help improve the protocol
Meiyuan Zhao, Intel Corp, et al.

22. November 2006
Feedback?
Meiyuan Zhao, Intel Corp, et al.

23. November 2006
Backup Slides
Meiyuan Zhao, Intel Corp, et al.

24. Secure Peer Link Establishment Goals
November 2006
Secure Peer Link Establishment Goals
Negotiate configuration parameters
Non-security parameters that enable peer-to-peer communication
Security related parameters for secure link set up
E.g., ciphersuite, nonces, keys, …, etc.
Limit (if necessary) number of peer links that a MP has to support
This would be a implementation-specific limitation
Enable authentication and key management for link security
Enable routing traffic and data traffic
Meiyuan Zhao, Intel Corp, et al.

25. Finite State Machine Goal: Interoperable protocol Requirements
November 2006
Finite State Machine
Goal: Interoperable protocol
Requirements
Fully specify the protocol behavior
Handle all possible failure cases
Handle race conditions
Meiyuan Zhao, Intel Corp, et al.

26. Finite State Machine Actions November 2006 States Events
0. IDLE
1. LISTEN
2. OPEN_SENT
3. CONFIRM_RCVD
4. CONFIRM_SENT
5. ESTABLISHED
6. HOLDING
Events
CancelPeerLink (CNCL)
PassivePeerLinkOpen (PAS)
ActivePeerLinkOpen (ACT)
CloseReceived (CLR)
OpenReceived (OPR)
ConfirmReceived (CNR)
Timeout (RetryTimer) (TOR)
Timeout (OpenTimer) (TOO)
Timeout(CancelTimer) (TOC)
MICFailure (MIC)
NegotiationFailure (NF)
SecurityParameterMismatch(SPM)
Actions
SendClose (SCL)
SendOpen (SOP)
SendConfirm (SCN)
Meiyuan Zhao, Intel Corp, et al.

27. Finite State Machine State Transitions
November 2006 1 2 3 4 5 6
CNCL
- → 0
SCL → 6
- → 6
PAS
- → 1
- → 2
- → 3
- → 4
- → 5
ACT
SOP → 2
CLR
or - → 2
or - → 3
or - → 4
- → 6 or
OPR
SOP, SCN → 4
or SCL → 1
SCN → 4
or SCL → 6
SCN → 5
or - → 5
or SCL→6
or - → 6
CNR
or - →2
or SCL →6
SCN → 5 or
SCL → 6 or
- →4
TOR
SOP → 2 or
SOP → 4 or
TOO
TOC
SCL → 0
Meiyuan Zhao, Intel Corp, et al.

28. Summary of Finite State Automaton
November 2006
Summary of Finite State Automaton
Legend
Close / -, NF/Close, SPM/Close
transition
CancelLink
or *Timeout
Timeout(RetryTimer) / SendOpen
MIC/-
Event / Action
(RetryTimer) / SendClose
CancelLink or 3
Confirm / -
ActiveOpen / SendOpen 2
Timeout(OpenTimer) / Close
Close/-, NF/Close,
SPM/Close
ActiveOpen / SendOpen
Open / Confirm
Open / SendConfirm
MIC/-
Open / SendConfirm
PassivOpen / -
CancelLink / Close 1 5 6
CancelLink / -
Confirm / -
SPM / Close
Open / Send Open + Confirm
Open / Close
Confirm / Close
Close / - 4
Close / -
Close / Close
Close / -
SPM/Close, NF/Close
Timeout(RetryTimer) / SendOpen
MIC/-
CancelLink
(RetryTimer) / SendClose
or *Timeout
CancelLink or Timeout(CancelTimer) / SendClose
0: IDLE 1: LISTEN : OPEN_SENT : CONFIRM_RCVD : CONFIRM_SENT
5: ESTABLISHED : HOLDING
Meiyuan Zhao, Intel Corp, et al.

29. Current Protocol in Draft 0.4 (1)
November 2006
Current Protocol in Draft 0.4 (1) B A
Association Request (Ra)
Association Response
Subordinate MP
Superordinate MP
Meiyuan Zhao, Intel Corp, et al.

30. Current Protocol in Draft 0.4 (2)
November 2006
Current Protocol in Draft 0.4 (2) B A
Association Request (Ra)
Association Request (Rb)
Ra > Rb?
Ra > Rb?
Subordinate MP
Superordinate MP
Association Response (accept)
Association Response (deny)
Meiyuan Zhao, Intel Corp, et al.

31. Design Problems Unreliable communication
November 2006
Unreliable communication
Deadlock possible because of message loss
In current design, it is not well defined
Poor performance and livelock possible due to lack of instance identifiers
The design does not bound the connect time variance, because peers can get into an Open/Close Request/Response loop without instance identifiers
Link establishment specification is incomplete
Use random numbers for tie break
Superordinate and subordinate roles don’t serve a purpose and cause confusion
Collision will still happen with some frequency given the 32 bit size of the identifiers – about once every 216 link establishment attempts
Meiyuan Zhao, Intel Corp, et al.

32. Example: Transition Over Rebooting
November 2006
Example: Transition Over Rebooting
Association Request (R1) R1
reboot
Association Response
Superordinate MP ??
Current protocol doesn’t fully specify what to do
Meiyuan Zhao, Intel Corp, et al.

33. Example: Half-Open Connection
November 2006 B A
Association Request (Ra)
Association Request (Rb)
Ra > Rb?
Superordinate MP
Association Response (accept)
Idle
Association Response (deny)
Data Frame ….
Transmission Failure
Disassociate Request
Meiyuan Zhao, Intel Corp, et al.

34. November 2006
Half-Open Connection
The protocol is responsible for tearing down the link if it’s not functioning correctly
Eventually the timer can take care of it
However, this design is not robust
Push the responsibility to the lower layer
Unnecessary communication overhead involved
Meiyuan Zhao, Intel Corp, et al.

35. Example: Tie Break Failure
November 2006
Example: Tie Break Failure
Association Request (R1) R1
Association Request (R2) R2
timeout
Association Request (R1’)
R1’
R1 > R2?
Association Response
R1’ > R2?
Association Response
Superordinate MP
Superordinate MP
Two Superordinate MPs not a valid state in current protocol
Root problem: numbers used for tie break are transmitted separately.
Meiyuan Zhao, Intel Corp, et al.

36. Can we simply drop tie-breaking scheme?
November 2006
Can we simply drop tie-breaking scheme? B A
Association Request
Association Request
pending
pending
Association Response (accept)
Established
Authenticator: waits for supplicant to initiate authentication
2-message protocol is not enough!
Meiyuan Zhao, Intel Corp, et al.

37. Instance Identifier <A, B, Ra, Rb>
November 2006
Instance Identifier
<A, B, Ra, Rb>
Freshness of the communication
Deal with race conditions in parameter negotiation
When the new parameters take effect?
Re-negotiate parameters while maintaining the data traffic
Synchronize the usage of the new parameters
No identifier—have to tear down the link
Ease the internal implementation
One state machine instance handles one link instance
Deal with messages that have the matching instance identifier
Retries can be handled correctly
Generate a new state machine if receive a Peer Link Open request with a new random number
If no identifier
Have to generate a new state machine whenever receiving a Peer Link Open request or live with the race conditions
Meiyuan Zhao, Intel Corp, et al.

38. November 2006
Failure Case Analysis
Meiyuan Zhao, Intel Corp, et al.

39. Failure Case (1) November 2006 vs. …… …… ?? ?? ?? Open Open Open
Confirm
Confirm
Confirm
Authentication ??
Open
Authentication ??
Confirm
Open
Authentication
vs.
Confirm ?? …… ……
Open
Confirm
Open
Confirm
Confirm
Authentication
Authentication
Authentication
Meiyuan Zhao, Intel Corp, et al.

40. November 2006
Analysis
Common: Both protocols need to deal with the last message problem
Difference
Impact is different
4-message protocol has more predictable behavior
Hold off authentication until the retry is confirmed
Instance identifier: can distinguish the retries and the fresh start
Meiyuan Zhao, Intel Corp, et al.

41. Remaining Issues Detailed design on the security functions
November 2006
Remaining Issues
Detailed design on the security functions
Negotiate ciphersuite
Decide the shared PMK
Key wrapping on GTK
Temporal key derivation
Performance evaluation
Validation
Analyze and prove the security of the abbreviated protocol
Meiyuan Zhao, Intel Corp, et al.

42. Call for Instance Identifier
November 2006
Call for Instance Identifier
Need to name the session to bind necessary resource with link instance
802.11i uses different keys for different sessions
Implicit binding
doesn’t have instance identifier
Lock-out problem
STA loses states (including keys) and comes back, it CANNOT rejoin the network
802.11i is subject to trivial denial of service attacks
802.11w and r suffers too
Meiyuan Zhao, Intel Corp, et al.

43. The difficult question
November 2006
The difficult question
If AP has an authenticated station ‘X’....
and it receives an (unprotected) association request from station claiming to be ‘X’....
Should it:
(a) Ignore the request
(b) Fail the request
(c) accept the request
If the answer is (a) or (b) then we have a lockout problem since a station that loses its key state cannot rejoin the network.
Let’s explore the consequences of answer (c)
Meiyuan Zhao, Intel Corp, et al.

44. Answer ‘C’: accept association
November 2006
Answer ‘C’: accept association
The idea is to enable the existing authenticated station to continue un-interrupted while allowing the new station to complete the authentication phase.
If the new station succeeds, the state for the existing connection will be deleted. AP AP AP
existing
new X X X X X X
Association
Authenticating
(802.1X)
Authenticated
Meiyuan Zhao, Intel Corp, et al.

45. Can Answer ‘C’ really work?
November 2006
Can Answer ‘C’ really work?
Requires maintaining state for two stations with the same MAC address - differentiated by context
Requires de-multiplexing incoming messages to deliver to the correct instance of the station - even though destination address is the same!
Meiyuan Zhao, Intel Corp, et al.

46. Analysis Consider an attack where:
November 2006
Analysis
Consider an attack where:
STA ‘X’ is authenticated and protected
STA ‘Z’ is attacker using MAC address of ‘X’ AP
AP can only see one STA ‘X’
Forges messages from ‘X’ X Z
Meiyuan Zhao, Intel Corp, et al.

47. November 2006
AP Multi-State
AP receives unprotected messages that are inappropriate for a protected station:
open authenticate
associate request
AP assumes this is caused by either:
STA ‘X’ that has lost it’s key state, or...
A forgery attempt by unknown STA
AP decides to accept unprotected messages from “aspirant station” pending authentication This means:
New entry in STA table but with same MAC address as an existing entry
New 802.1X port and authenticator - but with same MAC address as existing port. Old port is closed, new port is open
MAC state very confused because of possible sequence number errors. Mayhem if one is in power save mode and the other not!
Meiyuan Zhao, Intel Corp, et al.