WPA2-Enterprise and 802.1X Simplified

Simplifying WPA2-Enterprise and 802.1X

WPA2-Enterprise has been around since 2004 and is still considered the gold standard for wireless network security, delivering over-the-air encryption and a high level of security. But don’t think that it’s gotten any easier to deploy in that time. Regardless of whether you are deploying it for the first time or a seasoned expert, there are always unique challenges ready to give you a headache.

WPA2-PSK and WPA2-Enterprise: what’s the difference?
Also known as WPA2-PSK (PSK standing for “Pre-Shared Key), this involves a single password to get on the wireless. It’s generally accepted that a single password to access Wi-Fi is safe, but only as much as you trust those using it. Otherwise, it’s a trivial thing for someone with the password to intercept the information. This is why WPA2-PSK is usually considered as insecure.

There are only a few situations in which WPA2-PSK should be deployed:

  • The network has just a few devices, all of which are trusted. This could be a home or small office.
  • As a way to restrict casual users from joining an open network when unable to deploy a captive portal. This could be a coffee shop or guest network.
  • As an alternative network for devices not compatible with 802.1X. An example being game consoles in a student dorm.
Deploying WPA2-Enterprise requires a RADIUS server, which handles the task of authenticating access. The actual authentication process is based on the 802.1X policy and comes in several different systems labelled EAP. Because each device is authenticated before it connects, a personal tunnel is effectively created between the device and the network. This is why WPA2-Enterprise is also referred to as secure wireless.

There is no definite number at which an enterprise network should be using 802.1X; it really depends on how much of a factor security is. Though as a rule of thumb, it should be considered anytime you care WHO is trying to connect.

The additional benefit of 802.1X is the ability to set up VLANs, which group wireless devices as if they were on a personal LAN network. This can make policy management easier, and can help optimize network traffic.


Deploying WPA2-Enterprise and 802.1X

There are just a few components that are needed to make 802.1X work. Really, if you already have access points and some spare server space, you really have all the hardware you need to make secure wireless happen. Sometimes you don’t even need the server: some access points come with built in software that can take care of it (though only for the smallest of small deployments). Regardless of whether you pay for management solutions or build one yourself from open source tools, the quality and ease of 802.1X is entirely a design aspect.

Learn more about the pieces of 802.1X
In order for a device to participate in the 802.1X authentication, it must have a piece of software called a supplicant installed in the network stack.  The supplicant is necessary as it will participate in the initial negotiation of the EAP transaction with the switch or controller and package up the user credentials in a manner compliant with 802.1X.  If a client does not have a supplicant, the EAP frames sent from the switch or controller will be ignored and the switch will not be able to authenticate.
Fortunately, almost all devices we might expect to connect to a wireless network have a supplicant built in.

Thankfully, the vast majority of device manufacturers have built in support for 802.1X. The most common exceptions to this might be consumer gear such as game consoles, entertainment devices or maybe some printers. Generally speaking, these devices should be less than 10% of the devices on your network and are best treated as the exceptional cases they are.

The switch or wireless controller plays an important role in the 802.1X transaction by acting as a sort of ‘broker’ in the exchange.  Until a successful authentication, the client will not have network connectivity, the only communication will be between the client and the switch in the 802.1X exchange.  The switch/controller will initiate the exchange by sending an EAPOL-Start packet to the client when the client connects to the network.  Client responses will be forwarded to the correct RADIUS server based on the configuration in the Wireless Security Settings.  When the authentication completes, the switch/controller will make a decision to allow the device on the network based on the status and possibly the attributes contained in the access_accept packet sent from the RADIUS server.

If the RADIUS server sends an Access_Accept packet as a result of an authentication, it may contain certain attributes which may provide the switch information on how to connect the device on the network.  Common attributes will specify which VLAN to assign a user or maybe a set of ACLs the user should be given once connected.  This is commonly called ‘User Based Policy Assignment’ as the RADIUS server is making the decision based on user credentials.  Common use cases would be to push guest users to a ‘Guest VLAN’ and employees to an ‘Employee VLAN’.

The Identity Store refers to the entity where the username and passwords are stored. In most cases, this is Active Directory or potentially an LDAP server. In most cases, any RADIUS server will be able to connect to your AD or LDAP instance to validate users. There are a few caveats to this where LDAP is used, specifically around how the passwords are hashed in the LDAP server. If your passwords are not stored in cleartext or an NTLM hash, you will need to chose your EAP methods carefully as certain methods such as EAP-PEAP may not be compatible. This is not an issue of RADIUS servers, it the problem is the password hash.

Developing more robust WPA2-Enterprise networks take more work, like setting up a PKI or Certificate Authority. But on the flip-side, you can make any of these upgrades without buying new hardware or making changes to the infrastructure. As an example, rolling out guest access or changing the authentication method. One upgrade many institutions have been doing recently is switching EAP methods from PEAP to EAP-TLS after seeing noticeable improvement in connection time and roaming ability. Again, improved wireless without changing a single piece of hardware.

Learn more about the pieces of 802.1X
The vast majority of authentication methods rely on username/password. It’s the easiest to deploy since most institutions already have some sort of credentials set up, but you’re still susceptible to all of the problems of passwords without an onboarding system (see below).

For password based authentication, there are basically 2 options: PEAP and EAP-TTLS. They both are functionally similar, but TTLS is not supported in any Microsoft OS before Windows 8 without using a third party supplicant like our Enterprise Client. At this point, most institutions have deployed or made the switch to PEAP. However, you can’t deploy PEAP without either using Active Directory (a proprietary Microsoft service) or leaving your passwords unencrypted.

Tokens used to always be physical devices in the form of key fobs or dongles that would be distributed to users, generating numbers in sync with a server to add extra validation to a connection. But dongles are expensive and get out of sync with the servers from time to time, but at least you could carry them around. They also could have advanced features like fingerprint scanners or plug in with USB.

Physical tokens are still in use, but their popularity is waning as smartphones have made them redundant. What you used to have on a fob can now be put into an app. There are also many other ways to do two-factor authentication outside of the EAP method itself, like using text messages or emails to validate a device.