1. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 1 A security model for wireless meshs 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, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-07-19 Authors:

2. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 2 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 and 802.1af. However, neither.1AE or.1af are at a point that they should be used for.11s. This model will include authenticating APs to the mesh, session key exchange, and datagram protection.

3. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 3 Goals Provide datagram protection between APs of the mesh Provide session keys for datagram protection Provide AP authentication to other APs of the mesh

4. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 4 The Problems A Mesh AP must be able to: –Establish trust with other Mesh APs (that is authenticate with others) –Establish trust with associated STAs –Protect data it sends to other Mesh APs –Protect data it sends to associated STAs The 2 nd and 4 th requirements are kind of met by 802.11i, it is the other two that we need to address

5. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 5 More on the Problems Protecting data takes two things: –Keys –Encrypted data envelopes With all those other good things like integrity check 802.11i provides the data envelopes –And some of the keys, but not all –Some of the keys are from other services like 802.1X

6. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 6 And yet More APs have a challenge in protecting STA specific and ‘general’ traffic –Per STA unicast keys Addresses the lack of trust between STAs –Per AP group key An important question is: –What is the trust model between Mesh APs? –Or more specifically, what is the trust between Mesh APs for forwarding STA specific traffic My answer is: Complete Trust

7. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 7 Mesh AP Trust model All APs MUST trust each other for broadcast/multicast traffic No AP knows which other APs will ‘touch’ STA specific traffic –And it may change from the time the AP ‘releases’ the data to the mesh if the STA roams Thus a Mesh AP need not use unicast keys, but can use group keys for even STA specific traffic

8. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 8 But What about Compromised Mesh APs? –Since there is no way to tell what traffic went through the compromised AP And it might have even changed the routing to get more traffic through it –Discovery of a Compromised AP requires complete mesh rekeying And if a group authentication key is used, replacement of that to! –There is little after the event analysis to determine what was compromised

9. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 9 But What about APs that leave the mesh and still have the group keys of all the other APs? –Is this really a security event? Did it really leave or only temporarily disconnected?

10. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 10 Mesh AP Trust model Premise Once an AP is authenticated to the mesh it is trusted by all other mesh APs and it trusts them Go read 802.1AE Each AP manages its own group key, including rekeying –The mesh MAY use mechanisms to forward an AP’s group key to all the APs in the mesh –This is a good optimization

11. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 11 Points of Note An AP that is both a mesh AP and has associated STAs transmits broadcast/multicast TWICE –Once with the group key known to the STAs –Once with the group key known to the mesh APs –This is a necessary evil Different trust models Mesh has to avoid broadcast storm –And the routing people say it is cleaner this way

12. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 12 Mesh authentication and Group keys Let’s use 802.1X just like in 802.11i Adhoc mode! Well we COULD, but –Dictates use of EAP –Very chatty –The PSK model not really secure Think IKEv2 –Known security model –Securely supports shared key methods And not chatty –Can support EAP if you really want it

13. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 13 But is it really IKEv2? Well it is not over UDP Can use 802.1X EAPOL-Key format –Ends up looking much like PSK mode? Does not create an IPsec SA –Rather a GTKSA

14. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 14 Where to go from here Work with any 11s proposal Develop group key ‘flooding’ method

15. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 15 Questions?

16. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 16 Slides included from prior version From 172r3 Included for historic reference

17. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 17 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?

18. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 18 Minimum Functional Requirements Number Functional catagory NameCoverageNotes FR4 TOPO_RT_FWDMesh Broadcast Data Delivery PDoes not complicate FR5 TOPO_RT_FWD Mesh Unicast Data Delivery PDoes not complicate FR7 TOPO_RT_FWD Mesh Network Size C1 key per AP scales easily FR8 SECURITY Mesh Security C FR10 SERV_CMP Backwards compatibility with legacy BSS and STA C STA has the same security behaviour

19. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 19 Minimum Functional Requirements Number Functional catagory NameCoverageNotes FR11 SERV_CMPUse of WDS 4- Addr Frame or Extension C Header included in AAD

20. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 20 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

21. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 21 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

22. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 22 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

23. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 23 What if we could use a different format? WE CAN’T 802.11s MESH will be Hop by Hop protection

24. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 24 Session Keys for the Mesh APs Two choices –Unicast keys between APs –Group keys, one per AP

25. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 25 Unicast Session Keying 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-authentication –Still need to consider key caching and aging –How does AP discover other APs? Keys for all APs in mesh or only discovered APs? Still need group keys for broadcast to neighbour APs? –And thus mechanism to distribute them

26. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 26 Group Session Keying AP creates group key and delivers it to first contacted mesh AP –How is group key protected at this point with no unicast key? Benefit for a Diffie-Hellman exchange 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

27. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 27 Session Keys for the Mesh APs Group keys are cleaner to deploy and scale 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

28. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 28 Authentication of AP to mesh Pre-shared key –Really a group key X.509 certificates ESP with RADIUS

29. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 29 Authentication With a Pre-shared Key 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 This whole exchange might be possible with IKEv2 over EAPOL- Key Exchange keys discarded

30. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 30 Possible Mesh AP Handshake * The Devil is in the Details + HDR, SAi, KEi, Ni HDR, SAr, KEr, Nr AP Derive Diffie-Hellman key Expand to: SKie,SKia,SKpi,SKre,SKra,SKpr Mesh AP HDR, SK {IDi, [CERTi,], AUTH} SK is Encrypt and (HMAC or SIGN) function AUTH is (HMAC or SIGN) of (first packet, Nr, HMAC(SKpi,IDr) HDR, SK {IDr, [CERTr,], AUTH, GKr [,GKlist]} AUTH is (HMAC or SIGN) of (second packet, Ni, HMAC(SKpr,IDi)) HDR, SK {GKi [,GKlist]} * Based on SIGMA which is the model for IKE and IKEv2 + Can we just use IKEv2?

31. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 31 Authentication 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 the exchange to establish MK between it and mesh AP –Just use IKEv2? Just use IKEv2 over EAPOL-Key? Including GK sharing as in PSK mode If this is a mesh annealing event, joining AP sends all keys of its mesh

32. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 32 Authentication with EAP over RADIUS 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 –Or with AP that has the RADIUS server –Any other join attempts will time out Once MK installed, process same as other modes

33. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 33 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

34. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 34 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

35. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 35 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

36. doc.: IEEE 802.11-05/0172r4 Submission July 2005 Robert Moskowitz, ICSAlabsSlide 36 QUESTIONS?