Ever since I started diving into ISE and 802.1X I always had a hard time telling PEAP-EAP-TLS and EAP-TLS apart, mainly because wherever I tried to read up on the subject there was never any clarification regarding the difference between these two and a lot of people seem to be using these terms interchangeably… which they are not.
Let's go through these methods to sort out their differences.
PEAP-EAP-TLS
PEAP stands for Protected Extensible Authentication Protocol. The keyword here is protected. When PEAP is used for authentication, the process will consist of two phases. The first phase will deal with Outer Authentication (PEAP) and the second phase will deal with Inner Authentication (EAP-TLS). The idea of PEAP-EAP-TLS is that both sides will authenticate each other’s identity using certificates, within an encrypted PEAP tunnel.
The Outer Authentication means that before the user/machine will be authenticated (the inner authentication) we will build a secure environment for the actual authentication to take place. To do this, we will establish an encrypted tunnel between the client and ISE by using the server-side certificate residing on the ISE server.
Assuming the client trying to authenticate itself or its user trusts the certificate on ISE (while this validation can be turned off, you really shouldn't), the validation of this certificate will be used to create the encrypted tunnel between the two. The client will identify itself with a bogus username at first, like the MAC address, the name "anonymous" or simply no username at all while the server (ISE) will identify itself using its certificate. The bogus username only exists to get the process started, ISE will not be using this username to do any actual authentication. The client will send an "OK!" to ISE, indicating that its certificate was accepted. The client and ISE will now set up a TLS-tunnel between them.
When the TLS-tunnel is created we are ready to move on to the actual user/machine authentication. Inside this encrypted tunnel, the client will now send over its actual user or machine certificate to the server. Mutual authentication will take place within the tunnel, the client will once again have to validate the server’s certificate as part of the EAP-TLS flow, followed by the client sending over its own certificate to the server, for validation.
ISE will use the various values in this client certificate to determine the user's identity and then based on the policies configured take action to grant a suitable authorization result like PermitAccess, VLAN-assignment, ACL, SGT-tag, etc.
This is what the configuration for PEAP-EAP-TLS would look like on a network profile in Windows 7.
EAP-TLS
EAP-TLS simply skips the first phase and goes straight to the actual authentication between the client and the server. The client will still validate the certificate ISE is presenting to it (if configured to do so), but it won't be used to set up a tunnel for encryption. When the client receives the ISE certificate and sees that it is a trusted certificate, it will proceed with sending its own certificate over in an attempt to authenticate itself. ISE will then proceed to decide on how to treat the authenticated client.
This is what the configuration for EAP-TLS would look like on a network profile in Windows 7.
Final Notes
So, what's the big deal? Sending your certificate (which has the public key included) is not considered insecure or dangerous, since a hacker can't do too much with the public key.
They (the potential hacker) will however know that you are using certificates at all to authenticate users and/or machines to grant network access if they are listening in your attempts to authenticate, be it on a wired or wireless medium. Maybe they could use this information to dig deeper into your network. For all we know, maybe they've already obtained one of your client's certificates and the private key that belongs to it. Knowing that certificates are used to grant network access, maybe they will give it a go and see what happens!
In terms of security, I have yet to find a reason NOT to use PEAP-EAP-TLS instead of “pure” EAP-TLS, but from my experience most of the networks I have run into uses pure EAP-TLS, because the process is a little bit more straightforward.
Pure EAP-TLS requires fewer packets during the authentication phase compared to PEAP-EAP-TLS, so I guess it has that going on for it, as well.