Your NAC Shouldn’t Make a PEAP: EAP-TLS Is the Better Authentication Solution

Two rows of blue and purple marshmallow Peeps with tape covering their beaks. This indicates that NAC Authentication method shouldn't be PEAP, but rather the more secure EAP-TLS.

If you use Identity Services Engine (ISE), ClearPass, Network Policy Server (NPS), or any other Network Access Control (NAC), this article is for you.

With the introduction of technologies like Microsoft's NPS in 2008, Cisco's ISE in 2011, and Aruba's ClearPass in 2012, the quest for robust security measures to protect network resources has led to the adoption of various authentication methods.

These methods all seek to regulate network access through user-defined policies, ensuring only authorized personnel and devices gain network entry.

Unfortunately, not all NAC authentication solutions are created equal, and for the purposes of this article, we’re going to focus on the two most popular: ISE and ClearPass.

AI generated graphic of the migration path from PEAP to EAP-TLS authentication. Image generated by Adobe Firefly AI.

PEAP vs EAP-TLS

Both ISE and ClearPass are built around RADIUS (Remote Authentication Dial-In User Service) to handle AAA for both users and devices. As with any authentication, there needs to be assurance that the conversation is secure—not only do we need to authenticate, but we also need to know the authenticating device itself can be trusted.

There are several different protocols that can be used for authentication, let’s discuss two of the more popular options and explain why you should never use one of them.

PEAP

Protected Extensible Authentication Protocol (PEAP) provides a method for securely transmitting authentication over an encrypted Transport Layer Security (TLS) tunnel.

PEAP comes with a major caveat: it only uses server-side certificates. Devices simply trust the server’s certificate, often established through Group Policy (which can easily be disabled).

The server trusts the endpoint based on the Microsoft username and password (MSCHAPV2), and in so doing, presents a major issue:

Untrusted Endpoints

Any device with valid login credentials can authenticate via PEAP. The trust for the endpoint is typically based on another attribute (DHCP, MAC OUI, SNMP, etc.).

EAP-TLS

There’s a better way, and its name is Extensible Authentication Protocol–Transport Layer Security (EAP-TLS). EAP-TLS is a version of PEAP that fixes the shortcomings of the latter by enabling mutual authentication using certificates.

The PEAP vs EAP-TLS question is really a no-brainer. With EAP-TLS you have:

  • Enhanced Security: Dual authentication significantly reduces spoofing as both user and the endpoint are required to present a trusted certificate.
  • Clearness in Authentication: By using dual certificates, EAP-TLS provides a clearer and more straightforward authentication process, eliminating the ambiguity and potential vulnerabilities associated with password-based methods.
  • Future-Proofing: PEAP is incompatible with many emerging security technologies like Microsoft’s Credential Guard in Windows 10 and 11. EAP-TLS, on the other hand, is fully compatible and is ready for future security enhancements.

One final question about PEAP you may be asking: What about devices I don’t manage and can’t put a certificate on?

Our answer: Do you really want those devices on your corporate network? You probably don’t, and even if they are allowed, they should be quarantined with zero access to internal resources.

AI generated image of PEAP vs EAP-TLS authentication protocols facing off against one another. Image generated by Adobe Firefly AI.

Migrating from PEAP to EAP-TLS

If you are still running PEAP, it’s time to transition to the more secure EAP-TLS. Here are the steps for a successful migration:

  1. Evaluate your Public Key Infrastructure (PKI): This evaluation should include your Certificate Authority (CA) servers and sub CAs. You want to ensure that the environment is set up for best practices and is using the correct hierarchy.
  2. Make Sure Your Root CA is NOT Joined to the Domain: Sub CAs are used for enrollment and they are AD-joined.
  3. Use Group Policy for All AD-Joined Devices to Trust the Server Certificate: Create and deploy a certificate template for NAC 802.1x authentication for auto-enrollment for users and computers. If they are NOT AD-joined devices, use InTune (or a similar solution) to push certificates to these devices—if they are completely unmanaged, then keep them off your network!
  4. Ensure your trust is set up with your PKI.
  5. Create your certificate authentication profile. This allows ISE to gather the identity within the client-side certificate and pull the identity for a specific certificate attribute (typically Subject Name).
  6. Add the profile to your Identify Source Sequence.
  7. Make sure EAP-TLS is part of your allowed protocols within your authentication.

HBS: Your Trusted NAC Authentication Partner

Our team at HBS boasts extensive expertise in configuring EAP-TLS for your NAC solution, and we offer comprehensive auditing and remediation of PKI.

If you are currently running PEAP MSCHAPv2 in your environment, or are uncertain about which method you are deploying, please contact HBS.

We are committed to ensuring your NAC solution is not only optimized for the present but also strategically positioned for the future.

author avatar
Carly Westpfahl