1. Update to Efficient Mesh Security and Link Establishment
Month Year
doc.: IEEE /1625r0
November 2006
Update to Efficient Mesh Security and Link Establishment
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
Braskich, et al
Braskich, et al

2. Month Year
doc.: IEEE /1625r0
November 2006
Abstract
This presentation is an update on the Efficient Mesh Security and Link Establishment proposal presented to TGs in Melbourne
11-06/1470 (doc), 11-06/1471 (ppt)
This proposal includes a security mechanism for mesh networks that allows mesh points to quickly, robustly, and efficiently establish secure mesh links to be used in routing and data transport
It is intended to resolve the following CIDs: 120, 121, 122, 199, 236, 237, 239, 240, 243, 244
Braskich, et al
Braskich, et al

3. Agenda History of the proposal Overview of the proposal
Month Year
doc.: IEEE /1625r0
November 2006
Agenda
History of the proposal
Overview of the proposal
Summary of updates since Melbourne
Discussion
Braskich, et al
Braskich, et al

4. History of the Proposal
Month Year
doc.: IEEE /1625r0
November 2006
History of the Proposal
This proposal is an extension of 11-06/1001 and 11-06/1353, originally presented by Jesse Walker in San Diego
Guiding philosophy: Develop a security architecture for Mesh Transport that leverages and builds upon conventions and mechanisms from .11i, .11r, and .11w where possible
Aligned with TGs PAR requirement: “The amendment shall utilize IEEE i security mechanisms, or an extension thereof…”
The authors of this proposal have incorporated updates based on feedback received in Melbourne and are interested in additional comments and suggestions
Braskich, et al
Braskich, et al

5. 11s Security Situation MP3 MP6 MP1 MP2 MP5 MP4 November 2006 MP7
Month Year
doc.: IEEE /1625r0
November 2006
11s Security Situation
MP3
The MPs are no longer wired to one another
There is no intrinsic node hierarchy
The criterion for selecting a next-hop MP to associate with is partially in-scope
We have some control over the behavior
We should not expect the routing protocol to be cognizant of the security mechanism
The number of alternative paths is considerably larger
In many usage models, MPs need to authenticate with a large (>10) number of neighbors
MP6
MP1
MP7
MP2
MP5
MP4
Secure candidate link
Unsecure non-candidate link
Wired backhaul
Braskich, et al
Braskich, et al

6. Efficient Mesh Security Proposal General Approach
Month Year
doc.: IEEE /1625r0
November 2006
Efficient Mesh Security Proposal General Approach
General approach
Build on trust relationships that result from 11i authentication
Introduce a mesh key distributor, and a mesh key hierarchy, into TGs to enable fast link establishment among mesh points.
High level description
The mesh key distributor uses a key hierarchy that is based on but not dependent upon TGr.
At first contact, use association and four way handshake frames to select and set up mesh key hierarchy for fast link establishment
Subsequent security associations within the same mesh may utilize the mesh key hierarchy
Architecture compatible with both 802.1X-based authentication and PSK
Braskich, et al
Braskich, et al

7. Rationale November 2006 Reduce barriers to link establishment
Month Year
doc.: IEEE /1625r0
November 2006
Rationale
Reduce barriers to link establishment
Proposal provides a first contact mechanism that is called when a MP joins the mesh
This establishes a derived key hierarchy for use in subsequent associations
Efficient mesh security associations (EMSA) minimizes messages and computations required to go from having a one link to the mesh to having many
Architecture provides additional benefits when using 802.1X-based authentication
Radius client used for mesh formation moved out of mesh authenticator and into mesh key distributor
Mesh key distributor will typically have wired connection to AAA server, reducing need to transport Radius messages over mesh links
Braskich, et al
Braskich, et al

8. doc.: IEEE 802.11-06/1625r0 Efficient Mesh Security
Month Year
doc.: IEEE /1625r0
November 2006
Mechanism Details
Efficient Mesh Security
Braskich, et al
Braskich, et al

9. Overview – Initial EMSA Handshake
Month Year
doc.: IEEE /1625r0
November 2006
Overview – Initial EMSA Handshake
This can be one entity (that could be co-located with the MA)
mesh key distributor
mesh authenticator
supplicant MP AS MP
See note 1
Peer Link Establishment
MA advertises services enabling supplicant to join.
Management
EAP Authentication
EAP Authentication
EAP Authentication
EAPoL via Mesh Data
EAP via Mesh Action
EAP over RADIUS
MA enables supplicant to perform EAP authentication.
Key Delivery
via Mesh Action
MA obtains a derived key to enable handshake with supplicant.
Note 1: The MKD is not an MP in the sense that it does not provide routing or forwarding services. In theory it can be any device that implements the EMS protocol. In practice, the MKD role will typically be co-resident with a portal.
4-way Handshake
MA derives PTK to secure link with supplicant.
EAPoL via Mesh Data
Key Holder setup handshake
via Mesh Action
Supplicant is now securely configured as a Mesh Authenticator
Braskich, et al
Braskich, et al

