As wireless networking technology has evolved rapidly in recent year and prices have plummeted, its popularity has risen. There is great interest across campus in making this technology widely available. ITS recognizes the value of wireless networking but believes the technology is still immature, suffering from deficiencies in bandwidth, security, and interoperability wit the wired infrastructure. For this reason wireless in the immediate future will hold a subordinate position to the wired network, functioning as a complement to it, not as a replacement for it. In order to meet the needs and desires of the CWU community while simultaneously addressing the concerns of ITS networking staff, wireless infrastructure on campus will be the sole responsibility of ITS. As with the wired network,only ITS is authorized to extend the wireless network and will do so in accordance with standards and an established plan.
Wireless networking is inherently insecure due to its transport medium. Unlike the wired network where physical access to a data jack is required, an unauthorized wireless host can easily join an unprotected WLAN from the privacy of the owner’s vehicle or other location beyond the reaches of any physical security providing the first line of defense for he wired network. Moreover, whereas in the switched CWU network environment a particular host sees only broadcasts and packets destined for its Ethernet address, a WLAN host can see and capture all traffic. Thus there are two levels of security concerns – the ability to connect to the WLAN, and once connected, the ability to eavesdrop on network traffic. The CWU WLAN infrastructure will address both of these issues by enforcing authentication and encryption.
A client adapter associates with an access point based on a common Service Set ID (SSID). Access points can be configured to broadcast their SSID in beacon packets, in which case the client does not need to know the SSID of the access point to associate. This feature will be disabled on CWU access points with the result that the client must have its SSID configured. Since the SSID will be well-known, this provides little security, but it does provide a first line of defense against outsiders who are attempting to map the WLAN. It also prevents accidental association with the CWU WLAN.
In the wired environment a host must be registered before it can access the CWU network. If the host is unknown the switch automatically places it on an isolated VLAN where it can do minimal harm. Only when a host is registered and associated with a responsible party can it communicate on the greater network. Likewise, WLAN hosts must be registered before they can connect to the network. The registration interface will remain the one currently in place for the wired network. A wireless option has been added to the Category drop-down list in support of WLAN hosts.
Each access point will be configured to require MAC authentication. With this setting in place the access point will look up the MAC address of a host attempting to associate. If it does not find the address the attempt will be rejected and the host will not be able to communicate on the WLAN. Host registrations will be maintained in the NetDB tables just as they are for wired hosts. Access points will be configured to query redundant freeRADIUS servers for MAC authentication. The RADIUS daemon has an Oracle interface which permits it to look up the address in the database and return the results to the access point. MAC authentication attempts will be logged by the RADIUS servers and a process can be configured to send alerts for failed attempts. MAC authentication will form the second line of defense against unauthorized access to the WLAN.
The best method to ensure only authorized hosts can access the WLAN is to require username/password authentication. Port-based authentication is addressed in the IEEE 802.1x standard. The implementation of this standard that will be utilized by CWU is EAP-TTLS/PAP. This method operates in a manner similar to SSL-enabled web communications. A certificate is required for the authentication server but not for the supplicant (the client component). Traffic is encrypted and login credentials pass within the encrypted tunnel. These credentials are then verified via LDAP against eDirectory by the RADIUS server. At present EAP-TTLS is the only widely available EAP method that permits authentication against eDirectory, as the other methods require access to the clear-text or NT-hashed password for verification. Closely related to EAP-TTLS, PEAP had the potential to provide this functionality as well, but Microsoft took a proprietary approach with its implementation of the protocol and required it to use MS-CHAPv2 authentication in the tunnel.
Since the PEAP implementation integrated into Windows will not meet our needs, in most cases a third-party supplicant is required. Experiments with the Meetinghouse AEGIS client, the Funk Odyssey client and the Alfa & Ariss SecureW2 client on the Windows platform have all been successful. The AEGIS client is full-featured and integrates well with the workstation login process (including the NetWare client) as does the Odyssey client, permitting single signon to the workstation, but these two are commercially licensed products. The SecureW2 supplicant is more basic and functions as an add-on to the wireless networking component of Windows. It is free. CWU has elected to purchase a 1000-user license for the Odyssey client. It is available as a free download for Windows XP and 2000 users during the host registration process.
There are also supplicants available for other platforms. The Open Source Openx supplicant runs on Linux and some Unix variants. Both Meetinghouse and Alfa & Ariss sell supplicants for the PocketPC, and Meetinghouse supports Linux as well. Apple's OSX v10.3 and higher include 802.1x support for the internal AirPort Extreme wireless interface. Many modern Intel laptops are also being shipped with built-in driver support for the protocol.
With these security measures in place, when a device and/or user on the WLAN disrupts the network, several steps can be taken to mitigate the problem. The host's entry in the database can be disabled, preventing MAC authentication from completing and preventing the DHCP server from returning an address. The user can also be prevented from authenticating. If the infraction is severe, the user object in eDirectory can be disabled, but this will prevent the user from logging in to eDirectory altogether. If it is desirable only to deny access to the WLAN, then there is WLAN access control flag associated with the user object which can be set to false. Once any of these measures is taken, the access point can be forced to de-authenticate the device, removing it from the network.
page 2 >>