Proposal for Network-Generated Device ID Scheme in IEEE 802.11

A scheme proposing the generation of network-assigned device identifiers for STAs in IEEE 802.11 networks is outlined. The network assigns unique IDs to devices, allowing flexibility in ID formats across different networks. STAs receive and use these IDs for tracking purposes. The process involves converting device IDs to blob instances, securing them with encryption, and handling them during association and communication phases.

• Network scheme
• Device ID
• IEEE 802.11
• Encryption
• Security

kobe_hen Follow

Uploaded on Sep 24, 2024 | 0 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. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. January 2022 doc.: IEEE 802.11-22/0154r0 Opaque Device Identifier Date: 2022-01-20 Authors: Name Dan Harkins Affiliations Address HPE Phone email Submission Slide 1 Dan Harkins, HPE

2. January 2022 doc.: IEEE 802.11-22/0154r0 Abstract A scheme to have a network-generated device ID is proposed Submission Slide 2 Dan Harkins, HPE

3. January 2022 doc.: IEEE 802.11-22/0154r0 Basic Idea Identifier is assigned by network to STA Network owns ID space, decides on format of ID Different networks can use different IDs as they wish To the STA, it s just a blob STA obtains a blob on first association STA includes blob in 4way HS 4way HS updates and produces a new blob that the STA uses on a subsequent association STA can opt out by just throwing away the blob and getting a new one on the next association if it wants to stop being tracked Requirement: all APs in ESS share a symmetric key Submission Slide 3 Dan Harkins, HPE

4. January 2022 doc.: IEEE 802.11-22/0154r0 Converting a Device ID to a Blob Instance from the network name space is treated as an opaque string could be a name, a number, anything that is significant to the network Different networks can use different name spaces Opaque string is padded, a single octet defines the length of the pad followed by length-1 octets of zero Therefore minimum pad is 1 octet, the length indicator Padded opaque string prepended with a random tweak Size of tweak influences security of blob an 8 octet tweak would secure blobs roughly to a birthday bound of 232 Tweaked padded opaque string is SIV encrypted (deterministic AEAD mode, no IV) Submission Slide 4 Dan Harkins, HPE

5. January 2022 doc.: IEEE 802.11-22/0154r0 Generation of Blob device identifier: blahfubar 4000blahfubar padded: tweaked: 71a08cf14000blahfubar key AES-SIV blob: 891b52f0725635f3abc8a6b13159df5afbf0a Submission Slide 5 Slide 5 Dan Harkins, HPE

6. January 2022 doc.: IEEE 802.11-22/0154r0 Handling of the Blob STA includes blob in message 2 of 4way HS First association there is no blob, if missing AP allocates a name out of the name space for the STA AP decrypts blob, validates tweak, discards padding and tweak Failure to decrypt could result in a deassociation if the group desires or it could just be treated as a missing blob Failure to validate tweak should result in deassociation AP makes note that STA MAC is now associated with the identifier AP re-encrypts identifier with new padding and tweak, stores latest tweak used to encrypt the identifier AP inserts new blob in message 3 of 4way HS STA retains new blob for subsequent association to allow tracking and throws it away if it wants to opt out of tracking AES-SIV decryption and encryption is very fast Submission Slide 6 Dan Harkins, HPE

7. January 2022 doc.: IEEE 802.11-22/0154r0 Properties of Scheme A passive attacker cannot determine a device identity A passive attacker cannot connect device identities across associations Identifiers can be arbitrarily padded to foil passive traffic analysis Identities are secure under a reasonable birthday bound (which will depend on the size of the tweak and the how the pad size varies) An attacker cannot substitute identifiers to connect distinct associations An AP needs to only manage a single symmetric secret, used to protect all identities used in the ESS, and 8 octets per allocated device ID All APs in the ESS can share the same symmetric key (in an out-of-band fashion) Minimal overhead e.g. 16 octet tag + 8 octet tweak + 1 octet pad length + padding = 25 octets plus padding Uses symmetric cryptography for speed and DOS resistance Each identifier is unique to the ESS it was obtained from, a given ESS will have no knowledge of the identifiers used in other ESSs Identifiers cannot be tracked across networks Slide 7 Submission Dan Harkins, HPE

8. January 2022 doc.: IEEE 802.11-22/0154r0 Use Cases Addressed Post-association access control User identified, access control determined at sign-up/first association Blob presented on all subsequent association, connection gets the treatment Attempts to access network without a blob can be denied if desired Post-association home automation First association is done at home when opener installed Garage door won t open unless appropriate blob is received Grocery store frequent shopper notification Keep reusing the blob at the store, tie visits to each other Customer support and troubleshooting Require some way to present a blob that could be read back 891b5-2f072-5635f-3abc8-a6b13-159df-5afbf-0a On second thought that might be a lot to read back Captive portal Blob is assigned when guest first goes through captive portal (using OWE, not open) Subsequent associations present blob, guest identified, captive portal avoided Maybe more! Slide 8 Submission Dan Harkins, HPE

9. January 2022 doc.: IEEE 802.11-22/0154r0 References 11-21/0488 11-21/0541 Submission Slide 9 Dan Harkins, HPE