Protocol Overview

Once the basic concepts underlying AAA have been explained, we can now proceed with a high level overview of the protocol. The following list outlines the basic steps involved in a normal RADIUS conversation:

  1. The users device connects to the NAS, and requests network access.
  2. The NAS turns the request into a RADIUS message, and sends the request to the RADIUS server.
  3. The RADIUS server queries the database for the users authentication credentials, and authorization policy.
  4. The database responds to the RADIUS server with the users credentials, or "unknown user".
  5. The RADIUS server responds to the NAS with an accept,or reject message.
  6. The NAS either disconnects the user, or informs them that they may obtain network access.

The NAS receives the users request for network access, and sends a RADIUS message called an Access-Request to the server. This message contains information about the user, including user name, authentication credentials (e.g. password), and requested service. The NAS may add additional information about itself, such as its host name, MAC address, wireless SSID, etc. The RADIUS server processes this request, queries one or more databases for user information, and usually returns another message, called an Access-Accept. That message that contains policy information which the NAS uses to both provide services to, and enforce the behavior of, the user.

As noted previously, there are a few important considerations in the above description. The first is that RADIUS is a client driven protocol. That is, all conversations in RADIUS are initiated by the client, and all information sent to the server is done solely at the discretion of the client. The RADIUS server does not choose what it receives, and cannot control what is sent by the NAS.

The RADIUS server has no control over what the NAS sends in a RADIUS packet.

That is, when the RADIUS server receives an authentication request from a NAS, the server has to work with the authentication protocol contained inside of that request. The server simply doesn't have any other choice. If the NAS sends a packet with an authentication protocol that the server does not support, the server has little choice but to reject that request in its entirety.

Another important side effect of this behavior is that the RADIUS server does nothing unless it receives a packet from a client. There are many situations where the client may stop communicating with the server. In all cases where this happens, the observed behavior of the server is that it communicates with the client, and then suddenly that communication stops. Again, in all cases, the cause of this break in communication is that the client is failing to continue the RADIUS conversation.

The RADIUS server does nothing unless prompted by the NAS.

The most common problem seen as a result of this limitation is that (for example) administrators configure a RADIUS server to tell the NAS to give the user a particular IP address, but the user does not end up using that IP. The first place to look for solutions is the NAS configuration, and the NAS documentation.

When all goes well in a normal RADIUS conversation, the user is authenticated, the server replies with an Access-Accept, and the NAS gives the user the requested service. If something goes wrong in the RADIUS conversation, other issues come into play. We'll cover those situations a little later in the book.