doc.: IEEE /1471r0 Submission September 2006 authors Slide 1 Efficient Mesh Security and Link Establishment 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, 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. Date: Authors:

doc.: IEEE /1471r0 Submission September 2006 authors Slide 2 Abstract This submission is an extension of 11-06/1001 and 11-06/1353, originally presented by Jesse Walker in San Diego and on the Sept 6 TGs telecon It proposes 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

doc.: IEEE /1471r0 Submission September 2006 authors Slide 3 Agenda Problem statement and goals Efficient Mesh Security Robust Peer Link Establishment Discussion

doc.: IEEE /1471r0 Submission September 2006 authors Slide 4 Problem Statement Security for mesh transport and mesh formation means –Prevent unauthorized devices from directly sending and receiving traffic via the mesh Protect unicast traffic between neighbor MPs Protect broadcast traffic between neighbor MPs –We take mesh formation to be setup for secure mesh transport Two mesh peers need to establish a fresh and never-before-used session key Each broadcast source needs to distribute its own broadcast key The transport security architecture should –Mutually authenticate neighbor MPs –Generate and manage session keys and broadcast keys –Detect message forgeries and replays received on a link –Data confidentiality over a link should also be supported

doc.: IEEE /1471r0 Submission September 2006 authors Slide 5 11i Security Situation All APs are connected to one another The criterion for selecting an AP to associate with is out of scope –We have no control over which AP is selected –It is in the vendor’s best interest to prevent oscillations because they are very costly The number of alternative links is limited STA AP 1 AP 6 AP 2 AP 3 AP 4 AP 5 Wired backhaul Secure link Unsecure candidate link Non-candidate link

doc.: IEEE /1471r0 Submission September 2006 authors Slide 6 11s Security Situation 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 –We need to authenticate with a large (>10) number of neighbors MP 7 MP 1 MP 6 MP 2 MP 3 MP 4 MP 5 Wired backhaul Secure candidate link Unsecure non-candidate link

doc.: IEEE /1471r0 Submission September 2006 authors Slide 7 Goals Develop a security architecture for Mesh Transport Reuse i where possible The selection of the “associated MP” is now in-scope –We can not pass the blame on the implementation –Routing needs to probe many candidate neighbors to select the best next hop Limiting the number of mutually authenticated nodes (“secure links”) is a form of topology control –The security mechanism should not be performing routing We cannot realistically wait for the individual authentication of 31 nodes before the network is operable –Some mechanism that leverages existing trust relationships is preferable

doc.: IEEE /1471r0 Submission September 2006 authors Slide 8 Some pointers The 11i-like mechanism is good for first contact –We can build on the trust relationships that result from 11i authentication There would be two types of authentication –An initial step (AAA-based authentication) –A “light-weight” step Authentication of nodes “within the mesh” should use the “light- weight” step only –We would not put an artificial constraint on topology –We can use a key hierarchy

doc.: IEEE /1471r0 Submission September 2006 authors Slide 9 Efficient Mesh Security Proposal Overview General approach –Introduce a key hierarchy into TGs to enable fast link establishment among mesh points. High level description –Key hierarchy 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

doc.: IEEE /1471r0 Submission September 2006 authors Slide 10 Overview – Initial EMSA Handshake AS mesh key distributor mesh authenticator supplicant MP MPP 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 Routing setup Key Holder setup handshake via Mesh Action 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

doc.: IEEE /1471r0 Submission September 2006 authors Slide 11 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 encrypted contents (encryption occurs at each hop). 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

doc.: IEEE /1471r0 Submission September 2006 authors Slide 12 Rationale Reduce barriers to link establishment –Proposal provides two mechanisms for establishing security associations a first contact mechanism that is called when a MP joins the mesh and a “light-weight” mechanism leveraging the mesh key hierarchy to establish additional links –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 –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

doc.: IEEE /1471r0 Submission September 2006 authors Slide 13 Mechanism Details Mesh Action Frames

