1. Mesh Security Proposal
Month Year
doc.: IEEE yy/xxxxr0
June 2006
Mesh Security Proposal
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
Zhao and Walker, Intel Corporation
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
June 2006
Abstract
This submission proposes a security architecture for s draft to
Establish mesh transport security
Extend AP security
Zhao and Walker, Intel Corporation
John Doe, Some Company

3. Agenda Problem statement Security goals
Month Year
doc.: IEEE yy/xxxxr0
June 2006
Agenda
Problem statement
Security goals
Transport and Mesh formation security proposal
AP security proposal
Discussion
Zhao and Walker, Intel Corporation
John Doe, Some Company

4. Problem Statement Security for mesh transport and mesh formation means
Month Year
doc.: IEEE yy/xxxxr0
June 2006
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 if possible
Security for AP means
Allow only authorized mesh devices to offer the AP function or detect when unauthorized devices do so
Zhao and Walker, Intel Corporation
John Doe, Some Company

5. Month Year
doc.: IEEE yy/xxxxr0
June 2006
Goals
Develop a security architecture for Mesh Transport and Mesh AP functions
Reuse i where possible
More specifically, achieve security with existing authentication mechanisms where possible
Define a flexible architecture adaptable to different deployment models
Zhao and Walker, Intel Corporation
John Doe, Some Company

6. Month Year
doc.: IEEE yy/xxxxr0
June 2006
Proposal Overview
First, use Mesh link state discovery and maintenance to establish association between MPs
While establishing link state, negotiate Supplicant and Authenticator roles
This is a new phase we introduce in order to allow using i authentication and key management protocols relatively unchanged
The detailed design is deferred until the link state discovery state machine is in place
Finally, initiate authentication and key management protocols as defined in i (with minor changes)
Insert the Supplicant’s GTK into 4-Way Handshake message 2
Zhao and Walker, Intel Corporation
John Doe, Some Company

7. Proposal Overview June 2006 Authentication Server Supplicant
Month Year
doc.: IEEE yy/xxxxr0
Proposal Overview
June 2006
Authentication Server
Supplicant
Authenticator
Link state and security capabilities discovery
Link state maintenance, Security and Role negotiation
Authentication
key management
Session Key distribution
Data protection: TKIP and CCMP
Zhao and Walker, Intel Corporation
John Doe, Some Company

8. Link State Discovery and Maintenance
Month Year
doc.: IEEE yy/xxxxr0
June 2006
Link State Discovery and Maintenance
Defined by Clause 11A.3.2
Defines the mesh analogue of association
Creates a link between two mesh peers
Detailed state machines still under development
The state machines will address the cipher suite negotiation problem
The details will affect how i security plugs into mesh: who can be Supplicant and who Authenticator
We plan to insert a new information element in Beacons and Probe Responses to advertise AS reachability
We plant to insert the new information element into Link State establishment frames to negotiate which peer is Authenticator and which is supplicant
Zhao and Walker, Intel Corporation
John Doe, Some Company

9. 802.11i Pairwise Key Hierarchy
Month Year
doc.: IEEE yy/xxxxr0
June 2006
802.11i Pairwise Key Hierarchy
Pairwise Master Key (PMK) : 256 bit Access token
Pairwise Transient Key (PTK) = i-PRF(PMK, min(AP Nonce, STA Nonce) || max(AP nonce, STA Nonce) || min(AP MAC Addr, STA MC Addr) || max(AP MAC Addr, STA MAC Addr))
Key Confirmation Key (KCK) – PTK bits 0–127
Key Encryption Key (KEK) – PTK bits 128–255
Temporal Key – PTK bits 256–n – can have cipher suite specific structure
Analog of the WEP key
Zhao and Walker, Intel Corporation
John Doe, Some Company

10. EAPOL-Key(SNonce, MIC, GTK1, STA RSN IE)
Month Year
doc.: IEEE yy/xxxxr0
June 2006 AP
4-Way Handshake
STA
PMK
PMK
Pick Random ANonce
EAPOL-Key(ANonce)
Pick Random SNonce, Derive PTK = i-PRF(PMK, ANonce || SNonce || AP MAC Addr || STA MAC Addr)
Pick group key GTK1, wrap it
EAPOL-Key(SNonce, MIC, GTK1, STA RSN IE)
Derive PTK, Unwrap GTK1 (Can be done later)
EAPOL-Key(ANonce, MIC, AP RSN IE, GTK2)
EAPOL-Key(SNonce, MIC)
Zhao and Walker, Intel Corporation
John Doe, Some Company

11. Month Year
doc.: IEEE yy/xxxxr0
June 2006
Discussion
Once authenticator and supplicant roles are decided, only ONE round of authentication and key management protocol is needed
One 4-way handshake is used to establish PTK for the session and TWO group keys by each MP for future broadcast message protection
GTK1 is transmitted in message 2
This design maintain the implementation and security of the 4-way handshake
Advantage: message 2 is a protected and reliable message
Overhead:
Supplicant generate and wrap GTK1 before sending message 2
Length of message 2 is increased
Authenticator unwrap GTK1 once receive message 2 (optional)
Zhao and Walker, Intel Corporation
John Doe, Some Company

12. 802.1X Authentication Server (Review)
Month Year
doc.: IEEE yy/xxxxr0
June 2006
802.1X Authentication Server (Review)
A logical entity that contains a database for authenticating at least immediate neighbors
It can be local and distributed, e.g., MP carry a database of other devices’ authentication credentials
It can be a small, e.g., a root key used to verify certificates held by other devices
It can be remote, e.g., RADIUS server.
Assumption: communication between authenticator and authentication server (local or remote) is authenticated and protected
And not in our scope
Zhao and Walker, Intel Corporation
John Doe, Some Company

13. Rationale Solution separates concerns
Month Year
doc.: IEEE yy/xxxxr0
June 2006
Rationale
Solution separates concerns
Security solution doesn’t have to solve the link establishment problem that is solved more easily directly (i.e., without security)
Establishing link separately greatly simplifies what security has to do
Design solves bootstrapping problem
But if we use 802.1X for authentication, each MP needs to be able to play three roles: Supplicant, Authenticator, and Authentication Server
Each MP needs to have some authenticated database to be able to directly authenticate the expected nearest neighbors, because an external AS may be unreachable by either peer
Zhao and Walker, Intel Corporation
John Doe, Some Company

14. Securing the AP There is nothing to be done
Month Year
doc.: IEEE yy/xxxxr0
June 2006
Securing the AP
There is nothing to be done
802.1X Clause and says authentication fails if the AS is not reachable from the Authenticator
This means AS reachability issue is solved from security perspective
Zhao and Walker, Intel Corporation
John Doe, Some Company

15. Month Year
doc.: IEEE yy/xxxxr0
June 2006
Summary
802.11i can be used almost without change by relying on the peer-to-peer link establishment mechanism defined in s 11A.3.2
Still need a mechanism to negotiate Authenticator and Supplicant
Need to use the 4-Way Handshake to distribute the Supplicant’s Group Key
802.1X Clause 8.2 already solves the AS reachability problem for APs
If we rely on 802.1X, then every MP must implement Supplicant, Authenticator, and Authentication Server Roles to support mesh formation when the AS is unreachable
Zhao and Walker, Intel Corporation
John Doe, Some Company

16. Feedback? June 2006 Month Year doc.: IEEE 802.11-yy/xxxxr0
Zhao and Walker, Intel Corporation
John Doe, Some Company