Using RADIUS For WLAN Authentication, Part I - Page 2

By Lisa Phifer

December 01, 2003

Applying RADIUS to Wireless LANs

In a wireless network that uses 802.1X Port Access Control, the wireless station plays the role of the Remote User and the wireless AP plays the role of the Network Access Server. Instead of connecting to the NAS with a dial-up protocol like PPP, wireless stations associate to the AP using 802.11 protocols.

Once associated, the wireless station sends an EAP-Start message to the AP. The AP requests the station's identity and relays it to an AAA Server inside the RADIUS Access-Request User-Name attribute.

As you may now expect, the AAA Server and wireless station complete the authentication process by relaying RADIUS Access-Challenge and Access-Request messages through the AP. Depending upon the EAP type, messages may be carried inside an encrypted TLS tunnel.

If the AAA Server issues an Access-Accept message, the AP and wireless station complete a handshake to generate session keys used by WEP or TKIP to encrypt data. At that point, the AP unblocks the port and the wireless station can send data and receive data to and from the attached network.

If the AAA Server issues an Access-Reject message, the AP disassociates the station. The failed station can try to authenticate again, but the AP prevents the station from actually sending data through the AP into the adjacent network. Note that the failed station can still listen to data sent by other stations -- that is the nature of a radio network, and why it's important to encrypt data sent over the air.

The Attribute-Value pairs included in RADIUS messages can be used by the AAA Server to deliver session parameters to the AP and wireless station, like Session-Timeout or VLAN tag (Tunnel-Type=VLAN, Tunnel-Private-Group-ID=tag). Exactly what additional information can be delivered and used depends on your AAA Server, AP, and station products.

Implementation Options

Once you understand the role played by RADIUS in WLAN authentication, it's time to start thinking about setting up an AAA server to support this interaction.

  • If you have an AAA server in your network that speaks RADIUS, it may already support 802.1X and your chosen EAP type(s). If so, your next step may be to learn how to configure these features.
  • If you have a RADIUS-capable AAA server that lacks 802.1X support, or does not support the EAP type(s) you've chosen, you can upgrade that server (if new software is available) or you can install a new server. If you install a new AAA Server just for 802.1X authentication, you may want to use RADIUS proxy features to chain your new server to your existing server. This approach lets you reuse your user database without making any significant changes to your existing server. RADIUS proxy can also make sense when the WLAN operator does not own the user database, as in a hotspot that supports roaming users.
  • If you don't have a RADIUS-capable AAA server, you may consider installing a server for WLAN authentication, or contracting with a managed service provider to conduct 802.1X WLAN authentication on your behalf. The latter option is of particular interest to smaller businesses that don't have IT staff to deal with installing and maintaining an AAA Server.

In part two of this tutorial, we'll examine these options in greater detail. We'll look at an in-house AAA example to see what's involved in setting up your own server, and we'll look at a managed service example to see just how that works. We'll also consider the tasks and cash outlays associated with these examples. So stay tuned for part 2, to be published next week.

Pages: 1 2


Comment and Contribute
(Maximum characters: 1200). You have
characters left.