doc.: IEEE /1471r0 Submission September 2006 authors Slide 14 Mesh Action Frame Details MAC Header (uses 4-address format) Mesh Action body FCS Octets:33variable4 CCMP header or IV/KeyID + Ext. IV Mesh Action Data Unit MIC or MIC + ICV Octets:8variable8 or 12 CategoryActionContents Octets:11variable Contains one or more information elements or fixed fields. The Mesh Action frame permits a 4-address MAC Header to be used with management information in the frame body. The Mesh Action frame permits management information contents to be encrypted & integrity- protected in the same manner as data frames.

doc.: IEEE /1471r0 Submission September 2006 authors Slide 15 Example Application: Mesh Security 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 association between two MPs to enable a mesh key hierarchy. 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.

doc.: IEEE /1471r0 Submission September 2006 authors Slide 16 Mechanism Details EAP message transport

doc.: IEEE /1471r0 Submission September 2006 authors Slide 17 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

doc.: IEEE /1471r0 Submission September 2006 authors Slide 18 Details: EAP Encapsulation IE Element ID LengthMIC Control MICEAP Message Type Message TokenSPAEAP Message Octets: variable 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 plus additional header information. 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. EAP Message contains an EAP packet, with format as defined in IETF RFC MIC algorithmReservedIE count Bit:B0 – B3B4 – B7B8 – B15

doc.: IEEE /1471r0 Submission September 2006 authors Slide 19 Mechanism Details Key delivery

doc.: IEEE /1471r0 Submission September 2006 authors Slide 20 EMSA Key Transfer Protocol mesh key distributor mesh node supplicant Authentication PMK-MA Delivery via Mesh Action Association & routing setup Mesh authenticator security establishment via Mesh Action 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 fast link establishment Management mesh authenticator

doc.: IEEE /1471r0 Submission September 2006 authors Slide 21 Mesh Key Hierarchy Overview 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 abbreviated 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 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

doc.: IEEE /1471r0 Submission September 2006 authors Slide 22 Security association between key holders The goal of authenticator security association is to establish secure communications between the key distributor and other key holders –The association is implemented using a new 3-message handshake between mesh key holders (MA & MKD) All messages are of the “Mesh Key Holder Security Establishment” Mesh Action type Establishing secure communications and deriving keys to enable key delivery is the first step in key delivery mesh key distributor mesh authenticator Handshake #1 (MA-Nonce) Category (0) Action (0) Mesh ID IE MKDDIEMKHSIE Mesh Key Holder Security Establishment Mesh Action Handshake #2 (MKD-Nonce, MIC) Handshake #3 (MIC)

doc.: IEEE /1471r0 Submission September 2006 authors Slide 23 Key Delivery (Pull Model – Message 1) Contents of MEKIE: –MIC Control: specify 1 IE protected –MIC: protects {MA (Sender) MAC || MKD (Destination) MAC || Type field (3) || MKDDIE || MEKIE (MIC = 0)} –Replay counter: c+1 –SPA: address of MP (“supplicant”) that “owns” requested PMK-MA –PMK-MKDName: identifier of key from which PMK-MA was derived (provided by supplicant) –ANonce: (zero) –Encrypted Contents Length: 0 –Encrypted Contents: (not present) After receiving a valid request message, the MKD attempts to locate a key for the node identified by SPA. If found, the MKD encrypts the key and related information and prepares to send the key to MA in a delivery message. mesh key distributor mesh authenticator PMK-MA request Mesh Action PMK-MA delivery pull Mesh Action Category (0)Action (3)MKDDIEMesh Encrypted Key IE PMK-MA request Mesh Action

doc.: IEEE /1471r0 Submission September 2006 authors Slide 24 Key Delivery (Pull Model – Message 2) Contents of MEKIE: –MIC Control: specify 1 IE protected –MIC: protects {MA (Destination) MAC || MKD (Sender) MAC || Type field (4) || MKDDIE || MEKIE (MIC = 0)} –Replay counter: c+1 (Same as in PMK-MA request message) –SPA, PMK-MKDName: (Same as in PMK-MA request message) –ANonce: value chosen by MKD and used in derivation of PMK-MKDName –Encrypted Contents Length: n –Encrypted Contents: AES-KeyWrap using PTK-KD of {PMK-MA || PMK-MAName || Lifetime*} After receiving a valid delivery message, the MA decrypts the PMK-MA and continues the security establishment with the supplicant using the PMK-MA delivered from the MKD MA-PMK delivery pull Mesh Action *16-bit unsigned integer representing number of minutes remaining in lifetime of PMK-MA being delivered mesh key distributor mesh authenticator PMK-MA request Mesh Action PMK-MA delivery pull Mesh Action Category (0)Action (3)MKDDIEMesh Encrypted Key IE

