radsecproxy

This section describes how to set up radsecproxy to act as a federation-level RADIUS and RADIUS/TLS server. It can then completely replace other RADIUS server products on the federation level.

More precisely, it will enable a server to:

• Accept requests from connected service providers via RADIUS and RADIUS/TLS.
• Forward requests to connected identity providers via RADIUS and RADIUS/TLS.
• Forward requests from international visitors to the European eduroam confederation root servers via RADIUS/TLS.
• Accept requests from the root servers via RADIUS/TLS for the own federation's users when they are roaming in another federation.

Version information

The prerequisites for this deployment are:

• radsecproxy version 1.6 or higher
• A server certificate and a private key for that certificate to establish the RADIUS/TLS connection which designates the server as an IdP+SP.

./configure
make
make check
make install

radsecproxy

/etc/radsecproxy.conf

Sample config file

Most of the radsecproxy configuration file is static. This walk-through goes through the template radsecproxy.conf line by line and explains the meaning of each stanza.

ListenUDP                 *:1812
ListenTCP                 *:2083

radsecproxy will receive requests from all connected Service Providers via both RADIUS and RadSec. Therefore it has to listen on the appropriate ports on its network interfaces (the * meaning: all interfaces). If you want radsecproxy to listen only on specific interfaces, enter the interface names here. Beware: in this case you may also have to set the more exotic options SourceUDP and/or SourceTCP (see the man page of radsecproxy for details).

LogLevel                3
LogDestination          x-syslog:///LOG_LOCAL0

LoopPrevention         On

FTicksReporting Full
FTicksMAC VendorKeyHashed
FTicksKey arandomsalt

# radsecproxy

if      ($programname == 'radsecproxy') and ($msg contains 'F-TICKS') \
then    @192.0.2.204
&       ~

tls defaultClient {
    CACertificatePath                   /etc/radsecproxy/certs/ca/
    CertificateFile                     /etc/radsecproxy/certs/CERT_PEM__
    CertificateKeyFile                  /etc/radsecproxy/certs/CERT_KEY__
    CertificateKeyPassword              __CERT_PASS__
    policyOID                           1.3.6.1.4.1.25178.3.1.1
#    CRLCheck                            On
}

tls defaultServer {
    CACertificatePath                   /etc/radsecproxy/certs/ca/
    CertificateFile                     /etc/radsecproxy/certs/CERT_PEM__
    CertificateKeyFile                  /etc/radsecproxy/certs/CERT_KEY__
    CertificateKeyPassword              __CERT_PASS__
    policyOID                           1.3.6.1.4.1.25178.3.1.2
#    CRLCheck                            On
}

rewrite defaultClient {
     removeAttribute                       64
     removeAttribute                       65
     removeAttribute                       81
}

Client definition

client 127.0.0.1 {
        type     udp
        secret   testing123
}

client ::1 {
        type     udp
        secret   testing123
}

There is no other RADIUS server running on localhost, which makes these client definitions almost superfluous. They may be of some use however to initiate debugging requests and tests from the server itself, so it is considered good practice to list localhost as a client. If your system is not IPv6-enabled, simply delete the second stanza.

client __SP_IP_ADDR__ {
        type     udp
        secret   __SP_SECRET__
        FTicksVISCOUNTRY XZ 		# will generate F-Ticks for a non-existant visited country
 }

Stanzas like this one are used for each connected service provider that is connected via RADIUS. You need to know the IP address of every SP's RADIUS server and negotiate a shared secret with the SP

Please note that the client and server stanza for the GEANT Monitoring (SA3-T2 activity) have the same host address, but different stanza names. This is important: it disables the LoopDetection for this host, and the SA3 monitoring deliberate uses loops to do its tests. The following stanza is the eduroam Service Activity's monitoring client. Negotiate the IP address and shared secret for European monitoring with the operators in SA3-T2 (eduroam Operational Team) and enter it here.

client SA3-monitoring-incoming {
         host            x.y.z.a
         type            UDP
         secret          __MONITORING_SECRET__
}

.

client incoming {
        host                              0.0.0.0/0
        host                              [::]/0
        type                              TLS
        tls                               defaultClient
        secret                            radsec
}

After all specific clients in the configuration, you can the above stanza as a "catch-all" for incoming RADIUS/TLS connections.It does not need to be modified (if you do not support IPv6, you can delete the second "host" line though). In particular, the string "radsec" for secret is fixed by the RADIUS/TLS protocol and is required to remain unchanged. It also has no effect; RADIUS/TLS depends on TLS security rather than the shared RADIUS secret.

