Extensible Authentication Protocol – Transport Layer Security (EAP-TLS) is an IETF open standard that’s defined in RFC 5216. More colloquially, EAP-TLS is the authentication protocol most commonly deployed on WPA2-Enterprise networks to enable the use of X.509 digital certificates for authentication.
EAP-TLS is considered the gold standard for network authentication security, but despite being universally recognized as ultra-secure, it’s still not widely implemented. That’s largely because EAP-TLS was developed before the industry had the mature device onboarding solutions necessary for smooth device configuration at an enterprise-scale.
Fortunately, EAP-TLS is much more viable with automated device onboarding solutions for BYOD and MDM like SecureW2’s JoinNow MultiConnector. Streamlined onboarding makes configuration a simple task, making premium Wi-Fi security viable for a larger proportion of organizations.
How does EAP-TLS work?
Despite being the pinnacle of authentication security, EAP-TLS remains a relatively simple framework for authentication. It doesn’t rely on overly complicated encryption schemes or anything like that – it’s predicated on the strength of public key cryptography.
Public key cryptography is a type of asymmetric cryptography that uses public-private key pairs to establish symmetric cryptography over an unsecured channel, removing the need to securely communicate a pre-shared key beforehand.
Practically speaking, TLS architecture is similar to most other EAP-types except that it requires mutual authentication via client-side certificates. X.509 digital certificates are incredibly versatile – they dramatically enhance user experience and security and can be configured to facilitate SSO for many services.
Is EAP-TLS secure?
EAP-TLS is widely regarded as the most secure authentication protocol for 802.1X networks. The requirement for mutual certificate authentication has kept the protocol not just relevant, but dominant, for over 15 years.
One of the primary security benefits of EAP-TLS networks is the ability to perform server certificate validation. This technique renders your users all but invulnerable to common over-the-air attacks like the notorious man-in-the-middle attack.
Those hacks usually rely on spoofed access points (AP) to fool users’ devices into automatically attempting to authenticate to the fake AP. The device will automatically submit real credentials without the user’s knowledge, allowing the hacker to farm credentials with little effort.
Server certificate validation requires both the client and the server to validate their identity, so a device configured for EAP-TLS authentication (and thus server certificate validation) won’t ever mistake a spoofed AP for the real one.
That mutual authentication requirement is fundamental to all certificate-based authentication; the true source of EAP-TLS’s strength. Certificates perform similar roles in other secure applications like S/MIME and digital signature signing.
Benefits of EAP-TLS
There are two primary advantages of EAP-TLS:
- EAP-TLS is the strongest authentication security. The use of X.509 digital certificates makes the protocol the undisputed champion, especially when those certificates are encrypted using modern techniques like elliptical curve cryptography (ECC).
- The end user experience in an EAP-TLS network is almost universally better than in credential-based networks. Certificates can’t be shared or removed from a device, so there’s no need for constant password-reset policies to maintain secure credentials. A certificate validity period is usually years-long instead of a password’s typical 90-day life.
Furthermore, users don’t need to remember passwords at all – certificates authenticate automatically. They can also be provisioned (or revoked) automatically and are easy to manage with a CMS like the one included in the SecureW2 Managed PKI.
Does EAP-TLS require certificates?
Technically, the standard does not mandate the use of X.509 digital certificates. In reality, however, omitting certificates would negate the security benefits of the protocol and render much of the infrastructure pointless.
Since EAP-TLS requires mutual authentication, you’re unlikely to ever find an implementation that does not require client-side certificates.
Alternate EAP Methods:
Extensible Authentication Protocol is not itself a wire protocol – it only defines a message format. The simple, utilitarian foundation has paved the way for a number of different strategies to encapsulate and protect EAP messages.
Many different EAP methods have been defined, though only a few of them see widespread use. Here’s a list of methods you might encounter:
- EAP Tunneled Transport Layer Security (EAP-TTLS)
- EAP Pre-Shared Key (EAP-PSK)
- EAP Password (EAP-PWD)
- Lightweight Extensible Authentication Protocol (LEAP)
- EAP Encrypted Key Exchange (EAP-EKE)
- EAP Transport Layer Security (EAP-TLS)
- EAP Protected One-Time Password (EAP-POTP)
- EAP Internet Key Exchange v. 2 (EAP-IKEv2)
- EAP Authentication and Key Agreement (EAP-AKA)
- EAP Authentication and Key Agreement prime (EAP-AKA’)
- EAP Flexible Authentication via Secure Tunneling (EAP-FAST)
- Tunnel Extensible Authentication Protocol (TEAP)
- EAP Subscriber Identity Module (EAP-SIM)
- EAP Generic Token Card (EAP-GTC)
- Nimble out-of-band authentication for EAP (EAP-NOOB)
Not all EAP methods are created equal. It could be a critical mistake to assume that an authentication protocol is secure just because it is ubiquitous.
A huge number of legacy systems still use outdated wireless security paradigms, including authentication protocols with known vulnerabilities. Unfortunately, networking with some of these systems (particularly on-premise networks) can require you to use special infrastructure to bridge the gap, or to sacrifice the security and convenience of contemporary authentication solutions.
Here we will compare EAP-TLS to the other two most commonly used authentication protocols for 802.1X networks.
What’s the difference between PEAP and EAP-TLS?
PEAP is an EAP protocol, despite the fact that it breaks the naming convention a little bit. The ‘P’ in ‘PEAP’ stands for “Protected” (Extensible Authentication Protocol). PEAP was the product of a collaborative effort between Cisco, Microsoft, and RSA, meant to add intrinsic protection to EAP, which relies on protected communications by default.
PEAP itself technically does not define a particular method; rather, it contains instructions for chaining together EAP protocols for additional security. In practice, almost every PEAP implementation is PEAP-MSCHAPv2 due to its inclusion in ubiquitous Microsoft environments.
Unfortunately, PEAP is highly susceptible to man-in-the-middle attacks and has been for more than a decade now. This is particularly crippling in an era where hackers are taking the time to be more hands-on. It’s not difficult to imagine a dedicated hacker spoofing your office access point from a van parked outside your house, a scenario made all the more likely as C-suite level executives are certainly working from home during the pandemic.
EAP-TLS entirely circumvents this issue by using server certificate validation. Even in the scenario described above, it’s relatively simple to use a VPN to secure a connection to your office RADIUS server for remote authentication.
Want to learn more about using a VPN for remote authentication? Check out the SecureW2 remote authentication solution for VPN.
What’s the difference between EAP-TTLS and EAP-TLS?
The primary difference between EAP-TTLS and EAP-TLS is that the former only requires server-side certificates rather than the mutual certificate authentication that characterizes EAP-TLS.
In order to compensate, TTLS uses a tunnel (hence “Tunneled” Transport Layer Security). It’s essentially an SSL wrapper encapsulating the standard EAP message. It does not encrypt the message, however.
Unfortunately, this means that EAP-TTLS communicates everything (including credentials) in clear text. And, since TTLS does not use server certificate validation, it’s particularly susceptible to being intercepted in over-the-air attacks… which completely bypass the tunnel and deliver credentials in clear text directly into the waiting hands of a hacker.
What is Required for EAP-TLS Authentication?
The minimum required infrastructure for EAP-TLS authentication is:
- User Directory
- 1x Capable Access Point and Controller
- Public Key Infrastructure (PKI)
Of course, that short list makes it look much simpler than it is. Just the PKI alone is composed of more than a dozen different components, each totally vital to the process of configuring, provisioning, revoking, and otherwise managing digital certificates.
There are ample open-source or otherwise free resources to cobble together a functional 802.1X network with EAP-TLS, such as FreeRADIUS and the Active Directory extensions NPS and AD CS.
Any self-made solution will still require significant effort to onboard devices, enough that it might dissuade an otherwise cautious admin from utilizing the best in authentication security. For most organizations, a managed cloud PKI service like SecureW2’s is the perfect balance of affordability and control without compromising any security.
Our turnkey PKI is totally vendor-neutral, it can be integrated into your existing network infrastructure to save time and money. Alternatively, it can be deployed as an out-of-the-box, plug-and-play network security solution. Our onboarding app is #1 rated in every marketplace and IT teams love the intuitive single-pane management system.
We have affordable options for organizations of every size. Click here to see our pricing.