doc.: IEEE /1471r0 Submission September 2006 authors Slide 25 Mechanism Details Discovery and Key Hierarchy

doc.: IEEE /1471r0 Submission September 2006 authors Slide 26 Beacons & Probe Responses A MP supporting mesh fast link establishment 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

doc.: IEEE /1471r0 Submission September 2006 authors Slide 27 Details: Mesh Key Distributor Domain IE Element IDLengthMKD Domain ID Mesh Security Configuration Octets:1161 MKD Domain ID contains a 6-octet identifier of the mesh key distributir domain. Mesh Authenticator, when set to 1 indicates that this device may act as an IEEE 802.1X Authenticator during EMSA handshakes Connected to MKD, when set to 1 indicates that this Mesh Authenticator has a connection to the mesh key distributor and can receive derived keys when acting as a mesh authenticator. Default Role Negotiation is set to 1 to indicate the MP is using the default method to select IEEE 802.1X Supplicant and Authenticator roles. –Based on B0 and B1 values, and using MAC address to break ties. Mesh Authenticator Connected to MKD Default Role Negotiation Reserved Bit:B0B1B2B3-B7

doc.: IEEE /1471r0 Submission September 2006 authors Slide 28 Additional AKM suites The following authentication & key management (AKM) suites will be defined in the RSN IE. The RSNIE is advertised in beacons and probe responses and appears in message exchanges to facilitate first contact and fast link establishment. OUISuite TypeAuthentication typeKey Management type 00-0F-AC5EMSA negotiated over IEEE 802.1X, or using PMKSA caching as defined in EMSA Key management 00-0F-AC6EMSA using PSKEMSA Key management 00-0F-AC7-255Reserved

doc.: IEEE /1471r0 Submission September 2006 authors Slide 29 Mechanism Details Peer Link Establishment

doc.: IEEE /1471r0 Submission September 2006 authors Slide 30 Relation to Peer Link Establishment Peer link establishment is a pre-requisite step before EMSA handshake Security analysis depends on robust peer link establishment

doc.: IEEE /1471r0 Submission September 2006 authors Slide 31 Problems with Link Establishment in Current Draft D0.03 (11A.1) 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 –Collision will still happen with some frequency given the 32 bit size of the identifiers – about once every 2 16 link establishment attempts

doc.: IEEE /1471r0 Submission September 2006 authors Slide 32 Example Specification Problem Association Response Superordinate MP Association Request (R1) R1 reboot Current protocol doesn’t fully specify what to do ??

doc.: IEEE /1471r0 Submission September 2006 authors Slide 33 Robust Peer Link Establishment Protocol Design Goals 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

doc.: IEEE /1471r0 Submission September 2006 authors Slide 34 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)

doc.: IEEE /1471r0 Submission September 2006 authors Slide 35 0: IDLE 1: LISTEN 2: OPEN_SENT 3: CONFIRM_RCVD 4: CONFIRM_SENT 5: ESTABLISHED 6: HOLDING 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

doc.: IEEE /1471r0 Submission September 2006 authors Slide 36 Future optimizations Work in progress… –In a later meeting, we intend to propose an abbreviated protocol as an addition to this contribution that overlays the 4-Way Handshake functions on top of the peer link establishment protocol, which would provide link establishment and security when keys are cached

doc.: IEEE /1471r0 Submission September 2006 authors Slide 37 Plan for Wednesday Plan to bring motion to group: Move to instruct the editor to incorporate r0 into the TGs draft Note: between now and Wednesday, we are happy to discuss the proposal in more detail and are interested in any additional feedback

doc.: IEEE /1471r0 Submission September 2006 authors Slide 38 Feedback?