Radio Measurement Action Protection

1. Radio Measurement Action Protection Emily Qi and Jesse Walker Intel Corporation Emily Qi & Jesse Walker, Intel Corporation

2. Acknowledgements • To Bernard Aboba, Jon Edney, and Mike Moreton for valuable discussion, input, and review Emily Qi & Jesse Walker, Intel Corporation

3. Agenda • Problem Statement • Design Goals • Proposal • Highlights • Q&A Emily Qi & Jesse Walker, Intel Corporation

4. Problem Statement • STAs will use 802.11k messages to optimize performance • Two sources of error: • Mis-measurement • 802.11k messages forgery • Protection cannot eliminate mis-measurement, but 802.11k message forgery can marginalize utility of any usage • No mechanism has been defined to protect 802.11k messages from forgery Emily Qi & Jesse Walker, Intel Corporation

5. Design Goals • Protect Radio Measurement frame from forgery, not measurement error • Define an optional protection mechanism for Radio Measurement Action • Utilize existing security mechanisms rather than creating new ones • The protection scheme should be extended to all 802.11 Action Frames • Scheme can potentially be used for other Task Groups • Don’t require other Task Groups to define their own Action Frame protection schemes Emily Qi & Jesse Walker, Intel Corporation

6. Proposal Overview • Define a new Action Frame attribute: • Protection-Capable or Non-Protection-Capable • Action Frames are Non-Protection-Capable by default (backward compatibility) • Radio Measurement Action Frames are Protection-Capable • Protection-Capable Action Frames are protected by the same Pairwise Cipher Suite as an ordinary Data MPDU • MPDU payload is TKIP or CCMP encrypted • MPDU payload and header are TKIP or CCMP integrity protected • Protected Frame Subfield of Header Frame Control Field is set • Only cipher suites already implemented required • Sender’s Pairwise Temporal Key protects unicast Action Frame, and current GTK protects multicast/broadcast • A RSN (802.11i) IE capability bit used to signal whether Protection-Capable Action Frames will be protected • The protection is required for 802.11 implementations that support 802.11k and TKIP or CCMP, but its use is optional Emily Qi & Jesse Walker, Intel Corporation

7. Protection-Capable Action Frame • Protection-Capable Action Frames will be protected if local policy requires • Non-Protection-Capable Actions Frame will be “normal” Action Frames – protection never applies • Proposal is to make only Radio Measurement Action Frames Protection-Capable in 802.11k • But other Task Groups can use the TGk protection scheme by making their Action Frames Protection-Capable • By default, all Action Frames are Non-Protection-Capable Emily Qi & Jesse Walker, Intel Corporation

8. Authenticated by MIC Encrypted 802.11 hdr 802.11 hdr FCS FCS Protected Action Frame Format Original Action Frame: Use the same cryptographic algorithm selected for Data MPDUs Protected Action Frame: 802.11i header Action frame body MIC Cryptographic Message Integrity Code to defeat forgeries Key ID IV Encryption used to provide confidentiality IV used as frame sequence space to defeat replay Emily Qi & Jesse Walker, Intel Corporation

9. Protected Action Cipher Suites • Same keys as for data (MPDU) • TKIP or CCMP • The proposal is if you implement a cipher suite, then you must extend it to protect Radio Measurement Action frames • If you do not implement CCMP, it is not required that you add it to comply with specification. • The proposal is to not extend WEP to protect Radio Measurement Action Frames • WEP is not secure • 802.11k requires software upgrade, and TKIP can be added with the same upgrade Emily Qi & Jesse Walker, Intel Corporation

10. Protected Action Frame Keys • Same keys as for data (MPDU) • Unicast Key = Temporal Key part of the PTK from the 802.11i 4-Way Handshake • Multicast/Broadcast Key = Current GTK distributed by the 802.11i 4-Way or Group Key Handshake • Uses the GTK’s KeyID as well • Observation: All authorized WLAN members get the necessary keys when they associate. Emily Qi & Jesse Walker, Intel Corporation

11. Protection Negotiation • Add a new RSN Capabilities bit “Protected Action Frames” • bit 6 is the next unused RSN IE Capability • Beacon/Probe Response source sets bit to indicate that protection is required for all Protection-Capable Action Frames • Beacon/Probe Response source clears bit to indicate it doesn’t support Action Frame protection or that protection is disabled • Responding STAs set the bit as the Beacon/Probe Response source sets it if they support Protected Actions Frames and clear it otherwise Emily Qi & Jesse Walker, Intel Corporation

12. Highlights • It provides protection scheme for Radio Measurement Action frame. It can be extended to other Action Frames. • It uses the existing security mechanisms rather than creating new security scheme or new radio measurement frame format • It is an optional feature in 802.11k and is required for 802.11 implementations that support 802.11k and TKIP or CCMP. • Its use is optional and can be negotiable between STAs. Emily Qi & Jesse Walker, Intel Corporation

13. Proposal Q&A (1) • What cipher suites used? Keys? • Same cipher suites and keys as 802.11i negotiates for data • But then this proposal requires CCMP, right? • No. The proposal requires that implementations be able to protect Action Frames with the same cipher suites they implement to protect data • So WEP is permitted? • No. The proposal explicitly forbids WEP, because WEP provides no forgery protection • Why is the body encrypted? Why not forgery protection only? • Reuse 802.11i, and avoid inventing a new cipher suite, and avoid changing 802.11i key derivation • STA Statistics Report requires confidentiality Emily Qi & Jesse Walker, Intel Corporation

