802.11w, WPA3, OWE, SAE, TDLS PeerKey handshake, DPP and MAC address randomization

802.11w

The 802.11i-2004 amendment addressed confidentiality and integrity but not availability. While it protected data frames, management frames were vulnerable to attacks, leading to DoS attacks.

An attacker knowing the MAC address(es) of a target STA can send a spoofed disassociation request (pretending to be the AP) or a spoofed reassociation request (pretending to be the STA) to the serving AP, causing the legitimate STA to be logged off.

The unprotected nature of management frames allows easy manipulation, leading to forgery and replay attacks.

The 802.11w-2009 amendment (included in IEEE 802.11-2012, 2016, 2020, 2024) addressed management frame security vulnerabilities by introducing integrity protection and confidentiality for certain management frames like Deauthentication, Disassociation, and Action frames. This protects these frames from spoofing and tampering.

It defines a new Broadcast/Multicast Integrity Protocol (BIP) that offers data origin authenticity and replay protection for management frames sent via broadcast or multicast, secured by the IGTKSA, protecting clients from spoofing attacks.

Due to 802.11w, the RSNE field has been extended by 2 bits (bits 6 and 7, i.e., the MFPR, Management Frame Protection Required, and MFPC, Management Frame Protection Capable, flags) to advertise the new capabilities, which indicate that 802.11w is supported.

Robust Action frames include Spectrum management, QoS, DLS, Block Ack, Radio measurement, SA Query, Fast BSS Transition, HT, Protected dual of public action, and Vendor-specific Protected Action frames. These frames, when protected, ensure that spectrum management operations are not disrupted by spoofing; prevent attackers from manipulating QoS parameters; secure direct communication between STAs; prevent attackers from manipulating block acknowledgment procedures; ensure the integrity of radio measurement reports; secure security association queries; protect the fast BSS transition process; secure HT-related operations; and allow vendors to protect their proprietary action frames.

Wireshark filter: wlan.fc.type == 0) && (wlan.fc.type_subtype == 0x0d)

It is known as Protected Management Frames (PMF) or Robust Management Frames (RMF).

When PMF is enabled and the 4-Way handshake is successfully completed, all transmissions of robust management frames are protected. These unicast frames benefit from both integrity and confidentiality protection using pairwise keys. Specifically, if CCMP or GCMP is utilized, data confidentiality is provided for both data frames and unicast robust management frames.

Group-addressed frame protection: Broadcast/multicast Robust Management Frames are integrity protected and authenticated (but not encrypted) using BIP. This protection is facilitated by the IGTK, which is used to generate a MIC for these management frames.

The MPDU of a BIP-protected management frame is structured as: {MAC Header || Frame Body || MME || FCS}

The Management MIC Element (MME) format is: {Element ID (1 byte, 0x4c) || Length (1 byte, 16) || KeyID (2 bytes) || IPN/BIPN (6 bytes) || MIC (8 or 16 bytes)}

The 48-bit IGTK Packet Number (IPN) for robust Management frames or BIGTK Packet Number (BIPN) for protected Beacon frames protects against replayed frames. Frames with duplicate IPNs are silently dropped. Specifically, the receiver maintains a 48-bit replay counter for each IGTK/BIGTK and compares the IPN value of each incoming frame against the corresponding replay counter, identified by the MME KeyID field. The replay counter(s), provided during either the 4-Way or Group Key handshakes, is initialized to the value supplied by the Authenticator.

MIC is computed over the concatenation of (AAD || Management Frame Body including MME). The length of the MIC field depends on the specific cipher negotiated and is either 8 octets (for BIP-CMAC-128) or 16 octets (for BIP-CMAC-256, BIP-GMAC-128, and BIP-GMAC-256).

The Key ID field identifies the IGTK or BIGTK used to compute the MIC.

AAD is defined as: FC (MPDU Frame Control field, with: Retry bit (bit 11), PwrMgt bit (bit 12), MoreData bit (bit 13) masked to zero) || A1 || A2 || A3, where: A1, A2, and A3 are the MPDU Address 1, 2, and 3 fields, respectively.

The IGTK is distributed within the third message of the 4-way handshake. When the AP updates the GTK, it initiates a Group Key Handshake. This handshake transmits the new IGTK, encrypted using the KEK, along with the updated GTK and an IGTK Packet Number. The IGTKSA comprises the following parameters: Direction Vector (indicating transmit or receive usage), Key ID, IGTK, and the Authenticator's MAC Address.

