De-Authentication

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).

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

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.