1. IEEE 802.11k Security: A Conceptual Model
Month 2004
doc.: IEEE /0724r0
July 2004
IEEE k Security: A Conceptual Model
Bernard Aboba
Microsoft
Bernard Aboba, Microsoft

2. July 2004
Overview
Before proposing an appropriate security scheme for k, we need to articulate the threat model – what we are trying to protect against.
The primary threats to RRM are bad measurements.
This is not a classic “denial of service” attack!
We also need to understand the deployment implications
Can implemented ciphersuites be reused?
Can RRM support be retrofit in existing NIC drivers?
Bernard Aboba, Microsoft

3. July 2004
Basic Principles
Radio Resource Measurement support is orthogonal to security.
RRM can be used with any level of security (even open auth)
RRM support should be easily retrofit on existing drivers
IEEE k security needs to leverage implemented ciphersuites
Adding ciphersuites creates deployment barriers
Subtracting ciphersuites lowers security
Many RRM security issues are not addressed by transmission security.
Measurements are only a “hint”.
Bad Measurements cannot be eliminated by security, only heuristics.
IEEE k implementations need to validate measurements whether or not frames are protected
Just because a measurement is protected doesn’t mean it’s correct!
Bernard Aboba, Microsoft

4. July 2004
Challenges
Addressing DoS attacks in k does not lessen the vulnerability of systems as a whole
Many DoS threats unaddressed by IEEE i
Many IEEE k DoS attacks cannot be eliminated by cryptography, only heuristics
Bernard Aboba, Microsoft

5. Measurements as “Hints”
July 2004
Measurements as “Hints”
Bad measurements are likely
Can result from poor calibration, stale data, timing errors, etc.
Robustness is the core requirement, not cryptography
STAs and APs need to be robust against misleading measurements
STAs and APs cannot trust IEEE k frames, even when security is in use.
Conclusion: IEEE k implementations must not assume that frames transmitted securely are correct!
Bernard Aboba, Microsoft

6. Bad Measurements Require Heuristics
July 2004
Bad Measurements Require Heuristics
Cryptography cannot guarantee accurate measurements
Security services (authentication, integrity, confidentiality) only ensure that bad measurements are received as sent.
Threats from bad measurements exist, even after security services are implemented
Replace “attacker STA” by “uncalibrated/poorly implemented but authenticated STA” and the same attacks are possible
Heuristics needed
For rubustness, STAs MUST be able to recover from reception of incorrect data
In a good implementation, service is not denied, only delayed
Conclusion: security only reduces the quantity of k attacks, but does not affect their quality.
Bernard Aboba, Microsoft

7. 802.11k Useful At Any Security Level
July 2004
802.11k Useful At Any Security Level
802.11k useful at any security level
Customers want to use k with Open Auth, WEP, TKIP, CCMP, etc.
Vendors may retrofit k on legacy NICs or APs
No room in NVRAM for additional ciphersuites
No additional CPU cycles for security
Conclusions
802.11k should utilize existing security mechanisms rather than creating new ones
802.11k security can’t be mandatory to use.
802.11k not the right group to tackle security for management/action frames
Handling action/management frame security in a new PAR would allow k to complete sooner, focus on the security threats unique to measurement
Bernard Aboba, Microsoft

8. Example: The Neighbor Report
July 2004
Example: The Neighbor Report
The Neighbor Report data is third hand - APA providing the STA with information about APB
The information is inherently suspect
Neighbor report entry can become stale: APB was a neighbor, but was removed for maintenance; how long before APA removes it?
Neighbor report entry can be polluted: APB was (incorrectly) submitted by STA in a Beacon Report, APA didn’t validate the entry with another STA or with its “Authorized AP list” before including APB in the Neighbor Report.
Neighbor report has limited “shelf life”: it’s only useful prior to scanning.
Bernard Aboba, Microsoft

9. Neighbor Report Robustness
July 2004
Neighbor Report Robustness
A STA may choose to ignore part or all of the measurements provided
The STA might validate the neighbor report using other mechanisms (active or passive scan)
The STA might ignore part or all of the neighbor report
A STA MUST be robust against misleading information.
Example: A STA should not “blacklist” APs based on the Neighbor Report
“Bad” APs are just lower priority, not “off limits”.
When information in the Neighbor Report conflicts with other sources, the other sources (scan, 4-way handshake, etc.) are definitive.
Once the STA scans, it behaves the same way it would if there were no Neighbor Reort.
The Neighbor Report has a very short “shelf life”
Bernard Aboba, Microsoft

10. Deployment Issues Separate RRM Security Negotiation
July 2004
Deployment Issues
Separate RRM Security Negotiation
Requires confirmation in 4-way handshake or the security negotiation is insecure.
Driver needs to pass up RRM security negotiation results to operating system to enable confirmation
New OIDs required; current WPA2 driver model does not support this!
End result: substantial delays until k can be supported
Cleaner to leverage i security negotiation
Legacy driver support
Many of today’s NIC drivers unlikely to be modified to support RRM
Data frame encapsulation enables RRM support to be added in the OS
Enables performance improvements for legacy drivers.
Bernard Aboba, Microsoft

11. Data Frame Proposal Pros Cons
July 2004
Data Frame Proposal
Pros
No changes to existing security mechanisms.
RRM uses implemented ciphersuites.
No modifications to 4-way handshake.
No additional text in k specification.
Compatible with WPA2 driver model.
Enables sending of RRM frames over the DS in future.
Cons
Requires allocation of new Ethertype
Experimental Ethertype used until actual Ethertype allocated
Bernard Aboba, Microsoft

12. July 2004
Feedback?
Bernard Aboba, Microsoft