Before 802.11w, an AP receiving a (re)association or (re)authentication request from an already associated STA would terminate the existing connection and initiate a new one.

Connection protection: To mitigate DoS attacks that exploit this behavior, the SA Query teardown protection mechanism was introduced.

This mechanism utilizes two new management frames: SA Query Request and SA Query Response.

Each SA Query includes a 16-bit transaction identifier (a non-negative integer). This identifier must be identical in both the SA Query Request and its corresponding SA Query Response.

Protected SA Query messages are robust action frames, therefore protected.

Scenario: An AP receives a spoofed (re)association request purportedly from a STA

Upon receiving the spoofed (re)association request, the AP responds with a rejection notice (status code 0x1E (30): “Association request rejected temporarily; Try again later”). The response includes an Association Comeback Time (TUS), for example, 10 sec
Immediately after, the AP transmits an SA Query Request (a verification "ping") to the legitimate STA

If an SA Query Response is received within the TUS, the AP assumes the STA is active.

If no response is received, the AP retransmits the SA Query Request. If a response is then received within the TUS, the AP again concludes the STA is active.

If the STA is active, the AP ignores any subsequent (re)association requests from that STA for the duration of the TUS.

If no SA Query Response is received within the TUS (after retransmission), the AP determines the STA is offline and will allow a subsequent (re)association attempt.

The STA is unable to respond since association is lost and the associated keys are deleted.

Scenario: A STA receives unencrypted disassociation or deauthentication frames purportedly from an AP

The STA transmits an SA Query Request to the AP.

If an SA Query Response is received within the initial timeout period, the STA concludes that the AP is active.

If no response is received, the STA retransmits the SA Query Request. If an SA Query Response is received within the retransmission timeout period, the STA again concludes that the AP is active.

If the AP is active, the STA will maintain the connection.

If no SA Query Response is received within the retransmission timeout period, the STA determines that the AP is offline and disconnects.

The frame body of a Deauthentication/Deassociation frame contains a 2-bytes Reason Code. The 802.11-2020 std. defines 68 different reason codes.

6 INVALIDCLASS2FRAME Class 2 frame received from nonauthenticated STA
7 INVALIDCLASS3FRAME Class 3 frame received from nonassociated STA

IEEE 802.11w provides the following security services:

Integrity/Confidentiality: Selected unicast management and action frames are encrypted and integrity-protected, mitigating eavesdropping and spoofing attacks
Connection protection: SA Query prevents STAs from disconnections due to spoofed (re)association/(re)authentication requests
Protection of group-addressed frames: BIP

BIP protects the integrity of broadcast/multicasts, preventing replay and spoofing attacks

802.11w protects only specific management (and action) frames. For effective protection, both APS and STAs must have 802.11w enabled. The WPA3 specification mandates PMF

Suggested reading: PMF robustness is evaluated in 'Empirical evaluation of attacks against IEEE 802.11 enterprise networks: The AWID3 dataset', IEEE Access, 2020

WPA3

WPA3, released by the Wi-Fi Alliance in June 2018, was introduced as a successor to WPA2. WPA3 does not supersede WPA2; both protocols are intended to coexist, implying a multi-year transition period

WPA3-Personal

Enhanced Password-Based Authentication: Achieved through SAE, replacing PSK in WPA2-Personal. SAE, a variant of the Dragonfly Key Exchange defined in RFC 7664, provides resistance against offline dictionary attacks. SAE was initially standardized for mesh networks in IEEE 802.11s (incorporated into IEEE 802.11-2012). It's important to note that vulnerabilities have been discovered in SAE implementations within WPA3
Forward Secrecy: Enabled by SAE
Wi-Fi Device Provisioning Protocol (DPP): Replaces Wi-Fi Protected Setup (WPS), enabling device authentication via QR codes, NFC tags, and other methods, without requiring passwords. DPP is the core technology of the “Wi-Fi Alliance's Easy Connect certification" program
Mandatory PMF (802.11w-2009)
OWE: Defined in RFC 8110. OWE provides unauthenticated encryption and is susceptible to MITM attacks. It is a feature of the Wi-Fi Alliance's "Wi-Fi CERTIFIED Enhanced Open" certification

WPA3-Enterprise

