Enhancing IEEE 802.11-22/441r0 Pre-Association Identification Schemes
Explore proposed changes and solutions for enhancing pre-association identification schemes in the IEEE 802.11-22/441r0 document. The document addresses privacy enhancement mechanisms, device IDs, and protocols for STA identification, aiming to improve network security and efficiency.
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
March 2023 doc.: IEEE 802.11-22/441r0 IE based pre-association identification schemes Date: 2023-3-14 Authors: Name Okan Mutgan Affiliations Nokia Address Phone email okan.mutgan@nokia- sbell.com zhijie.yang@nokia- sbell.com jianguo.a.liu@nokia- sbell.com Jay Yang Nokia Liu Jianguo Nokia Submission Slide 1 Okan Mutgan, Nokia
March 2023 doc.: IEEE 802.11-22/441r0 CID list-1 CID Comment Proposed Change Resolution the commenter will provide a solution. Device ID only can be used in post association, we need to a solution to cover the probing case. an AP may not grant an identifier to some STAs once it's recognized via the MAC address. RMA causes such implement broken, need to provide a solution to address it. 7 the commenter will provide a solution on it. 9 Specify a privacy enhancement mechanism for identifying a STA operating with a Random MAC Address before the association Provide a mechanism that supports scenario 4.2 by providing a MAC address based mechanism that allows a returning station to be recognized. No privacy enhancement mechanism is specified for covering the pre-association use cases specified by the 11bh group in the document 332r37. 36 Issue tracking document contains scenario (especially 4.2 : returning device) agreed by the group and that is not addressed by the current draft. 40 Submission Slide 2 Okan Mutgan, Nokia
March 2023 doc.: IEEE 802.11-22/441r0 CID list-2 CID Comment Proposed Change Resolution Need additional mechanisms to enhance the privacy during the pre-association procedure. Specify a privacy enhancement mechanism for covering pre- association use cases of doc 332r37. Add a STA-generated Device ID variant, and appropriate mechanism (if needed) to select an operating mode. Please allow STA to have a possibility to provide to AP the STA Identifier that is used to identify the STA. The document 332r37 describes some scenarios related to the pre-association procedure. The current draft does not propose any privacy enhancement during this procedure. 41 A mechanism for privacy enhancement is missing for the coverage of pre-association use cases specified in the doc 332r37. 42 With majority support for a STA-generated device ID (for example, Motion #3, although not 75% on a particular proposal, yet) and evidence that both network-generated and STA- generated can coexist (cf 11-22/0908), add a STA generated ID variant. 61 The 802.11bh should define a protocol that allows STA to provide STA ID that the STA uses to identify itself to the AP in the following authentications/associations. 64 Submission Slide 3 Okan Mutgan, Nokia
March 2023 doc.: IEEE 802.11-22/441r0 Motivation 11bh group should provide an additional scheme to address a batch of comments relevant to pre-association identification. SP in the plenary meeting in Bangkok: Do you support TGbh working on adding an additional mechanism to support identification prior to association (or at Association Request)? Y: 17 N: 4 Abs: 7 Submission Slide 4 Okan Mutgan, Nokia
March 2023 doc.: IEEE 802.11-22/441r0 IE based solution 1. Use public/private key stuff, e.g., ID encoding, refer to 2013r1 2. Use pairwise key stuff, this contribution will introduce this idea. Submission Slide 5 Okan Mutgan, Nokia
March 2023 doc.: IEEE 802.11-22/441r0 General Idea Current Draft (D0.2) defines identification for post association . pre-association identification can be extended based on D0.2 If STA wants post-identification -> use current draft solution (device ID assignment in 4-way HS Msg3, device ID usage in 4-way HS Msg2) If STA wants pre-identification -> use IE to send device ID protected (explained later) (device ID assignment in 4-way HS Msg3, device ID usage in pre-association frames) Two MIBs can be defined to separate two cases: post-association identification -> dot11PostAssocDeviceIDActivated is true pre-association identification -> dot11PreAssocDeviceIDActivated is true Submission Slide 6 Okan Mutgan, Nokia
March 2023 doc.: IEEE 802.11-22/441r0 Pre Assoc Proposal 1 - simple solution In the first association, STA and AP will generate a pairwise key derived from PTK Both sides will generate two blobs based on the pairwise key, install two blobs and one key locally. e.g. blob1=F(key, device ID); blob2=F(key, blob1); -> Dynamic blob generation After STA returns, it uses the blob1 in the IE for identification, once its done, STA sends blob2 and the STA and AP generate a new blob_x+1=F(key, blobx), go throw the oldest blob. In other words, STA and AP only keeps two blobs. Repeat the above steps until new key generated. Storage cost: both sides save two blobs and one key, device ID Computational cost: no on-line computational cost, one-time off-line computational cost. KDE parameter: None. IE information: Element ID length Blob field Submission Slide 7 Okan Mutgan, Nokia
March 2023 doc.: IEEE 802.11-22/441r0 Pre Assoc Proposal 1 - simple solution Device ID in IE may be included in: a. direct probe request b. authentication request and (re)association request frame c. identifiable public action frame (e.g. ANQP req) Submission Slide 8 Okan Mutgan, Nokia
March 2023 doc.: IEEE 802.11-22/441r0 Non-AP STA AP AP assigns device ID to STA (4-way HS Msg3) 1st Assoc Both sides generate and store key and two blobs(key, blob1,blob2) 2nd Assoc Send blob1 in the IE in pre-assoc frame (e.g. directed probe) Send the response with blob1 in the IE (ACK) Generate new blob (blob3) and throw blob1 on both sides Send blob2 in the IE in pre-assoc frame (e.g. auth) Send the response with blob2 in the IE (ACK) Generate new blob (blob4) and throw blob2 on both sides Submission Slide 9 Okan Mutgan, Nokia
March 2023 doc.: IEEE 802.11-22/441r0 Pre Assoc Proposal 2 - complete solution Based on proposal1, the IE will contain more information: Blob: for identification MIC: for authentication/validation PN: for replay attack Element ID Blob field length PN MIC Submission Slide 10 Okan Mutgan, Nokia
March 2023 doc.: IEEE 802.11-22/441r0 Putting all together AP Non-AP STA Non-AP STA AP dot11PreAssocDeviceIDActivated is true dot11PostAssocDeviceIDActivated is true 1st 1st Assoc Assoc 4 way HS Msg3 (device ID1) 4 way HS Msg3 (device ID1) Pre-Assoc frames (protected device ID1) 4 way HS Msg2 (device ID1) 2nd Assoc 2nd Assoc 4 way HS Msg3 (device ID2) 4 way HS Msg3 (device ID2) Ex case 2 Ex case 1 Submission Slide 11 Okan Mutgan, Nokia
March 2023 doc.: IEEE 802.11-22/441r0 SP For IE based solution, which one you prefer to address the pre-association identification schemes? Opt1: public/private key, refer to 2013r1 Opt2: Pairwise key, refer to this contribution Submission Slide 12 Okan Mutgan, Nokia
March 2023 doc.: IEEE 802.11-22/441r0 Thanks! Submission Slide 13 Okan Mutgan, Nokia
