As discussed in an earlier blog WPA2 Enterprise allows a network to authenticate each user with unique credentials, rather than a blanket passphrase. This is done through an EAP exchange over the 802.1X framework. We’ve touched on this briefly in a post about RBAC, but I wanted to take some time to review two of the different flavors of EAP so you can make an informed decision about which one is best for your organization.
There are two predominant versions of EAP being installed today – PEAP and EAP-TLS.
Protected Extensible Authentication Protocol (PEAP)
PEAP technically has multiple versions, but they all use the same basic “protected” transfer structure. The issue with legacy EAP was that the supplicant’s credentials were transmitted in cleartext… which is less than secure, because it opened up the potential for someone to intercept a username. PEAP corrects this by using two EAP exchanges – outer authentication and inner authentication. The outer authentication is a “dummy” EAP exchange (often using a ridiculous username) that sends information in cleartext to construct a temporary TLS tunnel. Once that encryption cover is in place, the inner authentication takes place securely inside the tunnel, out of sight of roaming sniffers. Can you see why it’s called “Protected”?
The most common version of PEAP is EAP-PEAPv0 (EAP-MSCHAPv2). The protocol used for the inner authentication is EAP-MSCHAPv2, which utilizes a user name and password as the credential. When using PEAP you will need to provide a server side certificate and set up a repository of usernames and passwords for individual client authentications. When your users connect to the network they will validate the server via the installed certificate and (if the trust is there) provide their unique credentials.
This option is popular because PEAP is widely supported by client devices and it allows you to easily utilize an existing database, like Active Directory. Your end users are already used to logging in to the domain using their AD credentials, so asking them to use those same credentials to log on to the network isn’t a stretch.
Extensible Authentication Protocol Transport Layer Security (EAP-TLS)
EAP-TLS is one of the most secure authentication methods available today. Rather than using the standard username / password combination for authentication, EAP-TLS requires both a server side and client side certificate. This means that you can avoid some of the risks inherent to passwords, like a user entering their credentials to connect to the network with an unapproved device or sharing their credentials with another employee. In order to connect to a network secured with EAP-TLS the client must have been provisioned a unique certificate by the network’s public key infrastructure (PKI).
The advantage of this level of security is also its inherent disadvantage. It can be a chore to implement a PKI if you don’t already have one in place. Provisioning this certificate based trust relationship to the client can be a straightforward process with Active Directory’s Group Policy when using Windows hosts, but it can introduce complications with some brands of smart devices unless you have a provisioning mechanism in place… manually installing certificates onto smartphones can be above the skill level of some users and it will bog down your IT department significantly.
Finally, if you do choose to go with EAP-TLS as your EAP structure, be sure to put some heavy security around the server that is housing your PKI.
I don’t mean to scare you away from EAP-TLS, as it is the definitive secure authentication solution. You should just be aware that this security comes at an administrative cost. If you want to go with EAP-TLS I would recommend looking into onboarding software to help provision certificates to your endpoints, like Aruba’s ClearPass or Cisco ISE.
EAP Options to Avoid:
There are many many many other EAP flavors available, too many to effectively cover in a single blog post. PEAP and EAP-TLS are the ones that I see the most often in the enterprise, with the occasional EAP-TTLS popping up here and there. However, there are some legacy EAP options with noticeable security flaws that are worth covering here, less to help plan the future and more to help you avoid these legacy options!
EAP-MD5 – This was one of the first EAP options available. It has severak major weaknesses – first, it does not use tunneled authentication, meaning that the username is transmitted in cleartext. Second, it uses MD5 encryption, which is not a very strong encryption suite. Third, it does not validate the server, opening you up to MiTM attacks.
EAP-LEAP – The username is transmitted in cleartext, which opens you up to social engineering attacks. There are better options out there.