1 / 22

Measurement Protection

Measurement Protection. Emily Qi and Jesse Walker Intel Corporation. Agenda. Problem Statement Design Goals Measurement Category Proposal Q&A. Problem Statement. STAs will use 802.11k messages to optimize performance 802.11k messages are subject to forgery

misu
Download Presentation

Measurement Protection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Agenda • Problem Statement • Design Goals • Measurement Category • Proposal • Q&A Emily Qi & Jesse Walker, Intel Corporation

  3. Problem Statement • STAs will use 802.11k messages to optimize performance • 802.11k messages are subject to forgery • Forged 802.11k messages can lead to poorer performance (or worse) than ignoring valid messages • No mechanism has been defined to protect 802.11k messages from forgery Emily Qi & Jesse Walker, Intel Corporation

  4. Design Goals • Identify which messages should be protected and which should not • Identify which messages can be protected and which can not • Define an optional 802.11k message protection mechanism • Provide sound, well reviewed protection • The protection scheme should extend to all 802.11 Action Frames Emily Qi & Jesse Walker, Intel Corporation

  5. 802.11k Measurement Requirement . U: Unicast; M: Multicast; B: Broadcast; Emily Qi & Jesse Walker, Intel Corporation

  6. What SHOULD be protected? • Integrity and Authenticity are more important than confidentiality for the measurement data • Broadcast and Multicast as well as unicast needs integrity/authenticity against outsider attacks • Any measurement (or info) provided the Beacon and Probe Response should be considered as informative advertisement. Protection requirement should be consistency with the rest of contents in Beacon and Probe Response Emily Qi & Jesse Walker, Intel Corporation

  7. What CAN be Protected? • Awkward to protect the frame which are sent before 4-ways handshake because it is sent prior to key establishment • Infeasible to protect measurement IEs in Beacon/Probe Response • Any action frame that is sent before 4-way handshake is infeasible to be protected The Action Frames, which are sent after 4-way handshake, can be protected Emily Qi & Jesse Walker, Intel Corporation

  8. Proposal Overview • To define a new attribute for Action Frames • Protection-capable frames or Non-protection-capable frames • By default, all Action Frames are Non-protection capable, for backward compatibility • Action Frame is protected in the same way as an ordinary Data MPDU • MPDU payload is CCMP/TKIP encrypted • MPDU payload and header are CCMP/TKIP integrity protected • Protected Frame Subfield of Header Frame Control Field is set • Sender’s Pairwise Temporal Key protects unicast Action Frame, and Sender’s GTK is used to protect broadcast/multicast Action Frame • A RSN (802.11i) IE capability bit used to signal whether Protection-capable Action Frames will be protected Emily Qi & Jesse Walker, Intel Corporation

  9. Protection-Capable Action Frame • All Task Groups are required to define a new attribute of their Action Frames • Protection-capable frames or Non-protection-capable frames • By default, all Action Frames are Non-protection-capable, for backward compatibility • Protection-capable Action Frame has to meet the following two conditions: • Should be protected • Can be protected – can only be sent after 4-way handshake • Protection-capable Action Frames will be protected if local policy requires • Non-Protection-capable Actions Frame will be “normal” Action Frames – protection never applies Emily Qi & Jesse Walker, Intel Corporation

  10. 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

  11. 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

  12. 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 Emily Qi & Jesse Walker, Intel Corporation

  13. 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 encryption 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

  14. 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

  15. 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

  16. 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

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

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

  19. Proposal Q&A • Why is the body encrypted? • Reuse 802.11i and avoid inventing something new; STA statistics report requires encryption • What cipher suites used? Keys? • Same cipher suites (keys) as 802.11i negotiates for data • Why not protect Beacons/Probe Response? • Infeasible: keys are not yet in place • 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.11x instead of just 802.11k Emily Qi & Jesse Walker, Intel Corporation

  20. Proposal Q&A (2) • Why not WEP? • The security requirement is integrity, not confidentiality; WEP only provides confidentiality • 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 • Why classification? Why not all Action Frames? Why must each TG decide? • We can’t foresee all possible Action Frame usages Emily Qi & Jesse Walker, Intel Corporation

  21. Proposal Q&A(3) • What about already-deployed hardware? • 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

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

More Related