PEAP vs EAP-TLS

That’s the million-dollar question whenever an organization begins an ISE project. Which is better? Which is easier to implement? Which is more secure? What’s the difference? This article will answer all of these questions, discuss when you would choose one over the other, and really do a deep dive into how each protocol works.


Extensible Authentication Protocol (EAP)

Before we get rolling, let’s take a quick look at what EAP is. EAP is the framework used for sending authentication material to an authenticator. To be clear, it is a framework and does not provide an actual authentication. It is essentially a generic standard which other vendors use to design their EAP Methods. For example, PEAP uses the EAP standard and was designed by Microsoft, Cisco, and RSA.


Protected Extensible Authentication Protocol (PEAP)

PEAP, like all other EAP methods determines how authentication materials are protected. I’m purposely using the word “Materials” as there is nothing saying the authentication mechanism has to be a username/password. For example, it could be a certificate. In other words, the word “credentials” would be more intuitive, but not exactly accurate.


We have three components to think about:

  1. Supplicant: This is a fancy way of saying “client” or “endpoint” or typically “workstation”. A supplicant is a client-side application.

  2. Authenticator: The Authenticator is the device that facilitates the authentication. E.g. A Switch or WLC is an Authenticator. The Authenticator accepts or rejects access based on what the Authentication Server has to say.

  3. Authentication Server: This is the server that actually verifies the authentication is valid. E.g. The ISE Server.

PEAP Step-by-Step

Step 1: The supplicant sends an EAPoL Start message. This basically says, “I want to authenticate”.

Step 2: The Authenticator replies with an Identity Request. This basically says “Fine, who are you?”.

Step 3: The supplicant sends their identity, which is typically a bogus username. The fake or bogus username is used to start the process and does not have anything to do with real credentials.

Step 4: The Authenticator takes the credentials and sends them to the Authentication Server as a “RADIUS Access Request”. The message basically says, “User BOGUS wants to authenticate”.

Step 5: The Authentication Server sends a PEAP Start message and its server certificate. The message basically says, “Let’s do this! Oh, and use this certificate to encrypt anything you send to me”.

Step 6: The client validates the certificate it received. This is configurable, but one way or another the client has to trust the certificate presented by the Authentication Server. Once done, the “outer” tunnel is established. The outer tunnel is the encrypted outer shell that keeps all communications secure.

Step 7: The Authentication Server does an EAP Request Identity, which basically says, “Who are you?”.

Step 8: The supplicant sends an EAP Response, which basically says, “I am Bob”.

Step 9: The Authentication Server does an EAP Request Challenge, or in other words says, “Hi Bob, what’s your password?”.

Step 10: The supplicant sends Bob’s password which is encrypted with the outer-tunnel, and in most instances, is also encrypted a second time in the inner-tunnel (MSchapv2).

Step 11: The Authentication Server sends an EAP Request Success.

Step 12: The Supplicant sends an EAP Response ACK (Acknowledgement).

Step 13: The tunnel between the Supplicant and the Authentication Server is torn down.

Step 14: The Authentication Server sends a RADIUS Access-Accept (or reject) to the Authenticator.

Step 15: The Authenticator sends an EAP Success (or failure) to the Supplicant.

Step 16: The Supplicant and Authenticator complete a handshake.

Step 17: The channel is open.


PEAP Summary

For the purposes of this article, we are concerned with two things:


How does the Supplicant know the ISE Server is legitimate?

The Supplicant knows the ISE Server is legit as it must trust the certificate being presented by ISE. The ISE certificate could be signed by an internal PKI (typically Microsoft) that the Supplicant trusts or it could also be a publicly signed certificate that the Supplicants trust by default. This is a pretty key concept and one that is frequently overlooked.


Here is a Supplicant configured for PEAP:

Notice how the “Verify the server’s identity by validating the certificate” is unchecked. This is a major security issue as the Supplicant will now automatically trust any certificate presented.


Here is a much more secure option:

We are saying you must validate the certificate. Plus, we are going a step further to say “The certificate not only has to be valid, it also must be signed by this specific CA”.


How are the authentication materials protected?

The trusted sever certificate works nearly identical to a typical HTTPS connection on a website. The supplicant encrypts with the server’s public key and the server decrypts with the private key. From there, a new key is negotiated to encrypt all transmissions in either direction.


Extensible Authentication Protocol - Transport Layer Security (EAP-TLS)

Now that we have PEAP figured out, we can take a look at EAP-TLS. We are going to dive right into the step-by-step process.


Step 1: The supplicant sends an EAPoL Start message. This basically says, “I want to authenticate”.

Step 2: The Authenticator replies with an Identity Request. This basically says “Fine, who are you?”.

Step 3: The supplicant sends their identity, which is typically a bogus username. The fake or bogus username is used to start the process and does not have anything to do with real credentials.

Step 4: The Authenticator takes the credentials and sends them to the Authentication Server as a “RADIUS Access Request”. The message basically says, “User BOGUS wants to authenticate”.


So far, this is identical to PEAP.