A security model for wireless meshs March 2005 doc.: IEEE 802.11-05/0172r2 March 2005 A security model for wireless meshs Date: 2005-03-15 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

March 2005 doc.: IEEE 802.11-05/0172r2 March 2005 Abstract The security model for an 802.11s mesh is different from STA-AP (Infrastructure) or STA-STA (AdHoc) model. It more mirrors that of an ethernet backbone of 802.1D bridges, which is the model for 802.1AE. This model will include authenticating APs to the mesh, session key exchange, and datagram protection. Robert Moskowitz, ICSAlabs Robert Moskowitz, ICSAlabs

Goals Provide datagram protection between APs of the mesh March 2005 Goals Provide datagram protection between APs of the mesh Provide session keys for datagram protection Provide AP authentication to other APs of the mesh Robert Moskowitz, ICSAlabs

Limitations imposed by 802.11i March 2005 Limitations imposed by 802.11i Datagram protection includes authenticating headers along with encrypting and authenticating data content 802.11 header contents MUST be modified to forward a datagram to the next AP in the mesh Only hop-by-hop protection is possible with the 802.11i framing This exposes data to each AP, one of which may be compromised Can we do better? Robert Moskowitz, ICSAlabs

Minimum Functional Requirements March 2005 Minimum Functional Requirements Number Functional catagory Name Coverage Notes FR4 TOPO_RT_FWD Mesh Broadcast Data Delivery P Does not complicate FR5 Mesh Unicast Data Delivery FR7 Mesh Network Size C 1 key per AP scales easily FR8 SECURITY Mesh Security FR10 SERV_CMP Backwards compatibility with legacy BSS and STA STA has the same security behaviour Robert Moskowitz, ICSAlabs

Minimum Functional Requirements March 2005 Minimum Functional Requirements Number Functional catagory Name Coverage Notes FR11 SERV_CMP Use of WDS 4-Addr Frame or Extension C Header included in AAD Robert Moskowitz, ICSAlabs

What if we could use a different format? March 2005 What if we could use a different format? Consider a format model similar to ESP-AH Data encrypted with ESP and headers and data authenticated with AH AES-CCM applied but without the AAD AES-CBC applied over AAD and CCM envelope Adds 8 octets Each forwarding AP removes outer authentication and reauthenticates End to end data privacy! But no control over PN by forwarding APs Possible to have duplicate PNs coming from different APs Thus must also add PN for 8 octets Robert Moskowitz, ICSAlabs

What if we could use a different format? March 2005 What if we could use a different format? Originating AP encrypts for end AP and authenticates for next AP But what is the end AP? Station could roam by the time forwarding is competed! And data still exposed on 2 APs Is this really worth it? Can we provide end-to-end? STA uses this new framing format, encrypts for end STA (or Mesh Portal) and authenticates for AP STA MUST always use new format, as it has no knowledge of the ESS structure Major change away from 802.11i How does STA key with another STA? How does STA learn Mesh Portal and set up a key Robert Moskowitz, ICSAlabs

What about encapsulation? March 2005 What about encapsulation? First, End-to-end security not possible STA to STA or STA to Mesh Portal STA’s security is to its AP current model Encapsulation layer provides entry to exit AP security Same problem with AAD Robert Moskowitz, ICSAlabs

What if we could use a different format? March 2005 What if we could use a different format? WE CAN’T 802.11s MESH will be Hop by Hop protection Robert Moskowitz, ICSAlabs

Session Keys for the Mesh APs March 2005 Session Keys for the Mesh APs Two choices Unicast keys between APs Group keys, one per AP For unicast keys Could key when there is a working link between APs Delay on first contact How are keys cached and aged To avoid key exchange every time of contact Could use pre-authenticaiton Still need to consider key caching and aging How does AP discover other APs? Keys for all APs in mesh or only discovered APs? Robert Moskowitz, ICSAlabs

