Enhancing Security for IEEE 802.11 Frames

Development and strategies for protecting crucial control frames in IEEE 802.11 networks, such as Trigger, BA, and BAR frames, to mitigate potential security attacks. Emphasizing the importance of Authentication for group-addressed control frames to maintain backward compatibility and ensure data integrity.

• Security
• IEEE 802.11
• Control Frames
• Authentication
• Network

korr_958 Follow

Uploaded on Sep 11, 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. doc.: IEEE 802.11-23/1995r0 Trigger, BA, and BAR protection Date: 2023-11-09 Authors: Name Affiliations Address Phone Email Po-Kai Huang Ido Ouzieli Danny Alexander Daniel F Bravo Intel Laurent Cariou Robert Stacey Ehud Reshef Submission Slide 1 Po-Kai Huang (Intel)

2. doc.: IEEE 802.11-23/1995r0 Abstract There have been presentations talking about protection for various control frames. [1-5] We provide follow up for the development of this topic. Submission Slide 2 Po-Kai Huang (Intel)

3. doc.: IEEE 802.11-23/1995r0 Which Control frame to protect? 3 Control frames stand out due to potential security attack Trigger frame Due to potential power attack since SMPS and eMLSR use Trigger frame to tell client to exit low power mode Due to potential fake request for long response BA protocol attack BAR frame and BA frame Due to BA protocol attack There are existing PBAC protocols to deal with BA protocol attack Only focus on BAR and disallow important moving window functionality for BAR frame and MU-BAR Directly protect BA and BAR is therefore better Submission Slide 3 Po-Kai Huang (Intel)

4. doc.: IEEE 802.11-23/1995r0 Which variants to protect? Trigger frame Flexibility of Trigger frame format implies feasibility to insert PN and MIC and be backward compatibility One solution will likely work for all variants Protecting all variants also address the fake request for long response BA Formats depending on the variants Should consider compressed BA and Multi-STA BA BAR Formats depending on the variants Should consider compressed BAR and Multi-TID BAR Slide 4 Submission Po-Kai Huang (Intel)

5. doc.: IEEE 802.11-23/1995r0 Mode of Protection Authentication of the frame is definitely required For group addressed frame, encryption of the body will directly create issues for backward compatibility Legacy will still parse encrypted User Info field to search for relevant User Info field and may parse wrong and respond TB to kill other TB transmission It is clear that we should consider Authentication only for group addressed control frame that are defined to be protected Examples of target group addressed control frame: Trigger frame and Multi-STA BA Submission Slide 5 Po-Kai Huang (Intel)

6. doc.: IEEE 802.11-23/1995r0 Cipher Usage 11be mandates support of GCMP-256, which implies that support of GMAC-256 is already there Propose to simply use GMAC-256 for Authentication only protection Already supported by all 11bn since 11bn will support 11be The best we can use anyway No need for further negotiation Submission Slide 6 Po-Kai Huang (Intel)

7. doc.: IEEE 802.11-23/1995r0 Discussion on Key For group addressed control frame that are defined to be protected, should use additional key per BSS to do the protection Similar to what we have done for GTK/IGTK/BIGTK For individually addressed control frame that are defined to be protected, would make more sense to have separate key (different from the key used for group addressed) for individual client Align with the direction in the existing spec to separate group key and individual key Submission Slide 7 Po-Kai Huang (Intel)

8. doc.: IEEE 802.11-23/1995r0 Conclusion We provide follow up on protection for Trigger frame, BA frame, and BAR frame Important control frame to protect due to security attack We discuss the following aspects for the development on this topic Which variants to protect Define authentication only for group addressed control frame that are defined to be protected Use GMAC-256 for group addressed control frame that are defined to be protected Have additional group key per BSS to protect group addressed control frame that are defined to be protected Submission Slide 8 Po-Kai Huang (Intel)

9. doc.: IEEE 802.11-23/1995r0 SP #1 Do you support to define Trigger frame protection in 802.11bn? Submission Slide 9 Po-Kai Huang (Intel)

10. doc.: IEEE 802.11-23/1995r0 SP #2 Do you support to define BAR frame protection in 802.11bn? Which variants to be protected is TBD Submission Slide 10 Po-Kai Huang (Intel)

11. doc.: IEEE 802.11-23/1995r0 SP #3 Do you support to define BA frame protection in 802.11bn? Which variants to be protected is TBD Submission Slide 11 Po-Kai Huang (Intel)

12. doc.: IEEE 802.11-23/1995r0 SP #4 Do you support to use GMAC-256 to protect group addressed control frame that are defined to be protected Submission Slide 12 Po-Kai Huang (Intel)

13. doc.: IEEE 802.11-23/1995r0 SP #5 Do you support to have one additional group key per BSS to protect the group addressed control frames that are defined to be protected? Submission Slide 13 Po-Kai Huang (Intel)

14. doc.: IEEE 802.11-23/1995r0 Reference [1] 11-23-0286 Trigger Frame Protection [2] 11-23-0312 Thoughts on Secure Control frames [3] 11-23-0352 Enhanced Security Discussion [4] 11-23-1102 security enhancement follow up [5] 11-23-1914 Enhanced Security Consideration in UHR Submission Slide 14 Po-Kai Huang (Intel)