RADIUS

RADIUS is a widely deployed protocol for network access AAA. Although there are many issues with RADIUS, including issues with security and transport, it will more than likely remain widely used for years to come because it is simple, efficient, and easy to implement. A username and password are entered to access the network and are passed by the Network Access Server (NAS) to a RADIUS server, which verifies that the information is correct and validated with its database. Access to the system is then authorized by RADIUS in accordance with rules configured by the network administrator. The AP plays the role of the NAS in a WLAN. RADIUS can use either an internal native database of users or may optionally point to an external (usually LDAP-compliant or -compatible) database such as Active Directory or Novell Directory Services. The transition from hardware authentication (MAC addresses) and shared keys (WEP) to user-based authentication (RADIUS) is one of the most important steps in ensuring scalability as you secure a WLAN. RADIUS is already in use in many organizations for wired networks, making adoption for the wireless segment easier.

RADIUS has been overwhelmingly adopted as the preferred authentication process for WLANs using 802.1x-based security solutions. Suggestions on RADIUS usage of IEEE 802.1x authenticators are provided in RFC 3580 [15], which was released in September 2003. There are several advantages to using RADIUS for authentication. RADIUS authentication is not based on hardware, reducing costs and administration overhead when upgrades occur or authentication data is changed. Accounting and auditing features are available in RADIUS, allowing enterprises to audit usage and create alarms for suspected unauthorized intrusion.

RADIUS also works just as well with VPNs in a wireless environment as it does with 802.1x/EAP-based solutions. The significant differences between the two are that each uses a different NAS device type and authentication protocol. In regard to the NAS device, the RADIUS server only cares about what type of protocol it supports. No matter how good a particular authenti cation and encryption technique might be, hackers are getting smarter all the time. It is impossible to develop an impenetrable security technology, so the goal of any security philosophy is to make it extremely difficult and unrewarding for unauthorized individuals to obtain access to network resources and information. A Kerberos-based approach to wireless does this with an efficient, proven, standards-based implementation that supports user roaming while addressing all of the known security deficiencies in the current 802.11 standard. The 802.11i standard, when approved, is expected to provide an extensible framework, allowing a variety of techniques. The success of the implementation of RADIUS in a WLAN depends largely on the selection of the server and the feature set to be used. Some of the factors and features that must be considered before implementing RADIUS with a specific security solution at any given site include the following:

Accounting
Clustering and failover support
EAP support
Legacy authentication protocol support
Multiple RAS vendor support
Mutual authentication support
Scalability
Software/appliance implementations including Kerberos

RADIUS servers should be selected and configured to meet not only the current transaction load, but also projected workload demands. Deploying a bare minimum configuration will raise long-term costs assuming the network load and the user base grow in the future. The baselining data, a site survey, and a review of projected growth curves are tools that should be employed to determine the necessary scalability before deciding on a RADIUS server configuration. Scalability can be determined by the RADIUS server's capability in passing authentication requests to another such server in lieu of proxy authentication. The RADIUS server's native database is the only one used, which becomes a limiting factor.

The RADIUS server should, of necessity, support the type of EAP in place in the organization. The wireless infrastructure devices chosen must support an EAP type matching the one supported by the server if an existing RADIUS server is already in the organization and cannot be changed.

If the RADIUS package selected supports a clustered design, new advantages and disadvantages enter into the equation. Clustering means that multiple servers, at an additional cost, run as a single computer, each sharing in the application's workload. Clearly, the operating systems running on such servers must also support clustering. This might create the need for additional licensing fees, software upgrades, and other ancillary costs; however, the benefits of clustering include built-in failover and redundancy. This protects the organization from data loss, reduces network downtime, and uses every bit of the deployed CPU power most efficiently.

RADIUS accounting permits a RADIUS server to track when users start and stop their dial-in connections and to acquire data about each session. Using RADIUS accounting, the RADIUS server maintains a history of all user dial-in sessions, indicating start time, stop time, and various statistics about the session. It also provides a current user list indicating which users are currently connected to which Remote Access Servers (RAS). The data collected by RADIUS accounting may be easily exported to spreadsheets or databases, where it can be analyzed by security personnel. RADIUS accounting provides ISPs with data for concurrency statistical monitoring (accounting for the number of concurrent logins per user), which can be fed into their billing software; this allows the ISP to charge the clients for additional logins or simultaneous logins. Other types of organizations may find this form of monitoring helpful where a central service provider passes charges through to other divisions in the organization as an internal cost.

