1 / 28

Measurement Protection

Intel Corporation presents a comprehensive solution to safeguard 802.11k messages from forgery, ensuring integrity and authenticity in Wi-Fi networks. The proposal defines protection mechanisms, addresses message categorization, and outlines protection negotiation strategies.

marcellusa
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, Intel Corporation

  2. Agenda • Problem Statement • Design Goals • Measurement Category • Proposal • Q&A Emily Qi, 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, 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 many other 802.11x management messages Emily Qi, Intel Corporation

  5. 802.11k Measurement Category . U: Unicast; M: Multicast; B: Broadcast; Emily Qi, Intel Corporation

  6. What SHOULD be protected? • Integrity and Authenticity are more important than confidentiality for the measurement data • Broadcast and Multicast needs integrity/authenticity as well as unicast • 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 • Most of Action Frames are “ever be protected” • See to our straw poll on Tuesday (in the backup slide) Emily Qi, Intel Corporation

  7. What CAN be Protected? • Infeasible 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, 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, 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, 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, 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, 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, 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 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 (Re) Association Request source sets it if they support Protected Actions Frames and clear it otherwise Emily Qi, 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, 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, Intel Corporation

  16. Proposal Q&A • Why not protected IE’s? • Can enable cut-and-paste attacks – 802.11 Hdr must be bound to the Action Frame payload • Why is the body encrypted? • Reuse 802.11i and avoid inventing something new • 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, Intel Corporation

  17. 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, Intel Corporation

  18. 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, Intel Corporation

  19. Feedback? Emily Qi, Intel Corporation

  20. Straw Poll: Measurement Request/Response . Y(#) =YES _#_ N(#) = NO _#_ Emily Qi, Intel Corporation

  21. Straw Poll: Action Frames in 11k . Y(#) =YES _#_ N(#) = NO_#_ Emily Qi, Intel Corporation

  22. Measurement Protection Question #1 • Does TGk need 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 • YES _______ • NO _______ • ABSTAIN _______ Emily Qi, Intel Corporation

  23. Measurement Protection Question #2 • Should TGk protect Action Frame in the same way as an ordinary Data MPDU and uses the same key as data payload? • To avoid rebuild whole security framework • YES _______ • NO _______ • ABSTAIN _______ Emily Qi, Intel Corporation

  24. Measurement Protection Question #3 • Should TGk use a RSN (802.11i) IE capability bit to signal whether Protection-capable Action Frames will be protected? • YES _______ • NO _______ • ABSTAIN _______ Emily Qi, Intel Corporation

  25. Backup Emily Qi, Intel Corporation

  26. Implementation Details: TX-STA Emily Qi, Intel Corporation

  27. Implementation Details:RX-STA Emily Qi, Intel Corporation

  28. Action Frames in 11k . Emily Qi, Intel Corporation

More Related