De-Authentication ====================== .. contents:: :local: :depth: 2 Overview -------- Deauthentication is a MAC-layer management primitive in IEEE 802.11 that terminates the **authentication relationship** between two peers (typically a Station and an Access Point). After deauthentication the recipient is no longer authenticated (and therefore not associated); the recipient must re-authenticate before it can associate and resume normal data exchange. Deauthentication is a more-absolute teardown than **disassociation**: disassociation removes the logical association used for data forwarding, whereas deauthentication removes the authentication binding itself (and as a result association state must be re-established after deauth). Frame format and semantics -------------------------- A Deauthentication frame is a Management frame (Type = Management, Subtype = Deauthentication). Key fields (after the standard 802.11 MAC header) are: - **Reason code** (2 octets) — numeric code describing why the sender is deauthenticating the peer. - No variable-length payload is required (vendor IEs may be present in some implementations). Typical behavior: - A **unicast** deauth is sent to a specific peer and is protected by the usual MAC-layer ACK mechanism (if received and decoded it will be ACKed). - A **broadcast** deauth (destination FF:FF:FF:FF:FF:FF) is not ACKed and serves as a network-wide notification (rare in normal operation). - In legacy 802.11b the frame is **sent in the clear** (unprotected). If Management Frame Protection (802.11w / PMF) is negotiated, deauth frames must be protected according to PMF rules. Deauthentication vs Disassociation ---------------------------------- - **Disassociation** (Mgmt subtype = Disassociation) severs the association but usually leaves authentication intact (so a station can reassociate without re-authenticating, subject to AP policy). - **Deauthentication** severs authentication; the station must **re-authenticate** before it can associate again. Reason-code table (numeric) --------------------------- The following **Reason Code** mappings are the standard numeric codes used in deauthentication and disassociation management frames (values taken from the IEEE 802.11 reason-code list used in practice). .. list-table:: :widths: 15 85 :header-rows: 0 * - 0 - Reserved (no specific reason) * - 1 - Unspecified reason. * - 2 - Previous authentication no longer valid. * - 3 - Deauthenticated because sending STA is leaving (or has left) IBSS or ESS. * - 4 - Disassociated due to inactivity. * - 5 - Disassociated because AP is unable to handle all currently associated STAs. * - 6 - Class 2 frame received from nonauthenticated STA. * - 7 - Class 3 frame received from nonassociated STA. * - 8 - Disassociated because sending STA is leaving (or has left) BSS. * - 9 - Station requesting (re)association is not authenticated with responding station. * - 10 - Disassociated because the information in the Power Capability element is unacceptable. * - 11 - Disassociated because the information in the Supported Channels element is unacceptable. * - 12 - Disassociated due to BSS Transition Management (or reserved in some revisions). * - 13 - Invalid element (an information element defined in the standard has contents that do not meet the specification). * - 14 - Message integrity code (MIC) failure. * - 15 - 4-Way Handshake timeout. * - 16 - Group Key Handshake timeout. * - 17 - Element in 4-Way Handshake different from (Re)Association Request / Probe Response / Beacon frame. * - 18 - Invalid group cipher. * - 19 - Invalid pairwise cipher. * - 20 - Invalid AKM (Authentication and Key Management) suite. * - 21 - Unsupported RSNE version. * - 22 - Invalid RSNE capabilities. * - 23 - IEEE 802.1X authentication failed. * - 24 - Cipher suite rejected because of the security policy. * - 25 - TDLS direct-link teardown: peer STA unreachable via TDLS direct link. * - 26 - TDLS direct-link teardown: unspecified reason. * - 27 - Disassociated because the session is terminated by SSP request. * - 28 - Disassociated because of the lack of SSP roaming agreement. * - 29 - Requested service rejected because of SSP cipher suite or AKM requirement. * - 30 - Requested service not authorized in this location. * - 31 - TS (Traffic Stream) was deleted because QoS AP lacks sufficient bandwidth for this QoS STA due to a change in BSS service characteristics or operational mode. * - 32 - Disassociated for unspecified QoS-related reason. * - 33 - Disassociated because QoS AP lacks sufficient bandwidth for this QoS STA. * - 34 - Disassociated because excessive number of frames need to be acknowledged, but are not acknowledged due to AP transmissions and/or poor channel conditions. * - 35 - Disassociated because STA is transmitting outside the limits of its TXOPs. * - 36 - Requested from peer STA as the STA is leaving the QBSS (or resetting). * - 37 - Requested from peer STA as it does not want to use the mechanism. * - 38 - Requested from peer STA as the STA received frames using the mechanism for which a setup is required. * - 39 - Requested from peer STA due to timeout. * - 40 - Peer STA does not support the requested cipher suite. * - 45 - In a DLS teardown frame: teardown initiated by DLS peer. In a Disassociation frame: disassociated because authorized access limit reached. * - 46 - In a DLS teardown frame: teardown initiated by AP. In a Disassociation frame: disassociated due to external service requirements. * - 47 - Invalid FT Action frame count. * - 48 - Invalid pairwise master key identifier (PMKI). * - 49 - Invalid MDE (Mesh) element. * - 50 - Invalid FTE (Frame Type Extension) (Mesh). * - 51 - SME cancels the mesh peering instance for reasons other than reaching the maximum number of peer mesh STAs. * - 52 - Mesh STA has reached the supported maximum number of peer mesh STAs. * - 53 - Received information violates Mesh Configuration policy. * - 54 - Mesh STA received Mesh Peering Close request. * - 55 - Mesh Peering Open retransmission retries exceeded. * - 56 - Mesh confirm timer timeout. * - 57 - Mesh STA fails to unwrap GTK or wrapped contents do not match. * - 58 - Received inconsistent mesh parameters between Mesh Peering Management frames. * - 59 - Mesh STA failed authenticated mesh peering exchange due to cipher selection failure. * - 60 - Mesh STA does not have proxy information for external destination. * - 61 - Mesh STA lacks forwarding information for destination. * - 62 - Mesh STA determines that next hop in active path is no longer usable. * - 63 - Deauthentication because MAC address of STA already exists in the mesh BSS. * - 64 - Mesh STA performs channel switch to meet regulatory requirements. * - 65 - Mesh STA performs channel switch with unspecified reason. * - 67 - 65535 - Reserved (various vendor/extension or future use). .. note:: Some reason-code values are reserved or have expanded meanings in later amendments (802.11r/802.11w/802.11s etc.), and some vendor systems may use vendor-specific codes or semantic mappings. Use the exact numeric code seen in captures together with the AP's logs / controller logs for precise diagnosis. See References below. :contentReference[oaicite:0]{index=0} Behavior on receipt -------------------- When a STA receives a deauthentication frame from its AP: - The STA validates the frame (CRC/format) and, if PMF is in use, verifies the management-frame protection integrity. If verification fails, the frame may be discarded or treated as suspicious. - If accepted, the STA reads the **Reason Code**, logs it and immediately transitions to the **Unauthenticated, Unassociated** state. - The STA typically **clears per-session keys** (PTK, GTK, replay counters) and any in-progress handshake state (e.g. 4-way handshake). - The STA notifies higher layers (supplicant/OS) so the user-space network manager can act (e.g. attempt reconnect, inform user). - If the deauth was unicast it will be ACKed at MAC layer (receiver sends MAC ACK). Broadcast deauths are not ACKed. When an AP receives a deauthentication from a STA: - The AP removes the STA’s AID and frees associated resources (power-save queues, per-STA state). - The AP may optionally notify backend AAA servers (RADIUS) depending on authentication integration. - The AP should log the event and reason code for troubleshooting. Interaction with RSN / 802.1X / Key Material ------------------------------------------- - Deauthentication implies termination of the RSN context: the PTK and per-station keys should be discarded, and any in-progress keying exchanges aborted. The supplicant should detect the failed session and clear transient handshake state. - Some implementations may keep PMK caches across deauths (vendor-dependent), but a true deauthentication per policy should remove authentication keys. - Reason codes in the 14–24 range frequently indicate RSN/802.1X related failures (e.g., MIC failure, 4-way timeout, cipher suite rejection). Use logs and reason codes together to debug security issues. :contentReference[oaicite:1]{index=1} Security implications — deauth attacks and mitigations ----------------------------------------------------- - Legacy 802.11b management frames (including deauth) are **unauthenticated** and can be spoofed by an attacker (for example an off-channel attacker crafting deauth frames with the AP’s MAC as source). This is the commonly seen **deauth flood** / **deauth spoof** attack used to disconnect clients. - **Mitigations**: - Deploy **Protected Management Frames (PMF / 802.11w)** where supported; PMF provides integrity protection for deauthentication and disassociation frames so a client can detect spoofed unprotected deauths and ignore them. - Rate-limit reconnection attempts on clients to avoid thrash under attack. - AP/controller-level heuristics to detect large rates of deauths and trigger countermeasures or alerts. - Monitor RADIUS/AAA and AP logs to correlate policy-driven deauths vs suspicious traffic. :contentReference[oaicite:2]{index=2} Examples (common situations) ---------------------------- - **Administrative removal**: operator commands AP to deauth a specific STA (reason: administrative removal). STA will drop to Unauthenticated state. - **Authentication failure**: 802.1X backend rejects or times out → AP deauthenticates STA with a reason code indicating authentication failure. - **Key handshake failure**: Repeated 4-way handshake failures or MIC errors may lead to deauths with reason codes 14–16. - **Roaming / load balancing**: some controllers use deauths to force clients to reconnect to a different AP (careful: causes full reauthentication). Implementation notes and best practices -------------------------------------- - **Emit clear logs**: when issuing a deauth, include the numeric reason code and textual description in AP logs and controller records. - **Use PMF**: enable management frame protection in modern deployments to prevent spoofed deauths (clients and APs must both support it). - **Graceful STA leave**: clients should send deauth when voluntarily leaving (battery shutdown, user disconnect) to help AP free resources immediately. - **Avoid forcing roaming by deauth** unless coordinated by controller logic; deauth causes full reauthentication and increases latency and load. - **Queue handling**: AP implementations should clear per-STA buffers and release AID slots promptly on deauth. Debugging tips -------------- - Capture traffic with a packet sniffer (Wireshark/tcpdump). Filter for management subtype deauthentication/disassociation (Wireshark display filters: ``wlan.fc.type_subtype == 0x000c`` for deauth, or use labels). - Inspect the **reason code** and correlate with AP logs / RADIUS logs. - If many deauths are observed with different spoofed source MACs → likely an external deauth attack; check regulatory and controller defenses. - Verify if PMF (802.11w) is advertised in the AP beacon / RSN IE. If PMF is required, unprotected deauths should be ignored by compliant clients. References ---------- - IEEE 802.11 Management frame reason-code definitions (standard mappings reproduced by vendor/standards references). :contentReference[oaicite:3]{index=3} - For practical debugging and vendor interpretations see the Juniper/Mist and Zyxel support pages. :contentReference[oaicite:4]{index=4} Appendix — common reason codes quick lookup ------------------------------------------- .. list-table:: :widths: 10 40 50 :header-rows: 1 * - Code - Short name - Short meaning * - 1 - Unspecified - Generic unspecified reason. * - 2 - PrevAuthNotValid - Previous authentication no longer valid. * - 3 - STA_Leaving - STA is leaving the BSS/ESS. * - 4 - Inactivity - Session timed out due to inactivity. * - 14 - MIC_Failure - Message integrity code (MIC) failure — security issue. * - 15 - 4wayTimeout - 4-way handshake timed out. * - 23 - 802.1X_Failed - IEEE 802.1X authentication failed. * - 24 - CipherRejected - Cipher suite rejected by security policy. * - 67..65535 - Reserved - Reserved / future use.