Friday Feb 23
Four Options for Secure Wireless Authentication with 802.1X
Updated on Tuesday, 31 January 2012 02:10

The use of 802.1X in wireless is currently the most widely accepted method for secure authentication and key exchange in enterprise environments. I would say the only other “industry-approved” method for secure wireless access would be an implementation of VPN connections, which has its own vulnerabilities and overhead.

There seems to be quite a bit of confusion about the options for performing 802.1X authentication in wireless networks. Here I’m outlining the three primary options when using 802.1X in wireless, and throwing in one additional 802.1X-like authentication using captive portals. Keep in mind this is 802.1X-specific and does not include WEP or WPA for encryption or authentication.

Option 1. 802.1X with Windows Login Pass-Thru

The first and most common setup of 802.1X in wireless is the use of the Windows login pass-through option. Obviously, if you have a non-Windows operating system, you’ll be using a slightly different version of this method, but it operates the same. I’m going to refer to Windows here, since that’s what the majority of enterprise and federal clients are using.
In a pass-through situation, the 802.1X supplicant on the laptop grabs the credentials entered, packages them in EAP (extensible authentication protocol, used in 802.1X) and passes them through to the network for decision-making. Most Microsoft environments using a login pass-thru will use EAP-PEAP (protected EAP) method of EAP to transmit the credentials.

Best used for: Medium to high security environments with homogeneous endpoints and operating systems that support native supplicants (Windows XP SP2 and later have the 802.1X supplicant built-in. Windows XP SP3 and later allow domain admins to manage the properties through group policy in AD.)

Pros: Pretty secure authentication since it’s using user credentials (versus machine logon). Easy to implement in the right environment and does not require a certificate infrastructure for the endpoints. Only the authentication server (RADIUS) needs a certificate to leverage PEAP.

Cons: Can be tricky in mixed environments with a variety of endpoints or in shared resource environments where logins may not be user-specific (ie labs with generic logon).

Option 2. 802.1X with Endpoint Certificates

In environments with full certificate infrastructures, an organization may decide to leverage certificates on endpoints instead of passing through user credentials. While certificates are considered one of the more secure options, its important to remember that at that point we are authenticating the device, not the user.
When using wireless 802.1X with certificates, you’ll usually select EAP-TLS or a similar vendor-specific EAP type.

Best used for: High security environments with all managed endpoints, a PKI certificate structure and key management.

Pros: Extremely secure authentication method, provided the certificate structure is trusted. Fairly easy to implement if a PKI solution is already in place.

Cons: This method authenticates devices with installed certificates, not users. Organizations with high security requirements and extensive audit and accounting needs will want to layer authentication methods (two factor or more) to validate the machine and user. This is a major undertaking if a certificate system is not already in place.

Option 3. 802.1X with Token Authentication

Token authentications can operate very similarly to certificates – pretty much identically actually. The primary difference is, unlike device certificates, tokens authenticate the user instead of the device. (Unless someone stole your token). Configurations for passing through 802.1X with tokens will be the same as those for certificates (if certificate-based) or credential pass-through (if using a hardware only code token).

Best used for: High security environments with a PKI certificate structure and or token management in place. Organizations that need two factor authentication.

Pros: Another extremely secure authentication method, based tokens (software or hybrid hardware) use certificates and/or a rolling hardware code that’s passes as simply as a credential.

Cons: The management overhead is comparable or greater than that required for endpoint certificates, with the added cost of the hardware itself and physical/administrative management of the devices.

Option 4. 802.1X with Web-Auth (Captive Portal)

Most vendors offer a web-authentication option that operates as a captive portal. These can be a little tricky since many vendors build in a proprietary system for ease of use and management. Other products use web-authentication is the tradition sense (as seen on many switches) and pass the credentials through just as you would a username and password in an 802.1X pass-thru. Although web-auth is not technically 802.1X, in standard implementations, it operates the same.

Best used for: Environments supporting non-managed devices, nomadic endpoints or users without full access privileges, such as guest users or hotel guests.

Pros: No configuration is required for the endpoint; all a user needs is access to a web browser. The back end can be managed manually through RADIUS group policy and directory ‘guest’ user accounts, or through a vendor-provided guest provisioning system.

Cons: This method is not ideal for most uses cases for authenticated users, employees and managed endpoints where a more secure system can be implemented. Some captive portal systems are clunky and require a user keep the primary browser windows to maintain a connection.

Wrap Up.

The back-end processing of the 802.1X credentials, regardless of the delivery, are processed the same way. The only differences are in what information is used to authenticate the user (or device) and how the information is gathered and sent. Each type of authentication will use a different method (or methods) of EAP and have different benefits in certain environments.

Related Posts and Resources.