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.
Very nice post. I just stujbled upon your weblog and wished to say that I’ve truly enjoyed browsing your blog posts.
After all I will be subscribing too your rrss feed and I hope you write again soon!
To implement WPA2-Enterprise security with Username/Password authentication, you might want to take a look on service provided by http://www.ironwifi.com. It’s easy to setup and you can start for free.
Loved the article. Only thing I would add is that there are some pretty decent CWP implementations out there now. Some of them can directly interface directly with a Directory Services system (AD, eDir, OD, generic LDAP, etc) or of course use RADIUS to do the same. All CWPs should be able to use HTTPS. A unique implementation, that I think is cool (warning: vendor bias), is self-registration for a Private PSK via an HTTPS CWP page. Of course, there are lots of other unique implementations as well, and that’s something to like about CWP implementations in general – uniqueness. Like you mentioned, it can be clunky if not implemented well.
Again, nice article.
Devinator
JJ,
If you’re talking encryption and tunneling (not necessarily remote access VPN), then that is something different than what I was referring to.
Yes, Aruba and Cisco both offer data tunnel encryption from the wireless client to the controller. Aruba has offered this since their earliest solutions, and Cisco introduced it as DTLS tunnel encryption as part of CAPWAP with version 6.0 in 2009.
I don’t consider those VPNs, just data tunnel encryption in the WLAN infrastructure. Good call-out though. I know many government installations require this for security certification.
Thanks,
Andrew
JJ,
Thanks for the additional information on NAC and fingerprinting. I agree with your recommendations on device fingerprinting, I think they only enhance solutions. I’m still skeptical on NAC, but then I don’t deploy many NAC solutions.
I can tell you that although most WLAN infrastructure vendors tout support for fast roaming via PMK caching or Proactive Key Caching, very few client devices support it. PMK caching is somewhat supported by clients, but it is caching an a per-AP basis and is not as effective as PKC/OKC.
That said, I cringed (nay, about died) when you said that you would recommend a VPN over Wi-Fi solution. VPN solutions will degrade user mobility as most IPSec sessions will break when roaming. SSL VPNs are better, but I would hesitate to recommend their use, especially on an internal private Wi-Fi networks. The use of VPNs was once warranted, prior to WPA2 security when insecure WEP was heavily used. However, I think that recommendation is outdated now, and actually hurts network performance and usability.
On public hotspots, definitely use VPNs because mobility between multiple APs is less common.
Thanks,
Andrew
Andrew,
Are we talking about the same VPN? I’m not sure; I mean mobile VPN solutions designed for wireless, not traditional remote-access VPNs. We may be talking about the same thing, and you still don’t recommend it. But, what I’ve found is – if they have a requirement for tokens then the traffic usually needs to be encrypted (not just encapsulated) on the wire past the AP and/or controller. Most of the clients I consult with that that have 2-factor requirements (ie law enforcement accessing CJIS and some hospitals even) use this type of solution. And although we don’t implment it, I thought some of the 802.11 wireless vendors offered a similar technology too? (for some reason I thought Aruba had an offering? Maybe not?) Anyway, that’s the VPN I’m referring to.
-jj
Hi JJ,
Great article!
What has your experience been with token authentication and usability when clients roam between access points? If fast roaming (key caching) is not used then wouldn’t the user have to type in their token PIN every time they roam to a new AP? I worry about usability of such a solution.
Also, with BYOD becoming a bigger trend, Option 1 PEAP using Windows Login Pass-Thru authenticates the user and not the device. So user’s could violate policy and connect their own personal devices to the corporate network using only their username and password. This can be mitigated with NAC solutions, but frankly those don’t scale well to large environments and are costly.
Another option is machine authentication. This is easy if using Windows machines that are added to Active Directory and have objects already. It can be done with the machine object instead of a certificate if desired, still using PEAP for instance.
Finally, a third mitigation option would be the use of newer WLAN infrastructure that can fingerprint the device operating system and apply different policies based on both user and device context (in addition to time, location, and other information). These fingerprinting algorithms use various methods including MAC OUI lookup, DHCP fingerprinting, HTTP header fingerprinting, SNMP, NetFlow, and others. It’s probably not perfect and is still definitely maturing, but it’s cheaper than NAC and may be “good enough” in many cases.
Aruba Device Fingerprinting:
http://www.arubanetworks.com/pdf/technology/whitepapers/WP_Bring-Your-Own-iPad-to-Work.pdf
Cisco ISE Profiling:
http://packetpushers.net/introducing-cisco-identity-services-engine-ise-profiling/
I’d love to hear your thoughts on these topics!
Thanks,
Andrew vonNagy
Andrew,
Luckily for me, deployments with tokens are rare with our customer base. That gets messy, and at that point I’d probably recommend a wireless solution that leverages VPN. However, it seems a lot of vendors now offer the key caching and forward/make those available between APs (or at least, that’s what I’ve been told/read in documentation). I can’t speak on experience here.
With BYOD, the newer trends (since as you noted this is an older article) are solutions that more are trying to ease the provision for secure wireless. In these, I’ve seen solutions that use a captive portal style to authenticate a guest/device combo, then flip the user to a wireless netowrk that uses a PSK and provisions that network for the client device. I’ve also seen solutions that provision temporary device certificates to address this and let the user/device participate in 1X without pre-configuration of the device. Both of those can be connected to internal AD/RADIUS or a guest solution. Also, I’m finding a lot of organizations have AD, domain or registry settings that don’t allow non-domain devices on the network. I should put this whole sentence in capital letters, I’m NOT a server person. I do what I need to do with RADIUS and AD to get things working, but I look to others with this core competency to tweak or figure out how to do something. I figure out WHAT we need to do, and get help figuring out the HOW so I can’t explain the exact settings that make this tick. I can tell you, usually machine-only authenticiation is not a reasonable solution for our customers. Most have requirements for being able to tie use of the device to a user so machine auths are only used in conjunction with user-auth. And, for this reason, we usually integrate with NAC to address most of this paragraph.
I really like device fingerprinting, and I recommend it for almost all our customers. It gives visibility in to who and what’s on the network and arms you with information to make better decisions for access, security and future growth needs. We generally recommend Bradford here. It’s easy to integrate with any wired and wireless solution, so regardless of the infrastructure, this solution stands on its own and can be persistent even as switches or AP vendors may be changed. They too use device profiling, and that can be applied for policies for devices, or in conjunction with information on the user or access type, etc. Similarly, that solution can use MAC OUIs, DHCP fingerprinting, the stuff you mentioned above and even NMAP scan matches.
We specialize in NAC, so integrating it is reasonable and easy for us to do. We sell (and have sold) quite a few different NAC solutions including software-based such as Symantec, network-based, Juniper, StillSecure, HP, Bradford, etc. Bradford is our best-of-breed recommendation bc it fits most needs, is flexible, much more scalable than other solutions and much less expensive than many solutions (for similar features). What works though depends on the environment, and there’s no silver bullet for that. I have a lot of NAC resources on this site, including the Universal NAC Feature Model document that explains how different NAC vendors implement their technologies.
Regardless of what specific solution they use (the ones you’ve listed above; in Aruba’s wireless, or integrated via Bradford, or Juniper, or Cisco ISE, Great Bay, etc) I think it adds great visibility and should be included in everyone’s wish-list for a solution with wired and wireless.
-jj