1. A Function Orientated Mesh Security Model
March 2006
doc.: IEEE /0493r0
March 2006
A Function Orientated Mesh Security Model
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
Robert Moskowitz, ICSAlabs
Robert Moskowitz, ICSAlabs

2. Topics Purpose of talk March 2006 Begin Discuss open items:
Forwarding,
Internal Routing, External Routing
Mesh Formation
Discussion of security concepts & Mesh
Mesh & Joining a mesh – Authentication & Authorization
Roles in Mesh for Forwarding, Internal Routing, External Routing, and Mesh Formation
Robert Moskowitz, ICSAlabs

3. Define ‘Mesh’ Mesh March 2006
A tightly bound collection of APs providing packet forwarding services
A mesh typically provides these services to STAs that have application services needing network connectivity
It is this forwarding service that defines the mesh as an entity
Contact to any forwarding AP is contact to the mesh
This is called ‘Fate sharing’: What happens to one forwarder can impact all
Robert Moskowitz, ICSAlabs

4. Define Forwarding Service
March 2006
Define Forwarding Service
A forward service moves a datagram to its destination
Forwarding is done on a per-link basis
Routing service
controls the forwarding service
Runs as application
Transport
Uses mesh transit
Wants ETE transport
Robert Moskowitz, ICSAlabs

5. March 2006
doc.: IEEE /0493r0
March 2006
‘Joining’ a Mesh
There are two, disjoint reasons a wireless device ‘joins’ a mesh
Become a member of the forwarding service
Be a mesh AP
Support routing service (End-to-end)
Use mesh forwarding service to transport datagrams from/to the STA
A device MUST only be permitted to become a member of the forwarding service if so authorized.
Authenticated as an ID that must equate to a key structure.
Robert Moskowitz, ICSAlabs
Robert Moskowitz, ICSAlabs

6. The 3 Node Mesh Myth March 2006 Focus: Link security = mesh security
A to B and B to C forwarding paths exist
The creation of path A to C creates more than “link” security encryption.
The loss of A to B creates a new security risk for traffic from A to B
C might be compromised
So security for the mesh is increased if the A to C link is uniquely Authenticated and secured C A B
Robert Moskowitz, ICSAlabs

7. Why is it a Myth March 2006 Mesh link security != mesh security
Nodes in middle may modify data
Nodes in Middle may be required to modify packets (HWMP routing)
A to E traffic may be forwarded through D
A has no control of its relationship with D
Any authentication and security for an A to C link does NOT reduce the risk of A to E traffic
This is what ‘Fate Sharing’ is all about B E A C D
Robert Moskowitz, ICSAlabs

8. A Myth for the Link Focused
March 2006
A Myth for the Link Focused
Security claims are dangerous things
They must truly reflect the risk model
Since any 3 forwarding node mesh could quickly turn into a 4 or n forwarding node mesh
Deplorers will not understand their exposure
Links != mesh B E A C D
Robert Moskowitz, ICSAlabs

9. Authentication ‘to the Mesh’
March 2006
Authentication ‘to the Mesh’
A wireless device authenticates to an AP that is a member of the forwarding service
At authentication time, the only thing the AP can believe is the device is an external STA
The AP obtains the Authorizing information from the AS and if more than an External STA invites the STA to Authenticate to Authorized Mesh services (forwarding, routing, etc.)
This initial authentication should use i and the resultant keys are used to protect authentication to authorized services
Robert Moskowitz, ICSAlabs

10. Authentication ‘to the Mesh’
March 2006
Authentication ‘to the Mesh’
Once the device is Authorized as a mesh AP and authenticated into the forwarding service
The mesh AP can be authenticated into the routing service
Any further contact to mesh through other mesh APs
Does not change its authorization to the routing service
Which will update the forwarding service
Thus nothing is gained, or defended, by requiring a unique, new, Authentication to the new contact point
Caveat
If the device also requires transport unique transport authentication MAY be needed
More on this later
Robert Moskowitz, ICSAlabs

