Cisco Blogs

Cisco Blog > Mobility

802.11i, Authentication and You

Not too long ago I was assigned to a troubleshooting and remediation project for a hospital here in the SF bay area. The problem, after much troubleshooting and lab recreations, was determined to be due to an unique issue with client roaming and authentication. During the course of troubleshooting my coworker and myself often found ourselves explaining 802.1X and 802.11i to others working on the troubleshooting effort, or requesting technical updates. So based on that experience, I started thinking this might a be a good topic to cover here.

Let’s review the some of typical components of the enterprise wireless security model.

What is 802.1X?
802.1X is not a protocol, but rather a framework for a “port-based” access control method.  802.1X was initially created for use in switches, hence the port-based terminology, which really doesn’t fit too well in wireless since users don’t connect to a port. In the end it’s meant to be a logical concept in the 802.11 world.  802.1X was adopted for wireless networks with the creation of 802.11i to provide authenticated access to wireless networks. At a high level. the framework allows for a client that has connected to the WLAN to remain in a blocked port status until it has been authenticated by a AAA server. Essentially the only traffic allow through this virtual blocked port is EAP traffic, things like HTTP would be dropped.

What is EAP?

EAP  (Extensible Authentication Protocol) is the authentication method used by 802.1X. It can take on various forms, such as PEAP, EAP-TLS, EAP-FAST, to name a few. There is one thing to remember when determining what EAP type to use in your network, is that it is dependent upon what your client and AAA server supports. This is it, your AP or AP/Controller hardware or code version will play no part in version is supported. Unless your AP/controller is acting as the AAA server, but I’ll stay away from that in this post. I think this can be a point of confusion for people who haven’t read much or anything about EAP methods. So, if some one asks what version of EAP the AP will support, all you need to do is ask them, what does their Client and AAA server support.

What is 802.11i?

Simply put, 802.11i is an amendment to the original 802.11 standard to address the well documented security short comings of WEP. It incorporates WPA  as a part of the 802.11i amendment and adds the fully approved WPA2 with AES encryption method. 802.11i  introduces the concept of a Robust Security Network (RSN) with the Four-way handshake and the Group key Handshake.

Now that I’ve reviewed the some of the concepts, let’s put it all together logically with the flow from initial client connection and end with the four-way handshake.

EAP Devices

Supplicant – device requiring authentication to the network.

Authentication Server – device that authenticates the supplicant. Typically uses an internal database or an external database of authorized users.

Authenticator – device which acts as a relay agent between the supplicant and authentication server.

Shown below is what each device in the Cisco CUWN would be considered.  If you were using a autonomous APs the Authenticator would be the AP itself.

EAP Devices

How do all these devices communicate and what is sent where?  Let’s expand the above image to include the conversation.

EAP Conversation

The above image is simplified to some degree, but what it  illustrates is that the controller really only acts as a middle man to get the conversation started with the Authentication Server. Once the Server has established the supplicant’s identity and verified it supports the EAP the supplicant is using, the authentication can begin. This phase will authenticate the client as valid and having permission to access the network, it does not establish the encryption keys to be used by the client for the duration of it’s session. This is done in the next step called the four-way handshake, illustrated below.

Four-way handshake

Once the EAP process is successful a master key generated, called the Pairwise Master Key (PMK), which at this point is stored on the Authenticator. This key, like it’s name suggests, is the master key for the device and is used to help generate all subsequent keys used for encryption. To break down the above image, the authenticator sense the ANonce, which is a randomly generated number to the supplicant. The supplicant that uses that info combined with the SNoce (another randomly generated number) to generate and install the Pairwise Temporal Key(PTK) on its side. The supplicant will send the SNonce plus the MICto the Authenticator, which will validate the MIC and combine the SNonce with it’s ANonce to create the PTK.

Both the AP and the Supplicant  have the information needed to encrypt/decrypt unicast traffic between the two once this part of the exchange is completed.

Now the authenticator will send the MIC and the Group temporal key(GTK) to the supplicant, so both devices can encrypt/decrypt multicast and broadcast traffic. The last step is for the supplicant to sent and acknowledgement that the keys were installed.

At this point the supplicant is connected to the network and ready to access the needed resources.  While I present a technical yet simplified version of the 802.11i process, I highly encourage anyone that hasn’t read the CWSP book yet to go get a copy and really dive into this.  I didn’t even touch on how this process changes with PSK (spoiler, it doesn’t really with the exception of no EAP) Once you start adding fast roaming to this and 802.11r, this can become slightly more complex. However if you have a good understanding of how this all works it will go a long way when trying to troubleshoot client connectivity issues.


Tags: , , , , , , , , , , , , , , , , , ,

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Not trying to nitpick, but the current SW has used CAPWAP vs. LWAPP for a while now...