The latest RADIUS server software normally provides support for MS-CHAP, MS-CHAPv2, multiple EAP types, and other types of authentication. A RADIUS software package that will support the authentication protocol(s) that are being used by the particular NAS units should be selected when implementing RADIUS. When legacy RAS devices are in place, it may be appropriate to select a less secure authentication but more mature protocol. Initially, it may be best to integrate support for legacy and leading-edge authentication protocols simultaneously to make the transition between older and newer systems easier and more cost effective. This is not an uncommon practice when moving between wireless VPN systems and 802.1x/EAP-based solutions.

The use of two-way login validation as mutual authentication instead of one-way authentication eliminates the risk of man-in-the-middle and rogue AP attacks. When one-way authentication is used, the client sends authentication credentials to the RADIUS server for verification. In two-way authentication, the server normally identifies itself to the client as a valid authentication server before client authentication. Mutual authentication can also refer to both the client and the AP having to authenticate to the authentication server. Mutual authentication support is an important feature to have as part of a RADIUS package used in wireless systems.

RADIUS protocol support is one particular feature to look for when purchasing a RADIUS server package. There are many types of RADIUS protocols, so the RADIUS server must be configured to speak the proper "dialect" to the local NAS. It is important to ensure that the RADIUS server is going to work with your organization's NAS.

RADIUS servers are available in various forms to include hardware appliances and software packages, and can even be integrated into wireless infrastructure devices such as APs. Most RADIUS appliances are rack-mountable units in a metal 1U chassis, running FreeBSD or Linux with open-source RADIUS applications or, more recently, Windows 2003. RADIUS appliances can provide either a centralized solution for controlling WLAN users or they may act as a RADIUS authentication proxy device. Appliance solutions are appropriate for nearly any size business (in large enterprises where distributed proxy RADIUS devices can help alleviate congested WAN links and in small and medium-sized businesses where a moderately scalable RADIUS solution may be practical and easy to manage).

RADIUS servers integrated into APs can use either internal user databases for authentication lookup or verify user credentials using another vendor's database through proxy authentication. These are stand-alone solutions appropriate for SOHO environments where there are a small number of users and the security solution is designed to minimize costs.

RADIUS server software is available on Windows, Linux, or Unix platforms. The costs for purchasing RADIUS software packages can range from free to very expensive depending on platform support, feature sets, and scalability. Scalability and redundancy are the biggest advantages of software-based RADIUS solutions. After a software RADIUS server package is installed, it is configured with an administrative software tool. In some cases, it is more appropriate to use a small-scale, purpose-built RADIUS implementation rather than a large, centralized RADIUS server (e.g., on a distributed WLAN with many hotspots, such as that offered by an ISP). It is advantageous and more scalable to have inexpensive RADIUS servers located at each site to perform key rotation/distribution, proxy authentication, and other wireless-specific functions locally. These "scaled-down" RADIUS servers would have to implement 802.1x/EAP in its various formats in order to be used effectively with WLANs.

Thoughtful decision making about how and where to deploy RADIUS servers in wireless environments will go a long way toward building a cost-effective and scalable network; however, some more typical deployment scenarios should be explored before inventing something new. These designs all work well: some are designed for a single site, whereas others are a better fit for a campus environment where secure roaming is desirable; other designs best serve organizations with multiple sites and combinations of architectures. Typical RADIUS configuration scenarios include the following:

Centralized authentication
Centralized authentication and security
Combination architectures
Distributed sites and security
Distributed sites
Distributed autonomous sites
Single-site deployments

In a single-site deployment scenario, all WLAN users are located at a single site and a central authentication database handles all user authentications. Authentication of users, management of WLAN and/or remote access, and establishing secure WLAN connections is handled by one or more RADIUS servers. WLAN users can be authenticated against any back-end authentication database that your RADIUS server supports. RADIUS/AAA servers and APs can be added to scale and to authenticate users against the central authentication database. If the spike in user growth is significant, it may make sense to use the distributed scenario because it scales much better than the single-site deployment model.

