16. RadSec (RFC 6614) Previous topic Parent topic Child topic Next topic

It is often the case that RADIUS requests need to be sent from one RADIUS server to another. This is called proxying. It is commonly used to send requests to another RADIUS server that is better able to handle the request. In Radiator proxying is usually implemented with the <AuthBy RADIUS> clause.
Conventional UDP based RADIUS proxying is inherently unreliable and insecure. It is unreliable because the UDP protocol does not guarantee delivery, and the RADIUS protocol only requires a limited number of retransmits. Therefore, in an unreliable or congested network, RADIUS packets may be irretrievably lost. Further, conventional RADIUS requests are not encrypted, and most of the attributes (other than the password) in a RADIUS request are in plaintext. This means that eavesdroppers can obtain valuable information from unprotected RADIUS requests.
As a result, RFC 6614 ‘Transport Layer Security (TLS) Encryption for RADIUS’ was created to specify a secure, reliable RADIUS transport. RFC 6614 is based on the original RadSec protocol in Radiator, and the Radiator RadSec implementation is by default compliant with RFC6614.
RFC 6614 RadSec is a communication protocol that provides secure, reliable proxying of RADIUS requests from one Radiator to another. It can be used in place of AuthBy RADIUS when proxying across insecure or unreliable networks.
When using RadSec, one Radiator is designated the RadSec client, and the other is the RadSec server. The RadSec client establishes the connection to the RadSec server, and sends RADIUS requests to the RadSec server over a reliable stream connection. The RadSec server sends any replies to each RADIUS request back to the RadSec client. A RadSec server can accept connections from any number of RadSec clients.
RadSec uses the TCP/IP (or optionally SCTP) stream protocol to transport requests from the RadSec client to the RadSec server and replies from the server to the client. By default, TLS is used to encrypt the requests, and to enforce server authentication with a server PKI certificate (i.e. the RadSec client confirms that it is connected to the RadSec server it expects by checking a server certificate). By default, the Radiator RadSec server requires that clients confirm their identity by requiring a PKI client certificate.

Figure 23. Using RadSec to proxy request from one Radiator to another

For more information about RadSec, including a description of the RadSec protocol, RadSec white paper Opens in new window. See also RFC 6614.