Deploying WPA requires a thorough audit of the business need the network will address and the applications that the WLAN will support. Roaming between access points wasn't easy with WPA--we often had to reauthenticate manually. WPA's lack of support for reauthentication is a constraint for real-time applications, especially when clients regularly roam between access points.
During our test run of WPA, we had multiple sensors running in the lab as part of a wireless security monitors review for NETWORK COMPUTING (see ID# 1504f2). We identified the WPA clients and access points as protected/encrypted entities. But when we launched denial-of-service attacks with a deauthentication packet, the WPA devices were susceptible.
Meanwhile, the closest we could get to 802.11i deployment was enabling AES instead of TKIP in the encryption process on the AP. We only used clients that had enough CPU power to support AES; handhelds couldn't be secured because they didn't have AES support. There was no difference in how the devices performed with AES. And when you transition from WPA to 802.11i, there shouldn't be much of a difference in session setup, but reauthentication and roaming will perform better. A RADIUS server customized for wireless LANs is designed on the same core architecture as a wired RADIUS server, but certain authentication protocols native to the original RADIUS standard need not be implemented for wireless. Protocols like SLIP, PPTP and L2TP are not suave enough for the wireless environment. Instead, WLAN RADIUS places an emphasis EAP.
Most WLAN RADIUS servers can be installed on Unix or Windows platforms. The server and the administration/configuration programs are independent. Interlink's Secure.XS and Meetinghouse's Aegis server use Java applications to administer the server. The server platform governs the breadth of authentication stores with which the wireless devices can interact. Some of the common ID stores are local database or flat ASCII file, SQL database, LDAP servers, Windows NT Domain, Windows Active Directory, Unix password/user files and/or token-based stores.
A RADIUS server can perform a look-up authentication or a log-in authentication. In the look-up mode, the server authenticates the user against the ID store and returns user-specific attributes from the ID store with the access-accept packet. In the log-in mode, the user's credentials are used to log in to the authentication store/system. If the credentials are validated, the user receives an access-accept packet. However, the user-specific attributes in the authentication stores cannot be returned to the client in login mode, rather a default reply attribute applied to all users is returned. This is an integration issue primarily with those ID stores that encrypt data-the predominant challenge is interfacing with Windows Active Directory and similar LDAP servers.