8021X Packet Flow (PEAP-MSCHAPv2)

PEAP-MSCHAPv2 is hopefully on the way out since it's slow, broken and cumbersome. Still, it's widely used and I do not see that changing in the near future. Organizations will need to have some form of PKI and other will need to begin retiring aging devices that do not support EAP-TLS (WPA2 or 3).

Since its so common and the fact I deal with a lot of troubleshooting issues related to this authentication method, I decided to make a post about it. This is going to focus primarily on the wireless side, between the supplicant and authenticator. If you’d like to learn about the wired side of things I found this blog post during my research.

First we’ll introduce the message exchange ladder to understand the shear amount of messages needed to completely authenticate the client. This hints at why this method is slow compared to other methods.


 
http://revolutionwifi.blogspot.com/2010/09/peapv0-packet-flow-reference.html

We’ll skip over the initial connection and start with the method selection. If you would like a refresher I wrote about it here.   

EAP Type Selection

First we see our Identity Request and Response Frames. Note there are two sets, relating to the dot1X 2001 and 2004 revisions. See https://en.wikipedia.org/wiki/IEEE_802.1X#Protocol_operation for more information. 
 

Depending on the client this does not have to contain identifiable data.

The next 3 frames show the radius server presenting the authentication method and client
Frame 10 is the most interesting of the bunch. We see the RADIUS server requesting the desired authentication method and providing the Challenge.

 Frame 11 has the client responding with its desired authentication type. 

Frame 12 is just a final acknowledgement from the Authentication Server

Setting up the Tunnel

Referring back to our diagram we are now going to setting up our outer tunnel for the inner method. There's a few interesting frames here that I will mention and expand on.

Frame 13 contains lots of good information about the client capabilities and used for troubleshooting connectivity problems, similar to an Association Request. Something else to note is this particular Intel AX201 NIC apparently is still using a deprecated field.


The two areas I would like focus on are the Cipher Suites and Signature Algorithms (Hashing)
Knowing the above we can quickly validate if a client is capable of connecting to various networks.

Frames 14-17 are transmitting the data we see reassembled in Frame 18. This is the (RADIUS) Server Hello and contains not only what the server supports or desires but also another critical piece of troubleshooting information (in my opinion); the EAP Certificate. This certificate is presented to the client so it can validate it against a Root CA in its certificate store to verify the RADIUS server.
Another fun fact about this is you can extract a certificate from a capture, download it as a .crt file and open it like any other! However you can still view the information like you would anything else in Wireshark as shown here.
Frames 19 and 20 finish the initial key exchange and make sure the Ciphers on either side are agreed upon.

Finally Frame 21 reports a successful Outer Tunnel creation.

Inner EAP Method

Unfortunately here's where things get obfuscated and we need to rely on the ladder.
The above is the series of exchanges for the inner EAP method. Looking through the frames the only thing to note is under the EAP header you will see whether the frame is a Request or Response. We have 8 frames that match the ladder above so we can assume what they may contain. All the other data is encrypted so nothing to explore there.
 

4 Way Handshake

At last we’re at the 4 way handshake, 34 frames and 318 milliseconds later. Mind you this was on an unloaded channel and writing this post made me think about a few things:
  • How much faster is EAP-TLS
  • How slow can things get on a congested network with high speed clients, low speed clients or heavy VoFi traffic
If you need a refresher on the handshake, see my post about this process.

QoS

It is worth mentioning all these frames were sent using QoS level 6 or 7 which is the highest available. This should ensure authentication messages are delivered in a timely manner, but that is not always the case.

Final Thoughts

And there we have it. A rundown of the exchanges needed to connect to a dot1X enabled network using PEAP-MSCHAPv2. Even though I troubleshoot this protocol often, it was still a bit of challenge putting this information into a post that covered the majority of the information without being too lengthy. I hope this helps others when it comes to troubleshooting or those curious about what is going on behind the scenes. With all that said, Ill leave you with a screenshot of the whole process.


 


  

Comments

Post a Comment

Leave a comment...

Popular posts from this blog

Capturing Roaming Events

Image
Finally! I scored a newer laptop to put Kali Linux on along with Windows to do some more wifi shenanigans. Before I was using a WLANPi on my desktop, which limited my mobility of course. Now I can follow devices and get closer to some of my other APs. Yes I know you can also use Pi as a remote capture device but that still didnt help with looking into roaming events. Now its been a few years since Ive used Kali and I was amazed at how polished its become. I think I used Backtrack about a decade ago to try and 'hack' my wifi with a WPA cracking tool. Needless to say that didnt launch my security career but it was quite interesting. There are plenty of tutorials on how to set you capture device in monitor mode so I wont go into that here. If you are curious here is the Airmon-ng website. Please note only certain chipsets are supported in Kali for this. Atheros cards seem to be the defacto standard for monitor mode support but I had a Comfast CF912 and TPLink Archer T9UH adapter ...
Read more

IoT and Smart Home Devices: Part 1

Image
  Source: https://www.sparkfun.com/products/17146                 This is going to be a multi part post going over a little IoT smart plug I picked up on clearance at Walmart. I'll make it clear I'm generally very skeptical about these types of devices so much that I don’t even want my roommates Alexa on the same network as mine. However with these things being so prolific it is best to understand them so we can better protect our networks. Ill start with a little background of the device, how I acquired it, and my research on the brand. I will then do my best to uncover any (hopefully) FCC filings and their documentation. From there we will explore a bit of the theory on how the majority of these cheaper devices connect to our networks. Lastly Ill do my best to capture packets during the join process but we will see how that goes with my limited setup.  I was looking to purchase a new Roku and since Walmart was the closest st...
Read more

Frame Exploration: Authentication Frames

Image
Authentication Frames in 802.11 are not about verifying the identity of clients or forming a secure connection. These frames are used to ensure each radio is actually a valid .11 device that can communicate on the network. It has been described similarly to plugging a network cable into the wall or switch.  Please note this is only valid for networks using WPA or WPA2. WPA3 introduces SAE (Simultaneous Authentication of Equals) and uses a 4 message exchange for authentication. We will be looking at Open System Authentication frames here.  In the above we have the two frame exchange between the client device and the AP. Each message is the essentially the same and contains a Sequence Number and Status Code to tell whether or not authentication was successful.  As with all other frames we can look at the FCF to verify what type of message it is too. And that's all there really is to it. If each radio can authenticate with one another they can proceed to the Association stag...
Read more