RealTime IT News

Using RADIUS For WLAN Authentication, Part I

As described in my last primer, WLAN security can be significantly strengthened by using 802.1X to control access point (AP) "port" access and deliver dynamic keys to authenticated users. Authentication Servers based on the RADIUS protocol play a key role in 802.1X. In part one of this tutorial, we take a closer look at how RADIUS works to better understand what's required from your RADIUS Server to support WLAN authentication.

Authentication, Authorization, and Accounting

The Remote Authentication Dial In User Service (RADIUS) protocol (RFC 2865) was originally defined to enable centralized authentication, authorization, and access control (AAA) for SLIP and PPP dial-up sessions -- like those made to a dial-up ISP. Instead of requiring every Network Access Server (NAS) to maintain a list of authorized usernames and passwords, RADIUS Access-Requests were forwarded to an Authentication Server, commonly referred to as an AAA Server (AAA stands for authentication, authorization, and accounting). This architecture (illustrated here) made it possible to create a central user database, consolidating decision-making at a single point, while allowing calls to be supported by a large, physically distributed set of NASs.

When a user connects, the NAS sends a RADIUS Access-Request message to the AAA Server, relaying information like the user's name and password, type of connection (port), NAS identity, and a message Authenticator.

Upon receipt, the AAA Server uses the packet source, NAS identity, and Authenticator to determine whether the NAS is permitted to send requests. If so, the AAA Server tries to find the user's name in its database. It then applies the password and perhaps other attributes carried in the Access-Request to decide whether access should be granted to this user.

Depending upon the authentication method being used, the AAA Server may return a RADIUS Access-Challenge message that carries a random number. The NAS relays the challenge to the remote user (for example, using CHAP). The user must respond with the correct value to prove its asserted identity (for example, encrypting the challenge with its password), which the NAS relays to the AAA Server inside another RADIUS Access-Request message.

If the AAA Server is satisfied that the user is authentic and authorized to use the requested service, it returns a RADIUS Access-Accept message. If not, the AAA Server returns a RADIUS Access-Reject message and the NAS disconnects the user.

When an Access-Accept message is received and RADIUS Accounting is enabled, the NAS sends a RADIUS Accounting-Request (Start) message to the AAA Server. The Server adds an accounting record to its log and acknowledges the request, whereupon the NAS activates the user's session. At the end of the session, a similar RADIUS Accounting-Request (Stop) message is exchanged so that accounting records will reflect the actual session duration and disconnect reason.

Security and Extensibility

All of these RADIUS messages are carried by UDP datagrams which consist of a message type, sequence number, length, Authenticator, and series of Attribute-Value pairs.

Authenticator: The purpose of the Authenticator is to provide a modest bit of security. The NAS and AAA Server use the Authenticator to demonstrate that both know the same secret password. The Authenticator also helps the NAS detect forgery of RADIUS responses. Finally, the Authenticator is used to obscure the user's password, inhibiting disclosure to the NAS or anyone else who might eavesdrop on the RADIUS messages.

The Authenticator sent in the Access-Request is a random number. An MD5 hash of this random number is exclusive OR'ed with the user's password and sent in the Access-Request User-Password attribute. All RADIUS response messages thereafter carry an MD5 hash of the shared secret, the request Authenticator, and other response values.

The Authenticator helps to deter passive eavesdropping, but an attacker who captures both RADIUS Access-Request and Access-Response messages can perform a dictionary attack to learn the shared secret. For this reason, it is best to use long random shared secrets and (when possible) use a secure medium to relay RADIUS protocol. Known vulnerabilities and usage guidelines to reduce risk are documented in RFC 3580.

Attribute-Value Pairs: Information carried by RADIUS is represented in the form of Attribute-Value pairs to facilitate extension to support a wide variety of access technologies and authentication methods. The original standard defined several common Attribute-Value pairs, including User-Name, User-Password, NAS-IP-Address, NAS-Port, and Service-Type. Vendors can also define new Attribute-Value pairs to carry vendor-specific extensions -- for example, RFC 2548 defines Microsoft Attribute-Value pairs associated with MS-CHAP.

In addition, many standard Attribute-Value pairs were defined several years ago to support the Extensible Authentication Protocol (EAP), an alternative to the older PAP and CHAP dial-up protocols. See RFC 3579 for the latest version of RADIUS support for EAP. This is of particular interest for WLAN authentication, since EAP is used by the 802.1X Port Access Control framework to carry out wireless station authentication.