Table of Contents Table of contents: Radiator® AAA Server Interoperation with iPASS Roaming 15 - Interoperation with iPASS Roaming Extensible Authentication Protocol (EAP) 17 - Extensible Authentication Protocol (EAP)

16. RadSec (RFC 6614)

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 24. Using RadSec to proxy request from one Radiator to another

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

16.1. RadSec Certificate Validation

During the establishment of a TLS RadSec connection between a RadSec client and RadSec server, certificate validation is performed in order to confirm that they are connected to the peer they expect to be connected to. This is a brief description of how validation is performed.
If a peer presents a certificate (TLS_RequireClientCert), then it is always validated using the peer certificate issuer's Root Certificate (see Section 3.11.2. TLS_CAFile or Section 3.11.3. TLS_CAPath) and any certificate revocation list (CRL) for the certificate's issuer (see Section 3.11.17. TLS_CRLCheck and Section 3.11.20. TLS_CRLFile). If TLS_PolicyOID is defined, the OIDs must be present in the certificate path. If that is successful, the contents of the peer certificate are checked:
In the RadSec server the client certificate is examined. It is accepted if:
  • The certificate contains a subjectAltName extension of type IPADDR that matches the client's IP address.
  • There were no subjectAltName extensions, but the certificate Subject contains a Common Name (CN) that matches the client's IP address.
  • The certificate Subject matches the TLS_ExpectedPeerName pattern.
and:
  • If TLS_SubjectAltNameURI is defined in the <ServerRADSEC> clause, the certificate must contain a subjectAltName of type URI that matches the TLS_SubjectAltNameURI regular expression.
  • If TLS_CertificateFingerprint is defined in the <ServerRADSEC> clause, the certificate's fingerprint must match at least one of the TLS_CertificateFingerprint options.
In the RadSec client, the server certificate is examined. It is accepted if:
  • The certificate contains a subjectAltName extension of type IPADDR or DNS that matches the Host name used to connect to the server. If TLS_SubjectAltNameDNS is set, use its value to match type DNS.
  • There were no subjectAltName extensions, but the certificate Subject contains a Common Name (CN) that matches the Host name used to connect to the server.
  • The certificate Subject matches the TLS_ExpectedPeerName pattern.
and:
  • If TLS_SubjectAltNameURI is defined in the <AuthBy RADSEC> clause, the certificate must contain a subjectAltName of type URI that matches the TLS_SubjectAltNameURI regular expression.
  • If TLS_CertificateFingerprint is defined in the <AuthBy RADSEC> clause, the certificate's fingerprint must match at least one of the TLS_CertificateFingerprint options.
  • TLS_SRVName check passes, usually applicable to <AuthBy RADSEC> utilised by <AuthBy DNSROAM>.
Table of Contents Table of contents: Radiator® AAA Server Interoperation with iPASS Roaming 15 - Interoperation with iPASS Roaming Extensible Authentication Protocol (EAP) 17 - Extensible Authentication Protocol (EAP)