IT Services’s user-facing instructions for connecting to eduroam have always been unequivocal about the username to use: if you want to connect to eduroam, your username is your SSO with @ox.ac.uk appended on at the end, all lower case. So, an SSO of unit1234 would become firstname.lastname@example.org. However, as you may have discovered, when you connect to eduroam within the University and authenticate without the @ox.ac.uk appended to your SSO, you will still be granted access.
RADIUS is the service underpinning eduroam authentication. In RADIUS parlance, the @ox.ac.uk is the username’s realm and declares the institution performing the authentication, in this case “ox.ac.uk”. Other institutions that offer eduroam have their own realms and when someone within the University uses a realm other than ox.ac.uk, say email@example.com, we will proxy the request to that foreign institution for them to authenticate.
Back in the dim and distant past, our RADIUS servers were configured such that if no realm was supplied when authenticating to eduroam here at the University, they would infer the realm to be ox.ac.uk and act accordingly. When configuring your device for connecting to eduroam, the advantage of making your realm explicit is fairly obvious: when you travel to other institutions that offer eduroam, you will be able to connect without any changes to your connection details, because the other institution will know to use the RADIUS servers at the University of Oxford to authenticate. The advantage of making your realm implicit is equally obvious: you save typing out 9 characters including that pesky ‘@’. For many years we’ve turned a blind eye to the practice of realmless authentication, but it’s coming to a head:
- The University of Oxford is not the only institution in this fine city offering eduroam. Other institutions are available. We’ve had reports that these institutions’ IT staff are being contacted by University members using realmless authentication with connection problems. “It works everywhere else, so it must be something wrong with your system”. Saying that the University’s instructions never mention realmless usernames is of little consolation to these IT staff fielding repeated support queries.
- Perhaps more importantly, since our RADIUS configuration was written Jisc has released an update to the eduroam technical specification. Specification 1.2 explicitly states that “only RFC 4282 compliant usernames (of the form userID@realm) to be employed for user authentication both for roaming users and for users when at the Home site”.
It’s the “at the Home site” that’s important for the second point. It means even though our internal authentication never leaves the confines of the University, we are in breach of the eduroam specification and we should fix that.
So with that out the way, how many devices are configured without a realm? It’s fairly easy to find out from our logs. Results for the past few days (no prizes for guessing on which day the undergraduates started arriving):
The configuration change to reject realmless usernames is relatively simple and we actually have had it waiting to be deployed for a while now. However, with at least 14,443 devices configured without a realm, all requiring reconfiguration after we mandate an explicit realm, it’s not a simple case of making the change and hoping the users will reconfigure it when they realize something’s wrong.
What about eduroamCAT?
eduroamCAT is no panacea. In fact, our eduroamCAT profile is configured to include the realm so these figures are even more stark, as the realmless authentications would thus have had to have been manually configured clients. If we were to enforce the realm in usernames though I’m sure eduroamCAT would play a large part in device conformance.
There’s no question of if we’re going to stop allowing realmless authentication. For us to comply with the requirements specified by Jisc it’s a case of when it’s going to happen. With so many devices configured without a realm it would be a very bold move for us to make the necessary changes next Friday before leaving for the weekend. Such a change would require involvement from all sectors of IT support, both within IT Services and within the general ITSS community. The benefits may not be felt directly by ITSS here, but certainly other institutions would appreciate the change.
In terms of helping ITSS know who has devices configured without a realm, it’s something that we are discussing here at the moment and once we have decided on the best course of action there most likely will be an announcement on a medium more formal than a blog post.