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

July 2004 Overview Before proposing an appropriate security scheme for 802.11k, 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

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 802.11k 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 802.11k 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

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

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 802.11k frames, even when security is in use. Conclusion: IEEE 802.11k implementations must not assume that frames transmitted securely are correct! Bernard Aboba, Microsoft

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 802.11k attacks, but does not affect their quality. Bernard Aboba, Microsoft

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 802.11k with Open Auth, WEP, TKIP, CCMP, etc. Vendors may retrofit 802.11k 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 802.11k to complete sooner, focus on the security threats unique to measurement Bernard Aboba, Microsoft

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

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

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 802.11k can be supported Cleaner to leverage 802.11i 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

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 802.11k 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

July 2004 Feedback? Bernard Aboba, Microsoft