Decoding Deauthentication January 25, 2010
Posted by Devin Akin in : Uncategorized , trackbackBecause 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»
This is the first time I had heard (or thought) about 802.11v providing input to the Wi-Fi Alliance Voice-Enterprise certification, but it does make sense. In sort of fills some of the gaps left by 802.11k. Hurry up Wi-Fi Alliance.
It’s funny how the 802.11 spec sort of grows on a person. At first it is all nonsense and tomfoolery, but over time it starts to make sense and the power of this knowledge gets a hold on you. Then you find yourself with a copy of it by your bed, and another one in the living room under your end table. Devin, what have you done to me?
Hey, don’t blame it on me! All I did was show you the light, and you took it from there.
It’s hardly my fault that I used section 9.6 to hook you. hehe.