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 (define) 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.
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.
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.