1. TruSecure Corporation
doc.: IEEE s
July 2004
July 2004
802.11s Security Proposal
Robert Moskowitz
ICSALabs a Division of
TruSecure Corporation
Robert Moskowitz, ICSAlabs
Robert Moskowitz, ICSAlabs

2. Topics Mesh Assumptions Mesh security Goals A Security view of a Mesh
July 2004
Topics
Mesh Assumptions
Mesh security Goals
A Security view of a Mesh
Not 100% thought out!
Robert Moskowitz, ICSAlabs

3. Mesh Assumptions An 802.11s mesh consists of both APs and STAs
July 2004
Mesh Assumptions
An s mesh consists of both APs and STAs
Per , an AP is a STA with additional functions
A mesh is a single IEEE 802 LAN
As defined in ISO/IEC
The 802 LAN does not extend beyond the mesh
Not sure this is necessary, but impacts Security
Robert Moskowitz, ICSAlabs

4. Mesh Security Goals Only designated STAs are APs
July 2004
Mesh Security Goals
Only designated STAs are APs
AP control traffic is secure from non-AP STAs
The security issues addressed by s apply only to the mesh of APs.
The attached STAs will continue to use i and mobility addressed by r
Traffic through the AP mesh will not be Decrypted/Encrypted at each AP
What one AP encrypts to send over the AP infrastructure, all APs can decrypt
Robert Moskowitz, ICSAlabs

5. Mesh Security Goals Frames are encrypted at most 3 times
July 2004
Mesh Security Goals
Frames are encrypted at most 3 times
STA to STA scenario
At originating STA to its AP
Originating AP to Destination AP
Destination AP to Destination STA
Broadcast/Multicast encrypted at all APs
How to prevent storms
Off -mesh to STA
Introducing AP to Destination AP
STA to off-mesh the opposite
Robert Moskowitz, ICSAlabs

6. July 2004
Mesh Security Goals
If an AP is detect as compromised it can be forced out of the mesh
A STA can determine if an AP is authenticated to the mesh
That is can detect rogue APs
Fast key establishment
Robert Moskowitz, ICSAlabs

7. A Security View of a Mesh
July 2004
A Security View of a Mesh
Connectivity Association (CA): The relationship between peer entities (on an IEEE 802 LAN) that allows them to communicate in a secure manner
Secure Channel (SC): A security relationship used to provide security guarantees for frames transmitted from one member of a CA to the others
There are N SCs within an CA.
SCs are unidirectional
All the SCs together in a CA define the CA
They also define the ‘Controlled Port’
Robert Moskowitz, ICSAlabs

8. B CAabcd A C SCA SCB SCC SCD D CA = Secure Connection Association
July 2004
CA = Secure Connection Association
SCi = Secure Channel from Station (I) to all stations on CA
SAij = Security Association Station (i) to Station (j) B
CAabcd A C
SCA
SCB
SCC
SCD D
Robert Moskowitz, ICSAlabs

9. A Security View of a Mesh
July 2004
A Security View of a Mesh
CA risks
Any node can spoof another node within the CA
But they are suppose to operate in a trusted manner
Cost of scaling
Every AP has a key from every AP
Robert Moskowitz, ICSAlabs

10. A Security View of a Mesh
July 2004
A Security View of a Mesh
AP join
AP has pairwise MK with every AP
AP sends its TX SAK to all APs protected with each MK
AP receives RX SAKs from all APs protected with each MK
Join forwarding techniques
Annealing techniques
AP never officially leaves
No rekeying or sync, use a key schedule
Robert Moskowitz, ICSAlabs

11. A Security View of a Mesh
July 2004
A Security View of a Mesh
AP membership management
Each AP has a D-H key
Each AP has an ACL of hash of public keys
Trusted method of distribution needed
Multicast probe for AP in ACL to create MK
AP dismissal
New ACL distributed
Remaining APs drop MK and RX key for dropped AP
APs rekey and distribute new SAK to remaining APs
Robert Moskowitz, ICSAlabs

12. A Security View of a Mesh
July 2004
A Security View of a Mesh
Benefits
No Key management costs after AP has joined the mesh
Security-Free mobility
No Decryption/Encryption of any frames within mesh for forwarding
Costs
Many keys to manage
Actually not hard to create
Robert Moskowitz, ICSAlabs

13. Questions! LOTS of work still to do July 2004
Robert Moskowitz, ICSAlabs