01-04-2025 04:58 PM
EAP-TLS and peap protocol establish secure tunnel b/w client & server
I.e., client is supplicant and server is radius server which is Cisco ise in my case.
Correct me if I am wrong
Solved! Go to Solution.
01-04-2025 06:23 PM
You are correct.. but i would add a few things to clarify.
The point of the tunnel / secure channel is to authenticate the endpoint for the most part.
with EAP-TLS both sides have certs and can be authenticate each other.
With PEAP the server will be authenticated by the client using the server cert, whereas the client will use username/password to do that.
there are many articles, one of them is below and you can also find youtube videos :
https://www.securew2.com/blog/everything-you-need-to-know-about-peap-security
**Please rate as helpful if this was useful**
https://www.securew2.com/blog/everything-you-need-to-know-about-peap-security
01-04-2025 06:23 PM
You are correct.. but i would add a few things to clarify.
The point of the tunnel / secure channel is to authenticate the endpoint for the most part.
with EAP-TLS both sides have certs and can be authenticate each other.
With PEAP the server will be authenticated by the client using the server cert, whereas the client will use username/password to do that.
there are many articles, one of them is below and you can also find youtube videos :
https://www.securew2.com/blog/everything-you-need-to-know-about-peap-security
**Please rate as helpful if this was useful**
https://www.securew2.com/blog/everything-you-need-to-know-about-peap-security
01-04-2025 06:54 PM
Thanks. We don't need username and password for eap-tls ?
01-05-2025 03:38 AM
It is not as easy as it seems; the general answer is no. Not both establish a secure tunnel, but this needs some clarification:
For PEAP (same for EAP-TTLS, EAP-FAST, or TEAP), we have a potentially sensitive payload to protect, a password-based client authentication. A secure tunnel is built (typically with TLS), and the client authentication is done through the tunnel.
For EAP-TLS, this tunnel is typically not built. We usually have a TLS exchange where the server and client prove their identity with certificates and public key cryptography. Generally, there is no tunnel involved. But here comes the "it depends":
EAP-TLS (RFC 5216) has an optional privacy feature where a kind of tunnel would be established, and the client exchange could be done through this tunnel. But I am not aware of any system doing this. This changed with EAP-TLS for TLS 1.3 (RFC 9190). Here, the privacy exchange is mandatory, and we always do the whole EAP exchange through a TLS-protected tunnel.
If you run a newer version of ISE and your client supports it (like newer Apple devices), you could see the systems do this exchange with EAP-TLS 1.3.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide