There are many options available when configuring wireless authentication. In this video, you’ll learn about EAP, EAP-FAST, PEAP, EAP-TLS, and more.
In a previous video, we talked about the need for authenticating to a wireless network. And of course, there are many different ways that you could authenticate to a network, and we’ve used many of these different authentication methods on our different networks through the years.
The most common type of authentication someone would use is their username and password. And it’s not unusual to add other types of authentication factors, along with the username and password.
Although we’ll sometimes use these authentication methods for wired networks, it’s very common to also see this on wireless networks. That’s mostly because wireless networks are sending and receiving into the air, and anyone who happens to be nearby with a wireless device could attempt to connect to that wireless network.
Many of the types of authentication we’ll use for wireless networks are built on a standard framework called the Extensible Authentication Protocol, or EAP. There are many, many different types of authentication methods using EAP, and different manufacturers will use EAP in different ways.
In the enterprise, we commonly see EAP authentication used in conjunction with 802.1X. So when you initially connect to the wireless network, you’ll be prompted for these authentication details, and the EAP framework will be used to provide that authentication confirmation behind the scenes.
802.1X is also referred to as port-based Network Access Control, or NAC. This means that if you’re trying to connect to the network, you don’t gain any access to this wired or wireless network, unless you’re providing the proper credentials using 802.1X
This almost always is using some type of centralized authentication database on the back end. When you first connect to the wireless network, you’ll be prompted with the username and password, and 802.1X will check that username and password by communicating on the back end to one of these databases.
Very commonly, we would use RADIUS, or TACACS, or LDAP to be able to have this centralized database of usernames and passwords.
There are usually three different parts to this to 802.1X authentication. There is the supplicant, this is commonly the client that is connecting to the network. There’s the authenticator, this is the device that provides the access you need to the network. And then there is this centralized authentication server that is doing the validation of the username and password.
If you try to connect to this network for the first time from the supplicant, the authenticator will not provide you with any access, because you’ve not authenticated yet. The authenticator will recognize that you’re trying to get access, and it will send an EAP request to the supplicant, asking if you’d like to provide some type of authentication. The supplicant sends a response to the authenticator, saying yes, I’m trying to gain access to the network. The authenticator then informs the authentication server that there’s a new person on the network who would like to authenticate.
The authentication server then asks if the supplicant is going to provide any login credentials. The authenticator passes through that request to the supplicant, saying, let’s provide some credentials. And then the supplicant provides username, password, and other types of authentication details.
The authenticator sends that information to the authentication server that’s in the back end. Those credentials are checked, and if everything matches, a message is sent back to the authenticator that the process was successful, and that user can gain access to the network.
One way of securely providing this authentication process is through a method of EAP called EAP-FAST. FAST stands for Flexible Authentication via Secure Tunneling. This is a way to make sure that the authentication server and the supplicant, are able to transfer information between each other over a secure tunnel.
This is accomplished with a shared secret referred to as a Protected Access Credential, or a PAC. The supplicant receives the PAC and then sets up a Transport Layer Security Tunnel.
This TLS tunnel is very similar to the TLS mechanism that’s used to encrypt information within a browser. Once this TLS tunnel is in place, everything sent across is encrypted, and then authentication details are sent over that TLS tunnel.
It’s common to see EAP-FAST used with a centralized authentication server, such as RADIUS, where you can have both the authentication database and EAP-FAST services running on that RADIUS server.
Another form of an encrypted tunnel being used with EAP is called PEAP. That stands for a Protected Extensible Authentication Protocol, and it was created by Cisco, Microsoft, and RSA Security.
This is also using TLS to be able to send this information, but instead of it being based on a shared secret with the PAC, we’re using the same method as a traditional web server by using a digital certificate. This digital certificate is only needed on the server. Your clients do not need separate digital certificates to be able to use PEAP.
If you’re authenticating to a Microsoft network, then you’re probably combining PEAP with MS-CHAPv2. This is Microsoft’s Challenge Handshake Authentication protocol, and it commonly integrates with some of the Microsoft CHAP version 2 databases.
PEAP could also be used with a more generic authentication type using a Generic Token Card, or GTC. And this can be used also with a hardware token generator to provide additional authentication.
A more secure form of EAP can be found with EAP-TLS. The TLS is Transport Layer Security, so we’re already performing a very strong encryption of data between our clients and our servers.
Unlike the previously described EAP implementations that did not need a digital certificate, or only needed a single digital certificate, EAP-TLS requires digital certificates on all devices. This is because we perform a mutual authentication when connecting to the network. Once the mutual authentication is complete, a TLS tunnel is then built to send the user authentication details.
If you’ve ever managed a network where every device had its own digital certificate, you know this is not a trivial task. You need a Public Key Infrastructure, or a formal PKI, so that you can properly, manage, deploy, and revoke any of these certificates that may be in use in your environment.
We also have to consider that some older devices may not allow for the use of digital certificates, and therefore, they would not be able to connect to the network and authenticate using EAP-TLS.
Your environment may have an authentication protocol that’s not already supported by one of these other EAP types. In that case, you may want to run EAP-TTLS. This is a Tunneled Transport Layer Security, where you can tunnel other authentication protocols within the existing TLS tunnel.
Unlike EAP-TLS, EAP-TTLS only needs a single digital certificate on the authentication server. We don’t have to deploy separate digital certificates to all of these other devices on our network. We would use the digital certificate on the authentication server to be able to create and send information over this TLS tunnel.
Once this TLS tunnel is in place, we can then send other authentication protocols across that tunnel. This might be other types of EAP, it could be Microsoft’s CHAP version 2, or any other type Authentication Protocol that we’d like to use.
You might also use EAP in conjunction with Federation. Federation is when you can link a user’s identity across multiple authentication systems. This is commonly used if you’re at a third-party location, and you would like to authenticate using credentials that were created for a different location.
RADIUS Federation commonly uses 802.1X as the authentication method. So you’re using EAP to authenticate, and you’re very commonly authenticating to a RADIUS server on the back end.
A common implementation of RADIUS Federation can be found with eduroam. This was built so that educators who were visiting a different campus could use their original username and password to be able to authenticate, regardless of what campus they may travel to.