Radius Authentication and Logging

Radius is a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. It allows us to store account information on a computer, normally a Unix server running a Radius daemon. Modem servers or terminal servers query the Radius server to authenticate users, and send logs to the Radius server for storage there.

There are two documents which describe the radius protocol from an official standpoint. These are both works in progress. The radius protocol, for authentication purposes, is described in draft-ietf-radius-radius-05.txt, and radius accounting (logging) is described in draft-ietf-radius-accounting-05.txt.

The problem is this: a typical Internet Access Provider has thousands of customers and several modem servers. The modem servers need information about each user, including their password. But keeping all of the modem servers up-to-date is a difficult task to manage. In many cases, the modem server may not even have the capacity to store the thousands of accounts which exist.

The solution is a central database, stored on a computer which has plenty of storage capacity (disk space), which can be queried by the modem servers on an as-needed basis. Radius serves this function.

The Radius Protocol

A radius server stores a database of accounts. Each account has an account name, and is a series of attribute/value pairs. A typical radius account entry looks like the following:

lamer   Password = "isuck",
        User-Service = Login-User,   
        Login-Service = Rlogin,
        Login-Host = varner.com,   
        Ascend-TS-Idle-Limit = 900,
        Ascend-Idle-Limit = 0,  
        Ascend-Preempt-Limit = 0

The name of this account is lamer. The attributes included in this account are Password, User-Service, Login-Service, Login-Host, Ascend-TS-Idle-Limit, Ascend-Idle-Limit, and Ascend-Preempt-Limit. Each of these attributes has a value, as shown above.

Attributes included in each account are either check items or reply items. In standard radius implementations, the check items are those attributes listed in the first line. In the example above, the only check item is the password.

When a radius client (normally a terminal server) submits an authentication request to the radius server, it supplies several attribute/value pairs to the server, relating to the session in question. Of utmost importance is the User-Name, used to find the account. Also, any check items must relate to attributes in the request. In our example, the radius client must send the user's Password as part of the request. The radius server compares it against the Password check item in the radius account entry. If all check items match, a successful response is given.

If all goes well, the radius server sends back a successful authentication response to the radius client. Accompanying that response are all of the reply items in the radius account entry. It is the terminal server's role to interpret these reply items and use them appropriately.