Securing Wireless Campus Networks

Clark Gaylord and Steven Lee

While no Ethernet-based network can be considered a "secure" communications medium, network operators take some solace that the exposure of traffic for a LAN is limited to those stations that have "physical access" to it. With a wireless LAN (WLAN), there is not even this meager security, as physical access to radio waves is defined by nothing stronger than geographic proximity. Unfortunately, the standard method for addressing this proximity vulnerability, "Wired Equivalent Privacy" (WEP), is not suitable for large-scale networks due to its shared-key nature and deficiencies in the encryption algorithm. As a result, enterprises and service providers alike have struggled with how to control access to their WLAN infrastructures so that the network is both usable and no worse than wired Ethernet in terms of data privacy.

The first order of business with network security is access control -- that is, how do we know that the user accessing the network is authorized for this use? At Virginia Tech, we currently have more than 2700 registered wireless users and 125 wireless access points. We need an approach to access control that is supportable to a large and diverse user community, that is manageable for a fairly large number of access points, and that provides reasonable assurance that network users are in fact authorized. Our approach so far has been based on the Ethernet media access control (MAC) address, both with DHCP and filtering at the access point. This article will provide implementation details for our approach, as well as a design for user-level access based on Virtual Private Networks (VPNs).

Overview

Access control requires a method whereby users are identified for this access. This could be a process where the user registers for the service and provides, or is provided, relevant data for this access. This may be assigning a username and password for login access, or it could be identifying the MAC address of the wireless network interface card (NIC) the user owns, or both. While the complete specification of a telecommunication database is very complex and has many elements that are specific to the organization, a simplified relational database structure would include tables that identify the user, their MAC address, and the wireless access points. A skeleton of some of the relevant relational database tables is shown in Figure 1. Our business and network engineering databases use Oracle, but other SQL-based relational databases could also be used.

To make our wireless LAN easy to support while maintaining some level of access control, we wanted to provide our access control with no end-user intervention or assumptions of end-user configuration. We also wanted as little reliance on vendor-specific features as possible. The one thing that all users have, by definition, is a wireless network interface card, which has a globally unique Ethernet address. This gives us a token to use as a proxy for the user, if we can find a way to use it that is vendor-neutral. One attribute of wireless LAN users is their inherent mobility, making DHCP an obvious requirement. So, by only supporting DHCP for IP assignment, and only allowing registered MAC addresses to be served an IP address by the DHCP server, a level of access control is achieved.

Advantages to this approach are that it is very straightforward to implement and it makes no assumptions about either the end-user configuration or the wireless access point. The most obvious disadvantage is that it is not a very strong access control mechanism. Any would-be user who desires unauthorized access need simply configure an IP address that is valid for the network and not currently in use, although even this is an overt act of misconduct. This is a trivial proposition for even novice users, so we wanted a stronger access control method.

Moving the access control closer to the user could reduce some of the exposure from a DHCP-only approach. Since the early days of Ethernet bridging, most managed bridges have had the ability to configure a list of MAC addresses assigned to an interface, and the bridge will only forward frames for those stations on the allowed list. With only one access point, such as one might have in a residence, a static list of allowed MAC addresses could be configured on the access point, and indeed this is a very good feature to use in a residential network. However, for a network of several access points with mobile users, such a static list on all access points would be a difficult network management problem.

To be manageable, this configuration must be dynamic, with the access points checking MAC addresses via some client-server protocol. Following the approach taken by Lucent, several vendors implement this feature by using the RADIUS protocol; the Enterasys access points that we use at Virginia Tech are such products. With this feature, the access point asks the RADIUS server whether the MAC address is a valid user (with plain-text password of "NOPASSWORD"). Thus, we can extract the authorized MAC addresses from our database and construct configuration files for the RADIUS server.

RADIUS Configuration

The model for RADIUS is that a network access server (NAS) will have users connecting to it. The NAS then receives authentication data from the user and sends requests to a RADIUS server based on the data to determine whether the user is authentic and is authorized for the network; hence, the NAS is a RADIUS "client". The NAS encrypts communication with the RADIUS server using a shared key (which can be client-specific).

