1. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 1 Update to Efficient Mesh Security and Link Establishment Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2006-11-13Authors:

2. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 2 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

3. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 3 Agenda History of the proposal Overview of the proposal Summary of updates since Melbourne Discussion

4. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 4 History of the Proposal This proposal extends the Walker/Zhao/Conner proposal (11-06/1001) from July Guiding philosophy: Develop a security architecture for Mesh Transport that builds upon conventions and mechanisms from.11i where possible –Aligned with TGs PAR requirement: “The amendment shall utilize IEEE 802.11i security mechanisms, or an extension thereof…” This proposal incorporates feedback received over the last six months

5. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 5 Dallas San Diego Evolution of Link Security Solution MP Authentication Key Provisioning Secure Link Key Management Protocol 802.11i: Provided by the backend with “Magic” 802.11i: Provided by the backend with “Magic”

6. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 6 11s Security Situation The MPs are no longer wired to one another There is no intrinsic node hierarchy In many usage models, MPs need to authenticate with a large (>10) number of neighbors Unlike the BSS case, an MP needs secure transports prior to choosing an efficient path MP 7 MP 1 MP 6 MP 2 MP 3 MP 4 MP 5 Wired backhaul Secure candidate link Unsecure non-candidate link

7. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 7 Efficient Mesh Security Overview General approach –802.11i could afford the luxury of assuming an enclave protecting the backend –Build on trust relationships that result from 11i authentication –Introduce a mesh key distributor, and a mesh key hierarchy, to enable fast link establishment among mesh points. High level description –The mesh key distributor uses a key hierarchy based on but not dependent upon TGr. –At first contact, use association and 4-Way Handshake to select and set up mesh key hierarchy for fast link establishment –Subsequent security associations within the same mesh may utilize the key hierarchy –Architecture compatible with both 802.1X-based authentication

8. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 8 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

9. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 9 Mechanism Details Efficient Mesh Security

10. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 10 Overview – Initial EMSA Handshake AS mesh key distributor mesh authenticator supplicant MP See note 1 Peer Link Establishment EAP Authentication EAPoL via Mesh Data EAP via Mesh ActionEAP over RADIUS Key Delivery via Mesh Action EAPoL via Mesh Data 4-way Handshake Key Holder setup handshake via Mesh Action 802.11 Management EAP Authentication MA enables supplicant to perform EAP authentication. MA advertises services enabling supplicant to join. MA obtains a derived key to enable handshake with supplicant. MA derives PTK to secure link with supplicant. Supplicant is now securely configured as a Mesh Authenticator This can be one entity (that could be co-located with the MA)

11. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 11 Overview – Subsequent EMSA Handshake AS mesh key distributor mesh authenticator supplicant MP See note 1 Peer Link Establishment Key Delivery via Mesh Action EAPoL via Mesh Data 4-way Handshake 802.11 Management MA advertises services enabling supplicant to join. If necessary, MA obtains a derived key to enable handshake with supplicant. MA derives PTK to secure link with supplicant. This can be one entity (that could be co-located with the MA)

12. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 12 Overview – Mesh Action Frames 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 hop-by- hop 802.11i protection. Contents are specified similar to action frames. Type value Type description Subtype value Subtype description 11Extended0000Mesh Data 11Extended0001Mesh Data + CF-Ack 11Extended0010Mesh Action 4-address MAC Header Encryption Header Mesh Action body MIC, (ICV), FCS Octets:338variable12/16 CategoryActionContents Octets:11variable

13. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 13 Mesh Key Hierarchy Overview A MSK is created for each supplicant when it joins a mesh –Generated during a MP’s EAP authentication and delivered to a mesh key distributor First PMK-MKD is derived from XXKey. Second, a PMK-MA is derived for each MA. –Used in the EMSA handshake A PTK, is derived from the PMK-MA by the MA & the supplicant MP. The KDK & PTK-KD secure PMK-MA distribution (11i)XXKey PMK-MKD PMK-MA PTK Held at MKD Derived at MKD; sent to MA MSK Mutually derived by MA & supplicant MP KDK PTK-KD Used by MA to secure communications with MKD

14. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 14 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

15. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 15 Discovery: Beacons & Probe Responses A MP supporting EMSA includes the following in its beacons and probe responses –Mesh Key Distributor Domain IE (MKDDIE) MAC Header Non-IE fields …RSN IEMesh 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. Information Elements

16. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 16 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 802.11 association design –Allow functions provided by 4-Way Handshake to be overlaid on top of link establishment with no loss of security

17. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 17 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 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)

18. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 18 Updates Since Melbourne

19. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 19 Updates to the proposal (1470r3) since Melbourne Summary of updates based on feedback received: Defined fragmentation of EAP messages to permit transport in mesh action frames via IEs (7.3.2.63-64, 8.8.3.2.3) Added Subsequent EMSA Handshake mechanism section (8.8.3.2) Text added to clarify MKD-AS relationship (8.8.1.1) Modified address field definitions in 7.2.4.3 (Mesh Management Frames) Rearranged fields in IE so MIC is at end (7.3.2.60) Modifications to KDKName to ensure uniqueness (8.8.2.7) Aligned headings & sections with TGs D0.04 Minor modifications for clarity & correcting minor errors

20. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 20 Feedback?

21. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 21 Motion MOTION: Accept the submission contained in document 11-06-1470-03-000s-efficient-mesh-security-and-link- establishment.doc, and instruct the editor to incorporate the changes into the draft. By: Second: Result: Yes: -, No: -, Abstain: -

22. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 22 Backup

23. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 23 EMSA Key Transfer Protocol mesh key distributor mesh node supplicant Peer Link Establishment PMK-MA Delivery via Mesh Action Mesh authenticator security establishment via Mesh Action 802.11 Management Step 2 Step 1 mesh authenticator First contact: security & routing setup 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 authenticator

24. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 24 Mesh Security (EMSA) Mesh Actions 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. CategoryActionContents Octets:11variable Cate- gory Action Value Description 00Mesh key holder security establishment: Establishes a security context between two MPs, including the distribution of a PMK- MA. 01PMK-MA delivery push: Facilitates delivery of a key in the mesh key hierarchy to a mesh authenticator. 02PMK-MA Confirmation: Sent by a mesh authenticator to confirm key delivery. 03PMK-MA Request: Sent by a mesh authenticator to request key delivery. 04PMK-MA delivery pull: Facilitates delivery of a key in the mesh key hierarchy to a mesh authenticator. 05PMK-MA delivery delete: Facilitates key deletion at a mesh authenticator. 06Mesh EAP encapsulation: Permits transport of EAP authentication messages between a mesh authenticator & mesh key distributor.

25. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 25 Details: EAP Authentication IE Element ID LengthEAP Message Type Message Token SPAMessage Fragments MIC Control MIC Octets:11116612 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. MIC algorithmReservedIE count Bit:B0 – B3B4 – B7B8 – B15

26. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 26 Details: EAP Message IE Element ID LengthFragment Control EAP Message Fragment Octets:111variable 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

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

28. doc.: IEEE 802.11-06/1625r1 Submission November 2006 Braskich, et al Slide 28 Summary of Features Robust Peer Link Establishment Protocol Mesh Key Hierarchy with link security & key distribution branches Initial & Subsequent EMSA Authentication 802.1X Role (Supplicant/Authenticator) Determination Mesh Key Holder Security Association handshake Mesh Key Transport protocols –Push delivery, Pull delivery, and Delete EAP Transport protocol (optional)