By Lisa Phifer

December 15, 2003

In part two of this tutorial, we considered using a managed RADIUS <DEFINE: RADIUS> service to support 802.1X Access Control for Wireless LANs. Here, we conclude our three-part tutorial by illustrating what it takes to configure an in-house RADIUS Server for authenticating wireless users.

Choosing A RADIUS Server Package

It’s important to choose the right flavor of RADIUS Server to meet your business needs. Some RADIUS Servers are general-purpose products that support different kinds of Network Access Servers, while others are narrowly-focused on wireless LANs. Some are simplified for small single-network use, while others are scalable, distributed systems designed for large ISPs and carriers.

For example, Funk Software packages its RADIUS engine in several formats:

•   Odyssey, for corporate WLANs using 802.1X port access control
•   Steel-Belted RADIUS (SBR) Enterprise, for both remote access and WLAN
•   SBR Global Enterprise Edition, for companies with many sites
•   SBR Service Provider Edition, for ISP remote access
•   SBR EAP Expansion Module, adds 802.1X to SBR/SPE
•   SBR Hotspot Edition, for browser-based and 802.1X authentication

If your company already has a RADIUS Server for remote access authentication, you may be able to leverage that Server to add WLAN authentication. Or you might install a new RADIUS Server for WLAN authentication only, with the option to forward Access-Requests from your new server to your existing server.

If you’re starting fresh, then consider whether LAN authentication is all that you’ll need. 802.1X can be used to control access in both wireless and wired LANs, but do you also need to authenticate remote access users — for example, teleworkers and travelers who access your network from the Internet over VPN tunnels? Obviously you don’t have to use the same RADIUS Server for both, but doing so might be more economical.

If you’re a hotspot operator, you probably already use RADIUS to account for subscribers who log into your Web portal. 802.1X rarely appears in hotspots today, but that may change soon. If Microsoft has its way, hotspot operators will run Windows Provisioning System (WPS) on Windows 2003 Servers to configure stations for 802.1X, making login more transparent. T-Mobile is now testing 802.1X with WPS in some of its hotspots, and hopes to roll this upgrade out in 2Q04. Windows XP stations equipped with the WPS patch will be able to use transparent 802.1X login, while others will still authenticate interactively using browsers. Until demand for 802.1X in hotspots is clear, operators may want to sit tight, letting enterprises cut their teeth on 802.1X first.

Also consider whether your RADIUS Server will be supporting access points (APs) at a single site or multiple sites. If multiple sites, consider running RADIUS Servers at each location to distribute load and optimize performance. Those RADIUS Servers may operate independently, but can rely upon a common (replicated) user database — for example, your Windows domain. Alternatively, you could create a hierarchy of RADIUS Servers where site servers relay Access-Requests to a central server, co-located with your user database. A centralized approach can pose performance and reliability concerns, but may be necessary if you can’t replicate your user database to every site.

In-House Server Example: Funk Odyssey

After you’ve selected a RADIUS Server product, it’s time for installation and configuration. Set-up details vary from product to product. For example, most are software installed on off-the-shelf hardware of your choosing, but some are pre-loaded appliances. Some RADIUS Servers are configured largely through text files, while others sport graphical dashboards. Even though these details differ, the tasks that must be completed are fairly consistent:

1.   Get the RADIUS service up and running.
2.   Issue a certificate to your RADIUS Server.
3.   Configure your RADIUS Server to accept selected EAP Types.
4.   Specify criteria used to map station identities to users and groups.
5.   Integrate your RADIUS Server with user databases and other Servers.
6.   Enable communication between your APs and your RADIUS Server.
7.   Launch a few 802.1X sessions to test your RADIUS Server.
8.   Review logs and accounting records to verify that your Server is operational.

To illustrate, let’s take a look at one RADIUS Server focused exclusively on WLAN authentication: Funk Odyssey.

Odyssey Server software must be installed on a PC running Windows XP Pro or Windows 2000. Odyssey must be the only program listening to the RADIUS ports, usually UDP/1812 (authentication) and 1813 (accounting). These ports can be changed but must match those configured into all of your Access Points. Odyssey runs as a service that starts automatically. All configuration changes are made through a Windows MMC snap-in called the Odyssey Server Administrator.

Start by issuing a digital certificate to your Odyssey Server. This server certificate will be used whenever a TLS (SSL) tunnel is launched, letting stations authenticate your Server. If you don’t have a Certificate Authority (CA), certificates can be purchased from a managed PKI service like Verisign or SeqID ProviderTrust. Funk supplies a test certificate generator which can be used to create a server certificate for Odyssey trials but not for production use.