Increased 192-bit sized keys
Authenticated encryption: 256-bit Galois/Counter Mode Protocol (GCMP-256)
Key derivation and confirmation: 384-bit Hashed Message Authentication Mode (HMAC) with Secure Hash Algorithm (HMAC-SHA384)
Key establishment and authentication: Elliptic Curve Diffie-Hellman (ECDH) exchange and Elliptic Curve Digital Signature Algorithm (ECDSA) using a 384-bit elliptic curve
Mandatory PMF

OWE

OWE = DH + 4-way handshake: No authentication, encrypted communications, PFS

PMF is required: the MFPR ("required") bit in the RSN capabilities field must be set to 1 in the RSNE transmitted by both the AP and the STA

AP: OWE AKM is advertised in RSNE contained in beacons and probe response frames

After a STA discovers an OWE-compliant AP, it performs open system authentication. Then it proceeds to 802.11 association via OWE

OWE information is added to 802.11 association requests and responses using an Element with ID = 255 and Element ID extension=32. A STA wishing to perform OWE must indicate the OWE AKM (00-OF-AC:18) and carry a DH parameter Element in the RSNE part of its association request

DH exchange uses Group 19 P-256 ECC (also used by SAE) with 128-bit CCMP or GCMP encryption

OWE transition mode: Support of both OWE STAs and non-OWE STAS

$z = F(DH(X, Y))$ , where x is the private key and Y is the peer's public key

Pseudo-Random Key (prk) = HKDF-extract(C | A | group, z), where C and A are the STA's and AP's public key (from the request/response association messages), and "group" is the two-octet group from the Diffie-Hellman parameter Element. The "C | A | group" part is the salt to the HMAC-based Extract-and-Expand Key Derivation Function (HKDF*)

As per RFC 8110, "z and prk should be irretrievably deleted once the PMK has been generated"

PMK = HKDF-expand(prk, "OWE Key Generation", n), where n is the bit length of the digest produced by the hash algorithm

PMKID = Truncate-128(hash(C | A)), where the hash algorithm can be SHA-256, SHA-384, or SHA-512

*HKDF-extract() and HKDF-expand() are defined in RFC 5869

OWE Security Considerations:

Opportunistic encryption does not provide authentication.
OWE only secures data sent over the wireless medium and does not provide security for end-to-end traffic. Users should still use application-level security to achieve security end-to-end.
OWE is susceptible to active attacks where an adversary impersonates an access point and induces a client to connect to it via OWE while it makes a connection to the legitimate access point. In this particular attack, the adversary is able to inspect, modify, and forge any data between the client and legitimate access point.
OWE is not a replacement for any authentication protocol specified in [IEEE802.11] and is not intended to be used when an alternative that provides real authentication is available.

SAE

SAE, a variant of the Dragonfly key exchange defined in RFC 7664, replaced open system authentication prior to network association in WPA3-Personal. The Dragonfly protocol is also employed by the EAP-pwd protocol, making it relevant to enterprise Wi-Fi networks

SAE was introduced in the IEEE 802.11s amendment, which was designed for mesh networks, and subsequently incorporated into the IEEE 802.11-2016 and later revisions of the IEEE 802.11 standard

The Wi-Fi Alliance presented SAE in mid-2018 as part of the WPA3 certification

SAE implements a password-authenticated key exchange (PAKE), where peers, relying solely on a shared password, establish a cryptographic key through a message exchange. This process eliminates the need for a central authority or certificates

SAE significantly enhances security in WPA3-Personal by providing resistance against offline dictionary attacks and offering perfect forward secrecy, representing a substantial improvement over the WPA2-PSK protocol

WPA3 mandates the use of PMF

The SAE basic protocol comprises a commit and a confirm phase between the STA and the AP

SAE introduces two new authentication frames: SAE Commit and SAE Confirm, representing the commit and confirm states, respectively

These auth. frames contain:

Authentication algorithm number (3)
Authentication sequence, 1 for Commit and 2 for Confirm
A status code, i.e., a value between 0 and 65,535, with 0 indicates "successful". Status code values between 1 and 107 represent various failure causes, while the remaining values are reserved. The 802.11-2020 std reserves 114, 115, 124, 127, and 130 to 65535

