A: Contact govroam@jisc.ac.uk and you'll be sent all the appropriate documentation for joining.
The full boarding form needs filling out completely. It asks for contact information, information about your RADIUS servers and various other pieces of information. If you're joining as a Federation, please fill in the Registry document too and send it to govroam@jisc.ac.uk.
Once we have properly completed forms then we'll sort out the appropriate payments, send you an encrypted file with the shared secrets for RADIUS servers, the Govroam App, subscribe you to the support mailing lists and add your support details to our Support Matrix.
A: Contact govroam@jisc.ac.uk and you'll be sent all the appropriate documentation for joining.
The Visited Only boarding form needs filling out completely. It asks for contact information, information about your RADIUS servers and for a letter of consent, on corporate headed paper, from someone senior e.g:
"Dear Sir/Madam, Re: Govroam Please accept this letter as authority of behalf of <insert organisation here> for the provision of the Govroam service over our network infrastructure as a Visited Only site. Your faithfully, <Director of IT>"
scan it to a PDF and upload it to the form.
Submit the form back to us, and then we'll send an encrypted file with the shared secrets for RADIUS servers, the Govroam App, subscribe you to the support mailing lists and add your support details to our Support Matrix.
A: There are three things to do:
1. If you've already got eduroam then take your existing configuration, duplicate the part of it related to visitors, change the 'eduroam' bits to 'govroam'. So that should cover the SSID, 802.1x setting on your wireless controllers, a VLAN to put the visitors on, an address range for them, firewall settings (same as eduroam). Then the RADIUS config should be able to send unknown realms to our NRPS.
2. Have your Director of IT (or someone suitably senior) write a brief letter of authorisation, on corporate headed paper, along the lines of
"Dear Sir/Madam, Re: Govroam Please accept this letter as authority of behalf of <insert institution/organisation here> for the provision of the Govroam service over our network infrastructure as a Visited Only site. Your faithfully, <Director of IT>"
scan it to a PDF and upload it through the form below.
3. Visit the Visited Only boarding form, fill it out and submit it. You will need to have the hostnames of your RADIUS servers already configured.
Then we'll send you an encrypted file with the shared secrets for our NRPS for you to configure in your RADIUS servers. We'll include a test account so that you can confirm that outgoing authentication requests work and we have a web page through which you can test incoming authentication requests. We'll sign you up to a technical mailing list and give you access to our Wiki of relevant information.
An overview of how to deploy visited-only govroam alongside an existing eduroam service: Joint deployment presentation (first presented November 2019)
Our technical requirements in detail: Tech Spec V3
A: They're very closely related but they aren't the same and there are no dependencies either way. eduroam has been around for years in the academic sector and is mature. Govroam uses exactly the same idea and technology but is aimed at NHS, Local Government and other public sectors. JISC runs the top level RADIUS servers for both services but they are completely separate services.
Thus it's possible to have neither, either or both.
If you already run eduroam as a Home site (i.e. a University) then adding Govroam as a Visited Only site is easy (and free). Essentially you need to duplicate your wireless and RADIUS configurations and request the shared secret details from JISC. This may require separate infrastructure (normally different RADIUS server VMs) or could be done on shared systems.
It's not possible for people with eduroam accounts to authenticate using Govroam, or vice versa. We encourage sites with eduroam to run Govroam Visited Only and Govroam sites to to eduroam Visited Only, for maximum coverage.
A: This very much depends upon the sort of users you have at your site. The services have concepts of Home and Visited:
Home is where a user has their credentials stored/generated (e.g. a University for an eduroam user or an NHS Trust for a Govroam user. At a Home site there will be a wireless system, RADIUS servers and a credential store (e.g. Active Directory).
Visited is where the user roams to and wants to work from. A Visited site will have a wireless system and RADIUS servers.
Now a site can be one or the other, or both. And that goes for both services. (Although it would be rare to have a Home only site).
Typical scenarios:
In both these scenerios there might be people who work for both the University and a Hospital. In which case they could have two sets of credentials or just credentials from one side. At either the Hospital or the University they could still connect with either set.
So ask yourselves “What sort of users to we want to offer services to?”. If you're a public sector employer then you'd want to be Home and Visited for Govroam. If you've got academic types on site then consider offering Visited for eduroam. If you're a University then you can offer Visited Govroam alongside your eduroam install for free.
A: As much or as little hardware as you want/Any RADIUS server.
A full service requires a wireless system, RADIUS and a network connection to the Internet. Assuming that you have the former and the latter then the RADIUS hardware is fairly simple. RADIUS software doesn't use much in the way of resources. e.g. A Raspberry PI running RadSecProxy could handle dozens of requests per second and would be functional for a medium sized enterprise - although not recommended! Any modern rack mount server, or a VM with a couple of CPU, a couple of GB of memory and 10GB of storage would be more than adequate for a top level RRPS or ORPS.
If you already have a RADIUS server then you may be able to configure it to act as an ORPS at no extra cost. If the software doesn't allow it, or you want to separate your services then the ORPS you add will only be handling the authentication requests destined/source to/from offsite, which will by about 1% of your total authentication requests.
As for the software - any modern RADIUS server can handle Govroam. There are no odd requirements. Having said that though, there should be a preference for servers which can handle Server Status (for resilience), CUI (Chargeable User Identity for audit), Operator-Name (for logging) and RADSEC (for the future).
If you value the service then resilience should be considered. At least two RADIUS servers at each level are recommended and three is quite common. Many RADIUS servers (and wireless controllers) offer load balancing options so hardware load balancers shouldn't be needed. The servers themselves are generally stateless and require no intercommunication.
A: Following on from the above question: between zero and a lot. If you have a spare piece of hardware, or can create a VM at no cost then installing a linux variant and FreeRADIUS would cost nothing. As would adding the ORPS capability to an existing RADIUS configuration. If you have to buy hardware then £500-1000 should cover the cost of a suitable Dell server. If you want to purchase RADIUS software such as Clearpass then you'll have to talk to a reseller as the licences can be complex. Even a reasonably sized hospital ought to be able have something for under £5,000 though. The final costs with depend on a number of factors which are site specific.
A: You can make this as simple or as complex as you wish. There is a minimum service level associated with govroam but it's not particularly restrictive. At the simplest level govroam Visitors to your site need a network segment separate from other users, a basic set of open ports (such as web and VPN) and some bandwidth.
Note 'govroam visitors'. If you're using govroam for your own people on your own site then you can treat them differently (put them on a VLAN/firewall context which has less restrictive firewalling or more access to local services, for example).
A common approach is to use a RADIUS attribute, set by the ORPS, to identify the user as a Visitor and set an appropriate role on the wireless system/firewall.
A: Easy one: any. The slightly longer answer is that any data in the inner tunnel is encrypted so is completely independent of the outer tunnel. As long as the outer tunnel has the right 'routing information' i.e. the realm, then the proxying will work. Thus each site can be using a different EAP type and it should all work. The use of PEAP is very common, EAP-TLS less so but plenty of sites use it successfully.
A: Jisc can provide a variety of different sorts of help at various levels and there are plenty of options outside of Jisc.
Jisc can:
Jisc isn't in a position to recommend external consultants or commercial third party partners, however, there are several companies who are able to offer these services and are currently doing so for both Govroam and eduroam. They should also be able to offer ongoing support.
Joining with an existing Federation has the benefits of potential significant reductions in boarding fees as well as access to people in your area and your field with existing experience of configuring Govroam.
Jisc has experience with RADIUS software such as FreeRADIUS and radsecproxy so can offer full configuration support as well as limited configuration advice on Clearpass.
Virtually all Universities have been using eduroam from many years so have significant experience and are often very willing to help others. They may not have much time to spare though and experience limited to the common eduroam RADIUS platforms, such as FreeRADIUS and Cisco ISE.
Jisc is able to provide a test account and some tools for external testing of credentials. We will work with sites until the boarding is complete and authentication works through the proxies.
A: Jisc aren't allowed to recommend particular RADIUS servers. The ones we're aware of that meet all the requirements of our Technical Spec are
radsecproxy is purely a proxy whereas the others can also integrate with data stores for authentication. Other RADIUS servers may also meet the requirements.
A:
This spreadsheet can be used as a template for the information that should be collected for sending to Jisc: (govroam@jisc.ac.uk). Use RED to indicate information to be removed, YELLOW for changes, and GREEN for new additions.
A: Follow these instructions: Unpacking .tar.gpg.zip file
A: If the RADIUS packets exceed the MTU size then they'll be fragmented. This normally happens only with EAP-TLS (client certificate based authentication). We have some suggestions on how to deal with packet fragmentation.
A: Firstly, the authentication request has to be made using EAP, not just a PAP or MSCHAP request. Secondly, until Jan 2018, the Root CA on the RADIUS server at the JISC end was a generic, self-signed one, but now is signed by QuoVadis. This used to require turning off certificate checking while testing but now shouldn't. However, if you still have problems it might be worth disabling verification so see if it helps.
A: In an ideal world the only unknown requests proxied from one RADIUS server to another would be those for realms which exist elsewhere. In practice though, most of the unknown requests don't contain a valid realm. For instance, a Camford (camford.org.uk) RADIUS server would forward a request for the holby.nhs.uk realm upwards and it would eventually arrive at the Holby RADIUS server but it would also forward cmford.org.uk, cmaford.org.uk, camford.uk etc. See section 4.2.1 of the Tech Spec for more info.
The number of these non-valids can exceed the valid one by factors of thousands to one (mostly because of retries from the client) and can put a significant and unnecessary load on RADIUS servers. So applying rules on the ORPS to spot and remove these as early as possible is a great idea. It's impossible to catch everything but there are a few easy rules that can be implement:
In FreeRADIUS take a look at the 'filter_username' policy which covers some of the basic cases. You will want to sanity check the tests though to make sure that they're suitable for govroam. If nothing else the file will give you a template to use when writing your own filters.
A: Normally it's the realm which the RADIUS server handles. If there are multiple realms then use the one which best identifies your site. The format is '1holby.nhs.uk'. The '1' is mandatory and defines the follow as a 'realm'.
A: Generally that your choice and dependent on what you need from the service and what tools you have.
Options:
A: EAP requests have inner and outer identities. Inner identities are something like 'fred@site.org' and the username part 'fred' is used to authenticate the user. The Inner identity is contained within an encrypted tunnel and not visible other than at the client and IdP ends i.e. the proxies can not see the Inner credentials.
The Outer identity is visible to all RADIUS servers and is sent unencrypted on the wire. It used only as a way of routing RADIUS requests around the infrastructure. The username portion is unused and irrelevant. i.e. from 'fred@site.org' only the 'site.org' portion is used, so that RADIUS proxies know where to send the request on to.
For security reasons it's strongly recommended that clients are configured with anonymous outer identities such as '@site.org' to prevent user names from being logged or being sniffed. As such it's incumbent on sites to ensure that their RADIUS servers do not insist on the outer ID matching the inner ID or that the outer ID username part is used for any aspect of authentication or routing.
To be clear, RADIUS proxies should proxy packets with outer of '@<realm>', 'anonymous@<realm>' or '<anything>@<realm>'. RADIUS IdPs should be able to authenticate based on the inner ID only.
The general advice is that it's not necessary and might not work anyway.
There are two issues to consider:
Most RADIUS servers have pretty decent load balancing built in anyway so putting an extra hardware layer in place wouldn't improve resilience much, if at all.
For proxying the Outer ID needs to be of the right format (@<realm>)
In RADIUS terms 'zombies' are RADIUS servers flagged as dead by another RADIUS server. RADIUS servers need to monitor the state of their neighbours to ensure that auth requests are handled. With TCP connections this could be done by simply noticing that the TCP connection fails, however with UDP this is not possible. Thus the approach is to wait a set time for a response and mark the neighbour as down (or a 'zombie') if no response is received. After another set period the neighbour is returned to the pool and the process starts again. Generally it only takes one such failed response for a server to be marked as a zombie. The response timeout is normally 30 seconds and the server would be down for five minutes.
This status monitoring is per pair of servers. If one site has four RADIUS servers and their neighbour has three then that means twelve pairings. Thus only twelve failed responses in a five minute period could mean that the neighbour site is completely unavailable. Once a RADIUS server has marked all its neighbours as down and there's nowhere else to send auth requests it will respond to new auth requests with a Reject and continue to do so until there is a neighbour available.
Without this monitoring process RADIUS servers wouldn't know if they're sending auth requests towards systems that had truely failed and a proportion of attempts would simply disappear, leaving the user waiting.
This is why it is absolutely critical that all authentication attempts are responded to.
Every single one.
Where Jisc has a customer which is an individual member such failures as above only affect the users of that member. However, where the customer is a Federation the problem is much greater.
The Federation's RADIUS servers are likely doing exactly the above status monitoring of their members and marking their neighbouring RADIUS servers as zombies where appropriate.
Whilst this all might sound like everything is in hand, it's not.
If a request originates at a member, let's say camford.ac.uk, and is sent via Jisc to the Scarfolk Federation for the holby.nhs.uk site then it passes through a number of RADIUS servers on the way, each doing the same status checks on their neighbours.
So, let's say that the holby.nhs.uk decides not to respond to the requests. After 30s the Scarfolk Fed RADIUS servers will mark the first holby.nhs.uk RADIUS server as a zombie.
BUT, and here is the real problem, Jisc's NRPS don't see a response coming back from the Scarfolk Fed's server so Jisc will mark the first Fed server as a zombie. Even Camford might then mark the first Jisc RADIUS server as down.
A Federation will have multiple members and thus lots of traffic. More members means they're more likely to have a site failing to respond and thus appear to Jisc to be failing to respond. Federations are more likely to be marked as zombies.
So it's imperative that Federations do everything they can do ensure that their members respond to every requests.
Every single one.
We ask that members don't do this sort of status monitoring on neighbours 'above' them in their hierarchy. i.e. Camford and Scarfolk shouldn't apply it to Jisc, and Holby shouldn't apply to to Scarfolk's RADIUS servers. However, not all RADIUS servers are capable of this selective status checking.
The important message is that every RADIUS server should respond to every request, no matter what. No exceptions. No excuses.