6.2 RADIUS

The RADIUS protocol was originally developed for use with dial-up networks. While it is still primarily used to authenticate dial-up accounts, it has become a popular tool for authenticating other network devices. This growth makes sense, as many administrators do not like the idea of maintaining one AAA server for routers and switches, and another for dial-in users.

RADIUS operates on Port 1812, over UDP transport, and is specified in RFC 2865. The original RADIUS protocol included support for the Point-to-Point Protocol (PPP) and Unix logins; vendors have incorporated support for other types of logins to their versions of RADIUS.

RADIUS authentication is handled through shared secret keys sent over clear text packets; however, passwords are encrypted using MD5. Because RADIUS packets are sent using UDP, there are several fail-safe mechanisms included to help ensure data reaches its intended destination. A RADIUS client can either be set up to resend transmissions at predefined intervals, until a response is received, or it can be set to failover to a second or third RADIUS server in the event of a failure.

Figure 6.3 outlines the process for a successful RADIUS authentication. The router has software, known as a RADIUS client, which interacts with the RADIUS server when it attempts to authenticate a user . The RADIUS server may forward the request to another RADIUS server, or query a Lightweight Directory Access Protocol (LDAP) server to authenticate the information. In cases where the RADIUS server authenticates against another, the RADIUS server acts like the client and forwards the authentication request in an encrypted format.

Figure 6.3. The RADIUS authentication process

If it is supported, the RADIUS server may issue an additional challenge-response request from the authentication user. If that is the case, the RADIUS server will issue an "access-challenge" request to the client, which in turn passes it on to the user. The user should reply with an appropriate response to the challenge.

If the RADIUS server is unable to locate the user, or the passwords do not match, the RADIUS server issues an access-reject, along with an error message, to the client, which passes it on to the end user. After the access-reject message is sent, it is discarded.

Because RADIUS transactions are performed across UDP, there is no confirmation between the client and the server that a successful request has been made until the server responds to the client. In order to solve this problem an access-request packet accompanies each request to a RADIUS server. The access-request contains the username and password of the user, as well as the client ID and client port the user is trying to access. The client keeps this information as well and begins counting down. If a response is not received from the RADIUS server within a certain amount of time, the client will either resend the request, or try a secondary RADIUS server ”depending on how the RADIUS administrator has configured the client.

The ability to attempt to authenticate logins multiple times against the same server or against multiple RADIUS servers helps to make it a robust protocol that is very resilient in the face of network problems. In fact, RADIUS has to be resilient because its primary use is in dial-up networks. Earthlink, MSN, and AT&T all use RADIUS authentication for their dial-up networks. They have millions of users dialing into their networks simultaneously ; if RADIUS were not robust, these providers would experience frequent outages.

6.2.1 RADIUS Security

In March 2002 a security alert was released by CERT detailing two buffer overflow vulnerabilities in most vendor implementations of RADIUS. The first was within the calculation of the MD5 encryption used to secure the authentication process. The second had to do with vendor-specific implementations of RADIUS.

The first vulnerability involved the MD5 encryption. The RADIUS client encrypts the shared secret key without taking into account the size of the RADIUS server buffer. If a large amount of data is sent in this manner, it could cause a buffer overflow, crashing the RADIUS server. This problem is more serious if an attacker actually has access to the shared secret, because at that point the attacker may be able to overflow the buffer and execute a command on the RADIUS server.

The second vulnerability has to do with vendor-specific information. RADIUS allows vendor- or user-specific information to be included in the packets sent between the RADIUS client and server. Some vendors did not enable proper data validation within their implementation of RADIUS. If an attacker were to populate vendor-specific fields, within the packet with a negative value (in this case, any value with a length less than two), it would have the same effect as a DoS attack, rendering the RADIUS server unusable.

The first step in securing RADIUS servers is to ensure that the server has the latest vendor-specific patches. As with anything else in the network, it is important to be aware of any RADIUS vulnerabilities and ensure that the RADIUS vendor is releasing timely patches.

Most RADIUS software will allow you to limit which servers can authenticate against the RADIUS server. This feature should be enabled in order to prevent wayward RADIUS clients from attempting to launch DoS attacks against a RADIUS server and to prevent other RADIUS clients from trying password attacks.

Most RADIUS solutions do a good job of logging information. It is important to log as much data as possible, including IP addresses and phone numbers , if the RADIUS server is being used to handle dial-up connections. In addition to access information, password failures are important to log, and many administrators will disable an account ”even temporarily ”after three failed attempts to log into the network.

Password protection is also important when dealing with RADIUS servers. If you rely on localized RADIUS authentication, then force users to adhere to the same password policies that are enforced throughout the company. However, it is worth exploring using RADIUS to authenticate against the existing username and password database (Figure 6.4).

Figure 6.4. Bob and Alice are directed to their respective servers for authentication based on the information in their domain

Figure 6.4 shows how a network might be set up to take advantage of an existing username and password database. Some RADIUS products, including Funk Software's Steel-Belted RADIUS and Nortel's Shiva Access Manager, have support for separating users into domains. In our example, Bob is part of the Marketing department, and Alice is part of the IT department. Both connect to the Network Access Server (NAS), which acts as the client, forwarding the authentication request to the RADIUS server. In this case, the username includes not only the login name , but also the domain of the user. The domain tells the RADIUS server where to forward the request. In Bob's case, the domain is marketing, so Bob authenticates to the RADIUS server as bob@marketing. Alice is in the IT department and is part of the IT domain. She connects with the login string Alice@it and is forwarded to a different server for authentication.

The advantage to this type of setup is that a user only needs one username and password to log into the network locally and remotely. This is also a disadvantage , because now an attacker only needs one password to successfully find a way into the network.

This type of access will be discussed in detail in Chapter 7.