Sunday 9 June 2013

Wi-Fi connection File Format

Wi-Fi connection File Format

In this article I’ll try to present one new standard ta needs to be created and demonstrate how it can be used by a Wi-Fi Hotspot provider. This is based on Scenario 3 in my article Wireless Guest Networks

The scenario (summary)

  • Wi-Fi Hotspot provider
  • Needs rigid solution
  • Needs to identify every user
  • Needs billing options

The solution

This solution is split into two parts, First I’m going to present the WiFi Connection File Format, then I’m going to explain how this fits into the scenario.

The File Format

This is going to be a standardized, clear text file format containing everything you need to connect to a wireless network. My suggested mockup is like this:

SSID v1.0
[basic]
SSID:Hotspot
security:WPA2-Enterprise
EAP:EAP-TLS

[EAP-TLS]
username:exampleuser
password:examplepassword
cert:(some certificate fingerprint)
cert:(another certificate fingerprint)

[Signature]
(Signature for the above document) (optional)

Let’s start from the top. The first line is a declaration of the file format and the version of that file format. The second line is a section declaration declaring that the following settings are basic settings. The next few lines consists of key:value pairs separated with a newline. The next section contains specialized settings for EAP-TLS, this is just an example, but imagine that this is supposed to provide all the information needed to connect to that network, no questions asked. The signature section is optional, It’s a signature confirming the authenticity of the above document and contains all the information needed to authenticate it. I would personally just use regular X.509 certificates in some way.

The reason for standardizing the file format is to have one standard way of providing the credentials; without having to coach the user using a long series of screenshots to do it. You can simply download this file and auto-run it. The Wi-Fi manager will then ask you if you want to apply these settings to that SSID, prompt you for overwriting ask you for approval of signature (if needed) and apply the settings.

Solving the problem

For this hotspot provider, there is a number of ways this could be applied as a solution. Common for all solutions is that they use WPA2-Enterprise (RADIUS) as the primary connection and authentication system. The service provider still needs to do a lot of work on the back-end of the system, but they can now trust the client device to remember the credentials and they don’t have to ask the user to authenticate every time. For expired subscriptions you can simply use RADIUS to kick the user off to a walled-garden VLAN with enough access to renew their subscription.

Option 1

User registration and authentication could simply happen over on a separate SSID in exactly the same way as hotspot solutions do today. The exception is that after completing the signup (or just regular login) the user is sendt a settings file and connects to the secured SSID.

Option 2

Same as Option 1, but using [WPA-Guest] on the same SSID.

Pros

  • Pretty easy to use, and easier than manual setup.
  • Secure (depending on setup)
  • Most Hotspot providers need to do most of this work anyway

Cons

  • Harder to set up

Summary

That completes the planned part of my series on wireless guest networks. If anyone in a position to do anything about this find this interesting, feel free to contact me, I really want to see this implemented.

Sunday 2 June 2013

Introducing EAP-Guest

Introducing EAP-Guest

In this article I’ll try to present a solution for providing encrypted wifi with authentication free access. This is based on Scenario 2 in my article Wireless Guest Networks

The scenario (summary)

  • Public access Wi-Fi provider
  • Many users
  • Many access points
  • Large coverage area
  • No need to identify individual users

The solution

As I hinted in my last article this article is going to introduce something that is as of yet not developed. As the title hinted to we are going to use WPA(2)-Enterprise and introduce a new EAP type, I’m going to call it EAP-Guest.

EAP-Guest, Overview

EAP Guest is a new EAP type that can be announced in the beacon (as a vendor specific extension) and can work in parallel with other EAP types on the same SSID. It requires no authentication credentials from the client, but does a couple of authentication exchanges to prevent man-in-the-middle attacks.

AEP-Guest, User perspective

The beacon includes EAP-Guest, so the padlock icon next to the SSID in the browser is set to something to make it stand out. This could be an open padlock, a padlock and a key or even a padlock with a G on it.
When the User selects the network, the client device initiates a regular WPA-Enterprise authentication session with EAP type EAP-Guest. During that authentication and identification run the service provider signs it’s packets with a X.509 certificate. The certificate is the tricky part, you need a central CA (Certificate Authority) to sign it. Issuing certificates for SSIDs are not an option, that’s way too complicated to enforce. I suggest using regular X.509 certificates for web use and present the domain and organization to the user for approval. When the certificate is approved the client device needs to store it for future use. Since there are large networks with multiple providers (e.g. eduroam) the client must be able to store multiple of these certificates.
Once the authentication process is completed (failure is an option) the client is returned a URL to go to and accepted into the network. The client must direct the user to this URL in a web-browser if the platform supports it.

Pros

  • Easy to use
  • Secure

Cons

  • Hard to set up
  • Requires new technology

Summary

The EAP-Guest solution is an imagined future solution to this problem and the very reason I wrote this series of articles. If you are a service provider and need user authentication on top of this solution, you only have to add a layer-3 security portal on top of WPA-Guest, this is the main motivation for the URL return at the end of the sequence. In the next article I’ll present a solution that I think is an even better solution for hotspot service providers.