11. Authorization Roles AS is storehouse of Authorization Roles
March 2006
Authorization Roles
AS is storehouse of Authorization Roles
AS may be an
External server (e.g. RADIUS)
PKI with roles in certificates
Local PDB (as is frequently used with IPsec)
The mesh, through the initial contact mesh AP as Authenticator, is notified of a Supplicant’s role
AS will only allow an Authenticator to accept Supplicant roles based on the Authenticator’s Role
Robert Moskowitz, ICSAlabs

12. What are Roles MPP MP MAP LWMP ExAP ExSTA
March 2006
What are Roles
MPP MP
MAP
LWMP
ExAP
ExSTA
Note:LWMP and ExSTA can never be Authenticators
See later slide
Robert Moskowitz, ICSAlabs

13. Roles Played and Allowed Supplicants
March 2006
doc.: IEEE /0493r0
March 2006
Roles Played and Allowed Supplicants
Authorized Role
Can be Authenticator
Supplicant Authorized as
MPP X
Any Mesh MP
MAP
Any
LWMP
ExAP
ExSTA
MPP needs some function
Robert Moskowitz, ICSAlabs
Robert Moskowitz, ICSAlabs

14. In the Beginning Everything is a STA
March 2006
In the Beginning
Everything is a STA
Only device really defined in
Yes APs are in but what trustable management frames positively differentiate an AP from a STA
That is, without Digital Signatures on Beacons and Associates and time stamps to prevent replay attacks, all content is at best a hint
Hints SHOULD be used to order contact exchange
LWMP starts contact to MP
MP without Mesh state starts contact to MP with Mesh state
Consider i authentication (i.e X)
Avoid dual 802.1X exchanges
Device is authenticating to MESH, not peer
Robert Moskowitz, ICSAlabs

15. Roles – from Investigations suggestions
March 2006
Roles – from Investigations suggestions
Mesh Formation
Forwarding – comments on AP
Routing
Transport
Robert Moskowitz, ICSAlabs

16. AP Function & Forwarding
March 2006
AP Function & Forwarding
All the AP function means is that this mesh node interacts with the AS as an AP.
If the AS is RADIUS, added RADIUS functionality (What is the AP’s IP address? What is its Secret) may be needed
Since all APs also have the Forwarding function, the Forwarding function MAY be used to secure the Authenticator-AS converation
Robert Moskowitz, ICSAlabs

17. Mesh Formation – aka ‘joining’ the mesh
March 2006
Mesh Formation – aka ‘joining’ the mesh
A node, authenticated to the mesh (device on the mesh), is not yet authenticated to any of its authorized functions
Mesh authentication may be implied
Each authorized function needs its own authentication.
Piggy-backing may be developed to optimize startup cost
This approach allows each function to be optimized to its security risk model.
Robert Moskowitz, ICSAlabs

18. March 2006
Routing Function
Routing contains both Multicast and Unicast protocol functions
‘Standard’ MSEC methods may be used to add the node to the secure multicast group
Including any depart or dismiss activities by the multicast group
e.g. TELSA may be appropriate here
This applies for both internal and external routing
Once a node is added to the secure multicast group, no further authentication is needed as the node gains links to the mesh
Robert Moskowitz, ICSAlabs

19. Transport Function For External APs and STAs For LWMP
March 2006
Transport Function
For External APs and STAs
Use r to secure transport
External STAs MUST distrust the Mesh security
For LWMP
Group key for all datagrams
LWMP MUST trust the mesh security for forwarding/routing services
For other Mesh Nodes
Same as LWMP
Robert Moskowitz, ICSAlabs

20. March 2006
QUESTIONS?
Robert Moskowitz, ICSAlabs

21. Purpose of Authentication
March 2006
Purpose of Authentication
Establishes devices ‘right’ to be part of, or connected to Mesh
Notifies both parties of roles
For Mesh nodes
Provides list of nodes by role
For External (non-mesh) nodes
Set up is complete and ready for use
Robert Moskowitz, ICSAlabs

22. Further thoughts on Transport
March 2006
Further thoughts on Transport
Do LWMPs really ‘trust’ the mesh security?
If not use r?
But can multiple links be kept active as required for an LWMP?
In a Campus of multiple meshes in an ESS, how best to authenticate LWMP?
802.11r?
Robert Moskowitz, ICSAlabs