RADIUS Authentication Process
RADIUS supports a variety of methods for authenticating users, in part, because it is an open protocol. A RADIUS server can authenticate a user based on its own internal username or password list, or it can act as a client to authenticate the user based on various other authentication systems, such as a Windows NT domain controller. The method used, of course, depends on a specific vendor’s implementation of RADIUS. Typically, a user login is queried from the network access server to the RADIUS server and a response is sent from the RADIUS server. The user login consists of what is commonly referred to as an Access−Request, and the server response is commonly referred to as an Access−Accept or an Access−Reject. The Access−Request packet contains the username, encrypted password, IP address, and port. After the RADIUS server receives the Access−Request packet, it begins to query its database for a matching username and password pair. If it cannot find a match, the server sends an Access−Reject packet back to the network access server. If it finds a match, the server sends an Access−Accept packet back to the network access server. This is detailed in Figure 2.6.
Figure 2.6: RADIUS authentication process.
Note There is a third response a RADIUS server can use: Access−Challenge. A challenge packet sent from the RADIUS server simply asks the network access
server to gather additional data from the client. Challenge packets are typically sent during an established session.
RADIUS Authorization Process
As mentioned earlier, RADIUS combines authentication and authorization. But to a small degree, they are separate. The RADIUS authentication process must be complete before the authorization process can begin. After the RADIUS server has found within its database a matching pair for the credentials that were supplied to it from the network access server during the authentication phase, the RADIUS server returns an Access−Accept response to the network access server. It is at this point that the RADIUS server bundles within the Access−Accept packet a list of attribute−value pairs that determine the parameters to be used for this session. (Refer to Figure 2.6 earlier in this chapter.)
RADIUS Accounting Process
The network access server and RADIUS server communicate accounting information between one another on UDP port 1646. It is the network access server’s responsibility to send accounting information to the RADIUS server after initial authentication and authorization is complete, and it does so by sending an Accounting−Request packet to the server. This is considered the Accounting−Start packet. Because RADIUS implements services using the UDP protocol (which is
connectionless oriented), the RADIUS server has the responsibility of acknowledging the Accounting−Request packet with an Accounting−Response packet. When the session is complete, the network access server sends another Accounting−Request packet to the RADIUS security server, detailing the delivered service. This is considered the Accounting−Stop packet. Finally, the RADIUS security server sends an Accounting−Response packet back to the network access server, acknowledging the receipt of the stop packet. This is detailed in Figure 2.7.
Figure 2.7: RADIUS accounting process.