Filtering of Invalid Realms

Download as PDFDownload as PDF

Advisory: Filtering of Invalid Realms in Auth Requests sent to the NRPS

May 2014 - 15/05/2014

This advisory is relevant to ALL Visited (SP) service organisations participating in eduroam in the UK. It describes the recommendation, which will be included in the next revision of the Technical Specification, to filter out bad and doomed authentication requests containing malformed or 'homeless' usernames in order to reduce unnecessary loading of the national proxy servers.

In order to help maximise the efficiency of the National RADIUS Proxy Servers (NRPSs) all organisations providing Visited services should filter malformed outgoing RADIUS authentication requests on their border Organisation RADIUS Proxy Servers (ORPSs) and not pass bad requests to the NRPSs. This minimises the unsuccessful authentication attempts (ones which will never succeed) and means that genuine authentication requests are dealt with as quickly as possible.  To this end section 4.2.1 of the eduroam Technical Specification (version 1.3) states:

  • Visited organisations MUST forward RADIUS requests originating from eduroam Network Access Servers (NASs) which contain user names with non-local realms to a NRPS via an ORPS.

and

  • Visited organisations MUST NOT forward requests containing user names which do not include a realm nor any which are non-NAI compliant.

The first part of that statement is simple, user names MUST contain an "@" symbol (e.g. username@camford.ac.uk) and so bare usernames (e.g. "username" in this case) are NOT allowed. The second part is a little more complicated however. The definition of "NAI compliant" for the realm part is quite complex but basically it boils down meaning that it must be syntactically valid, i.e. the realm part of the user name must meet all of the following requirements:

  • MUST contain at least one dot ("."), e.g. "camford.ac.uk" is OK,
  • MUST NOT start or end with a dot, e.g. ".camford.ac.uk" or "camford.ac.uk." are both invalid,
  • MUST NOT have two or more sequential dots, e.g. "camford.ac..uk" is invalid,
  • MUST consist only of alphanumeric, hyphen and dot characters, so that's a-z, 0-9, "-" and ".", spaces are explicitly not permitted, e.g. "camford.ac uk" is invalid,
  • following on from the previous point the realm MUST NOT start or end with a space, e.g. "camford.ac.uk " is invalid,

We also request that sites do NOT forward requests with user names matching any of the following,

  • ends with ax.uk
  • ends with ax.edu
  • ends with @ac.uk
  • ends with sc.uk
  • ends with ac.edu
  • ends with ac.u
  • ends with .local
  • ends with the organisation's own realm without the .ac.uk (e.g. ends in camford rather than camford.ac.uk. Nb. this applies only to organisations providing both Home and Visited services)
  • contains common typo or other errors in the organisation's realm/sub-realm name (e.g. canford.ac.uk, staffcamford.ac.uk - check your NRPS error log for hints!)

There is also a list of common realms which we ask Visited organisations to reject locally rather than forward as, whilst they are syntactically valid, they are not eduroam members at this time and are not expected to be in the future. This list currently comprises:

  • myabc.com
  • 3gppnetwork.org (plus all subrealms thereof)
  • 3gppnetworks.org (plus all subrealms thereof)
  • gmail.com
  • googlemail.com
  • hotmail.com
  • hotmail.co.uk
  • live.com
  • outlook.com
  • yahoo.com
  • yahoo.cn
  • unimail.com

A description of how to implement the above recommendations is beyond the scope of this document since there are various different RADIUS servers deployed by members and each platform requires difference configuration methods.

Comments

+1
+1 -1

Hi,

I don't know if this is any use, but here is a regex expression that will parse an email address and check its format (I am not a regex guru so this is built from things I have pulled of the web). I know the realm is not strictly an email address but the syntax should be the same. I am sure some one if they wish can strip it to only check the realm part of the string.

^([a-z0-9]+)([._-]([0-9a-z_-]+))*@([a-z0-9]+)([.]([0-9a-z]+))*([.]([a-z0-9]+){2,4})$

It covers all the white space, double .. and single @.

(?:ax.uk|ax.edu|@ac.uk|sc.uk|ac.edu|ac.u|b|.local|myabc.com|3gppnetworks.org|gmail.com|googlemail.com|hotmail.com|hotmail.co.uk|live.com|outlook.com|yahoo.com|yahoo.cn|unimail.com)

matches any of the invalid realms. NOTE you still need a separate rule to then block own realm with out the ".ac.uk"

But if you block any thing that matches these two regex from getting forwarded, you should in most cases be cleaning up most of the issues mentioned above.

Many radius servers seem to accept regex as arguments in a policy, and for some people starting out in eduraom who are new to radius, writing a policy for all the above might seem a bit daunting. With a regex for validating the formatting of the realm, and one for stripping out known bad realms it will allow every one to be compliment right from the start. And if and when changes are made, if the regex is edited and republished its a quick copy and paste to insure your site is still compliant.

0
+1 -1

Very useful thanks Aaron; although I had to amend the regex for invalid realms slightly to include a $ at the end of the the realm names to show that they terminate (especially important on the |ac.u$| option). I also didn't think the |b| option should have been included?

This was the amended version:
(?:ax.uk$|ax.edu$|@ac.uk$|sc.uk$|ac.edu$|ac.u$|.local$|myabc.com|3gppnetworks.org|gmail.com|googlemail.com|hotmail.com|hotmail.co.uk|live.com|outlook.com|yahoo.com|yahoo.cn|unimail.com)