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:
Supplicant: This is a fancy way of saying “client” or “endpoint” or typically “workstation”. A supplicant is a client-side application.
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.
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.
Step 5: The Authentication Server sends its Server Certificate to the Supplicant.
Step 6: The Supplicant sends its Client Certificate to the Authentication Server.
Well, that’s different. With EAP-TLS, there is true mutual authentication and client-side certificates are required. This is a deal-breaker for a lot of organizations that do not have a working PKI or the required expertise. The process to distribute certificates from Active Directory is simple, but many find it a bit scary for whatever reason.
Step 7: Both the server and the client validate the other’s certificate. This is the actual authentication and the largest advantage to using EAP-TLS over PEAP. The remaining steps are identical with PEAP.
Step 8: The Authentication Server sends a RADIUS Access-Accept (or reject) to the Authenticator.
Step 9: The Authenticator sends an EAP Success (or failure) to the Supplicant.
Step 10: The Supplicant and Authenticator complete a handshake.
Step 11: The channel is open.
PEAP vs EAP-TLS Summary
Here is a breakdown of the advantages and disadvantages of both protocols. It typically comes down to whether or not you have a functioning PKI or are willing to build one. Once again, this is not a huge undertaking and should strongly be considered for any ISE deployment.
Ease of Use: For the end-user, it doesn’t make a difference as in both cases, the process is 100% transparent. In terms of deployment, PEAP is a bit easier as you do not have to think about an internal PKI.
Security: EAP-TLS is the more secure of the two as it does not rely on passwords. It’s kind of human nature, especially in the security arena, to overemphasize the thing that is better than the other thing. Think of it like this… Should I vacation in Tahiti or Bora Bora? This is where the human nature bit sneaks in, and they respond with “Fiji” or “One or the other is the worst place on earth”. The point is, I’m sure one is better than the other, but who cares if you get to go to either. Too often, perfect is the enemy of excellent.
Of course, I don’t know what your application is, and you may be protecting the nuclear launch codes. If that’s the case, well, go with the most secure option you can get your hands on.
Performance: No perceivable difference. EAP-TLS may be a nanosecond faster, but who cares?
ISE Configuration Ease: Makes virtually no difference.
I always suggest EAP-TLS until there is a compelling reason (usually the word no), to go with PEAP. The bottom line is in fact, EAP-TLS is the better choice, but I won’t lose any sleep if I have to go with PEAP in all but the most secure environments.
If you have any questions regarding this article, contact us today!