FreeRADIUS

FreeRADIUS logo

Overview

FreeRADIUS is used by SOWN to carry out distributed authentication using the 802.1X protocol through the eduroam network (as a participating organisation within the Janet network). This allows users at all member institutions to gain Internet access through SOWN[at]Home nodes.

Organisations that are part of the eduroam network can choose to be home, visited or both. As SOWN is just trying to provide extended Internet access to users at existing member institutions, we only implement the visited aspect. Therefore, users with a sown.org.uk domain account cannot be authenticated to gain Internet access at other organisations within eduroam.

When an access (authentication) request gets sent from a user's device, through a SOWN[at]Home node, it first goes to SOWN's FreeRADIUS server. It inspects the outer anonymous identity, which has the correct domain but has a generic username (typically the word "anonymous") to work out where to relay the request. At present all requests are forwarded onto Janet's pool of RADIUS servers.

Once an access request reaches one of Janet's RADIUS servers, if the domain in the anonymous identity is that of another UK institution (e.g. university, college, etc.), the RADIUS server will send the request directly onto one of that institution's RADIUS servers. If the domain is for a non-UK institution, this will be relayed via one or more intermediaries. For a European university, this will go via one of GÉANT's RADIUS server and then onto one to the RADIUS servers of the appropriate national university network (e.g. RENATER or DFN) before finally reaching a RADIUS server of the member institution, which can actually carry out the authentication.

Technical Detail

SOWN currently only runs FreeRADIUS on one production server (AUTH-2), which presently runs version 3.0. SOWN FreeRadius' server configuration defines a home server pool for the Janet network, which lists its three RADIUS servers and a type that describes the method of how to choose which home server to send an authentication request.

home_server_pool janet {
    type = load-balance
    home_server = roaming0.ja.net
    home_server = roaming1.ja.net
    home_server = roaming2.ja.net
}

Each of these Janet home servers have their own configuration, including the type (auth for authentication or acct for accounting), IP Address and UDP port as well as a shared secret to ensure secure communication.

Basic home server configuration is generated by Janet, so that each partner organisation has their own unique shared secrets for each of the three servers. SOWN downloaded their personalised configuration (similar to that below) from Janet's eduroam support site, so it could be integrated it into its FreeRADIUS server configuration.

home_server roaming0.ja.net {
    type = auth
    ipaddr = 194.82.174.185
    port = 1812
    secret = [REDACTED]
    response_window = 5
    status_check = status-server
    zombie_period = 10
    num_answers_to_alive = 3
}

The other configuration options provide the following functionality:

  • response_window: The number of seconds after an authentication request before the home server is considered unlikely to respond and an access reject response is sent saying the user could not be authenticated.
  • status_check: How to check if the home server is dead. status-server means that the local server will probe the specified home server for Status-Server packet responses.
  • zombie_period: The number of seconds in which the home server has not responded to any packets before it is considered dead. Prior to this period the home server could be alive or dead (i.e. a zombie).
  • num_answers_to_alive: The number of consecutive responses to Status-Server probes from the local server before the home server is confirmed as being alive.

When an access request reaches this home institution it can unpack this request and see the inner real identity of the requesting user, along with either the password or a hash of the password sent by the user on their device in their authentication request.

How the outer and inner parts of the request are constructed and the encryption used is determined by the protocols set. The most common sets of protocols used are PEAP-MSCHAPv2 and EAP-TLS. Historically, SOWN has been more concerned about ensuring PEAP-MSCHAPv2 works when authenticating to use SOWN[at]Home nodes for Interney access. This was the set of protocols favoured by Microsoft Windows back around 2010. However, EAP-TLS is generally considered a more secure and efficient set of protocols. To complete an authentication request requires numerous steps, (PEAP-MSCHAPv2 has 22 steps, EAP-TLS has 12 steps).

Additional Information

SOWN does however implement its own local authentication so SOWN members can use their accounts to authenticate access to various services it runs to maintain the network. However, more recently (since 2023), SOWN has been moving away from using RADIUS authentication towards Authentik, which makes it easier to integrate with a wide myriad of different authentication mechanisms.

SOWN uses RADIUS accounting as well as authentication to gather data usage statistics for SOWN[at]Home nodes. Using RADIUS accounting packets to update a database table containing each user session. This in turn is converted using RRDtool to produce per node data usage graphs over time.