1. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 1 IEEE 802.11k Security: A Conceptual Model Bernard Aboba Microsoft

2. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 2 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?

3. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 3 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!

4. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 4 Data Frame Proposal Described in detail in 11-04-0722-Action- Ethertype.doc Allow encapsulation of Action frames as data frames Does not affect other management frames FieldsOctets SME-Information Ethertype1-2 SME-Information Version3 SME-Information Type4 SME-Information Length5-6 SME-Information Body7-N

5. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 5 Flow of Information Incoming –Incoming Action Ethertype data frame passed up by driver to the OS –OS passes information back down to the driver via an OID –Result: no special treatment for Action Ethertype in driver. Outgoing –Driver requests formation of an Action frame from the OS. –OS encapsulates Action frame in an Action Ethertype and sends it back down to the driver.

6. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 6 Data Frame Proposal Pros –Guaranteed to work on all existing hardware. No need for separate negotiation, configuration or policy –No changes to existing security mechanisms. RRM uses implemented ciphersuites. No modifications to 4-way handshake. –Compatible with WPA2 driver model. Driver passes up SMI-Information frames to OS as data OS reflects SMI-Information frames back down to the driver via OIDs Enables sending of RRM frames over the DS in future. Cons –Requires allocation of new Ethertype Experimental Ethertype used until actual Ethertype allocated

7. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 7 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

8. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 8 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!

9. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 9 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.

10. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 10 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

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

12. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 12 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”

13. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 13 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.

14. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 14 Motion Instruct the editor to incorporate text from 11-04-0722-00-000k-action-ethertype.doc into the TGk draft

15. doc.: IEEE 802.11-04-0724-01-000k Submission July 2004 Bernard Aboba, MicrosoftSlide 15 Feedback?