In the distributed autonomous sites (or networks) scenario, all user authentication happens locally by replicating the authentication database from the central site downstream to each autonomous site or network. WLAN and/or remote access use is available at each autonomous site or network and managed through the use of one or more RADIUS servers. The availability of a central site network or operating hub is not an issue in this scenario. Each RADIUS server handles user authentication locally, sets up secure WLAN connections, and if necessary, records accounting data. In this scenario, access to your network is governed locally and is not subject to the reliability of a link back to a central authentication store. You can easily add RADIUS servers to absorb the performance hit associated with adding new WLAN users. The distributed RADIUS servers handle the full computational load associated with setting up the secure WLAN connection. Although this architecture is appropriate on networks where authentication databases are deployed (which can be easily and reliably replicated, such as Windows or LDAP), it may not be appropriate for authentication systems such as token systems or SQL databases, which are not easily replicated.

In the distributed sites with centralized authentication and security scenario, WLAN APs at each site or on each network authenticate users against an authentication database located at a central site or operating hub in an architecture composed of distributed sites, networks, or clusters of APs. All WLAN and/or remote access use is managed at a central site through one or more RADIUS servers. The central site RADIUS server handles user authentication locally, sets up the user's secure connection, and if necessary, records accounting data. As with the distributed autonomous site scenario, the availability of a central site network or operating hub is an issue. Bandwidth usage may also be an issue. A RADIUS/AAA server is not needed on each satellite location, network, or AP cluster in this scenario, but it presents two issues that merit consideration. Although this scenario carries certain cost benefits, some issues should be considered before selection and deployment. A WLAN user's ability to connect to the network depends on the status of the link between the distributed networks and the central site or operating hub. Users will not be able to connect to the network if this link goes down. If the network does go down, rekeying for security purposes will be required for users who are disconnected from the network. The RADIUS/AAA server at the central site must perform the cryptographic computations necessary to set up the secure WLAN connection in addition to its primary function of authenticating users. A performance bottleneck can result if you are managing a large number of WLAN users. This problem can be alleviated by adding RADIUS servers as your WLAN user population grows. This scenario is appropriate for networks connected by very fast, highly reliable links. It also has advantages when it is not practical to replicate the authentication database to each distributed network, such as environments in which you require WLAN users to authenticate through some type of token.

In both the distributed sites and centralized security scenarios, the authentication database is located at the central site or at a network hub. WLAN and/or remote access usage is located at each site, network, or AP cluster, and authentication services are managed by one or more RADIUS servers in an architecture composed of distributed sites, networks, or clusters of APs. The distributed RADIUS server queries the central site for user authentication, sets up the secure connection itself, and if necessary, records accounting data locally or forwards data to the central site. The availability of a central site network is an issue. As with the previous scenario, you are at the mercy of the reliability of the link between the distributed network and the central site or operating hub; however, this presents an additional benefit in that you can distribute the load associated with setting up the secure WLAN connection to the RADIUS servers located on the distributed networks, resulting in better performance and using less bandwidth on the link between the distributed and central sites. As with the previous scenario, this scenario is appropriate for networks that are connected by very fast, highly reliable links. It also has advantages where it is not practical to replicate the authentication database to each satellite network, such as in an environment requiring your WLAN users to authenticate through some type of token.

The architectural scenarios presented in the previous paragraphs can be mixed and matched on the network. In some cases, you may have a more distributed approach to your WLAN deployment where some of your distributed networks may be small, consisting of only a few WLAN users. You may want to forego installing a RADIUS server if those networks are linked reliably to your central site and have your central site RADIUS server handle their authentication and security. There may be other cases where you have one or two remote offices that are not reliably linked to your central network even though you have deployed a centralized authentication and security scheme. When this occurs, you may have to distribute RADIUS servers to those networks even if only a few WLAN users are in that location, in order to protect the integrity and security of the network. A primary benefit of 802.1x in these types of situations is its flexibility.