1. A security model for wireless meshs
September 2005
doc.: IEEE /0172r5
September 2005
A security model for wireless meshs
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. September 2005
doc.: IEEE /0172r5
September 2005
Abstract
The STA-AP (Infrastructure) or STA-STA (AdHoc) risk models are compared to that of a AP Mesh and from this, a necessary and sufficient security model for an AP Mesh and included Multicast groups is defined.
This model will include authenticating APs to the mesh, session key exchange, and datagram protection.
For you fellow Baby Boomers. Ever play WFF and POF (or how ever we spell it back then, been a long time) in High School? 
Robert Moskowitz, ICSAlabs
Robert Moskowitz, ICSAlabs

3. What is different between an ESS and a WDS?
September 2005
What is different between an ESS and a WDS?
And ESS consists of one or more APs used by STAs to access the DS.
No knowledge of the layer 2 structure and forwarding of the DS is assumed.
The risk to the STAs is to
Attacks by other STAs
MITM attacks by compromised APs
A compromised AP SHOULD have no effect on other APs in the ESS or STAs using those APs
That is NOT catastrophic to the ESS
Robert Moskowitz, ICSAlabs

4. What is different between an ESS and a WDS?
September 2005
What is different between an ESS and a WDS?
A WDS consists of two or more APs connected via an link
A WDS MAY be connected to one or more non networks via ‘portals’.
A WDS MUST have a packet forwarding mechanism
802.11s imposes a per-link security model
Unless static, the packet forwarding mechanism CAN be subverted to force all traffic through a selected AP
If an AP is subverted it is IMPOSSIBLE to predict the extent of the ‘damage’
A subverted AP is catastrophic to the WDS
Thus there is no measurable risk reduction in isolating unicast traffic visibility to those APs that are on the forwarding path
CAVIAT #1
A multicast group is a virtual mesh of virtual links, REQUIRING tunneling
Robert Moskowitz, ICSAlabs

5. September 2005
Security Claim #1
Group keying of ALL mesh traffic supplies a SUFFICIENT security approach.
Each AP in the mesh has a key, known to all other APs for data protection.
These group keys are INDEPENDENT of any IBSS group key used by the AP for supporting STAs
CAVIAT #1
For each multicast group that an AP is part of, the AP has a key, known to all other APs in the multicast group for data protection.
Robert Moskowitz, ICSAlabs

6. September 2005
Security Claim #2
Once an AP is authenticates its first link into the mesh, it MAY acquire all group keys within the mesh
Thus the AP authenticates to the mesh, not to individual APs within the mesh
A pairwise key is created in this initial authentication to securely pass group keys. This pairwise key has no further use.
Challenges
As the mesh grows, how are group keys distributed?
Particularly in the case of mesh ‘annealing’
When an AP rekeys, how is its group key distributed?
Do we care about departures?
If we care about PFS, how are the new keys distributed?
Robert Moskowitz, ICSAlabs

7. How can group keys be distributed?
September 2005
How can group keys be distributed?
An AP acquires the group keys of its neighbors through the neighborhood map distribution
Limits the number of group keys maintained within an AP
There is only ONE group key, or Master key for the mesh.
The CCMP sequence space is divided by Mesh AP ID
Each AP’s group key is derived from the Master key in such a manner that all APs can derive it.
Challenge
When one AP exhausts its key, how does it trigger complete mesh rekeying?
In annealing, does one Master key ‘win’ or is the whole rekeyed?
Robert Moskowitz, ICSAlabs

8. September 2005
Security Claim #3
A single Master key for the Mesh is sufficient to maintain mesh security
We know how to securely derive multiple keys from a single key
CAVEAT #1
A single Master key for each multicast group is sufficient to maintain multicast security.
Robert Moskowitz, ICSAlabs

9. September 2005
Security Claim #4
An AP, needing a new group key, generates the new Master key and propagates it across the mesh
Challenge
How is a race condition handled?
How does an AP determine which Master key to use to derive the AP group key to decrypt a packet?
Can KeyID be used?
Follow i GTK rekeying?
CAVEAT #1
Does this work for multicast groups that have a controlling node?
Robert Moskowitz, ICSAlabs

10. Observation on Multicast Groups
September 2005
Observation on Multicast Groups
A multicast group SHOULD be a virtual mesh
A multicast group MAY not be contiguous
There MAY be mesh APs, not in the group, on the forwarding path for the group
Multicast groups that MUST be secured separately from the mesh MUST be tunneled.
Without exception
Tunnel is for multicast virtual links
Multicast tree pruning MUST trigger rekeying the group
Robert Moskowitz, ICSAlabs