10. Overview – Mesh Action Frames
Month Year
doc.: IEEE /1625r0
November 2006
Overview – Mesh Action Frames
Type value
Type description
Subtype value
Subtype description 11
Extended
0000
Mesh Data
0001
Mesh Data + CF-Ack
0010
Mesh Action
A new frame type is defined, called “Mesh Action.” It permits management functions to occur over multiple hops.
Mesh Action is treated as a data frame, with encrypted contents (encryption occurs at each hop).
Contents are specified similar to action frames.
4-address MAC Header
Encryption Header
Mesh Action body
MIC, (ICV), FCS
Octets: 33 8
variable
12/16
Category
Action
Contents
Octets: 1
variable
Braskich, et al
Braskich, et al

11. Mesh Key Hierarchy Overview
Month Year
doc.: IEEE /1625r0
Mesh Key Hierarchy Overview
November 2006
MSK
A MSK is created for each supplicant when it joins a mesh
Its generated during a MP’s EAP authentication and delivered to a mesh key distributor (e.g., via RADIUS)
Note: XXKey is a portion of MSK
A first derived key, the PMK-MKD, is obtained from XXKey.
A second derived key, the PMK-MA, is generated to use in an EMSA handshake.
The MKD derives a unique PMK-MA, as required, for each MA.
The PMK-MA is distributed to appropriate MA
A transient key, the PTK, is mutually derived from the PMK-MA by the MA & the supplicant MP.
The KDK & PTK-KD are used by key holders
They are used for the purposes of securing communication between an MA and MKD.
(11i)
XXKey
PMK-MKD
Held at MKD
KDK
PMK-MA
PMK-MA
PMK-MA
PTK-KD
Derived at MKD; sent to MA
PTK
Mutually derived by MA & supplicant MP
Used by MA to secure communications with MKD
Braskich, et al
Braskich, et al

12. EMSA Key Transfer Protocol
Month Year
doc.: IEEE /1625r0
EMSA Key Transfer Protocol
November 2006
mesh key distributor
After a mesh node establishes a security association with a key distributor (step 1), it can start taking delivery of key material (step 2) and serve as a mesh authenticator for other nodes
mesh node
mesh authenticator
First contact: security & routing setup
Mesh authenticator security establishment
Step 1
supplicant
via Mesh Action
mesh authenticator
Peer Link Establishment
Step 2
Management
PMK-MA Delivery
via Mesh Action
Braskich, et al
Braskich, et al

13. Mesh Action frame type permits EAP transport
Month Year
doc.: IEEE /1625r0
November 2006
EAP message transport
mesh key distributor
mesh authenticator
supplicant
Initial EAP message
Supplicant & MA first complete link establishment.
Initial EAP encap. Request
EAP encap. Response
Mesh Action frame type permits EAP transport
EAP encap. Request
Final EAP encap. Response
Note: If MA does not know appropriate EAP type for initial message to supplicant, MA may send “EAP-Start” indication to MKD.
Final Response has special Message Type:
2 = Supplicant should be accepted.
3 = Supplicant should be rejected.
Message Type = 1 (request)
Message Type = 11 (response)
Protocol provides means to validate data origin authenticity and message integrity across a multi-hop link
Braskich, et al
Braskich, et al

14. Discovery: Beacons & Probe Responses
Month Year
doc.: IEEE /1625r0
November 2006
Discovery: Beacons & Probe Responses
A MP supporting EMSA includes the following in its beacons and probe responses
Mesh Key Distributor Domain IE (MKDDIE)
Information Elements
MAC Header
Non-IE fields …
RSN IE
Mesh ID
MKDDIE
FCS
Advertises capability to use mesh fast link key hierarchy in AKM Suites list.
Provides information to supplicant to ensure its key hierarchy is available at the MA advertising this beacon.
Braskich, et al
Braskich, et al

15. Mesh Security (EMSA) Mesh Actions
Month Year
doc.: IEEE /1625r0
Mesh Security (EMSA) Mesh Actions
November 2006
Cate-gory
Action Value
Description
Mesh key holder security establishment: Establishes a security context between two MPs, including the distribution of a PMK-MA. 1
PMK-MA delivery push: Facilitates delivery of a key in the mesh key hierarchy to a mesh authenticator. 2
PMK-MA Confirmation: Sent by a mesh authenticator to confirm key delivery. 3
PMK-MA Request: Sent by a mesh authenticator to request key delivery. 4
PMK-MA delivery pull: Facilitates delivery of a key in the mesh key hierarchy to a mesh authenticator. 5
PMK-MA delivery delete: Facilitates key deletion at a mesh authenticator. 6
Mesh EAP encapsulation: Permits transport of EAP authentication messages between a mesh authenticator & mesh key distributor.
Category
Action
Contents
Octets: 1
variable
Category & action definitions are separate from existing Action frames.
Define category 0 = “Mesh Security”.
Several action codes are defined for category 0.
The contents are further defined for each of these action values.
Braskich, et al
Braskich, et al

16. doc.: IEEE 802.11-06/1625r0 Peer Link Establishment
Month Year
doc.: IEEE /1625r0
November 2006
Mechanism Details
Peer Link Establishment
Braskich, et al
Braskich, et al