If the MAC address is a valid RADIUS user, the MAC address is considered authorized to use the wireless LAN. For ease of integration, we wanted to use a RADIUS server that would support plain-text configuration files. There are two files that are relevant for our purposes: one for the user database (with the MAC addresses of authorized users), and the other to identify the RADIUS clients (i.e., the wireless access points) and their associated encryption keys.

We have used two popular open source RADIUS servers -- FreeRADIUS and OpenRADIUS -- both of which are licensed using the GNU General Public License. Each of these has been effective, and each can readily be configured to use text-file databases with slightly different file formats. FreeRADIUS has a large installed base and active user community, and it is closely modeled on legacy RADIUS servers from Livingston and Cistron. OpenRADIUS is written and maintained by Emile van Bergen.

As its name implies, OpenRADIUS is designed to be an open, modular system, with child processes forked for the various methods of performing authentication, authorization, logging, accounting, etc. The distribution includes a module for text-file configuration similar to the legacy RADIUS servers. It could also be readily extended with a module to do direct database lookups, but we use the provided "ascfile" module. Note that, as shipped, OpenRADIUS has some back-door users configured in the main configuration file; these should be removed before using this server in production. Both FreeRADIUS and OpenRADIUS built easily from the distribution tarballs on the FreeBSD and Solaris systems on which we installed them.