11. More Observation on Multicast Groups
September 2005
More Observation on Multicast Groups
An AP rejoining a group MUST reauthenticate to the group
Fast re-authentication is a requirement
This is different from i PMK caching
NOTE
If APs are removed from the mesh when they are disconnected from the mesh by rekeying the mesh
Fast re-authentication is a requirement for APs rejoining the mesh
Robert Moskowitz, ICSAlabs

12. September 2005
Security Claim #5
Authentication of an AP to the mesh MAY use existing 802.1X/EAP mechanisms
802.1X-REV discusses the challenge of which AP has access to the AS.
New authentication mechanisms MAY be very attractive
Particularly IKE over EAPOL
New EAPOL-Key ID
Strong security statement even with pre-shared keys.
Robert Moskowitz, ICSAlabs

13. September 2005
QUESTIONS?
Robert Moskowitz, ICSAlabs

14. September 2005
The following slides are from the previous versions of this presentation
For continuity
Robert Moskowitz, ICSAlabs

15. September 2005
Abstract
The security model for an s 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.
Robert Moskowitz, ICSAlabs

16. Goals Provide datagram protection between APs of the mesh
September 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

17. The Problems A Mesh AP must be able to:
September 2005
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 2nd and 4th requirements are kind of met by i, it is the other two that we need to address
Robert Moskowitz, ICSAlabs

18. More on the Problems Protecting data takes two things:
September 2005
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
Robert Moskowitz, ICSAlabs

19. September 2005
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
Robert Moskowitz, ICSAlabs

20. September 2005
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
Robert Moskowitz, ICSAlabs

21. But What about Compromised Mesh APs?
September 2005
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
Robert Moskowitz, ICSAlabs

22. September 2005
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?
Robert Moskowitz, ICSAlabs

23. Mesh AP Trust model Premise
September 2005
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
Robert Moskowitz, ICSAlabs

24. September 2005
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
Robert Moskowitz, ICSAlabs

25. Mesh authentication and Group keys
September 2005
Mesh authentication and Group keys
Let’s use 802.1X just like in i 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
Robert Moskowitz, ICSAlabs

26. But is it really IKEv2? Well it is not over UDP
September 2005
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
Robert Moskowitz, ICSAlabs

27. Where to go from here Work with any 11s proposal
September 2005
Where to go from here
Work with any 11s proposal
Develop group key ‘flooding’ method
Robert Moskowitz, ICSAlabs

28. September 2005
Questions?
Robert Moskowitz, ICSAlabs

29. Slides included from prior version
September 2005
Slides included from prior version
From 172r3
Included for historic reference
Robert Moskowitz, ICSAlabs

30. Limitations imposed by 802.11i
September 2005
Limitations imposed by i
Datagram protection includes authenticating headers along with encrypting and authenticating data content
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 i framing
This exposes data to each AP, one of which may be compromised
Can we do better?
Robert Moskowitz, ICSAlabs

31. Minimum Functional Requirements
September 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

32. Minimum Functional Requirements
September 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

33. What if we could use a different format?
September 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

34. What if we could use a different format?
September 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 i
How does STA key with another STA?
How does STA learn Mesh Portal and set up a key
Robert Moskowitz, ICSAlabs

35. What about encapsulation?
September 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

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

37. Session Keys for the Mesh APs
September 2005
Session Keys for the Mesh APs
Two choices
Unicast keys between APs
Group keys, one per AP
Robert Moskowitz, ICSAlabs

38. Unicast Session Keying
September 2005
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
Robert Moskowitz, ICSAlabs

39. September 2005
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
Robert Moskowitz, ICSAlabs

40. Session Keys for the Mesh APs
September 2005
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
Robert Moskowitz, ICSAlabs

41. Authentication of AP to mesh
September 2005
Authentication of AP to mesh
Pre-shared key
Really a group key
X.509 certificates
ESP with RADIUS
Robert Moskowitz, ICSAlabs

42. Authentication With a Pre-shared Key
September 2005
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
Robert Moskowitz, ICSAlabs

43. Possible Mesh AP Handshake* The Devil is in the Details+
September 2005
Possible Mesh AP Handshake* The Devil is in the Details+
Mesh AP AP
HDR, SAi, KEi, Ni
HDR, SAr, KEr, Nr
Derive Diffie-Hellman key
Expand to: SKie,SKia,SKpi,SKre,SKra,SKpr
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?
Robert Moskowitz, ICSAlabs

44. Authentication with X.509 Certificates
September 2005
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
Robert Moskowitz, ICSAlabs

45. Authentication with EAP over RADIUS
September 2005
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
Robert Moskowitz, ICSAlabs

46. Configuration Requirements
September 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
Robert Moskowitz, ICSAlabs

47. Configuration Requirements
September 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

48. Summary No change to 802.11i security frames Group keys used
September 2005
Summary
No change to i 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

49. September 2005
QUESTIONS?
Robert Moskowitz, ICSAlabs