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 detailed 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
In particular, enable s to support other security approaches not contemplated by the authors
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
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
Both parties’ control ports are blocked once starting link establishment, until the end of 4-way handshake
Zhao and Walker, Intel Corporation
John Doe, Some Company

7. Architecture Security Capability Discovery
Month Year
doc.: IEEE yy/xxxxr0
June 2006
Architecture
Security Capability Discovery
Role Negotiation and Security Negotiation
Key Management
Zhao and Walker, Intel Corporation
John Doe, Some Company

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

9. 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 may have some authenticated database 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

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

11. Discovery and Negotiation Goals
Month Year
doc.: IEEE yy/xxxxr0
June 2006
Discovery and Negotiation Goals
Discovery
Discover the available mesh for joining
What Authenticated Key Management (AKM) Protocol, Unicast and Multicast Ciphersuites are available?
Negotiation—Enable parties to agree on the security roles and security policy to use with an association
Who’s the authenticator, who’s the supplicant?
Agree on which of those options enabled to use
Goals
Interoperability with already-deployed and non i legacy STAs
Enable the authentication role negotiation
Prevent MPs from join mesh as a STA
Create mechanism for extending i framework to permit AKMs, Ciphersuites not defined by i
Minimize new overhead in Beacons
Zhao and Walker, Intel Corporation
John Doe, Some Company

12. RSN Information Element
Month Year
doc.: IEEE yy/xxxxr0
June 2006
RSN Information Element
Element ID
Length
Version
Group Key Ciphersuite Selector
Pairwise Ciphersuite Count
Pairwise Ciphersuite List
AKM Count
AKM List
Capabilities
PMK ID Count
PMK ID List
Mesh Default, Auth Always Possible = unused Capabilities field bits
Zhao and Walker, Intel Corporation
John Doe, Some Company

13. RSN Capability Bits Mesh Default: Auth Always Possible
June 2006
RSN Capability Bits
Mesh Default:
If set to 1, use the role determination mechanism specified in
If set to 0, use a role determination mechanisms specified elsewhere (another information element)
Auth Always Possible
Set to 1 if the sender can always authenticate (e.g., a mesh-wise Authentication Server is reachable)
Set to 0 if the sender has to rely on a local database
Zhao and Walker, Intel Corporation

14. Discovery June 2006 Advertises the sender can reach the AS Month Year
doc.: IEEE yy/xxxxr0
June 2006
Discovery
Probe Request
Beacon or Probe Response + RSN IE (AP supports CCMP Mcast, CCMP Ucast, 802.1X Auth, Mesh Default = 1, Auth Always Possible = 1)
Advertises the sender can reach the AS
Zhao and Walker, Intel Corporation
John Doe, Some Company

15. Role Negotiation Goal: Decide roles for authentication
Month Year
doc.: IEEE yy/xxxxr0
June 2006
Role Negotiation
Goal: Decide roles for authentication
Examine the “AS Reachability” bit in RSN IE
If only one party has AS Reachability=TRUE
then this party is the Authenticator, the other is the Supplicant
If both or neither have AS Reachability=TRUE
then the one with higher MAC address becomes Authenticator, the one with lower MAC address is the Supplicant
Zhao and Walker, Intel Corporation
John Doe, Some Company

16. Association Response (success)
Month Year
doc.: IEEE yy/xxxxr0
June 2006
Security Negotiation
Supplicant
Authenticator
STA Selects Unicast Cipher Suite, Authentication and Key Management Suite from Advertised
Association Req + RSN IE (STA requests CCMP Mcast, CCMP Ucast, 802.1X Auth, Mesh Default = 1, Auth Always Possible = ANY)
Association Response (success)
Zhao and Walker, Intel Corporation
John Doe, Some Company

17. Discovery and Negotiation Discussion
Month Year
doc.: IEEE yy/xxxxr0
June 2006
Discovery and Negotiation Discussion
Beaconing
MPs sends beacons with “from DS” bit turned off
Ordinary STAs will NOT respond to beacons from MPs
Remember an AS is a logical construct
A logical entity that contains a database for authenticating at least immediate neighbors
Group Ciphersuite must be lowest common denominator ciphersuite
Extensible: RSN IE permits the addition of new ciphersuites and AKMs not contemplated by i
Zhao and Walker, Intel Corporation
John Doe, Some Company

18. Key Management Goals Given a “good” PMK Guarantee fresh session key
Month Year
doc.: IEEE yy/xxxxr0
June 2006
Key Management Goals
Given a “good” PMK
Guarantee fresh session key
Demonstrate liveness of peer PMK holder
Bind session key to the communicating AP and STA
Synchronize session key use
Distribute the Group Keys
Both party needs to distribute its group key for broadcast/multicast protection
Protect Discovery and Negotiation from Downgrade attack
Establish a (statistically) unique session identifier
Zhao and Walker, Intel Corporation
John Doe, Some Company

19. EAPOL-Key(SNonce, MIC, GTK1, STA RSN IE)
Month Year
doc.: IEEE yy/xxxxr0
June 2006
Supplicant
Authenticator
4-Way Handshake
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

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

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

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

23. June 2006
Motions
Motion 1: Move to instruct the editor to incorporate into the TGs draft
Motion 2: Move to instruct the editor to incorporate into the TGs draft
Zhao and Walker, Intel Corporation

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

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