A Function Orientated Mesh Security Model

Slides:



Advertisements
Similar presentations
LB84 General AdHoc Group Sept. Closing TGn Motions
Advertisements

[ Interim Meetings 2006] Date: Authors: July 2005
Resource Request/Response Discussion
TGn Sync Atlanta Presentation on Confirmation
IEEE White Space Radio Contribution Title
TGu/TGv Joint Session Date: Authors: July 2005 July 2005
LB73 Noise and Location Categories
LB73 Noise and Location Categories
Waveform Generator Source Code
March 2014 Election Results
TGp Closing Report Date: Authors: July 2007 Month Year
Attendance and Documentation for the March 2007 Plenary
3GPP Extended Date: Authors: July 2005 July 2005
[ Policies and Procedure Summary]
Motion to accept Draft p 2.0
Protected SSIDs Date: Authors: March 2005 March 2005
3GPP liaison report July 2006
[place presentation subject title text here]
Pre-Authentication Authentication of Management Frames
TGp Motions Date: Authors: November 2005 Month Year
TGp Closing Report Date: Authors: March 2006 Month Year
TGu-changes-from-d0-02-to-d0-03
TGp Closing Report Date: Authors: May 2007 Month Year
Contribution on Location Privacy
Quick Beacon Impacts on LB 92
Call for OLSR Participation
November Opening Report
TGp Closing Report Date: Authors: March 2006 Month Year
March 2007 doc.: IEEE /0389r0 March 2007
Reflector Tutorial Date: Authors: July 2006 Month Year
CID#102 - Channel Allocation for P2P
TGv Redline D0.07 Insert and Deletion
TGu Timeline Date: Authors: January 2005 January 2005
TGv Redline D0.06 Insert and Deletion
Solution for comment 32 Date: Authors: July, 2008
ADS Study Group Mid-week Report
IEEE P Wireless RANs Date:
TGu-changes-from-d0-01-to-d0-02
LB73 Noise and Location Categories
TGy draft 2.0 with changebars from draft 1.0
TGv Redline D0.10 Insert and Deletion
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
Redline of draft P802.11w D2.2 Date: Authors:
TGp Closing Report Date: Authors: March 2007 Month Year
TGr Proposed Draft Revision Notice
Off-channel selection
TGu-changes-from-d0-02-to-d0-03
[ Policies and Procedure Summary]
March Opening Report Date: Authors: March 2011
May 2005 CAPWAP AHC Closing Report
Proposed changes to the v Draft
Beamforming and Link Adaptation Motions
Draft P802.11s D1.03 WordConversion
Questions to the Contention-based Protocol (CBP) Study Group
Motion to go to Letter Ballot
EC Motions – July 2005 Plenary
TGu-changes-from-d0-04-to-d0-05
for video transmission, Status
Transition Nowhere Date: Authors: Sept 2005 Sept 2005
TGu-changes-from-d0-03-to-d0-04
TGu Timeline Date: Authors: January 2005 January 2005
TGu Motions Date: Authors: May 2006 May 2006
New User Plane Requirement
MAC Address Spoofing in Mesh
WAPI Position Paper Sept 2005 Sept 2005 IEEE WG
Use of KCK for TGr Management Frame Protection
TGu Timeline Date: Authors: July 2005 July 2005
TGr Proposed Draft Revision Notice
TGp Motions Date: Authors: January 2006 Month Year
May 2012 Opening Report Date: Authors: May 2012
Presentation transcript:

A Function Orientated Mesh Security Model March 2006 doc.: IEEE 802.11-06/0493r0 March 2006 A Function Orientated Mesh Security Model Date: 2006-3-8 Authors: 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 <stuart.kerry@philips.com> 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 <patcom@ieee.org>. Robert Moskowitz, ICSAlabs Robert Moskowitz, ICSAlabs

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

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

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

March 2006 doc.: IEEE 802.11-06/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

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

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

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

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 802.11i and the resultant keys are used to protect authentication to authorized services Robert Moskowitz, ICSAlabs

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

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

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

Roles Played and Allowed Supplicants March 2006 doc.: IEEE 802.11-06/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

In the Beginning Everything is a STA March 2006 In the Beginning Everything is a STA Only device really defined in 802.11 Yes APs are in 802.11-1999 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 802.11i authentication (i.e. 802.1X) Avoid dual 802.1X exchanges Device is authenticating to MESH, not peer Robert Moskowitz, ICSAlabs

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

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

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

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

Transport Function For External APs and STAs For LWMP March 2006 Transport Function For External APs and STAs Use 802.11r 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

March 2006 QUESTIONS? Robert Moskowitz, ICSAlabs

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

Further thoughts on Transport March 2006 Further thoughts on Transport Do LWMPs really ‘trust’ the mesh security? If not use 802.11r? 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