RADIUS
Remote Authentication Dial-In User Service (RADIUS) is a client/server protocol originally designed to give remote users the ability to access services via dial-up connections. (If you don’t know what dial-up is, it is because you are too young. Back in my early days, we did not have always-on broadband or fiber connections to the Internet; we had to use our telephone landlines to dial in to the Internet.) RADIUS was a service used for remote authentication with dial-up network access. Because of its flexibility, over time RADIUS has evolved and been adopted and adapted for other scenarios as well. Today it is a protocol we use with AAA for authentication, authorization, and accounting purposes.
The best way to learn about RADIUS is through an example of its use. Refer to Figure 3-1 as we go through the following example.
)
Figure 3-1 Admin Using SSH to Manage a Router and Router Authenticating the Admin Using RADIUS
On the right side of this figure is a RADIUS server. It is a server that contains a database of usernames and passwords, and it can communicate using the RADIUS protocol. You can implement RADIUS servers with several different options; in this example, we use Cisco Identity Services Engine (ISE). This is the server part of the client/server protocol.
In the middle of the figure is a router. This router is configured to communicate with the RADIUS server using the RADIUS protocol any time authentication needs to be performed. This is the client part of the client/server protocol.
Now focus on the left side of the figure, where you see the administrator of the router. The admin opens the SSH client and makes a connection to the router using SSH (port 22) for management purposes. They then need to provide their username and password to authenticate. When the router receives the username and password, it contacts the RADIUS server by using the RADIUS protocol so that the RADIUS server can determine if the admin is authenticated or not, based on the credentials provided. If the admin provided a username and password listed in the database, the RADIUS server tells the router to grant the admin access. If they did not provide a username and password listed in the database, the RADIUS server tells the router to deny the admin access.
With RADIUS, authentication and authorization happen at the same time. So, when the admin is being authenticated by the RADIUS server, the server can also be configured to tell the client (the router in Figure 3-1) what the user (the admin in Figure 3-1) is allowed and not allowed to do, based on a database of permissions that has been defined on the RADIUS server. For example, in Figure 3-1, once the user authenticates, they may only be authorized to configure, verify, and troubleshoot routing protocols on the router. Or maybe they are authorized to only perform verification tasks and no configuration tasks.
As mentioned earlier, because of its flexibility, RADIUS can be used in many different scenarios. For example, Figure 3-2 shows a wireless user, a wireless access point, and the RADIUS server.
)
Figure 3-2 Wireless User Authenticating to the Wireless Network Using 802.1x, EAP, and RADIUS
For this scenario, the wireless user needs access to the network. When connecting, they provide their username and password to the wireless AP, using 802.1x and Extensible Authentication Protocol (EAP) messages. The wireless AP (RADIUS client) then sends those credentials to the RADIUS server, using the RADIUS protocol. The RADIUS server compares the username and password to those listed in the database. If the username and password are correct, the RADIUS server notifies the wireless AP that the user is authenticated and authorized, and the wireless AP can provide the user access to the network. If the username and password are not correct, the RADIUS server notifies the wireless AP that the user is not authenticated or authorized, and the wireless AP can prevent the user from accessing the network.
In addition to configuring authentication and authorization, you can also configure accounting with RADIUS. This gives you a centralized way of keeping track of who has been authenticated and who has not, when they were authenticated, and when they were not authenticated. This is important from a security standpoint as it gives you the ability to keep track of all successful and unsuccessful authentication and authorization sessions.
RADIUS uses UDP as its transport protocol. Traditionally, UDP port 1645 was used for authentication and authorization, and UDP port 1646 was used for accounting. However, today we typically see UDP port 1812 for authentication and authorization and UDP port 1813 for accounting. Why is this important? Many Cisco devices default to using 1645 and 1646 as the port numbers, but the RADIUS servers default to using 1812 and 1813 as the port numbers. So, when setting up RADIUS on many Cisco devices, you have to change the port numbers on those devices to 1812 and 1813.
If you are interested in reading more about RADIUS, you can check out RFC 2865, which covers authentication and authorization for RADIUS, and RFC 2866, which covers accounting for RADIUS.