1. A security model for wireless meshs
March 2005
doc.: IEEE /0172r3
March 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. March 2005
doc.: IEEE /0172r3
March 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.
This model will include authenticating APs to the mesh, session key exchange, and datagram protection.
Robert Moskowitz, ICSAlabs
Robert Moskowitz, ICSAlabs

3. 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

4. Limitations imposed by 802.11i
March 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

5. 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

6. 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

7. 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

8. 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 i
How does STA key with another STA?
How does STA learn Mesh Portal and set up a key
Robert Moskowitz, ICSAlabs

9. 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

10. 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

11. 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
Robert Moskowitz, ICSAlabs

12. Unicast Session Keying
March 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

13. March 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

14. Session Keys for the Mesh APs
March 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

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

16. Authentication With a Pre-shared Key
March 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

17. Possible Mesh AP Handshake* The Devil is in the Details+
March 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

18. Authentication with X.509 Certificates
March 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

19. Authentication with EAP over RADIUS
March 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

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

21. 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

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

23. March 2005
QUESTIONS?
Robert Moskowitz, ICSAlabs