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

November 2006

Braskich, et alSlide 1

doc.: IEEE 802.11-06/1625r1

Submission

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 <http:// 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 <[email protected]> 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 <[email protected]>.

Date: 2006-11-13Name Company Address Phone email Tony Braskich Motorola Inc. 1301 E Algonquin Rd,

Schaumburg, IL 60196 +18475380760 [email protected]

W. Steven Conner Intel Corporation JF3-206, 2111 NE 25th Ave, Hillsboro OR 97124

+1-503-712-4990 [email protected]

Jan Kruys Cisco Systems 10 Haarlerbergweg 110-1CH Amsterdam, Netherlands

+31 20357 2447 [email protected]

Steve Emeott Motorola Inc. 1301 E Algonquin Rd, Schaumburg, IL 60196

+18475768268 [email protected]

Jesse Walker Intel Corporation JF3-206, 2111 NE 25th Ave, Hillsboro, OR USA 97124


Meiyuan Zhao Intel Corporation JF3-206, 2111 NE 25th Ave, Hillsboro, OR USA 97124


Rainer Falk Siemens Otto-Hahn-Ring 6, 81730 München, Germany

+49 8963651653 [email protected]

Authors:

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

Agenda

• History of the proposal

• Overview of the proposal

• Summary of updates since Melbourne

• Discussion

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

Dallas

San Diego

Evolution of Link Security Solution

MP 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”

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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

MP7

MP1

MP6

MP2

MP3

MP4

MP5

Wired backhaul

Secure candidate link

Unsecure non-candidate link

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

Mechanism Details

Efficient Mesh Security

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

Overview – Initial EMSA Handshake

ASmesh key distributor

mesh authenticatorsupplicant MP MP See note 1

Peer Link Establishment

EAP Authentication

EAPoL via Mesh Data EAP via Mesh Action EAP 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 AuthenticationEAP 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)

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

Overview – Subsequent EMSA Handshake

ASmesh key distributor

mesh authenticatorsupplicant MP MP See note 1


Key Delivery

via Mesh Action

EAPoL via Mesh Data

4-way Handshake

802.11 ManagementMA 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)

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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

11 Extended 0000 Mesh Data

11 Extended 0001 Mesh Data + CF-Ack

11 Extended 0010 Mesh Action

4-address MAC Header

Encryption Header

Mesh Action body

MIC, (ICV), FCS

Octets: 33 8 variable 12/16

Category Action Contents

Octets: 1 1 variable

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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-MAPMK-MA

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

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

EAP message transport

mesh key distributor

mesh authenticatorsupplicant

Initial EAP messageSupplicant &

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

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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

Information Elements

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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)

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

Updates Since Melbourne

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

Feedback?

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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: -

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

Backup

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

EMSA Key Transfer Protocol

mesh key distributor

mesh node

supplicant


PMK-MA Delivery

via Mesh Action

Mesh authenticatorsecurity 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

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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.

Category Action Contents

Octets: 1 1 variable

Cate-gory

Action Value

Description

0 0 Mesh key holder security establishment: Establishes a security context between two MPs, including the distribution of a PMK-MA.

0 1 PMK-MA delivery push: Facilitates delivery of a key in the mesh key hierarchy to a mesh authenticator.

0 2 PMK-MA Confirmation: Sent by a mesh authenticator to confirm key delivery.

0 3 PMK-MA Request: Sent by a mesh authenticator to request key delivery.

0 4 PMK-MA delivery pull: Facilitates delivery of a key in the mesh key hierarchy to a mesh authenticator.

0 5 PMK-MA delivery delete: Facilitates key deletion at a mesh authenticator.

0 6 Mesh EAP encapsulation: Permits transport of EAP authentication messages between a mesh authenticator & mesh key distributor.

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

Details: EAP Authentication IE

Element ID

Length EAP Message Type

Message Token

SPA Message Fragments

MIC Control

MIC

Octets: 1 1 1 16 6 1 2 16

• 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 algorithm Reserved IE count

Bit: B0 – B3 B4 – B7 B8 – B15

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

Details: EAP Message IE

Element ID

Length Fragment Control

EAP Message Fragment

Octets: 1 1 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

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

0: IDLE 1: LISTEN 2: OPEN_SENT 3: CONFIRM_RCVD 4: CONFIRM_SENT

5: ESTABLISHED 6: HOLDING

0 1

2

4

5 6PassivOpen / -

CancelLink / -

ActiveO

pen / S

endOpen

ActiveOpen / SendOpen

Open / SendC

onfirm

Open / Send Open + Confirm

Confirm / -

Confirm / -

CancelLink / Close

Clo

se /

-

Close / -

Close / -

(RetryTimer) / SendClose

or *Timeout

CancelLink or Timeout(CancelTimer) / SendClose

Timeout(RetryTimer) / SendOpen

Timeout(RetryTimer) / SendOpen

Open / CloseConfirm / CloseClose / -

CancelLink

CancelLink

Open / SendConfirm

3

Open / C

onfirm

CancelLink or

(RetryTimer) / SendClose

Close / Close

or *Timeout

Legend

transition

Event / Action Timeout(OpenTimer) / Close

Close/-

Robust Peer Link Establishment State Machine

November 2006


doc.: IEEE 802.11-06/1625r1

Submission

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)

Documents

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