Search Now

Decoding Deauthentication

Because the boys and girls at IEEE have done such an astounding job on the 802.11 standard, I’m certainly going to mention that this is their fine work.  Below is an excerpt from 802.11-2007 (copyright IEEE).

————————
5.4.3.2 Deauthentication
The deauthentication service is invoked when an existing Open System or Shared Key authentication is to be terminated.  Deauthentication is an SS.

In an ESS, because authentication is a prerequisite for association, the act of deauthentication shall cause the STA to be disassociated. The deauthentication service may be invoked by either authenticated party (non-AP STA or AP).  Deauthentication is not a request; it is a notification. Deauthentication shall not be refused by either party. When an AP sends a deauthentication notice to an associated STA, the association shall also be terminated.

In an RSN ESS, Open System authentication is required. In an RSN ESS, deauthentication results in termination of any association for the deauthenticated STA. It also results in the IEEE 802.1X Controlled Port for that STA being disabled and deletes the pairwise transient key security association (PTKSA). The deauthentication notification is provided to IEEE Std 802.1X-2004 via the MAC layer.

In an RSNA, deauthentication also destroys any related PTKSA, group temporal key security association (GTKSA), station-to-station link (STSL) master key security association (SMKSA), and STSL transient key security association (STKSA) that exist in the STA and closes the associated IEEE 802.1X Controlled Port.
If pairwise master key (PMK) caching is not enabled, deauthentication also destroys the pairwise master key security association (PMKSA) from which the deleted PTKSA was derived.

In an RSN IBSS, Open System authentication is optional, but a STA is required to recognize Deauthentication frames. Deauthentication results in the IEEE 802.1X Controlled Port for that STA being disabled and deletes the PTKSA.
————————

Just as a point of fact, next to the Bible, the 802.11 standard (with amendments) is my favorite book.  Who would’ve thought that the 802.11 standard had groupies like me. :)   Anyway, back to the topic at hand….  The reason I copied this small section into this blog is that there’s no point in trying to recreate something that’s already practically perfect…if not completely perfect.  In GA, we call that “reinventing the wheel.”  These guys said it better than I could have, so we’ll use their text to talk about this week’s topic: deauthentication (deauth).

What a deauth does (recap, in plain Geeky English)

1) breaks the 802.11 authentication and association
2) closes the “controlled port” for 802.1X/EAP authenticated clients
3) deletes the PTKSA and GTKSA (meaning the PTK which were formed during the 4-Way Handshake is now invalid)
4) deletes the PMKSA unless PMK caching isn’t enabled

It’s #4 that I’m most interested in talking about.  Regardless of architecture (controller-based or controller-less), most vendors have the ability for the PMKSA to be cached.  This means that when an 802.1X/EAP client roams, the PMK is still used for the next authentication.  Today’s de facto standard fast/secure roaming algorithm, called Opportunistic Key Caching (OKC), has the AP to which the client is associated forwarding the PMK to either a controller or other APs directly, where it’s used to create a new PMKID which the client can use for roaming to new APs.  It works well, and the Wi-Fi Alliance’s Voice-Enterprise certification will pull components from 802.11r, k, & v to enhance and standardize this process.

So to recap, deauth frames break PTKSAs (on the current AP and client) but allow PMKs to live on for reuse at other APs.  Obviously this isn’t a top-of-mind subject, but when you’re constantly designing stuff, you run into weirld little nuances like this that can catch you off-guard.  Obviously I’m not as advanced in 802.11 protocol and system design as our top hardware and software engineers, but in striving to reach their level of uber-geekiness, I stumble across little protocol nuggets like this that I can share.

As my good friend Criss likes to say: hope this helps.

/Devinator



Comments for Decoding Deauthentication

blog comments powered by Disqus