eduroam(UK) Advisory: Injection of Operator-Name attribute by the NRPSs

This advisory is relevant to all eduroam(UK) Home (IdP) and Visited (SP)  service organisations. It describes a measure that eduroam(UK) intends to take to improve the ease of interpreting and parsing logs for all member organisations when troubleshooting user difficulties and when progressing security incidents. Since this involves insertion of information into request packets that our member organisations send to the National RADIUS Proxy Servers for forwarding it is incumbent on eduroam(UK) to apprise our members. The NRPSs will be configured to inject the relevant Operator-Name attribute into authentication requests received when the attribute has not already been inserted by the Visited organisation. It is planned for this to be put into effect by 1 November 2018 (this was duly carried out).

No action is required by member organisations – this advisory serves simply as a notification of the introduction of the measure on the NRPSs.

12/10/2018

Background and Scope

Member organisations providing a Home service for their users have a responsibility for helping to resolve problems that their users might experience when roaming to other eduroam locations. Frequently the first recourse will be to look in their RADIUS logs for information about the attempted authentication event.

However, since it can take several hops between RADIUS servers before a user’s authentication request ultimately reaches the Home site, the Home site has no simple way of determining where an authentication attempt originated - unless the O-N attribute is present.

The main benefit of O-N insertion is to make it easier for system administrators and eduroam(UK) Support to troubleshoot problems eduroam users may be having, specifically by making it easier to locate relevant sections in RADIUS logs and to identify which location the user was at when a problem was experienced. 

eduroam(UK) has long recommended that wherever possible member organisations should implement the insertion of the appropriately formed Operator-Name (O-N) attribute into RADIUS packet authentication requests sent to the eduroam(UK) National RADIUS Proxy Servers (NRPS). See https://community.jisc.ac.uk/library/janet-services-documentation/advisory-injection-operator-name-attribute  This recommendation has been included in the Technical Specification since version 1.2 (Aug 2012). But since not all RADIUS platforms support the insertion of O-N, notably Microsoft NPS, this has never been a mandatory requirement. The majority of new members now utilise Microsoft NPS - which has led to a growing deficit in the implementation of O-N insertion and consequently the community is missing out in a big way on the benefits. 

The presence of the O-N attribute in authentication requests received by the NRPS is also very helpful to eduroam(UK) when providing technical support to our members. Furthermore, the introduction of the eduroam Visitor Access service now requires the inclusion of the O-N attribute since this provides the requisite location information to enable eVA guest account authentication to be restricted to the eduroam service of the organisation that creates the guest account.  

With the migration to the new Support server now complete, eduroam(UK) has the capability to inject the relevant Operator-Name attribute into authentication requests, on behalf of our members, before onwards forwarding to the Home organisation/ETLR RADIUS servers, where the attribute is not already present.

This is something that our colleagues in SURFnet already do and eduroam(UK) will follow suit. It must be emphasised that this insertion of Operator-Name will not overwrite any value that organisations may have already inserted in authentication requests sent to the NRPS.

Mechanism

The new Support server holds details of all eduroam(UK) member organisation ORPSs together with the realms that these support and importantly an ‘organisation identifier’. The organisation identifier must be based on a domain name which the organisation owns or has the right to use it. The organisation system administrator can select and change what name will be used through the ‘Organisation settings’ panel on the ‘Configure’ page of the Support server. If the organisation is already inserting an O-N, the ‘Identifier’ registered in the organisation’s config on Support server should be the same as in the O-N content being inserted. 

Example for Camford below. The ‘camford.ac.uk’ identifier will result in the attribute ‘1camford.ac.uk’ being injected as the O-N (the 1 is the Namespace ID and means that the O-N uses a DNS domain name).

The ‘Identifier’, (which the organisation sys admin can edit), will form part of the configuration uploaded to the NRPS. The injection of O-N will be implemented using the Radiator command AddtoRequestIfNotExist.

Operator-Name Injection at the NRPSs

The NRPSs will be configured to inject the relevant Operator-Name attribute into authentication requests received when the attribute has not already been inserted by the Visited organisation. The O-N to be injected will be derived from the ‘Identifier’ registered in Support. The records for all member organisations are by default populated with the information provided on the application form or the first registered realm. It is planned to put O-N injection at the NRPS into effect by 1 November 2018.

Action to be taken

No action is required by member organisations – this advisory serves simply as a notification of the introduction of the measure on the NRPSs. You may wish to review your registered ‘Identifier’ value.