University of Cambridge RADIUS infrastructure

The University of Cambridge Computing Service operates a RADIUS infrastructure for the purpose of authenticating, authorising and accounting network access requests. This service is federated with the national JANET Roaming service which is, in turn, linked to the international eduroam federation. Access to the RADIUS service is available to University and College institutions running their own internal RADIUS proxies and servers.

This page explains the RADIUS infrastructure, how it interfaces with other systems (within the University Computing Service, to university institutions and outside the university) and how it can be used by institutions to control network access. A degree of familiarity with RADIUS and associated protocols (e.g. EAP) is required to understand some of the information explained here.

Contents

• Architecture
• Network Access Tokens database
• Clients
  • Terms of access for the RADIUS service
• Servers
• Outer-identity rewriting

Architecture

The RADIUS service is provided by a pair of servers running the FreeRADIUS open-source RADIUS server software. These servers perform three main functions:

• Authenticate and Authorise access for local Cambridge users from both local and remote locations (e.g. from another eduroam-enabled site) against the Network Access Tokens database.
• Proxy authorisation and accounting requests to other RADIUS servers, both inside and outside the university network, for remote users visiting the university (or users from institutions within the university with their own authentication database).
• Accounting to track and trace usage.

To perform these functions, the RADIUS servers maintain relationships with other RADIUS-capable devices:

• Clients from inside and outside the university send messages to the servers to request that a connection is authenticated, authorised or accounted; these may be handled locally (for @cam.ac.uk usernames) or proxied on to other servers.
• Servers handle requests for authentication, authorisation or accounting from the UCS servers on behalf of clients for remote users (usernames NOT @cam.ac.uk - either institutions within the university [@inst.cam.ac.uk] or outside the university) to the eduroam network.

The following diagram illustrates how the Computing Service RADIUS infrastructure interfaces to other systems:

(click on image for larger version)

RADIUS has inherent redundancy when multiple servers are configured: a RADIUS client, such as an institutional RADIUS server or wireless access point, will automatically detect failed upstream RADIUS servers and resend the request to the remaining available server(s). Periodically, the client will retest the connection to the server, and reestablish it when it become available again.

Network Access Tokens database

To provide the backend authentication and authorisation for @cam.ac.uk usernames, a pair of servers hold the Network Access Tokens database. Accounts for users are automatically created upon their first visit to the network authentication token website, which is protected by Raven; there is no need to explicitly apply for a separate account.

The database itself is only accessible to the UCS RADIUS servers; these take requests from RADIUS clients (as described here) to authenticate user access. Direct access to the database from other services is not permitted.

Clients

Any institution wishing to make use of the RADIUS service to provide access for local (university) or external users must run its own RADIUS servers, which will proxy authentication, authorisation and accounting messages from their own access points and network switches up to the UCS servers.

The institution should contact UCS Network Support with the hostnames and IP addresses of their internal RADIUS servers (which can be on public or CUDN-wide private IP addresses). A maximum of three RADIUS servers can be nominated per institution.

The UCS will then allocate a unique shared secret passphrase for each server-client pair (so, with three institutional RADIUS servers and two UCS RADIUS servers, there will be a total of six shared secrets) and these will be returned to the institution. In addition, the UCS servers will be configured to accept requests from the IP addresses supplied.

The authentication and authorisation requests will need to be configured to talk to radius0.csx.cam.ac.uk (131.111.1.70) and radius1.csx.cam.ac.uk (131.111.1.71) on UDP port 1812. The accounting requests talk to UDP port 1813 on the same two servers. Institutional firewalls must be configured to permit the outbound traffic and responses.

Theoretically, an institutional wireless controller or access point could be configured as a direct client of the UCS service. However, this is discouraged for a number of reasons:

