Preventing Client Tracking in IEEE 802.11-23: OTA MAC Rotation Approach

oct 2023 n.w
1 / 5
Embed
Share

"Learn about preventing client tracking in IEEE 802.11-23 by implementing OTA MAC rotation to avoid privacy compromises. The proposal aims to hinder tracking across epoch boundaries, enhancing user privacy within each epoch. Details include the approach, HKDF negotiation, HKDF-Extract process, IRM generation, and more."

  • IEEE
  • Privacy
  • Tracking
  • OTA MAC Rotation
  • HKDF

Uploaded on | 1 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. Oct 2023 doc.: IEEE 802.11-23/1818r0 OTA MAC Rotation Date: 2023-10-19 Authors: Name Stephen Rodriguez Affiliations Cisco Systems Inc Address ::1 Phone email stephen.rodriguez@ieee.org sorr@cisco.com Stephen Orr Cisco Systems Inc Submission Slide 1 Stephen Rodriguez, Cisco Systems Inc

  2. Oct 2023 doc.: IEEE 802.11-23/1818r0 Summary Background Unencrypted predictable frame fields can enable client tracking by identifying a set of frames for which a single client is transmitter or intended receiver. This can allow tracking presence or location of the person using that client, compromising privacy. Proposal Goal: prevent tracking associated clients across epoch boundaries, within each epoch is acceptable. OTA Randomization: Prevents client frame tracking across epoch boundaries Re-randomize MAC address at every epoch Does not prevent client frame tracking within an epoch Submission Slide 2 Stephen Rodriguez, Cisco Systems Inc

  3. Oct 2023 doc.: IEEE 802.11-23/1818r0 Approach At association AP STA and non-AP STA shall negotiate if they both support OTA rotation; AP STA and non-AP STA shall use HKDF to construct the new OTA MAC prior to epoch HKDF-Extract requires a salt, and IKM (Input Keying Material) value to derive the PRK (pseudo random key) For the salt value we can use an FTM value the PMK derived from the 4WHS shall be used as the IKM Because FTM (Fine Time Measurement) and PMK are known to both AP and non-AP STA the new IRM can be validated by the AP There is no need to send the new IRM over the air, STA can just start using it PRK = HMAC-Hash (FTM, PMK) Hash algorithm would be aligned with the Hash algorithm used with the AKM during association (SHA256, 384,512) Submission Slide 3 Stephen Rodriguez, Cisco Systems Inc

  4. Oct 2023 doc.: IEEE 802.11-23/1818r0 Approach HKDF-Expand (PRK, info, L) -> OKM Pseudo Random Key calculated from HKDF-Extract function (PRK) Info context, in this case New OTA MAC L length of output keying material in octets (<= 255*HashLen) IRM_List = HMAC-Hash(PRK, "New OTA MAC , L) Hash would be aligned with the Hash algorithm used with the AKM during association (SHA256, 384,512) L = Num_Macs * 6(bytes) Num_Macs must be an integer between 1 and 42 Mac1 = IRM_List [first 6 bytes:] | Mac2 = IRM_List [second 6 bytes:] etc; second bit force to 26 A | E to align with IEEE Submission Slide 4 Stephen Rodriguez, Cisco Systems Inc

  5. Oct 2023 doc.: IEEE 802.11-23/1818r0 Client Initiated Rotation Before the defined epoch, allow the client to rotate the OTA mac Announce time Tell AP-STA when we will start to use new OTA IRM sent in a protected frame e.g. in 1 minute we will use new OTA IRM Once announce time has elapsed, countdown to Sunset time starts. Sunset time After old mac shall not respond and AP shall not forward packets for old IRM Fully Untrusted - DTIM * 5 Semi Untrusted DTIM * 5 Trusted DTIM * 5 Submission Slide 5 Stephen Rodriguez, Cisco Systems Inc

Related


More Related Content