When an AP receives a Commit frame, it undertakes elliptic curve cryptographic (ECC) operations as part of the SAE handshake. The connecting STA generates this frame, which contains a Scalar and an Element (an ECC point). The STA selects a large, random private scalar, which is never directly transmitted. Instead, it performs elliptic curve point multiplication using a base point, generating an ephemeral public key (Element) that is included in the Commit frame. The Scalar field contains a masked version of the private scalar, providing protection against side-channel attacks by preventing an observer from inferring the private scalar based on timing, power consumption, or other measurable characteristics. Upon receiving the Commit frame, the AP uses the transmitted Element and Scalar, along with its own randomly generated private scalar and corresponding Element and Scalar, to perform ECC calculations. This results in both parties independently deriving a shared secret key, ensuring mutual authentication and forward secrecy.

The Wi-Fi passphrase is first processed using a Password Element (PE) derivation function, which transforms it into a cryptographic base value for the key exchange. Alternatively, in 802.11-2020, if the AP signals support for SAE Hash-to-Element, the hash-to-curve technique (SSWU) is used instead, mapping the inputs directly to an ECC point in constant time, eliminating the inefficiencies of hunting-and-pecking. The AP signals this capability by setting the SAE Hash-to-Element bit (bit 5) in the Extended RSN Capabilities field of the RSN Extension Element (RSNXE).

Following the Commit exchange, both the STA and AP send Confirm messages to finalize authentication. These messages contain a cryptographic hash, typically produced by HMAC-SHA-256, generated using a KCK derived from the shared secret, a confirm counter, and the Scalars and Elements exchanged in the Commit messages.

APs perform computationally intensive operations when processing SAE Commit frames creating a potential DoS attack vector, where an attacker floods the AP with forged SAE Commit frames

To mitigate this threat, SAE includes an anti-clogging defense mechanism, which comprises a simple cookie exchange procedure.

This defense is activated when the number of in-progress connections reaches or exceeds a predefined threshold

Once the anti-clogging mechanism is activated, upon receiving an SAE Commit frame from an STA, the AP responds with a new SAE Commit frame containing an anti-clogging token (cookie) of up to 256 bytes

In the hostapd implementation, the cookie is generated using the formula: Cookie = HMAC-SHA-256 randomkey (MAC STA), where the 64-bit randomkey is produced calling randomgetbytes()

The STA must return the same cookie, and the AP will reject SAE Commit messages unless they contain a valid cookie associated with the (original) sender's MAC address

The threshold that triggers the mechanism is known as dot11RSNASAEAntiClogging Threshold, and it is adjusted according to the capabilities of each AP (a typical value is 5)

TDLS PeerKey handshake

The TPKSA is used to create session keys to protect a TDLS session between two non-AP STAs. The TPKSA is established through a TPK handshake between the TDLS initiator STA and the TDLS responder STA.

Both STAs must have established an RSNA with their common AP before initiating the TPK handshake

The TPK handshake comprises 3 messages, all encapsulated in data frames and transmitted through the AP:

TDLS Setup Request,
TDLS Setup Response,
TDLS Setup Confirm

The purpose of the direct link is to reduce traffic load on the AP and alleviate potential congestion

Security assumptions:

Both the TDLS initiator and responder STAs are associated with the same AP. Each STA has an established RSNA with the AP used for TDLS setup
The nonces exchanged between the two STAs are not exposed by the AP or the participating STAs to any external party
The AP is assumed to be non-malicious and uncompromised. It does not use the nonces to derive the TPK and attack the TDLS. Additionally, TDLS message security processing at the AP is protected from unauthorized eavesdropping, alterations, insertions, and substitutions

Discovery and teardown process: Before establishing a link, the initiator STA attempts to learn the capabilities of the responder STA. This is done via a TDLS Discovery Request, which includes a Link Identifier element. If the responder STA can establish a TDLS connection, it responds with a TDLS Discovery Response. The response is sent directly to the initiator STA, not through the AP. If either STA wishes to terminate the link, it sends a Teardown message through the AP

The following 3 elements are used in the context of the TPK handshake:

Fast BSS Transition element (FTE): This element includes information required to perform the Fast Transition authentication sequence or Fast Initial Link Setup (FILS) within an RSN. FILS is part of the "Wi-Fi Optimized Connectivity" Wi-Fi Alliance certification, which is a key component of Wi-Fi CERTIFIED Vantage

Link Identifier element: This element contains information that identifies a TDLS direct link

Timeout Interval element (TIE). This element carries time intervals and timeouts

TDLS PMK handshake msg. 1: TDLS initiator → TDLS responder {Link Identifier element, RSNE, Timeout Interval element, FTE}