17. Robust Peer Link Establishment Protocol Design Goals
Month Year
doc.: IEEE /1625r0
November 2006
Robust Peer Link Establishment Protocol Design Goals
Peer link establishment is a pre-requisite step before EMSA handshake
Security analysis depends on robust peer link establishment
Design Goals of updates to peer link establishment:
Deal with the unreliable communication channel
No deadlock or livelock
Bind peers to link instances to
Enhance performance by bounding the variation in the link establishment time
Remove race conditions inherent in the association design
Allow functions provided by 4-Way Handshake to be overlaid on top of link establishment with no loss of security
Braskich, et al
Braskich, et al

18. Robust Peer Link Establishment Overview
Month Year
doc.: IEEE /1625r0
November 2006
Robust Peer Link Establishment Overview
Three messages
Peer Link Open, Peer Link Confirm, Peer Link Close
Rules
Both peers can initiate the link establishment protocol
The peer link is established if and only if both peers send and receive Open and Confirm messages
Link instance
Identifier <myId, peerId, myRa, peerRb>
myId and peerId: MAC addresses
myRa and peerRb: random numbers generated for this link instance
Enforce binding between link instance and messages
Peer Link Open (myId, peerId, Ra)
Peer Link Confirm (myId, peerId, Ra, Rb)
Peer Link Close (myId, peerId, Ra, Rb)
Braskich, et al
Braskich, et al

19. Month Year
doc.: IEEE /1625r0
November 2006
Updates to the proposal based on questions, comments, and suggestions received
Summary of updates since Melbourne meeting:
Defined fragmentation of EAP messages to permit transport in mesh action frames via IEs ( , )
Text added to clarify MKD-AS relationship ( )
Rearranged fields in IE so MIC is at end ( )
Modifications to KDKName to ensure uniqueness ( )
Minor editorial updates & correcting other minor errors
Note: the authors of the proposal are open to incorporating additional updates based on any feedback and suggestions
Braskich, et al
Braskich, et al

20. Feedback? November 2006 Month Year doc.: IEEE 802.11-06/1625r0
Braskich, et al
Braskich, et al

21. Backup November 2006 Month Year doc.: IEEE 802.11-06/1625r0
Braskich, et al
Braskich, et al

22. Details: EAP Authentication IE
Month Year
doc.: IEEE /1625r0
November 2006
Details: EAP Authentication IE
Element ID
Length
EAP Message Type
Message Token
SPA
Message Fragments
MIC Control
MIC
Octets: 1 16 6 2
MIC algorithm
Reserved
IE count
Bit:
B0 – B3
B4 – B7
B8 – B15
EAP Message Type differentiates between request and response messages.
Response messages are further differentiated into three subtypes.
Message Token permits matching response messages to requests.
In a request message, it contains a random nonce.
In a response message, it contains the value of “Message Token” from the request to which it corresponds.
SPA (supplicant address) provides the address of the supplicant node that is undergoing EAP authentication.
Message Fragments contains the number of EAP message fragments in this action frame. Fragments are individually carried in EAP Message IEs that follow this IE.
MIC algorithm selects an available algorithm for calculating the MIC.
IE count indicates the number of information elements protected by the MIC.
MIC (message integrity check) contains a check value calculated using a pairwise key. It protects the contents of this IE, all EAP Message IEs that follow within this action frame, and additional header information.
Braskich, et al
Braskich, et al

23. Details: EAP Message IE
Month Year
doc.: IEEE /1625r0
November 2006
Details: EAP Message IE
Element ID
Length
Fragment Control
EAP Message Fragment
Octets: 1
variable
Fragment Control contains an integer indicating the number of each fragment of an EAP message. The fragment number is set to 0 in the first or only fragment of an EAP message and is incremented by one for each successive fragment of that EAP message.
EAP Message Fragment contains an EAP packet, or a fragment of an EAP packet, with format as defined in IETF RFC 3748
Braskich, et al
Braskich, et al

24. Robust Peer Link Establishment State Machine
Month Year
doc.: IEEE /1625r0
Robust Peer Link Establishment State Machine
November 2006
Close / -
Legend
CancelLink
or *Timeout
transition
Timeout(RetryTimer) / SendOpen
(RetryTimer) / SendClose
CancelLink or
Event / Action 3
Confirm / -
ActiveOpen / SendOpen 2
Timeout(OpenTimer) / Close
ActiveOpen / SendOpen
Open / Confirm
Close/-
Open / SendConfirm
Open / SendConfirm
PassivOpen / -
CancelLink / Close 1 5 6
CancelLink / -
Confirm / -
Open / Send Open + Confirm
Open / Close
Confirm / Close
Close / - 4
Close / -
Close / Close
Close / -
Timeout(RetryTimer) / SendOpen
CancelLink
(RetryTimer) / SendClose
or *Timeout
CancelLink or Timeout(CancelTimer) / SendClose
0: IDLE 1: LISTEN : OPEN_SENT : CONFIRM_RCVD : CONFIRM_SENT
5: ESTABLISHED : HOLDING
Braskich, et al
Braskich, et al