We use the oratcl package to access our Oracle database from Tcl programs. Listing 1 shows programs for extracting users and clients from the database into the text configuration files. The extractUsers.tcl script populates the RADIUS users file, and extractClients.tcl populates the RADIUS clients (or FreeRADIUS's preferred clients.conf) file. Each of these scripts allows the respective configuration files to be prepended and appended with other files, thereby making it possible to integrate them easily into an organization's workflow. For example, an organization might already have a RADIUS user database for remote access. This existing file could be the users.top file in our scenario, and MAC addresses for wireless LAN access will be appended to this file. The resulting users file will contain all of the original remote access users plus the wireless LAN MAC addresses. These files need to exist so, if they are not needed, a simple touch on each would be necessary. We run these scripts via cron on a different system than our RADIUS server, and distribute the RADIUS configuration files via CVS. The code supports both FreeRADIUS and OpenRADIUS servers by specifying the server at the command line, for example, "extractClients.tcl [open|free]".

Using Virtual Private Network for Access Control

The two limitations of using the MAC-based filtering are: MAC addresses are user-configurable (though this may not be common knowledge among as many users as IP address configurability); it relies on features of the Lucent-style access points (though other vendors may have similar methods for doing MAC-based filtering). A stronger access control method can be achieved, sacrificing some of the user convenience of the MAC-based methods, by using a Virtual Private Network (VPN)-based approach in conjunction with appropriate network access control.

Although this approach does require some explicit user sign-on process, it is a straightforward design to implement and support. For this approach to be manageable, the wireless LAN must be a different Ethernet broadcast domain (subnet) from the wired LAN. This is commonly done using virtual LANs (VLANs), so that the same Ethernet cabling and switching can be used for both the wireless and wired LANs in a building. By using a different VLAN for wireless, user mobility can also be better supported. Areas in a building or between several buildings may have different wired LAN subnets but might be geographically close enough that wireless users could seamlessly roam among these areas. While the use of separate VLANs for wireless does not in itself provide any inherent security to the wireless LAN, it does provide a convenient way to implement different network policies on the respective router interfaces. This fact is especially useful in using VPN as a wireless access control method.

Many organizations already have some form of VPN for their users who are at arbitrary points on the Internet to be able to access resources internal to their campus networks. This "location transparency" of VPNs can also be used for wireless access control. Another benefit for any network user, but especially popular for wireless networks, is that VPNs can offer encryption between the user and the VPN server (though thereafter the traffic travels from the VPN server to its final destination with whatever privacy the application uses). While this approach is weaker than application or socket-layer encryption, it does mitigate some of the risk for clear-text applications (e.g., standard POP3 traffic).

VPNs operate by encapsulating entire packets into the payload of other packets. In this way, the encapsulated packets are "tunneled" through a transport network of another point (the destination of the carrying packet, i.e., the other end of the tunnel), where they are decapsulated and forwarded to their ultimate destination. There are numerous specific tunneling protocols for VPNs; the most common ones are Point-to-Point-Tunneling Protocol (PPTP), Layer2 Tunneling Protocol (L2TP), and the many associated protocols collectively referred to as IPsec. For ease of support and ubiquity, we use PPTP, but for the purpose of providing access control to the wireless LAN, any of these could be used.

In addition to the tunneling protocol itself, there are two different modes of operation for VPNs: client-initiated and network-initiated. Network-initiated VPNs are sometimes referred to as LAN-to-LAN VPNs; they are not useful as a way of controlling access to a wireless LAN infrastructure. The client-initiated VPNs can be viewed as a "virtual dial-up" approach, where the transport network plays the role of the modem connection in traditional dial-up. The client-initiated mode is also one that suits the portable Internet user well, allowing users to establish VPN tunnels from wherever they may be on the Internet back to the campus.

Any VPN service has its own access control mechanisms, and these are used indirectly for regulating access to the wireless LAN infrastructure. Using the virtual dial-up approach, the end system will have two network interfaces -- the (native) physical WLAN interface, and the virtual VPN interface. Each of these will have an IP address. The usual VPN configuration would establish the default IP route via the VPN interface. Once the tunnel is established, the only traffic that would be sent through the router of the wireless LAN subnet would be destined for the VPN server. By applying access lists to this router interface to prevent any traffic from the wireless LAN other than that destined for the VPN server(s), a strong access control to the wireless LAN is established. It is true that would-be unauthorized users would have access to the wireless LAN itself (although the MAC-based controls could still apply), but these users would not be able to access anything off the wireless LAN subnet. The following listing shows a typical access-control list (ACL) for the router interface of a Cisco 6000:

ip access-list extended only-to-vpn
! allow native traffic to vpn land
 permit ip 10.0.1.0 0.0.0.255 192.168.47.0 0.0.0.255
! allow native traffic to dhcp/dns land
 permit ip 10.0.1.0 0.0.0.255 192.168.53.0 0.0.0.255
! no other native traffic. Everything must go to vpn.
 deny ip any any
interface VLAN945
 description Wireless LAN
 ip address 10.0.1.1 255.255.255.0
 ip access-group only-to-vpn in
interface VL530
 description DHCP/DNS network
 ip address 192.168.53.1 255.255.255.0
interface VL147
 description VPN network
 ip address 192.168.47.1 255.255.255.0

Note that the above router access control requires all wireless LAN users to establish a VPN tunnel to access anything off the wireless LAN. Without this requirement, WLAN users could still voluntarily choose to use a VPN service for any encryption or location transparency it might offer. This would not make the VPN an effective access control method for the wireless LAN, but it may be of value in some organizations. Also, the VPN only controls access to resources off the wireless LAN; using this approach does not prevent users from accessing others on the wireless LAN without using the VPN tunnel. To accomplish this, some link-layer access control, such as that described above using MAC addresses, would also have to be used.

Conclusion

The implementation described in this article is an effective means of providing a scalable yet manageable method for access control. The MAC authentication solution allows quick unimpeded access to the network while still giving a reasonably effective means for controlling access. Although the TCL code provided is intended to create the RADIUS users and clients files, organizations that use the ISC DHCP server could easily adapt extractUsers.tcl to generate host entries for MAC-based DHCP access as well.

VPN tunnels provide an optional authentication method and can also offer privacy of data but necessitate the additional task of logging on to the network. It sacrifices the automatic user login of a MAC-based authentication, which all users find convenient, and it adds another point of failure for the users network service. Hence, we plan to initially offer VPNs to the university community as an optional service, thereby necessitating the use of MAC-based authentication as the primary access control mechanism. As we gain more confidence in the robustness of end-user VPN software, it may become viable to make this a mandatory component for wireless LAN users. An organization wanting to enforce the use of VPN tunnels for wireless users could take advantage of the VLAN network architecture. Moreover, the VPN service is useful to users from any insecure network, whether at some arbitrary Internet location or on a campus-wired Ethernet.

To address the state of wireless LAN security, the IEEE commissioned a task group within 802.11, known as TGi, to develop methods for wireless LAN security. In the meantime, several vendors have proposed proprietary extensions to 802.11 networks to address these matters. There are numerous examples, including some that try to address some of WEP's deficiencies, such as methods for rapidly changing WEP keys, using per-client WEP keys, and others. All these suffer from being non-standard methods and relying on vendor-specific solutions.

Given the enormous popularity of 802.11b networking over the last two years, it is unlikely that users and organizations will want to replace all of their existing investments if a suitable method can be devised to address these matters. TGi and others have been looking at 802.1x as a likely candidate to address many of these concerns. The 802.1x protocol specifies a port-based client-server access control mechanism that restricts unauthenticated users at the network port, whether it is an edge switch or a wireless access point. At this time, it is only supported in access points by a few vendors, and end-user operating system support is still immature. Still, this an encouraging development that could be an important advance for both wired and wireless LANs as it matures.

As standards for stronger wireless LAN security, such as 802.11i, mature, they may supplement and augment the approaches given here. The methods described in this article can readily be deployed today. When used together, they give a reasonable and effective approach to wireless LAN security, making this medium no worse than wired Ethernet; indeed with the additional support for encrypted VPN tunnels, such an approach offers a level of data privacy beyond that of the usual wired Ethernet. On the other hand, not deploying a well-managed wireless LAN service could be a serious liability to any organization. In the absence of any well-managed alternatives, users will deploy their own wireless LAN networks, with highly variable awareness and ability to secure them.

References

Borisov, Nikita, Ian Goldberg, and David Wagner. Security of the WEP Algorithm. 2001. Available from: http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html

Eisinger, Jochen. Exploiting known security holes in Microsoft's PPTP Authentication Extensions (MS-CHAPv2). 2001. Available from: http://www.counterpane.com/

Ferguson, Niels and Bruce Schneier. A Cryptographic Evaluation of IPsec. 1999. Available from: http://www.counterpane.com/

FreeRADIUS software -- http://www.freeradius.org/

Fluhrer, S., I. Mantin, and A. Shamir. Weaknesses in the key scheduling algorithm of RC4. Eighth Annual Workshop on Selected Areas in Cryptography (August 2001).

Gast, Matthew S. 802.11 Wireless Networks: The Definitive Guide. O'Reilly & Associates. 2002.

Gaylord, Clark and Steven Lee. Wireless LAN Security in a Campus Environment. 2002. Available from: http://rdweb.cns.vt.edu/~cgaylord/

Microsoft. Privacy Protected Network Access: Virtual Private Networking and Intranet Security. 1999. Available from: http://www.microsoft.com/windows2000/techinfo/howitworks/security/comsec.asp

Northcutt, Stephen, et al. Inside Network Perimeter Security. New Riders. 2003.

OpenRADIUS software -- http://www.openradius.net/

Oratcl software -- http://oratcl.sourceforge.net/

Schneier, Bruce and Mudge. Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol (PPTP). 1998. Available from: http://www.counterpane.com/

Schneier, Bruce and Mudge. Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2). 1999. Available from: http://www.counterpane.com/

Stubblefield, Adam, John Ionnidis, and Aviel D. Rubin. Using the Fluhrer, Mantin, and Shamir Attack to Break WEP. AT&T Labs Technical Report TD-4ZCPZZ. 2001.

Clark Gaylord is a Senior Research Engineer with Virginia Tech's Communications Network Services department. In addition to architecting Virginia Tech's wireless LAN service, he leads engineering of capacity planning, bandwidth management, and other network management efforts for the Virginia Tech campus network and Network Virginia.

Steven Lee is a Wireless Network Engineer with Virginia Tech's Communications Network Services department. He is responsible for the deployment engineering of Virginia Tech's wireless LAN and DHCP services.