RSNE: Ver. = 1; TDLS initiator STA's pairwise cipher suites for TPKSA; WEP and TKIP must not be used; Group cipher suite = 00-OF-AC:7 (Group address traffic is not allowed); AKM suite count field = 1; The AKM suite list field = 00-OF-AC:7 (TPK handshake); RSN Capabilities field: No Pairwise subfield = 0 and the PeerKey Enabled subfield = 1; PMKID Count subfield, if present, shall be set to 0; PMKID list = zeroed; Group Management Cipher Suite subfield, if present = 00-OF-AC:7
TIE: indicates the lifetime of the TPKSA. The Lifetime Interval Type field = 2. The minimum lifetime = 300 sec
FTE: SNonce: a 256-bit value chosen randomly by the TDLS initiator; All other fields are zeroed

TDLS PMK handshake msg. 2: TDLS responder → TDLS initiator: {Link Identifier element, RSNE, Timeout Interval element, FTE}

RSNE: A pairwise cipher suite selected from those contained in RSNE of msg. 1; Pairwise cipher suite count = 1; All other RSNE fields shall be same as those received in msg. 1
TIE: the same as that in msg. 1
FTE: Anonce = A randomly generated 256-bit value; SNonce same as that received in msg. 1; MIC: It is calculated on the following fields in that order {TDLS initiator MAC address, TDLS responder MAC address, Transaction Sequence number = 2, Link Identifier element, RSNE, TIE, FTE, with the MIC field of the FTE set to 0}; MIC calculation uses: TPK-KCK and AES-128-CMAC; All other fields are zeroed

TDLS PMK handshake msg. 3: TDLS initiator → TDLS responder: {Link Identifier element, RSNE, Timeout Interval element, FTE}

RSNE: The same as that received in msg. 2
TIE: The same as that received in msg. 2
FTE: Except for the MIC field, its contents should be the same as that received in msg. 2; MIC: is calculated on the following fields in that order {TDLS initiator MAC, TDLS responder MAC address, Transaction Sequence number = 3, Link Identifier element, RSNE, TIE, FTE, with the MIC field of the FTE set to 0}; All other fields are zeroed

The TPK is derived as:

TPK-Key-Input = Hash(min (SNonce, ANonce) || max (SNonce, ANonce))

TPK = KDF-Hash-Length (TPK-Key-Input, "TDLS PMK", min (MACI, MACR) || max (MACI, MACR) || BSSID)

Hash: the SHA-256 algorithm. It corresponds to the negotiated AKM
KDF-Hash-Length: the key derivation function
Length: TK_bits + 128
TK_bits: cipher-suite dependent, e.g., for CCMP-256 is 256 bits
MACI and MACR: the MAC addresses of the TDLS initiator and responder
SNonce and Anonce: the exchanged nonces during the TDLS handshake
BSSID: the BSSID of the BSS of which the TDLS initiator is associated to

TPK is split into TPK-KCK and TPK-TK. TPK-KCK is computed as bits 0-127 of the TPK. This key is used to provide data origin authenticity in TDLS Setup Response/Confirm frames

The TPK-TK is used to provide confidentiality for direct-link data

DPP

Wi-Fi Device Provisioning Protocol (DPP): A Wi-Fi Alliance standard, streamlines and secures the onboarding of Wi-Fi devices. It involves two primary entities: the Configurator and the Enrollee

Roles

Enrollee: This is the device being provisioned, such as an loT sensor, smart appliance, or other. It announces its presence and provides the necessary information for secure authentication and configuration.
Configurator: This is the device or system that initiates the provisioning process, often a smartphone, tablet, or AP. It authenticates the Enrollee and configures its network settings

Prior to the DPP protocol's commencement, the Configurator must obtain a URI that includes the Enrollee's bootstrapping public key. This is typically achieved by scanning a QR code, using an NFC tag, downloading from the manufacturer's cloud, or via alternative means

Initiator/Responder: Either the Configurator or Enrollee can assume either role, allowing for flexible protocol initiation

Bootstrapping Keys (Ik, Rk): Long-term identity public/private key pairs, forming the basis of trust, and are usually acquired through out-of-band methods

The Initiator obtains the Responder's public key (Rk) through:

QR codes: Encoding a URI that directly contains the Responder's public key
Short-range communication (NFC, BLE): Used for proximity-based key transfer
Cloud-based retrieval: Obtaining the key over HTTPS from a manufacturer's cloud service
Public Key Exchange (PKEX): A wireless method for key exchange

For mutual authentication, each device acquires the other's public keys (Ik and Rk)