Session Keys for the Mesh APs March 2005 Session Keys for the Mesh APs For group keys AP creates group key and delivers it to first contacted mesh AP How is group key protected at this point with no unicast key? AP forwards group key to all other APs in Mesh Addition to mesh routing protocol? Mesh AP forwards all current group keys to new AP How? Annealed meshes result in key forwarding in both directions Key owner determines its lifetime and starts its propagation All APs have N keys at all times Robert Moskowitz, ICSAlabs

Session Keys for the Mesh APs March 2005 Session Keys for the Mesh APs Group keys are cleaner to deploy and scales better In my not so humble opinion! What about risks? With group keys a compromised AP will have all keys in mesh With unicast keys a compromised AP will have keys for all APs it ever had or likely to have a link to With group keys whole mesh has to rekey With unicast keys any AP that had a key from compromised AP deletes that key Group keys do have a greater risk Unicast key recovery is less disruptive Recommend to use Group keys Compromised AP potential disaster regardless of model AP could alter routing to force all traffic through it until discovered Robert Moskowitz, ICSAlabs

Authentication of AP to mesh March 2005 Authentication of AP to mesh In PSK mode Mesh AP starts exchange similar to the 4-way handshake, but is providing its group key to mesh Note that a compromised AP requires changing PSK Unicast key approach would have to completely rekey as well Joining AP includes its group key in handshake Mesh AP sends its group key in handshake Mesh AP sends all other keys in mesh after successful handshake If this is a mesh annealing event, joining AP sends all keys of its mesh Robert Moskowitz, ICSAlabs

Authentication of AP to mesh March 2005 Authentication of AP to mesh With X.509 certificates Assumption: Any AP can validate any other AP’s certificate Assume CRL distribution not an issue at join time Joining AP does not send any data until it can retrieve the current CRL to validate other cert Joining AP originates a SIGMA exchange (as in IKE) to establish MK between it and mesh AP Just use IKEv2? Kind of complex for this application Rest is same process as in PSK mode If this is a mesh annealing event, joining AP sends all keys of its mesh Robert Moskowitz, ICSAlabs

Authentication of AP to mesh March 2005 Authentication of AP to mesh With EAP over RADIUS with 802.1X mode Each AP is a RADIUS client With all that entails including fixed IP addresses IETF could fix this Fixed addresses will probably be the rule in meshes Mesh build-out starts from Mesh Portal Any other join attempts will time out Once MK installed, process same as other modes Robert Moskowitz, ICSAlabs

Configuration Requirements March 2005 Configuration Requirements Surprising little! What is your trust model and authentication method? In PSK mode Install shared secret in all mesh APs Ability to change secret in and out of band In X.509 certificates Install AP certificate Set valid certificate policy E.G. issuerName and OU CRLs will arrive over IP via crlDistributionPoint HTTP, LDAP, other per CA technology In EAP with RADIUS mode IP address (or FQDN) of RADIUS server(s) RADIUS Shared secret AP Identity UserID and Password, X.509 certificate And that is all Robert Moskowitz, ICSAlabs

Configuration Requirements March 2005 Configuration Requirements IP address for mesh AP is outside the scope of the security functions But RADIUS imposes static IP addresses X.509 CRLs cannot be retrieved until IP services functioning Policy for operating with a potentially stale CRL E.G. no STA packet forwarding until new CRL retrieved E.G. Always trust a non expired CRL until told otherwise Retrieve new CRL(s) as cached ones expire Robert Moskowitz, ICSAlabs

Summary No change to 802.11i security frames Group keys used March 2005 Summary No change to 802.11i security frames Group keys used AP always transmits to mesh with its group key Minimal configuration requirements PSK and SIGMA-cert provide clean mesh startup Issue with CRL with certificates RADIUS usage imposes a span-out mesh setup Robert Moskowitz, ICSAlabs

March 2005 QUESTIONS? Robert Moskowitz, ICSAlabs