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.

July 2005

Robert Moskowitz, ICSAlabs

Slide 1

doc.: IEEE 802.11-05/0172r4

Submission

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 <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 <[email protected]> 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 <[email protected]>.

Date: 2005-07-19

Name Company Address Phone emailRobertMoskowitz

ICSAlabs/Cybertrust

Oak Park, MI 248 968-9809 [email protected]

Authors:

mailto:[email protected]

mailto:[email protected]

July 2005


Slide 2

doc.: IEEE 802.11-05/0172r4

Submission

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.

July 2005


Slide 3

doc.: IEEE 802.11-05/0172r4

Submission

Goals

• Provide datagram protection between APs of the mesh• Provide session keys for datagram protection• Provide AP authentication to other APs of the mesh

July 2005


Slide 4

doc.: IEEE 802.11-05/0172r4

Submission

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 802.11i, it is the other two that we need to address

July 2005


Slide 5

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 6

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 7

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 8

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 9

doc.: IEEE 802.11-05/0172r4

Submission

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?

July 2005


Slide 10

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 11

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 12

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 13

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 14

doc.: IEEE 802.11-05/0172r4

Submission

Where to go from here

• Work with any 11s proposal• Develop group key ‘flooding’ method

July 2005


Slide 15

doc.: IEEE 802.11-05/0172r4

Submission

Questions?

July 2005


Slide 16

doc.: IEEE 802.11-05/0172r4

Submission

Slides included from prior version

• From 172r3• Included for historic reference

July 2005


Slide 17

doc.: IEEE 802.11-05/0172r4

Submission

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?

July 2005


Slide 18

doc.: IEEE 802.11-05/0172r4

Submission

Minimum Functional Requirements

Number Functional catagory

Name Coverage Notes

FR4 TOPO_RT_FWD Mesh Broadcast Data Delivery

P Does not complicate

FR5 TOPO_RT_FWD Mesh Unicast Data Delivery

P Does not complicate

FR7 TOPO_RT_FWD Mesh Network Size

C 1 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

July 2005


Slide 19

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 20

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 21

doc.: IEEE 802.11-05/0172r4

Submission


• 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

July 2005


Slide 22

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 23

doc.: IEEE 802.11-05/0172r4

Submission


WE CAN’T

802.11s MESH will be Hop by Hop protection

July 2005


Slide 24

doc.: IEEE 802.11-05/0172r4

Submission

Session Keys for the Mesh APs

• Two choices– Unicast keys between APs– Group keys, one per AP

July 2005


Slide 25

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 26

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 27

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 28

doc.: IEEE 802.11-05/0172r4

Submission

Authentication of AP to mesh

• Pre-shared key– Really a group key

• X.509 certificates• ESP with RADIUS

July 2005


Slide 29

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 30

doc.: IEEE 802.11-05/0172r4

Submission

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

MeshAP

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?

July 2005


Slide 31

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 32

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 33

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 34

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 35

doc.: IEEE 802.11-05/0172r4

Submission

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

July 2005


Slide 36

doc.: IEEE 802.11-05/0172r4

Submission

QUESTIONS?

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.

Documents