I was invited to deliver a presentation at the recent CyberUK event on the work that Common Technology Services (CTS) is doing to enable Wi-Fi roaming between government buildings.
In my first post I discussed the threats that the government can face when delivering Wi-Fi. In this post we will be discussing the steps CTS is taking to enable government-wide secure Wi-Fi.
Cross government Wi-Fi
We’ve developed two Wi-Fi solutions for government:
- user.wifi
- device.wifi
They provide appropriate security and solve the two main use cases to provide access to:
- The internet
- Internal networks
It's easy to make a system that is so secure that nobody can use it. Security is always a trade off but we've tried to mitigate the most common threats without compromising usability.
Internet + roaming = user.wifi
This solution provides internet access to guests, visitors & staff with ‘always on’ virtual private networks (VPNs).
You can implement user.wifi on your existing Wi-Fi infrastructure in less than an hour. It uses the open standard RADIUS which is supported on almost all wireless access points. It provides internet access only, it's user enrolled, and it allows seamless roaming across all participating buildings. Combined with a VPN it means users can work anywhere.
Adding user.wifi to sites
Sites are added by the Wi-Fi provider directly via an email self-service system.
We've tried to remove as much manual administration as possible. We’re also trying to automate the troubleshooting, by sending an email to the administrator of the site if a common problem is detected such as a mistyped shared secret password between the Wi-Fi and the central service.
GDS are funding the solution, so there is no cost for departments. It can be implemented in just a few minutes, and the more buildings we get on board, the more places users can roam to.
It's currently being piloted in a few buildings including this one in Aviation House, and we will be moving to Beta in the next few weeks when it will have a full service wrap and be made available to all government organisations. Keep an eye out for the guidance.
Adding users to user.wifi
The user credentials are randomly generated, so if the certificate isn't checked properly and they are stolen then all an attacker gains is access to the internet. The clients are also isolated from each other on the wireless infrastructure so that an attacker can't just sign up as a guest and harm other users.
Staff can get an account by sending an email from a government address to enrol@user.wifi.service.gov.uk. Those at CyberUK may have done this to get on the Wi-Fi.
If you are organising a meeting or event, you can send a list of email addresses and/or phone numbers to sponsor@user.wifi.service.gov.uk, and an account will be set up automatically for each person with their login details sent to them directly.
A visitor to a building can text a number shown on a poster, and receive terms and conditions. Once they’ve replied that they agree they are sent a username and password to login to the network.
A common authentication solution and network name allows devices to roam when they enter any participating building, the user doesn't have to do anything at all after logging in for the first time, it just works.
Privileged access + managed devices = device.wifi
User.wifi might be the only solution that you choose to deploy if you are happy for your devices to use VPNs to get back to internal systems. But if you want direct privileged network access, you may wish to consider implementing our second solution: device.wifi, alongside user.wifi.
It's important to note that this solution is only suitable for managed devices so it's no use for guests or bring your own device. Most of the work needs to be done by the implementing organisation.
What we are proposing is very similar to most enterprise Wi-Fi deployments. It relies on Public Key Infrastructure for security. You will need to roll out certificates to managed devices and use them to securely authenticate to the wireless network. It's worth noting that the same technologies can also be used to secure wired networks.
The server certificate will be signed by your internal certificate authority (CA) and checked automatically by policy so there is no risk of connecting to a rogue network.
The clients authenticate using device certificates which can't be stolen by a rogue network, and if the private key is installed in the Trusted Platform Module it's very hard to get them off the device they are installed on.
Secure roaming
Once we’ve established demand we’ll look at adding a central authentication proxy which sits in the centre acting a bit like a telephone exchange and knows how to connect every device in government to their home authentication service. You can then securely authenticate devices belonging to other organisations and your users can then roam to other buildings.
The central proxy acts a bit like a telephone exchange, connecting the user back to their home department, to check their certificate when roaming away from a home building.
Device.wifi gives better security than user.wifi because it uses certificates to authenticate and the certificate of the network is checked automatically.
The trade off here is that some infrastructure and configuration is required by each IT department to make it work, making it only suitable for corporate managed devices.
However, the usability is still preserved as the user doesn't have to do anything at all.
Intelligent VPN: home/roaming detection
The design of device.wifi is complemented by an intelligent ‘always on’ VPN, which knows the difference between being connected to a trusted internal network and when it is roaming. This means it knows when to bring up the VPN and gives the user a seamless experience. It reduces unnecessary latency of tunnelling the traffic to the home cloud or datacentre, allowing intelligent routing decisions to be made at the local site for direct access to cloud or VoIP services.
We have Shared WAN guidance which shows how to share network links in multi tenanted buildings. This will provide a good user experience by making it as simple as possible to enrol, and choose where they work.
Doing something lots of times in a standard way is good, but only if you need lots of instances of the thing. We think doing something once is better.
One final thing
If you are implementing Wi-Fi, try to keep it secure. And consider using our guides to allow roaming. You can email the CTS team for more information.
5 comments
Comment by Andrew posted on
A review of this service
It was great to see user.wifi in the wild at Civil Service Live yesterday. I tried the service on both my iPhone and my Defra Lenovo Laptop and thought you'd like to know how I got on.
On my iPhone (obviously this isn't a Defra device!)....
Registering was easy by SMS, the instructions clear and concise although the text service took a while to respond and the messages didn't come form the number I sent too which was a bit messy.
The network was easy to find and connect to using the details supplied but I got a certificate error, which I ignored - I suspect most people will.
The wifi connection was stable and fast.
On my Defra Laptop....
Firstly it wasn't clear if I could use the same login on multiple devices so I decided to use the email route to request a new password. This was tricky... I dug my blackberry out and sent an email from my defra.gsi.gov.uk account, having to use a gov.uk account seemed unnecessary when anyone with a mobile number can use the service.
I got a response pretty quickly, there was a delay but it wasn't as long as via SMS. The email was OK in terms of clarity but could have been better formatted and I'm not sure that most people would understand the bit about certificate thumbprints or know how to check.
Anyway I found the wifi network and tried to connect on my Defra laptop but again hit the certificate error, I couldn't get past this and couldn't proceed further with the test.
I'd love to know if my Defra kit would have got further without the certificate error. We normally hit the 'wall of VPN' when trying to use Wifi that requires a login which makes mobile working tricky.
So I think on the basis of yesterday's experience I'll give this 3 out of 5, but as a mobile government worker can see massive potential.
I hope this feedback helps!
Comment by Lucy D posted on
Hello Andrew
Always good to get feedback so thank you for taking the time. If you would ever be interested in talking to our user researchers do let us know and drop us an email at contact.cts@digital.cabinet-office.gov.uk
Comment by Andy Crawford posted on
Many thanks to you and your colleagues for this great work. It's simple and can hopefully be adopted quickly across government, local and central. I have a question regarding the scope of the work however, specifically whether this service will be available to NHS organisations and allow health colleagues to authenticate to user.wifi?
I am actively involved in a regional collaborative project to allow health and social care colleagues to co-locate and this solution would simplify this immensely. However, first indications are that colleagues with an nhs.net address cannot subscribe to the user.wifi service. Is this intentional? If so, are there plans to extend this service to nhs.net addresses?
Thanks
Comment by Alistair Cowan posted on
Hi Andy,
Thanks for your comment.
Currently, the wifi is only a pilot service for central government. However, the next version of the service will be available soon and will be open to all publically funded organisations including the NHS.
We hope this will provide more opportunities for greater collaboration between health, social care, local and central government.
Regards,
Alistair
Comment by Matt posted on
Great idea I've just started looking into it (we have the 'wall of VPN' can't enter a password issue too).
Is there a list of participating buildings anywhere? That would be really useful.