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
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.
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.