As part of my role I assess existing WLAN’s for Voice support. During the survey I like to independently verify as much of the information I’ve been given as possible using protocol analysis.. One setting that I always struggled to find was the security in use, particularly when EAP / Dot1X was in use.
I had most of it figured out and was able to answer my last few questions when I took the CWAP course recently with Peter Mackenzie (@MackenzieWiFi). So here is a look at spotting the security in use on an SSID.
Normally information about the security employed on an SSID can be found in the RSN IE (Information Element) of Beacons and Probe Responses. RSN stands for Robust Security Network, which I believe was introduced with 802.11i. This was the amendment that made the WI-Fi Alliances WPA2 security suite an official part of the 802.11 standard. You won’t find an RSN IE in SSID’s running WEP or WPA(1) as they are pre-802.11i.
To illustrate this point the below screenshot shows a Probe Response from an SSID using Open authentication (left) and an SSID using WPA2 authentication (right). You can see the RSN IE in the WPA2 Probe Response below, but not in the Open Authentication (pre-802.11i) Probe Response.
It is worth recapping here that WPA2 is the authentication and key management method for all 802.11i SSID’s, whether they use a Pre Shared Key or EAP (Extensible Authentication Protocol). Often people assume WPA2 is only what you use at home on SSID’s with a password and EAP is something else. This is not the case, WPA2 is used to define the secure handshake process for both PSK and EAP SSID’s, hence you will see in Windows options for WPA2-Personal (PSK) and WPA2-Enterprise (EAP).
So, assuming you’re working with a WPA2 SSID then you need to look at the RSN IE (Information Element) in either the Beacons for the SSID or in the Probe Responses to a connecting client. The mystery doesn’t end there though. If you’re used to looking at 802.11 frames then you’ll know that they are basically a different language! Understanding what all these Bits mean is enough to make anyone go crossed eyed. Thankfully both Omnipeek and Wireshark do a pretty good job of decoding (translating) those Bits into useful information.
The below screenshot shows the RSN IE of a WPA2-PSK Probe Response. Without the magic of our Protocol Analyser software we would have to know that 00-0F-AC-04 meant CCMP was in use for encryption and that 00-0F-AC-02 meant that a Pre Shared Key (PSK) was in use for access credentials. Instead, Omnipeek in this case, puts a lovely mucus green note on the end telling us this (Wireshark does this also).
In case anyone has forgotten, CCMP is the 802.11i derivative of AES used to encrypt WPA2 connections. When you see CCMP you can read it as AES.
It is also helpful to know that the Extensible Authentication Protocol (EAP) is just a framework for passing some sort of authentication and keying mechanism over, it is not a defined mechanism itself. Implementations such as PEAP or EAP-TLS are specific authentication mechanisms that build on the EAP framework to specify exact how an authentication exchange should take place.
For some reason EAP has become the terminology used for RADIUS based credential access on 802.11 networks. However, it is actually EAP encapsulated in the IEEE 802.1X standard (or Dot1X as its commonly known) that is used to secure our “EAP” SSID’s.
Ok. Enough! My head is hurting. So what about EAP SSID’s? How do we verify these settings in our protocol analysis? Well, there is a reason I dove into that very in-concise and ungraceful (and probably slightly wrong) description of EAP. And that is because you won’t find it listed in your frames!
The screenshot below shows a Probe Response from a WPA2-EAP SSID. Notice how the AKMP Suite is listed as 802.1X, not EAP? Frustratingly you won’t find the EAP type (PEAP, EAP-TLS, etc) listed in any Beacons or Probe Responses. This is because the AP is going to use 802.1X between the client and itself. The encapsulated EAP frames will then be sent onto the RADIUS server who decides which EAP type to use. In fact, when configuring an SSID for EAP you won’t actually be able to specify an EAP type to use (…unless you’re using the controller/access point as the RADIUS server as well).
Note: The above Probe Response shows the SSID also supports 802.11r or Fast Transition (FT) as it’s known in the standard.
So you are able to verify that the SSID is using WPA2-EAP but this is not enough if you’re trying to configure your client correctly to connect. How do we verify the specific EAP type in use? Well, as far as I know, the only way is to try and connect to the SSID and watch the EAP messages (known as EAP Over LAN or EAPOL messages). The below screenshot shows a RADIUS server asking a client (in this case an iPhone) to use EAP-TLS for authentication.
But to support EAP-TLS a certificate needs loaded onto the client, which we did not do in this test. So the client sends a Negative Acknowledgement (N-Ack) to the RADIUS server declining EAP-TLS, as you can see below. These frames all happen in sequence, so you can tell the NAk is for the previous EAP-TLS request.
Thankfully the RADIUS server is setup with multiple authentication mechanisms so it now requests the client uses PEAP.
This time the client does support PEAP so it Responds reiterating the use of PEAP, and starts the handshake process by saying “Hello”.
There will then be lots more EAPOL messages in your protocol analysis as the client and RADIUS server continue the challenge and keying involved in the EAP type in use.
All of this information is contained in the 802.11 headers so is viewable without needing to decrypt any captures. If you want to look for yourself and have a play around you can download the EAP Association capture used for these screenshots here.
I hope this helps you understand a bit more about protocol analysis of 802.11 authentication mechanisms and proves useful when you have a client struggling to connect to an SSID. As always, please leave your feedback below and connect with me on Twitter at @Mac_WiFi.
** Thanks to Keith Miller (@packetologist) for the minor correction and Rob Lowe (@roblowe6981) for prompting me to upload the capture file **