IEEE 802.11-19/1900r1 MLA Security Considerations

IEEE 802.11-19/1900r1 MLA Security Considerations
Slide Note
Embed
Share

This document from November 2019 discusses security considerations for IEEE 802.11-19/1900r1 MLA architecture. It covers topics such as MAC addresses, MAC-SAP, security proposals for group-addressed and unicast frames, and key set applications.

  • IEEE
  • Security
  • MAC addresses
  • MLA
  • Architecture

Uploaded on Apr 13, 2025 | 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.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. November 2019 doc.: IEEE 802.11-19/1900r1 MLA Security Considerations Date: 2019-11-xx Authors: Name Duncan Ho Affiliations Address Qualcomm Phone (858) 845-3214 email dho@qti.qualcomm.com 5665 Morehouse Dr, San Diego CA 92131 appatil@qti.qualcomm.com Abhishek Patil Qualcomm gcherian@qti.qualcomm.com George Cherian Qualcomm aasterja@qti.qualcomm.com Alfred Asterjadhi Qualcomm Submission Slide 1 Duncan Ho, Qualcomm Incorporated

  2. November 2019 doc.: IEEE 802.11-19/1900r1 Introduction We discuss the following in this presentation Recap of current MLA architecture proposal and focus on the link MAC addresses and the MAC-SAP MAC address Present some considerations and proposals on MLA security for group-addressed and unicast frames Submission Slide 2 Duncan Ho, Qualcomm Incorporated

  3. November 2019 doc.: IEEE 802.11-19/1900r1 MLA Architecture recap Each MLLE has a uniqee MAC- SAP MAC Address that interfaces with upper layers Each STA (link) has its own MAC Address The MAC Addresses could be the same or different between links The MAC Addresses could be the same or different than the MAC- SAP MAC Address MAC Addr (M) Upper MAC MAC-SAP Common association context (including security) Common BA space Lower MAC STA (MAC/PHY) x STA (MAC/PHY) y WM WM Submission Slide 3 Duncan Ho, Qualcomm Incorporated

  4. November 2019 doc.: IEEE 802.11-19/1900r1 MLA Architecture recap (cont d) Upper-MAC maintains the following, shared by all links MAC-SAP MAC address Single BA session, single SN space (per TID) So MPDUs can be tx/retx on any link and have a common BA scoreboard Single Association and security context Single multi-link association established via signaling over a single link Single 4-way handshake to establish a single (common) security context Single PN (per MLLE) Helps maintain existing data reception processes on the receiver i.e., Replay check follows reordering based on common SN Single replay detection block follows reordering and BA block Submission Slide 4 Duncan Ho, Qualcomm Incorporated

  5. November 2019 doc.: IEEE 802.11-19/1900r1 MLA Security Context Considerations For simplicity we propose the following: A single key set (i.e., PTK, etc) applied to all the links Either individual per-link GTK/IGTK or a single GTK/IGTK (more on later slides) PTK generated using the MAC-SAP MAC addresses of the two peer entities MAC-SAP MAC address servers as a common address for all the links Prefer this over using a link MAC address because the link may be disabled at times after association whereas the MAC-SAP MAC address is always there regardless of the state of the links Submission Slide 5 Duncan Ho, Qualcomm Incorporated

  6. November 2019 doc.: IEEE 802.11-19/1900r1 Group-Addressed Frames Considerations Currently, for link-specific group-addressed frames (e.g., robust management frames) uses Broadcast/multicast integrity protocol (BIP) For BIP, a 48-bit IPN (IGTK PN) is used for replay attack protection AAD uses FC, A1, A2, and A3 Problem: A2 may be identical between two links in MLA; Hence the AAD will not be unique A link-specific group-addressed frame transmitted on one link may be replayed on another link and still be accepted by the STA on the other link Submission Slide 6 Duncan Ho, Qualcomm Incorporated

  7. November 2019 doc.: IEEE 802.11-19/1900r1 Security Options Option 1 Mandate for an MLLE of an AP to use different link MAC addresses on each radio. Use a single GTK/IGTK for all the links (or alternatively use one GTK/IGTK per link) Pros: no changes to the AAD and it works for legacy STAs as well Cons: requirement of using different link MAC addresses. Legacy STAs on one link will know the GTK of the STAs associated in the other links Option 2 Generate one IGTK per link during association Pros: no changes to AAD. If re-key is needed on one link, only the STAs on that link needs to be re-keyed Cons: more keys to maintain Prefer Option 1 Slide 7 Submission Duncan Ho, Qualcomm Incorporated

  8. November 2019 doc.: IEEE 802.11-19/1900r1 Unicast Frames Considerations Currently for single-link, CCMP/GCMP use the following: CCMP Nonce = Nonce flags || A2 || PN GCMP Nonce = A2 || PN AAD uses A1/A2/A3/A4 Next, we explore whether existing CCMP/GCMP derivation can be reused for MLA i.e., using the link MAC addresses as A1-A3 like today Submission Slide 8 Duncan Ho, Qualcomm Incorporated

  9. November 2019 doc.: IEEE 802.11-19/1900r1 Unicast Frames Considerations (Cont d) Problem: the same Nonce value will be reused to encrypt different data (a security flaw) if all of the following are true: The A2 of two different links are the same (allowed by the MLA architecture) A frame is retransmitted on another link using the same A2 and same PN (PN remains the same across retransmissions to avoid out-of-order PN received after SN re-ordering) The A1 of two different links are different (allowed by the MLA architecture) <- different AAD data gets re-encrypted using the same Nonce This is a violation of the spec per sub-clause 12.5.3.1 CCM requires a fresh temporal key for every session. CCM also requires a unique nonce value for each frame protected by a given temporal key, and CCMP uses a 48-bit packet number (PN) for this purpose. Reuse of a PN with the same temporal key voids all security guarantees. Submission Slide 9 Duncan Ho, Qualcomm Incorporated

  10. November 2019 doc.: IEEE 802.11-19/1900r1 Security Options Option 1: Include a link identifier and a direction bit in the Nonce Nonce needs to be unique for the peer MLLEs that share the same TK Keep the length of the Nonce the same because the length is highly optimized for encryption computation Need to puncture the link identifier and direction bit into the current Nonce No strict requirements to contain all 48 bits of the TA. Justifications can be found in RFC 3610 Chapter 5 (Nonce Suggestions; last paragraph) for CCM and NIST SP 800-38D chapter 8.2.1 for GCM Pros: Maintain the current security level (A1-A4 fields protected like today) Allows same or different link MAC addresses Cons: Implementation modification to the Nonce input is needed Submission Slide 10 Duncan Ho, Qualcomm Incorporated

  11. November 2019 doc.: IEEE 802.11-19/1900r1 Security Options Option 2: mandate separate MAC addresses per radio Pros: clean solution. Can reuse all CCMP/GCMP for both unicast and group-addressed frames Cons: Excludes cases where only one MAC address is available Forces different link MAC addresses so more MAC addresses needed Submission Slide 11 Duncan Ho, Qualcomm Incorporated

  12. November 2019 doc.: IEEE 802.11-19/1900r1 Conclusion For MLA Operation, we presented some security issues associated with unicast and group-addressed frames that are specific to MLA operation We presented some options to solve these issues for MLA Submission Slide 12 Duncan Ho, Qualcomm Incorporated

  13. November 2019 doc.: IEEE 802.11-19/1900r1 SP1 Do you support the following? After multi-link setup between two MLLEs, a single PMK/PTKSA and PN space are established, maintained and used across links Submission Slide 13 Duncan Ho, Qualcomm Incorporated

  14. November 2019 doc.: IEEE 802.11-19/1900r1 SP2 Do you support the following? An MLLE on an AP uses different MAC addresses on each link? Submission Slide 14 Duncan Ho, Qualcomm Incorporated

More Related Content