3.113. <ServerRADSEC> Previous topic Parent topic Child topic Next topic

This clause accepts RadSec (RFC 6614) connections from <AuthBy RADSEC> clauses in other Radiators and processes RADIUS requests sent over the RadSec connection in a similar way to how a Client clause received conventional UDP RADIUS requests. RadSec can be used to provide secure reliable proxying of RADIUS requests from one Radiator to another, even over insecure networks. For more information, see RadSec white paper Opens in new window.
Both <ServerRADSEC> and any <AuthBy RADSEC> clauses that connect to it must have the same Secret configured, otherwise they are not able to exchange RADIUS requests correctly, irrespective of whether any TLS or other configuration parameters are correct.
All valid RADIUS requests received by <ServerRADSEC> are dispatched to the first matching <Realm> or <Handler> clause, in the same was as the <Client> clause. The reply to any incoming request will be automatically delivered back to the original requesting <AuthBy RADSEC> client.
<ServerRADSEC> supports TLS. For more information about TLS parameters, see Section 3.9. TLS configuration.
When UseTLS is enabled, <AuthBy RADSEC> clients always expect to receive a TLS server certificate from <ServerRADSEC>. This means that if you enable UseTLS, you must configure a server certificate, otherwise <AuthBy RADSEC> is not able to establish a TLS encrypted connection to <ServerRADSEC>.
Operators can use a third party free or commercial Certificate Authority to generate private certificates for RadSec clients and servers.
For compliance with RFC 6614, ServerRADSEC defaults to a Secret of 'radsec', Transport of 'tcp', UseTLS enabled, and TLS_RequireClientCert enabled.
When a RadSec client presents a certificate to the RadSec Server, the RadSec server performs a number of checks to validate the client certificate. The client certificate is checked for valid start and end dates, and also checks the chain of validity back to the issuing Certificate Authority, using the root certificates specified in TLS_CAFile or TLS_CAPath. If TLS_PolicyOID parameter is defined, the OIDs must be present in the certificate path. Also a client certificate is only accepted if at least one of the following conditions are true:
  • The IP address of the client exactly matches a subjectAltName with type IPADD (IP Address) in the certificate.
  • The Subject in the certificate matches the pattern specified by the TLS_ExpectedPeerName parameter in this <ServerRADSEC> clause.
  • If TLS_SubjectAltNameURI parameter 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 parameter is defined in the <AuthBy RADSEC> clause, the certificate's fingerprint must match at least one of the TLS_CertificateFingerprint options.
Note that the default TLS_ExpectedPeerName pattern is .+, which matches any Subject. This means than in the default configuration, <ServerRADSEC> accepts any client whose client certificate can be validated against a root certificate specified by TLS_CAFile or TLS_CAPath.
These certificate validation rules are consistent with RFC 2595.