RadSec

RADIUS and Untrusted Networks

RADIUS is the most widely used protocol for exchanging authentication information between network devices and AAA servers. It has been around for decades and being very simple has been adopted very widely in the industry. Now with the increased adoption of remote work and increased mobility of networks, there is an expectation that networks can be setup or accessed from anywhere as long there is some form of internet connection. This means that traffic flows through untrusted networks before reaching perimeter firewalls or cloud based firewalls. While RADIUS has been great for exchanging authentication data within trusted networks, it becomes very insecure when used in untrusted networks.

RADIUS uses MD5 and shared secret to encrypt sensitive attributes like password. However MD5 is old and weak leading to potential vulerabilities similar to the Blast RADIUS vulnerability discovered in early 2024. Apart from weak encryption, RADIUS also exposes other metadata about the autentication request like username, location, wireless SSID name, MAC address of the device etc. These attribute in the RADIUS exchanges are not encrypted and can be read in cleartext by anyone who can capture the RADIUS packets.

Hence there is a need for a more secure way to exchange authentication information.

RadSec: RADIUS in a TLS wrapper

This is where RadSec comes into play. RadSec first establishes a TCP connection between the network access device (NAD) and AAA server over TCP port 2083. This TCP connection uses mutual TLS authentication where both the RadSec client and server present their certificates to each other. Once the certificates have been verified and trust validated, the TLS tunnel is established.

Now with a secure tunnel between the network device and AAA server, all the RADIUS authentication and accounting messages are sent inside the tunnel. This way it is now safe from eavesdropping.

RadSec in ClearPass

For a network device to be able to send authentication requests to ClearPass, it first has to be added to the Network Devices list with the correct shared secret. If you want the device to use RadSec instead of RADIUS, there is a checkbox to enable RadSec. Once RadSec is enabled the shared secret field is greyed out and a RadSec settings tab appears.

The IP or Subnet Address here should be the NAS-IP-Address in RADIUS request. Now within internal networks, the NAS-IP-Address and actual IP address of the network device could be the same. However with RadSec use cases, authentication requests are often NATed and hence there would be the source IP address which would be the NATed IP address of the request and the NAS-IP-Address which is the actual address of the device. By default ClearPass validates both. Hence if there is NAT involved, ensure that the source IP address is entered in the “Source Override IP Address” field as shown below:

By default mutual TLS authentication of the certificates involve both OCSP and CRL checks. There are also additional validations available where you can validate the CN or SAN of the certificate or can check serial number of the issuer certificate.

RadSec Allow All

Typically, it is a good idea to validate both the NAS-IP Address and the source IP of the request so that you know exactly where the request is coming from. However there are scenarios where devices use public internet connections provided by ISPs. The public IP of these devices would keep changing from time to time and as and when these devices move between locations. Hence it becomes difficult to nail down a source IP address. For these situations it is now possible to add 0.0.0.0/0 as source override IP address with ClearPass version > 6.11.7 or 6.12.0.

When using this RadSec Allow All feature, ensure to use additional certificate validations to ensure that only devices with valid trusted RadSec certificates are allowed to connect.

Load Balancing RadSec

RadSec being TCP, it uses long lived TCP connections with both authentication and accounting messages sent within the trusted tunnel. Any standard load balancer can be used to balance the TCP connections. One thing to note is that some RadSec connection could have high rate of authentication requests while others do very less authentication. For example, RadSec connection from a wireless gateway in the corporate building with 1000 employees will have very high volume of authentications compared to a few small branch location with 10 employees each. Load balancers might give equal weightage to these RadSec connections, resulting in skewed load balancing. Another options is to terminate the TLS session at the load balancer and to send the raw RADIUS packets to the AAA servers. Very few commercial load balancers if any support this. RadSec proxy is one open source solution which can be used for terminating RadSec connections.