Enterprise-Class Wi-Fi Security
Published: 03/12/2009
While using a pre-shared key-based WPA / WPA2 802.11 network can be generally secure if a strong passphrase value is chosen, it still has the same disadvantage as any other shared-key system such as WEP. If a fired employee knows the value of the passphrase, then the only other thing required to access the wireless network is the WPA 4-way handshake which can be trivially sniffed through the air. Having the pre-shared key and the 4-way handshake allows anyone to capture and decrypt 802.11 transmissions since the Pairwise Master Key (PMK) (and hence the Pairwise Transient Key (PTK)) for the given client-to-AP session is now determined.
Updating this pre-shared key across dozens, hundreds, or thousands of machines in a private corporate environment is a serious administrative burden and also provides no real authentication to determine which specific individuals accessed the network since everyone shares the same credential (the shared key).
This is where the 802.1X scheme comes in to help provide both a unique PMK for each association attempt, as well as link-layer authentication before the wireless client is completely bridged onto the network to receive a DHCP lease. However, there are quite a few moving parts which all must coordinate seamlessly together, otherwise the system fails and troubleshooting can be difficult if the engineer does not have the tools or know where to isolate the problem. The complexity of an environment can also be further compounded by the number of choices in client authentication methods (certificates, usernames / passwords, smart cards, etc.) as well as the variety of supplicant / wireless client software which sometimes conflict with each other if there's more than one on a given machine.
This article uses the supplicant built into Windows XP / Vista configured with the EAP capabilities available in a native Microsoft-centric network (this is typically either PEAP or EAP-TLS) in implementing an 802.11i environment. If it is preferred that the users authenticate themselves by traditional username /password credentials, then choose PEAP / MS-CHAPv2. If the users should be required to authenticate by certificates, EAP-TLS or PEAP-TLS are the standard options. There are naturally more configuration options in the 802.1X world such as other EAP types, RADIUS products (Juniper SBR, Cisco ACS, etc.), etc.. This article will get through with the minimum amount of parts as possible.
The Breakdown of Network Components
There are five main parts to configuring an 802.1X-based Microsoft enterprise Wi-Fi network:
- Set up Active Directory (if not already done so).
- Create a root enterprise certificate authority.
- Create / configure a RADIUS server (in this example, using Microsoft IAS).
- Configure the access point to perform 802.1X ("WPA Enterprise") authentication with IAS.
- Configure the client machine supplicant (in this example, Wireless Zero Config (WZC).
In this article, the network will have the following basic layout with the DNS namespace corp.mycorp.com:
| Domain controller | CORP-DC01 | 10.1.1.11 |
| Certificate authority | CORP-ROOTCA | 10.1.1.12 |
| RADIUS server (IAS) | CORP-IAS | 10.1.1.13 |
| Access point | CORP-AP01 | 10.1.1.21 |
1. Set up Active Directory
This should be self-explanatory to any Windows administrator. Promote a server to be a domain controller, set up the LDAP namespace, raise the forest and domain functional levels, install DNS / DHCP, set the domain password policy to enforce 127-character passwords which have a maximum lifetime of three days, etc..
2. Create / Configure an Enterprise (Active Directory-Integrated) Root CA
More Information
3. Install / Configure (IAS), a la Microsoft RADIUS
More Information
4. Access Point Configuration
In 802.1X terminology, the middle-man between the client and server (in this case the AP) is known as the "authenticator" and serves as the relay point between the "supplicant" (client) and the "authentication server" (RADIUS server).
Configure a RADIUS client entry for the IAS server using the same shared secret entered previously in the IAS configuration. Depending on the access point, other items may need to be set such as support for TKIP and / or CCMP, VLAN, etc.. Consumer-grade access points by Linksys, Netgear, D-Link, Buffalo, etc. which support 802.1X may not have very many options compared to a business-grade Cisco unit. In general, consumer access points do not support 802.1X / EAPOL functionality unless an Open Source firmware is applied.
For example, on a Cisco 1200 series access point, the authentication type for the configured SSID to be used in an 802.1X configuration may need to be set for Open authentication with EAP.
Cisco 1200 Series Configuration Example
Bear in mind that this same concept can be applied to 802.1X-capable LAN switches as well (for example, Cisco's 2950 series using the dot1x commands).
5. Client Supplicant Configuration
Determine if there's a supplicant on the machine other than Wireless Zero Configuration (WZC), such as Dell TrueMobile, Intel PROSet Wireless, ThinkVantage Access Connections (commonly installed on IBM and Lenovo machines), Juniper (formerly Funk Software) Odyssey, SecureW2, etc.. If WZC is preferred, then disable the others (typically a service) so there's no contention for the wireless radio hardware. Sometimes, installing the driver of a given 802.11 card might force the use of a third-party supplicant.
If the client is XP and WPA2 is required for the network, then a Microsoft update may be required (http://www.microsoft.com/downloads/details.aspx?familyid=2726F32F-D52B-4F84-ACE8-F7FC20195769&displaylang=en). Otherwise, the best that XP's WZC can support is WPA / TKIP. If there are any 802.11b-only clients in the network, then they will be limited to this as well.
Root CA Certificate
The root CA's certificate is automatically installed in a domain member's Trusted Root Certification Authorities store of the local computer account context, not the user's. If the machine is not a member of the Active Directory domain, then manually import the root CA certificate by opening the certifcate file from the root CA host's CertEnroll share (in this article's example, that would be \\CORP-ROOTCA\CertEnroll).
View Manual Root CA Certificate Import Process
Username / Password Authentication: Protected EAP (PEAP) with MS-CHAPv2
If the IAS is configured for PEAP (with MS-CHAPv2 as the inner authentication method), then perform the following supplicant configuration on the client-side:
PEAP Configuration for Windows XP
PEAP Configuration for Windows Vista
By default, WZC automatically sends the credentials of the currently-logged-on user to the network. If the credentials reflect a valid domain account, then the wireless authentication will be transparent to the user. However, if the logged-on user is a local account or otherwise a non-domain member, then the following dialog will need to be unchecked so the user is prompted when the wireless association occurs (this is under the PEAP profile created earlier within the Protected EAP Properties dialog):
Once the client machine is configured, create a domain user in Active Directory and under the Dial-in tab, select Control access through Remote Access Policy. This allows control of user access based on the policy controls set within IAS. The typical scenario is to have the new user log into the machine once while connected to the LAN so domain credentials are cached locally on the machine. Then the next time the user logs onto the desktop while disconnected from the LAN, WZC will automatically initiate an association and EAP authentication with the AP / back-end domain services (IAS and AD).
Client Certificate Authentication (EAP-TLS or PEAP-TLS)
While username / password credentials for 802.11i networks are convenient and somewhat easier to implement, the security around passwords are always the weak link because in most cases users choose cryptographically weak password values. Certificates are a much stronger alternative, although traditionally this has meant the extra step of deploying certificates to all users. With Active Directory's Autoenrollment feature, this should not present much of a problem for domain users. However, a few configuration steps need to be performed within Active Directory as well as on the server functioning as the enterprise certificate authority.
Show Active Directory User Certificate Configuration
Domain users will eventually get a user certificate assigned to them while logged into their machine. This can be verified by opening the Certificate Manager (certmgr.msc) in the context of the logged-on user and looking under the Personal store. However, rather than wait for the autoenrollment to occur, users can force the issuance of a certificate to them within the Certificate Manager window.
Manual User Certificate Request Process
Once user certificates are issued, then client station supplicants can be configured:
EAP-TLS / PEAP-TLS Configuration for Windows XP
EAP-TLS / PEAP-TLS Configuration for Windows Vista
Configuring Non-domain Clients / Users
There are always exceptions in any environment and no matter what the corporate IT security policy says, someone will drum up an excuse to have a guest or personal machine (unauthorized by IT) be given access to the secure 802.11i network. If the C / EO / IO / FO / OO or whoever is demanding the exception, then it's just a few steps to allow the unclean, filthy, virus-ridden zombie machine onto the WLAN:
Configuration for Non-Domain Entities
Mac OS X Clients
The supplicant built into Mac OS X (at least Leopard as of this writing) natively supports more EAP types than Windows, although PEAP-TLS may not be one of them. Selecting PEAP within OS X will assume that the inner identity is MS-CHAPv2 based.
Mac OS X Configuration
Group Policy Wireless Connection Profile Distribution
If Active Directory's schema is properly updated, 802.11 wireless connection profiles can be centrally configured and deployed via Group Policy for Windows Vista clients. See http://technet.microsoft.com/en-us/library/bb727029.aspx for more details.
What the Traffic Looks Like
The following are example packet traces which can be viewed with Wireshark (the captures have extraneous packets filtered out to highlight the key events in the authentication process):
PEAP / MS-CHAPv2:
Traffic Between Client and AP (capture file: example_peap_ms-chapv2_client.cap)
Traffic Between AP and IAS (capture file: example_peap_ms-chapv2_ias.cap)
EAP-TLS:
Traffic Between Client and AP (capture file: example_eap-tls_client.cap)
Traffic Between AP and IAS (capture file: example_eap-tls_ias.cap)
PEAP-TLS:
Traffic Between Client and AP (capture file: example_peap_tls_client.cap)
Traffic Between AP and IAS (capture file: example_peap_tls_ias.cap)
Troubleshooting
There are several places to check regarding authentication issues. IAS logs all authentication attempts to files under %SystemRoot%\system32\LogFiles. While interpreting the raw log files may be confusing, a utility like the IAS Log Viewer can aid in translating the values of the fields. Authentication attempts can also be seen in the System event logs on the IAS server:
IAS System Event Log Example
Another method of debugging the RADIUS stream between the access point and IAS is to insert a FreeRADIUS server (running on Linux or FreeBSD) between them. Therefore, the AP sends the RADIUS requests to FreeRADIUS, and FreeRADIUS relays the message to IAS. With FreeRADIUS (radiusd) running in debug mode and sending runtime output to a file (radiusd -X >> /var/log/radiusd/debugs) it would be possible to tail the file and see very verbose RADIUS protocol-level messages.
However, having packet-level visibility provides the most benefit since seeing the problems at this level provides immediate insight into the exact reasons why something fails. The two best places to monitor traffic is at the RADIUS server (with a sniffer located either on the server itself or via switch mirror port) and the client side.
Installing a sniffer on the client will allow visibility on EAP / 802.1X messages, but due to limitations with most Windows drivers, 802.11 link messages such as Probe Requests, Association Requests, etc. will not be displayed. If using Wireshark to sniff on the client station itself, uncheck the Promiscious Mode option.
The other (free) option in monitoring the client side is to use a second machine with the BackTrack Linux LiveCD in order to see all the beautiful 802.11 management frames pass between the client station and the AP.
Is All This Really Worth It?
For business environments with more than a dozen or two users, relying on a common passphrase-key is risky due to the relatively easy traffic exposure to anyone who knows the pre-shared key value, because obtaining the WPA 4-way handshake and nonce values is trivial. The administrative burden of updating a single pre-shared key across all network clients in itself makes it worth migrating to a longer-term solution that also provides user-specific logging of who gets onto the network (and at what time).
Home users, on the other hand, generally wouldn't have a need for this level of security unless they're either extremely paranoid, interested in examining the potential of 802.11i, or just want Wi-Fi bragging rights in the neighborhood. Like yours truly. =)
Go back to the main articles list.