“The more convenient it is to connect to a network, the less secure it is.”

In this post I will talk about wireless security why you would use dot1x in a corporate environment. I will also use Cisco ISE as part of the various solutions as the use case, but in reality I could have also used Aruba ClearPass as the central authentication solution. I will start off by summarizing all the authentication option in a nutshell before I dive deeper into the intricacies of dot1x.

There are many ways in which you can implement wireless security. Typically there is a correlation between the level of security and the convenience in the way you connect. So the trade off here is that the easier it is to connect, the less secure it will be. I have added the picture below to present the various methods of connecting against convenience v. security.

So where does this leave us with what authetication option to use for what device? Authentication is important to understand because it basically allows for network administrators to dictate who can connect to your network. Of course based on the trust level of the endpoint we also need to be able to have some infuence on what the endpoint can connect to. For this post I do not want to go too much into the authorization part of Dot1X.

Summary of authentication types

Let us first jump into what authentication types are available and what type has the most common use case. Fter that I will expand a bit more on each of these types. The picture below shows the mostly used authentication options for each device or endpoint:

Each of these authentication types have have place and utility. And the picture above shows the most common authentication deployment types. The picture below shows as similar break down based on endpoint type and for what SSID you would typically use each method.

What you can see in this picture is that people would mainly use Dot1X as the authentication type to connect to a corporate network. Simply because it provides many option and because it offers the securest authentication and encryption of data.

Open Networks

The most common use case for an open wireless network, is guest access, Guest access can come in the shapes of hotspot, self registered or sponsored guest access.

Pre shared keys (PSK)

Using PSK as the authentication method for wireless security is mainly for home users. It can be as simple as putting it on a fridge magnet so your friends can get onto your network. I know i am oversimplifying it slightly, but it is generally not used in corporate environment and should not be for good reasons. Not in the last reason for its lack of scalability.

MAC Authentication Bypass (MAB)

You would use MAB primarily for devices that do not do Dot1x. Either these devices are incapable or we just do not bother to configure the dot1x supplicant on them. So the simplest way to identify those devices is to use their MAC address. Because MAC addresses are per definition unique, however a man in the middle can spoof this.

A lot of time you see administrators use MAB for cameras, phones (although you could use certificate based authentication), printers etc. You can use MAB for both wired and wireless authentication. Obviously when a none dot1x device connects to your dotx secured network, EAP (which is part of the dot1x framework) will time out. By this time the MAC address of the endpoint is already known, because of the endpoints DHCP requests for instance.

The wireless LAN controller can then present the MAC address of the endpoint onto ISE to make an evaluation based in its Policy sets. As a consequence ISE can then allow the endpoint to connect by sending a RADIUS ACCEPT back to the AP.

Wireless Security dot1x options

So this is where things get interesting and more complicated. IEEE 802.1X (dot1X), is a standard that describes the encapsulation of Extensible Authentication Protocol (EAP). This protocol runs both on wireless and wired networks. Dot1X authentication involves three parties: a supplicant, an authenticator, and an authentication server. The picture below show the mechanism behind dot1X.

The authenticator in the picture can be an AP in wireless deployment and the authentication server can be something like Cisco ISE. As you can see EAP is at the heart of all this. There are literally dozens of EAP methods available and most APs and Authentication servers support a majority of those. The table below shows a summary of the most popular ones, with their pros and cons.

If you use Cisco ISE you can set up your policy sets in such a way that you allow only certain EAP methods. ISE will actually let you turn off certain methods if you want, perhaps because they are not considered being secure enough. Either way, choosing a method depends on a large number of parameters.

A review of the above table usually provides the following conclusions:

• MD5 isn’t typically used as it only does a one-way authentication, and perhaps even more importantly doesn’t support automatic distribution and rotation of WEP keys so does nothing to relieve the administrative burden of manual WEP key maintenance.
• TLS, while very secure, requires client certificates to be installed on each Wi-Fi workstation. Maintenance of a PKI infrastructure requires additional administrative expertise and time in addition to that of maintaining the WLAN itself.
• TTLS addresses the certificate issue by tunneling TLS, and thus eliminating the need for a certificate on the client side. Making this an often preferred option. Funk Software* is the primary promoter of TTLS, and there’s a charge for supplicant and authentication server software.
• LEAP has the longest history, and while previously Cisco proprietary (works with Cisco Wi-Fi adapters only), Cisco has licensed LEAP to a variety of other manufacturers through their Cisco Compatible Extensions program. A strong password policy should be enforced when LEAP is used for authentication.
• EAP-FAST is now available for enterprises that can’t enforce a strong password policy and don’t want to deploy certificates for authentication.
• The more recent PEAP works similar to EAP-TTLS in that it doesn’t require a certificate on the client side. PEAP is backed by Cisco and Microsoft and is available at no additional cost from Microsoft. If desired to transition from LEAP to PEAP, Cisco’s ISE authentication server will run both

The next thing I will do is expand on the various EAP methods. I will explain how they work, how to configure them based on a use case.