Security considerations:

Security of Key Transfer: The goal is to minimize eavesdropping and tampering. QR codes and NFC provide physical verification. Cloud retrieval uses HTTPS and authentication
BLE/NFC are vulnerable to relay attacks and skimming (an attacker illicitly captures or copies data transmitted wirelessly between devices)
The flexibility of bootstrapping methods can introduce security risks due to user error

Bootstrapping keys establish a temporary, authenticated connection

The Responder strongly authenticates to the Initiator (proof of private key ownership)

The Initiator can use:

The default option (weak authentication), where the Initiator simply proves knowledge of the Responder's public key as a means of confirming prior bootstrapping
Alternatively, mutual authentication can be enabled, allowing the Initiator to prove ownership of its private key and provide strong authentication to the Responder

Authenticated Diffie-Hellman (ADH) or similar protocols are used to establish a secure channel, and to derive a shared secret. A symmetric key, Ksym, used for encrypting configuration data in the next phase, is then derived from this shared secret

PAKE protocols, such as Dragonfly, can utilize the shared secret derived from ADH for added security against offline attacks

Configuration Phase: Secure Data Transfer: The Configurator encrypts the configuration data using the symmetric key (Ksym), established during the authentication phase. This encryption ensures the confidentiality and integrity of sensitive information, such as the Wi-Fi network's SSID and password

Configuration Parameters: The Configurator transmits the following information to the Enrollee: SSID, Password (network passphrase), The authentication type(s) for the network, other network settings

During this phase, Connector-I and Connector-R are generated; these are used as inputs for the Network Access phase

Network Access Phase: PMK Establishment: The Enrollee and the AP establish the PMK through the Network Introduction protocol, as specified in DPP. This process involves the exchange of connectors, specifically Connector-I and Connector-R. Connector-I contains the Initiator's public network access provisioning key (NK), and Connector-R contains the Responder's public network access provisioning key (PK)

Each device then derives a shared secret (N) using its private network access provisioning key (nk or pk) and the peer's public network access provisioning key (PK or NK), respectively

The PMK is subsequently derived from this shared secret (N) using the HKDF. The PMKID is also generated to identify the PMK

The shared secret (N) is securely deleted after the PMK and PMKID are generated

PTK Derivation: The PTK is derived from the PMK through the standard 4-way handshake, verifying that both the Enrollee and the AP possess the correct PMK and establishing a secure communication channel

MAC address randomization

STAs transmit probe requests and listen for probe responses, which contain SSIDs. Each STA's MAC address is included within its probe requests

To protect STAs from tracking during network discovery and post-association, MAC address randomization is employed. This technique obscures the sender's identity by periodically replacing the device's hardware MAC address with a Locally Administered Address (LAA)

While MAC address randomization has been implemented since 2014, the standardization effort has resulted in the publication of RFC 9724 in March 2025

Prior to RFC 9724, vendors and researchers developed custom randomization schemes. For example, Android versions 12 and later, similar to iOS 14, support "non-persistent randomization". This scheme re-randomizes the Wi-Fi module's MAC address at the start of each new connection under these conditions:

The DHCP lease has expired, and more than four hours have passed since the device's last disconnection from the network
The current randomized MAC address for the network profile was generated over 24 hours ago

Attacker's model: Considers a passive attacker who wishes to infer the movement of certain persons by monitoring their STA's probe requests

The attacker deploys numerous distributed receivers, enabling surveillance of a substantial area, such as a train station, airport, or university campus

By analyzing the U/L bit within the MAC address, the attacker can differentiate between globally and locally administered MAC addresses

The attacker may attempt to leverage OUI's present in locally administered MAC addresses to infer device manufacturer information. It should be noted that modern devices may randomize OUIs or utilize private OUI ranges, limiting the reliability of this technique

The attacker may also attempt to track devices by analyzing recurring or persistent elements within the MAC address or other information, such as the RSNE. The specific exploitable information within the RSNE depends on implementation and configuration. Additionally, the attacker could use timing. analysis of probe requests to gather additional data on device behavior

The structure of a 48-bit MAC address:

octet 1: Organisationally Unique Identifier (OUI)
octet 2: Network Interface Controller (NIC) Specific

octet 2 structure (8 bits: b7b6b5b4b3b2b1b0):

b0: 0 = unicast, 1 = multicast
b1: 0 = globally unique (OUI enforced), 1 = locally administered