Enhancing IEEE 802.11 MAC Header Protection for UHR Efficiency
"Explore how IEEE 802.11 proposes MAC header protection to boost reliability, reduce latencies, and minimize power usage in UHR devices. Learn about key factors, parameters, and considerations for optimal header protection implementation." (Total characters: 288)
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
November 2023 doc.: IEEE 802.11-23/1888r1 MAC header protection follow-up Date: 2023-11-02 Name Affiliation Address Phone Email Abhishek Patil appatil@qti.qualcomm.com Duncan Ho Jouni Malinen Qualcomm Inc. Alfred Asterjadhi George Cherian Gaurang Naik Submission Abhishek P (Qualcomm), et. al., Slide 1
November 2023 doc.: IEEE 802.11-23/1888r1 Background UHR is focused on improving reliability, reducing latencies and lowering power consumption at devices. In order to achieve these goals, UHR will rely on signaling information via the MAC header fields (such as A-Control) or via Control frames (e.g., Trigger etc). However, Control frames and several fields in the MAC header are not protected. Several contributions have highlighted the need for protecting these fields and frames to help UHR meet its objectives [1, 2, 3, 4] This contribution provides additional details on MAC header protection and considerations for selecting the security parameters to enable this protection. Submission Slide 2 Abhishek P (Qualcomm), et. al.,
November 2023 doc.: IEEE 802.11-23/1888r1 Factors to consider (recap) The header protection scheme needs to account for field values getting updated when an MPDU is retried. Such as Retry bit, PM bit, A-Control field etc In addition, the scheme must not require re-encryption of the payload of an MPDU during a retry Consequently, MAC header protection cannot be combined with MPDU encryption. In other words, the two need to be separate processes and only the header protection step is performed when an MPDU is retried. Submission Slide 3 Abhishek P (Qualcomm), et. al.,
November 2023 doc.: IEEE 802.11-23/1888r1 Overview of the proposal Protection is provided via integrity check A MIC is generated based on (subset of) MAC header fields. Since the contents of the header fields can change when an MPDU is retried, a fresh MIC is generated (only) for the header fields each time an MPDU is retried Note, the payload of the MPDU is not re-encrypted Submission Slide 4 Abhishek P (Qualcomm), et. al.,
November 2023 doc.: IEEE 802.11-23/1888r1 Parameters needed for MIC generation The MIC generation will require the following parameters: A temporal key (TK`) A packet number (PN`) Address 2 (A2) field which carries the transmitter MAC address Fields that are being protected A2||PN` is used to generate a Nonce Next, we examine considerations for TK` and PN` Submission Slide 5 Abhishek P (Qualcomm), et. al.,
November 2023 Proposal for temporal key (TK`) for MIC computation doc.: IEEE 802.11-23/1888r1 From security point of view, using the same key in two different algorithms is a bad practice As it can make related key attacks possible. As a result, the TK` cannot be the same as the TK (which is used for encrypting the MPDU payload) Therefore, a separate key is strongly recommended Establish an additional key during association for header protection Alternative approaches can be discussed The separate TK` could also be used for (individually addressed) Control frame protection Submission Slide 6 Abhishek P (Qualcomm), et. al.,
November 2023 Proposal for packet number (PN`) for MIC computation doc.: IEEE 802.11-23/1888r1 The PN` provides protection against replay attacks Same functionality as PN used during the payload encryption However, the usage of PN` differs from PN in the following aspects: The PN value remains the same when an encrypted MPDU is retransmitted. In contrast, a new PN` value is required each time an MPDU is (re)transmitted a new MIC is computed for each (re)transmission. Packet number required for (individually addressed) Control frame protection could also be drawn from the PN` space Submission Slide 7 Abhishek P (Qualcomm), et. al.,
November 2023 doc.: IEEE 802.11-23/1888r1 In summary This contribution proposes to protect fields in the MAC header via integrity check A new MIC is generated for the header fields each time an MPDU is (re)transmitted A different key is recommended for header MIC generation Which could also be used for protecting the Control frames Packet Number (PN`) used for generating the header MIC needs to be drawn from a different space than that used for MPDU encryption PN for Control frame protection could be drawn from the separate space Submission Slide 8 Abhishek P (Qualcomm), et. al.,
November 2023 doc.: IEEE 802.11-23/1888r1 References [1] 11-23/286: Trigger frame protection [Po-Kai Huang et al. (Intel)] [2] 11-23/352: Enhanced security discussion [Liwen Chu et al. (NXP)] [3] 11-23/356: MAC Header Protection [Abhishek Patil et al. (Qualcomm)] [4] 11-23/1102: Security Enhancement follow up [Liwen Chu et al. (NXP)] Submission Slide 9 Abhishek P (Qualcomm), et. al.,
November 2023 doc.: IEEE 802.11-23/1888r1 SP #1 Do you support to define a mechanism in TGbn that protects the MAC header for individually addressed Data and Management frames? Submission Slide 10 Abhishek P (Qualcomm), et. al.,