The certificate must be installed in the Server’s Local Computer’s Personal Certificate Store, then is bound to Odyssey using the TLS Settings panel. TLS security parameters can also be configured — for example, choosing acceptable key exchange, encryption, and message integrity algorithms. You must then select one or more EAP Types to be used with 802.1X, defined in priority order. The Server illustrated in Figure 1 will first try to authenticate stations using EAP-TLS. If that fails, it will try EAP-TTLS, then LEAP.

When EAP-TLS is used, the RADIUS Server must know which user certificates to trust. The Server can trust all certificates issued by a given CA, or it can be more selective — for example, trusting only certificates issued to subjects in a specified domain (e.g., anyuser@mycompany.com). But trusting a user certificate is not enough — the Server must map the station’s identity to a user database that determines whether access is allowed. This can be based on part or all of the Subject’s Common Name (CN) or SubjectAltName in the user’s certificate. Because all permitted mappings will be tried when authenticating via EAP-TLS, it is best to minimize selected options.

Next, the RADIUS server must be configured with policies that determine which users and groups are permitted to access the WLAN, along with session parameters like timeout. This step depends upon the EAP Type and user database or external authentication server to be consulted.

For example, Odyssey is optimized to authenticate WLAN users against login names and passwords stored in Windows user databases (i.e., Active Directory or NT Domain). Odyssey policies therefore explicitly allow or deny access by Windows User and Group names known to the Odyssey Server. When using EAP-TLS, these names are presented in user certificates; when using PEAP or EAP-TTLS, they are delivered over TLS tunnels that carry an authentication protocol like MS-CHAPv2. The Server can be configured to handle requests locally or forward them to another domain.

RADIUS Access-Requests that should be forwarded to another domain are relayed to another RADIUS Server. Larger networks may have multiple RADIUS Servers to balance load or serve as stand-bys. Separate RADIUS Servers may be designated to handle Access-Requests from users in different domains — for example, to authenticate roaming users against their home network’s user database.

Requests can also be forwarded it is necessary to consult another kind of user database. For example, Odyssey can be configured to forward requests to a Funk SBR/Enterprise Server to authenticate against records stored in an LDAP directory, SQL or ODBC database, or RSA ACE/Server. Integration with existing user databases and external authentication servers should be considered when choosing your RADIUS Server so that your solution can reach all required data with optimum performance and reliability.

Before you can test your RADIUS Server, it must be configured to communicate with your WLAN’s Access Points. The Server must be given the IP address(es) of every AP and a shared secret used to authenticate communication with that AP.

At the opposite end, each AP must be configured with the RADIUS Server’s domain name or IP address, authentication and accounting port numbers, and the same shared secret. Configuration differs slightly for each AP; Funk offers several Quick Start Guides to illustrate common enterprise APs like the Proxim AP-2000 and Cisco Aironet 340/350/1200. Wireless APs and cards that have been tested with Odyssey are enumerated on Funk’s Website. For best results, use a supported combo, but you may also be able to use an AP or card that’s not yet been tested.

An extra step is needed when Network Address Translation (NAT) exists between the AP and RADIUS Server. For example, your APs may be located on the far side of a wireless gateway that NATs traffic from the wireless LAN. In that case, define static NAT bindings for each AP so that they can be individually authenticated by your RADIUS Server. You may also need to modify gateway or firewall rules so that RADIUS flows between these endpoints.

Stations on your WLAN can launch test sessions to validate your RADIUS Server configuration. To trouble-shoot and diagnose problems, consult the RADIUS Server’s logfile. Traffic analyzers on wireless and wired LAN segments can also prove helpful in determining where messages are being blocked or where 802.1X authentication is failing. Problems may include mismatched IPs/ports/secrets (dropped packets from between the AP and RADIUS Server), Server authentication failure (TLS session rejected), and user authentication failure (802.1X ends with RADIUS Access-Reject). Diagnosing the failure reason may require digging into the RADIUS Server’s log, since much of the exchange is encrypted. A RADIUS test client like the one freely available from IEA Software can also be helpful.

Conclusion

In this article, we’ve illustrated just one RADIUS Server. Product user interfaces and features differ, but we hope this example gives you a feel for what it takes to set up a RADIUS Server for use with 802.1X. To learn more about setting up this and other RADIUS Servers, consult the vendor Web sites listed in part two of this tutorial.

As we have seen, there are many ways to add RADIUS authentication to your WLAN, ranging from managed services to shareware to commercial products, small and large. Acronyms and security jargon make 802.1X port access control somewhat daunting. We hope that this tutorial helps to demystify the role of RADIUS and provides a starting point for using 802.1X to keep wireless intruders away.