The eduroam trust model requires that a SP that tries to connect has:

• A X.509 certificate from an eduroam-accredited CA
• which carries a Policy OID as configured above to prove authorisation as a eduroam Service Provider

These checks were defined via "tls defaultClient", above.

Request forwarding

To deliver requests to your connected IdPs, their servers need to be configured. This stanza is for IdP servers using RADIUS.

server __DESCRIPTIVE_NAME_ {
          host     __IP_ADDR__
          type     UDP
          secret   __SERVER_SECRET__
}

This is the equivalent stanza for IdP servers using RADIUS/TLS.

server __RADSEC_PEER_DNS_NAME_ {
          type         TLS
          tls          defaultServer
          secret       radsec
          statusserver on
}

The two following stanzas define the uplink to the European eduroam Confederation root servers. This entry can be kept as it stands and doesn't need any further configuration.

server etlr1.eduroam.org {
          type                  TLS
          tls                   defaultServer
          secret                radsec
          statusserver          on
}

server etlr2.eduroam.org {
          type                  TLS
          tls                   defaultServer
          secret                radsec
          statusserver          on
}

European monitoring works both ways. The client entry near the beginning of the configuration file was needed for incoming requests from the monitoring servers. The entry below specifies the outgoing connections to the monitoring server. Outgoing connections are currently monitored with RADIUS only. Use the negotiated IP address and shared secret with SA3-T2 Monitoring in the following stanza:

server SA3-monitoring-outgoing {
          host                  a.b.c.d
          type                  UDP
          secret                __MONITORING_SECRET__
}

After defining the server configurations, we need to define which RADIUS realms are going to be forwarded to which server(s). This is done in the remainder of the configuration file.

First, there are (very few) known-bad realms which are not forwarded at all. They should ideally never reach the FLR server, and be caught by the SP local RADIUS server, but as an extra safety measure they are filtered (i.e. immediately rejected) here:

realm /myabc\.com$/ {
          replymessage "Misconfigured client: default realm of Intel PRO/Wireless supplicant! Rejected by <TLD>."
          accountingresponse on
}

realm /@.*3gppnetwork\.org$/ {
		  replymessage "Misconfigured client: Unsupported 3G EAP-SIM client!"
		  accountingresponse on
}

realm /^$/ {
          replymessage "Misconfigured client: empty realm! Rejected by <TLD>."
          accountingresponse on
}

Note: if you need to blacklist an existing realm for some reason, you can follow the myabc.com example, copying and replacing it with the realm to be blacklisted.

Requests for proper realms that are coming in from upstream and are supposed to be handled by an identity provider are listed in stanzas like the below. _IDP_REALM_ contains the realm of the connected IdP. Create one such stanza for each IdP realm. If an IdP has multiple servers for a failover configuration, you can list all servers in a row, as in the example below.

realm /IDP_REALM$/ {
              server         __FROM_SERVER_STANZAS_ABOVE__
              server         __BACKUP_NAME__
}

The configuration stanza below is for outgoing European monitoring connections.

realm /eduroam\.YOUR_TLD/ {
              server         SA3-monitoring-outgoing
}

All the valid realms were listed earlier in the configuration file, and this server is authoritative for the own TLD. If a supplicant or downstream servers sends a realm with the own TLD, but also with a realm name that is not registered, this request is unauthorised and bound to fail. It will be rejected immediately to prevent routing loops.

realm /\.YOUR_TLD$/ {
              replymessage "Misconfigured supplicant or downstream server: uses known-bad realm in <TLD> federation!"
}

Finally, all realms that do not belong to the own federation are forwarded to the European eduroam Confederation root servers. However, we limit this to 'sane' realms: these must include a tld of at least 2 characters. Anything else is dropped.

realm /@.+\..{2,}$/ {
              server           etlr1.eduroam.org
              server           etlr2.eduroam.org
}

realm * {
			  replymessage "Misconfigured client: username does not contain a valid realm!"
}

Goodies

This section contains some optional configuration parameters that can do good in many cases.

Keeping the config file at a manageable size

radsecproxy allows to split the configuration file into several files on disk and include the parts into the main configuration file. This is very practical when many sites have to be managed. You can create a subdir and put the client, server, realm parts together in one file per participant. By adding