14. Proposal Q&A (2) • But why encrypt? After all, the information is valuable whether or not it is protected. • All STAs admitted to the network negotiate keys and so can decrypt any Action Frame meant for them • TGk has already voted that Radio Resource measurements are class 3, so can only be sent or received after the link is established • I want the data to be unencrypted • This requires the definition and negotiation of a new cipher suite • This requires that 802.11i key derivation to change • Why not derive from the Group Key, as in the Edney/Haskin’s proposal • This compromises the Group Key through key reuse for multiple functions Emily Qi & Jesse Walker, Intel Corporation

15. Proposal Q&A (3) • The proposal protects broadcast/multicast. That’s a security vulnerability • This issue is spurious. It applies to all protection schemes. • The proposal’s broadcast/multicast protection support will be handled by a separate motion if the proposal is accepted. • Why not protect Beacons/Probe Response? • Infeasible to make work: keys are not yet in place, and sequence numbers have not been synchronized, and Beacons are broadcast (see previous issue) Emily Qi & Jesse Walker, Intel Corporation

16. Proposal Q&A (4) • This proposal makes Action Frame protection mandatory, right? • No. The proposal negotiates Action Frame protection separately from data protection. Whether to use protection is a local policy. • And whether to make any particular Action Frame Protection-Capable is up to the Task Group. • But this is a security violation; protection should always be used? • Security is always a tradeoff and always a matter of local policy. Deployers who do not want to deploy security should not be penalized. Task Groups that don’t want their Action Frames protected don’t have to Emily Qi & Jesse Walker, Intel Corporation

17. Proposal Q&A (5) • Why use a capability bit from the RSN IE? • Prevent Downgrade Attacks: 4-Way Handshake can protect this bit from Forgery and Replay attack • Mechanism applicable to all 802.11 projects, not just 802.11k • Why not allow unprotected Action Frames prior to 4-Way Handshake, then convert to protected afterward? • The data is no less valuable before the 4-Way Handshake than after: either is it worth protecting or it is not • TGk has already voted that Radio Resource measurements are class 3, so can be sent or received only after the link is established Emily Qi & Jesse Walker, Intel Corporation

18. Proposal Q&A (6) • Why classification? Why not all Action Frames? Why must each TG decide? • We can’t foresee all possible Action Frame usages • What about already-deployed hardware? This breaks it, right? • Action frames are Non-protection-capable by default • Already deployed hardware will ignore the Protected Action Frame bit of the RSN IE Capabilities field, so will never negotiate to use Protected Action Frames Emily Qi & Jesse Walker, Intel Corporation

19. Proposal Q&A (7) • But really, security is outside the scope of the TGk PAR, right? • True the PAR never mentions security • But expectation exists that Task Groups will not break already-approved standards, and TGk breaks IEEE/ANSI STD 802.11i-2004 if it uses Action Frames without a protection scheme Emily Qi & Jesse Walker, Intel Corporation

20. Feedback? Emily Qi & Jesse Walker, Intel Corporation

21. Protected Frame Bit • Protected Frame (“WEP bit”) Subfield of the 802.11 Frame Control Field indicates whether the Action Frame is protected or unprotected • “Protected Frame” bit = 1 for Protected Action Frame • “Protected Frame” bit = 0 for Unprotected Action Frame (normal Action Frame) Emily Qi & Jesse Walker, Intel Corporation

22. Beacon/Probe Response: RSN IE Capabilities: Protected Action Frame bit = 1 if AP protects Action Frames/ 0 = if AP doesn’t protect Action Frames (Re)Associate Request: RSN IE Capabilities: Protected Action Frame bit = 1 if STA protects Action Frames/ 0 = if STA doesn’t protect Action Frames Protection Negotiation (cont…) STA AP • RSN IE Protected Action Frame Subfield Specified BSS policy: • AP sets to 0 if Protected Action Frames not supported/enabled • AP sets to 1 if Protected Action Frames supported and enabled • STA sets to 0 if doesn’t support Protected Action Frames • STA sets to value set by AP if it supports Protected Action Frames Emily Qi & Jesse Walker, Intel Corporation

23. Implementation Details… • If the BSS policy does not require protected Action Frames, then STAs shall send all Action Frames without encryption • Including all Protection-capable Action Frames • If the BSS policy requires protected Action Frames, then a STA shall discard any unprotected Protection-capable Action Frame it receives • Including those received before the 4-Way Handshake completes • If the BSS policy requires protected Action Frames, then a STA shall send all Protection-capable Action Frame encrypted or none should be sent • The STA shall not send Protection-capable Action Frames at all if the peer has not agreed to protection • A STA shall never protect to Non-Protection-capable Action Frame it sends • And shall discard any it receives that are protected Emily Qi & Jesse Walker, Intel Corporation

24. Implementation Details… • Transmitter uses next CCMP PN or TKIP TSC to construct Protected Action Frame • Use sequence number given by PN/TSC to construct protected payload and increment counter. • Each receiver implements a new counter for management frames • New counter initialized to zero • Sequence number in received Protected Action frame compared with new counter value • If received sequence number does not exceed last valid value, discard the frame as a replay • If received sequence number exceeds last valid value and Protection Action Frame decrypts correctly, accept packet and set counter value to received sequence number value Emily Qi & Jesse Walker, Intel Corporation

25. Implementation Details: TX-STA Emily Qi & Jesse Walker, Intel Corporation

26. Implementation Details:RX-STA Emily Qi & Jesse Walker, Intel Corporation