• the institution will need to perform accounting for connections made into their network to avoid the UCS needing to trace accesses within the institution (however, accounting messages for accesses using accounts authenticated against or via the UCS RADIUS servers should still be proxied);
• local authorisation decisions (e.g. based on ESSID, interface number, etc.) cannot be handled by the UCS RADIUS servers;
• in the future, it is likely there will be a need to amend the RADIUS requests before passing them on to the UCS servers;
• the institution is likely to need to return custom attributes such as 'user VLAN' to the network access server; this is especially the case for wired 802.1X connections;
• RADIUS is a complex protocol and it is necessary to have a degree of local debugging (possibly with test account provision) to determine the request sent to the UCS servers, rather than require the UCS to resolve issues with local access points or other servers.

Terms of access to the RADIUS service

The RADIUS service is provided exclusively for the purpose of network access: the service (both local @cam.ac.uk and eduroam accounts) must not be used as a general authentication service for services such as email, filestore, websites, etc.. In particular, this service must not be used to protect any personal information.

Institutions must not interfere with the authentication protocols themselves; they must not perform activites such as local EAP termination.

In addition, if the use of this service is for the local provision of university or external services (e.g. eduroam), the terms of use of those services must be adhered to.

Any violations of these rules are likely to result in client (and server) relationships between the UCS and institutional RADIUS servers being terminated. If in doubt, an institution should consult Network Support before using the service to provide any particular facility.

Servers

An institution only needs to be configured as a RADIUS server, with the UCS servers as clients, if it wishes to authenticate users itself against a local authentication database. Ordinarily, there is no need to do this as the UCS's Network Access Tokens database can provide authentication for users within the university who have a Raven account; if authorisation decisions need to made against the username, the user's identity is made available in the outer-identity upon successful authentication.

If an institution wishes for this to be configured, they should contact Network Support with the IP addresses and hostnames of their RADIUS servers (up to a maximum of three, including any clients already allocated) and their desired RADIUS realm which is to follow the '@' sign in usernames. This realm must correspond to a DNS domain name to which the institution is entitled, as allocated by the UCS's Institution Strategy team.

The UCS will then supply a set of shared secret passphrases for each server-client pair (which will be the same as the corresponding ones for RADIUS client access to the UCS servers) and the UCS servers will be configured to forward all requests for that institution (ending in @inst.cam.ac.uk by their outer-identity) to the institutional RADIUS servers.

If the institution wishes their realm to be connected into the JANET Roaming/eduroam hierarchy, this should be stated in the request and the UCS will contact JANET Roaming Support to set up the appropriate forwarding. It should be noted that, unlike DNS domains, there is at present no automatic forwarding of subdomains to the university servers and there is a manual overhead with each additional realm.

Outer-identity rewriting

It is important to understand, when proxying RADIUS authentication and authorisation messages using EAP (used for network authentication using 802.1X over both wired and wireless connections), that requests typically have two usernames: the inner-identity and outer-identity:

• The inner-identity is the connecting user's real username and is usually protected using SSL such that it can only be read by the user's home site RADIUS servers. The UCS RADIUS servers are the home site servers for @cam.ac.uk usernames.
• The outer-identity is the public username that the connecting user supplies to the network access server (e.g. wireless access point) and intermediate hierarchy of RADIUS proxy servers to allow them to route the request to the correct home server.

Normally the realm part of a username (the part after the '@' sign) is the same for both the inner- and outer-identity. Often the outer-identity is something such as anonymous@camford.ac.uk (although the local-part before the '@' sign can be blank; the UCS recommends this is how local users configure their devices) and the inner-identity is the real username from the site, e.g. xyz789@camford.ac.uk. This allows the visitor to hide their real identity from a visited site. In the event of misuse matching up authentication records from the visited and home sites allows the real user to be determined. However, the UCS servers will rewrite the outer-identity to be the inner-identity when accepting a request for access proxied by an internal (to the university) RADIUS client for a local (@cam.ac.uk) user. This allows an institution within the university to determine the real identity of the user for accounting and authorisation purposes. For example, a college or department may wish to use the UCS server to authenticate the user (prove they are who they say they are) but use the returned identity to authorise their access (perhaps based on a local list of valid users).