include /etc/radsecproxy.conf.d/*.conf

into the main config file, you can put all the participant files into that directory.

Caveats

RADIUS/TLS: Obtaining and managing certificates

RADIUS over TLS is a new way of interconnecting federations (and later, if desired, eduroam IdPs and eduroam SPs). It uses TLS encryption instead of IP address and shared secret pairs to authenticate and authorise eduroam servers. When replacing such explicit configuration-based authorisation with a dynamic, automatic provisioning model, it is important to clearly define the rules for issuance of an eduroam server certificate, because the possession of the certificate will enable the holder to participate in eduroam.

In order to make use of this new feature, your FLR server must have acquired an eduroam server certificate. Depending on which federation or world region you are from, the procedures for getting a certificate will differ. The following two subsections are a globally valid description of the eduroam Trust Model. This trust model is currently only implemented by one CA, which operates in Europe. The last subsection provides details for European eduroam participants.

The eduroam server certificate trust model: eduPKI PMA and the eduroam Trust Profile

During the design of the X.509 trust model for eduroam, certain requirements had to be considered.

• It became clear that no single one Certificate Authority (CA) can or should issue all eduroam certificates world-wide. Instead, rules were defined under which multiple CAs can issue eduroam certificates.

• These CAs could possibly be general-purpose CAs that also manage certificates for other services besides eduroam. Consequently, the eduroam trust model had to allow to differentiate eduroam server certificates from other certificates from the same CA in a standardised manner.
• A CA would need to conform to certain quality assurance criteria, which need to be assessed by an oversight committee.

As a result of these requirements, the GEANT project's eduPKI task created a framework for the eduroam trust model:

• an oversight body, the "eduPKI Policy Management Authority" (eduPKI-PMA) was created and produced a document with defined Quality Assurance criteria for CAs which would like to become part of the eduroam trust model. The rules for CA accreditation are set forth in section "CA Accrediation Process" at https://www.edupki.org/edupki-pma/pma-governing-documents/. Note that eduPKI PMA is currently the only PMA, but this doesn't preclude other PMAs in other world regions from emerging.
• a X.509 trust profile for the eduroam service was created, which designates two so-called "policy OID" fields to eduroam IdP and SP servers. The trust profile can be found on this page: https://www.edupki.org/edupki-pma/edupki-trust-profiles/
• this trust profile requires that CAs which use this policy OID will check the authorisation of a certificate applicant whether or not he is actually an eduroam IdP and/or SP server operator.

This way, it can be assured that only authorised eduroam operators get eduroam certificates and can establish connections to other eduroam servers.

Managing accredited CAs in eduroam servers

As at May 2020, this section may be outdated. The TACAR list of eduPKI eduroam certificates does not include the eduPKI CA certificate described below and does include a certificate that is not widely accepted. There are planned changes that may result in this process being entirely revised. However, in the mean time, use of TACAR will lead to FetchCRL3 errors and including the eduPKI CA certificate manually is required for a functioning eduroam RadSec implementation.

The number of accredited CAs and the list of certificates can change at any time. It is important that all eduroam servers consult an up-to-date list of accredited CAs. The list of currently accredited CAs is maintained in a TERENA repository of the TACAR service. A browsable list can be found here: https://www.tacar.org/cert/list/

Please refrain from manually downloading CAs as a one-time action. Otherwise, your CA list will eventually become outdated and this will create service disruption for some eduroam users!

There is currently one accredited Certification Authority: the eduPKI CA, located at https://www.edupki.org/edupki-ca/ . eduPKI CA acts as a catch-all world-wide for eduroam participant countries which do not have their own accredited CA for the eduroam service. Such further CAs are welcome to apply for eduPKI PMA accreditation.

eduroam operators should request their eduPKI CA eduroam certificate by following the instructions on the eduPKI CA eduroam RA pages at: http://www.eduroam.org/index.php?p=europe&s=edupki

Updating CRLs on your server

Since certificate possibly need to be revoked in case of private key compromise or other reasons, it is important that all RADIUS servers which validate eduroam-accredited CAs consult an up-to-date CRL list for each of the CAs. eduroam suggests to use the script "FetchCRL3" which was developed in the Grid community for this very purpose (download here).

Usage:

• place the .info files of all accredited CAs into one otherwise empty directory ( download edupki.info ) - let's assume for this example that the path to those files is
  

  /path/to/certificates/

• find out the command which restarts your RADIUS server on your system - let's assume for this example that the command is
  

  systemctl restart radiusd.service

• The following command will attempt to fetch an up-to-date CRL for the CA, and only if successful, will restart your server:

  fetch-crl -l /path/to/certificates/ && systemctl restart radiusd.service
  
  

• This script should be executed in a cron job on a regular basis (we suggest daily).