EAP-PEAP Handshake

Summary

Excerpt From Wi-fi-vulnerabilities part 2 Webinar
CTO Dr. Brett Walkenhorst Explains EAP-PEAP Handshake.
Protected Extensible Authentication Protocol, or EAP-PEAP, is a set of more than forty authentication techniques. In order to create a secure tunnel where other EAP protocol actions take place, PEAP acts as the outer layer. To securely exchange credentials, the procedure involves server-client exchanges, TLS tunnel setup, identity exchange, and challenge-response phases. Secure communication is made possible by the generation of session keys from a symmetric key created during the TLS tunnel construction, following successful authentication. In business network contexts, this technique guarantees safe encryption and authentication.

Video Transcript

So the most common of those forty plus methods is called EAP PEEP. And that's a bit of a mouthful, but PEEP is protected EAP. That serves as an outer layer. Like I talked about, there's often this inner and outer kind of layer that gets set up to authenticate.

So PEEP is the process by which we establish a secure tunnel within which everything else in the EAP protocol can flow. So it's very similar to what you saw before. I've dropped some of the grayed out stuff at the top just in the interest of of space. And I'm drawing straight lines across even though I'm obscuring away the fact that the access point is still the middleman.

So the access point is still passing traffic, but I'm just abstracting that away for the sake of of space and simplicity. So in this case, once the server gets the identity of the client that's supplicating for connection to the network, the server is gonna send a start a message to start the peep process as well as a certificate that the client can then use to establish jointly with the server a TLS tunnel.

So they're gonna negotiate a symmetric key, establish TLS, and then inside of that tunnel, everything else is gonna play out. Everything that we talked about before, except that in this case, there's an additional exchange of identity to allow for the possibility that a client doesn't want to share its true identity in the first stage before encryption has been put in place.

So there's the second stage of identity exchange, and now we're back to that challenge response phase, which can include credentials, I think, for ePEAP and by default, it's not. But you've got this challenge response. If everything goes well, you've got success. At that point, the encryption has done its job.

Credentials have been exchanged in a secure way. We tear down the TLS tunnel. The server tells the access point that we're good to go. The client is authentic. And now the access point is free to negotiate the four way handshake once again. This time, not with a share key as in the personal, with enterprise.

It's simply to establish session keys because authentication has already occurred. Now in this case, the four way handshake is going to create session keys from a key that was established when the TLS tunnel was established. So instead of some pairwise master key being generated from some shared secret or from a password, it's generated from the symmetric key that is established in the Diffie Hellman exchange after the server sends its certificate to the client.

So that becomes the PMK that then generates the PTK, which is the session key in the four way handshake.