Yes, Hotspot 2.0 is the Future of Secure Guest Wi-Fi

Since first blogging about Hotspot 2.0 and its application to typical enterprise WLAN guest networks I’ve learned quite a bit more thanks to several helpful tweets from Dave Wright of Ruckus Wireless. Although the large majority of the focus of Hotspot 2.0 still seems to be on integration with cellular carriers for AAA services and all the complexity and exclusivity that entails, there are provisions for simpler, anonymous, and secure Hotspot 2.0 guest networks that are much closer to what the typical enterprise WLAN operator will actually deploy. As I’ve said before, authentication is not a priority for most WLAN operators on their guest network, but encryption certainly is.

Is it the holy grail of guest Wi-Fi? Maybe, but more on that after we look at the Wi-Fi Alliance Passpoint (Release 2) Deployment Guidelines. In all 61 pages of the document, there are these few paragraphs devoted to what I predict to be the most common use of Hotspot 2.0.

12. Free Public Hotspot 2.0-Based Hotspots 

Hotspot Operators may provide Hotspot 2.0-based free, public, hotspot service. In this particular service, Hotspot Operators have the need to ensure hotspot users have accepted the terms and conditions governing their hotspot’s use, but are not interested in knowing (or do not wish to know/track) any particular user’s identity. This functionality is provided by Hotspot 2.0 Release 2 infrastructure. The Hotspot Operator configures their infrastructure as follows:

  1. The user in a Free Public Hotspot initiates the online sign-up registration process with the Free Public Hotspot’s OSU server.
  2. During the registration exchange, the OSU server presents the terms and conditions to the user.
  3. If the user accepts the terms and conditions, the OSU server issues a credential; if the user refuses, no credential is provisioned. Note that the same credential is issued to all users which have accepted the terms and conditions; therefore, the Hotspot Operator cannot track the identity of an individual user during the Hotspot 2.0 Access state (see section 6).
  4. When the user/mobile device returns to the same Free Public Hotspot, the previously provisioned credentials are used to provide secure, automatic access. The mobile device authenticates using EAP-TTLS, which provides for the generation of unique cryptographic keying material even though users share a common password.

If the terms and conditions change, then the user is taken through a subscription remediation
process during which the new terms and conditions are presented. If the user accepts the
changed terms and conditions, then a new credential is provisioned. 

There you have it. Hotspot 2.0 does provide for anonymous and secure guest networks. In short, 802.1X/EAP authentication is accomplished with EAP-TTLS through a common credential that is issued after the signup process. In fact, this has already been deployed by the cities of San Jose and San Francisco. To get an idea of how it works from a user’s perspective, check out the directions here.

Yes, you can do this all without Hotspot 2.0 in a less elegant way: Add a notice to your guest network captive portal that users can login to the secure network with a specific generic credential, and even a link to download a .mobileconfig profile for iOS and Mac OS users. However, the user experience won’t be standardized like it is with an OSU server, and non-Apple users will have to manually configure a connection to the 802.1X network, including adding a cert to their trusted roots. Not good UX. And definitely not fast, free, and easy.

The bad news: With Hotspot 2.0, the guest network captive portal is here to stay.

The good news: Users only have to wrestle with the captive portal once (unless the client credential is changed). And perhaps the technology behind the portal is more mobile client-friendly than today’s captive portals. Hopefully a HS2 client sees the OSU server being advertised by ANQP and immediately presents a notification to the user. If the user doesn’t play ball, the client should disconnect and the SSID should not be saved as a preferred SSID.

The great news: This is a lower-friction way to get secure Wi-Fi to guests.

Is this the holy grail? That depends on what you think that is. To me, the barrier to entry is low enough that I think this is a win for guest Wi-Fi.

Another wrinkle: The Hotspot 2.0 802.1X network can still be configured to automatically connect guests from known realms. That means that you could add eduroam and the coming anyroam realms to the SSID to onboard users from those participating organizations securely and automatically. And yes, no captive web portal either. So if the opportunities to integrate with AAA clearinghouses grow (exist at all?), the number of users subjected to the captive portal shrinks.

I’m sure there are concerns regarding the possibility of new SSID’s. Luckily, a legacy open guest network can serve Hotspot 2.0 incompatible clients while also delivering the Online Sign Up portal to compatible clients. That means no new SSID’s.

For the visual learners among us, your typical enterprise WLAN might look like this now:

A typical enterprise WLAN
A typical enterprise WLAN

To support secure Hotspot 2.0 guest clients, it might look like this in the future:

A Hotspot 2.0-enabled enterprise WLAN
A Hotspot 2.0-enabled enterprise WLAN

I’m looking forward to seeing gear get updated to support Hotspot 2.0 Rev 2 so we can see this in the wild. Ruckus is doing a great job banging the drum for Hotspot 2.0, but other vendors seem to be further behind. Client support is not great (come on, Android), but Apple has supported it since iOS 7, so here’s hoping that will drive others to follow suit.

Advertisements

Hotspot 2.0 Can Disrupt the Cellular Marketplace

When it comes to cellular in the U.S. there are two major carriers, AT&T and Verizon, and everybody else. While Sprint and T-Mobile both also compete in the national market, they have far fewer subscribers and a reputation for poor coverage. This has essentially been the state of affairs since Cingular bought AT&T Wireless in 2004 and continued business using the AT&T brand. There are some smaller regional competitors, but their market share is limited, and their customers roam onto one of these national networks when they leave their regional service area.

I think the combination of Hotspot 2.0 and Voice-over-Wi-Fi (VoWiFi), or “Wi-Fi Calling” as it’s known has the potential to disrupt the current cellular marketplace dynamics.

Sprint and T-Mobile have been dropping their prices to try to attract customers away from the Big Two (AT&T and Verizon) for years, even offering to pay early termination fees and give trade-in credit for phones, but it appears that this has largely been unsuccessful. When you can’t make a call from within your own home or office, who cares how cheap the service is?

Part of the problem for T-Mobile is that a lot of the spectrum they own is higher frequency than their competitors, so it doesn’t penetrate buildings as well due to the increase in attenuation that occurs as wavelength decreases. That’s a tough problem to solve.

carriers

VoWiFi and Hotspot 2.0 can change all of that.

VoWiFi extends the network’s voice coverage into the subscriber’s home and office, where subscribers can easily connect their phone to the W-Fi network, which takes care of that concern. Sprint and T-Mobile could also partner with SOHO Wi-Fi router manufacturers so that Hotspot 2.0 roaming integration was preconfigured for their networks on these products. Imagine if a subscriber could buy a NETGEAR “T-Mobile Edition” router and have VoWiFi calling work out of the box, without any configuration on their phones.

Imagine if Sprint and T-Mobile aggressively pursued Hotspot 2.0 integrations with major public Wi-Fi providers. Their subscribers would have seamless VoWiFi coverage in the areas where they currently have the biggest problem: indoors. As public Wi-Fi continues to expand, the voice coverage for these carriers could expand right along with it.

In fact, if we assume a properly designed WLAN, in very high density environments the indoor service for these carriers could be superior to the Big Two. Ever go to a ballgame and been unable to make a call or use data in a full stadium? That’s a common experience and Wi-Fi roaming integration solves that. Wi-Fi was designed to meet LAN access needs like this. Why not actually use it that way?

This could make Sprint and T-Mobile attractive again. Although I don’t imagine the costs would be very significant as it doesn’t involve building new towers and deploying more of their own hardware, they would probably need to compensate large public Wi-Fi operators for the use of their networks. That would allow them to keep their service priced below the Big Two.

Cellular data offload is commonly thought of as a driver for the adoption of Hotspot 2.0. Voice coverage expansion for smaller carriers may be more important.

eduroam – Secure, Automatic Roaming Between WLAN’s

eduroam (education roaming) is the secure worldwide federated network access service developed for the international research and education community.

I’ve been really intrigued by the WLAN phenomenon eduroam which has swept across much of Europe and is being deployed in many US universities this academic year. This is a secure WLAN roaming technology, but it doesn’t require Hotspot 2.0/Passpoint/802.11u/Rev 1/Rev 2 (whatever you want to call that).

Participating institutions put up an ‘eduroam’ SSID with 802.1X authentication, and on the back-end authentication is handled by the authenticating user’s home institution’s RADIUS server, rather than the local server of the WLAN. That allows users to establish secure connections to any participating institution’s WLAN.

To get a user on the WLAN, RADIUS requests are proxied by the local RADIUS server to the eduroam regional or top-level RADIUS routing servers. The eduroam server inspects the username in the request for the domain, e.g. user@example.edu, matches the realm ‘example.edu,’ and then proxies the request to the users home institution’s RADIUS for authentication. The home institution’s server then responds through the same proxying scheme.

eduroam RADIUS routing example
eduroam RADIUS routing example

For users, it ‘just works.’ They connect to the SSID once and add it to their preferred SSID list just like any other network, then their device automatically connects securely wherever they see the eduroam SSID. Could be another university, could be a coffee shop, or even an airport.

For participating institutions, they just need to configure a few RADIUS proxying rules for users outside of their institution, and then users from hundreds of institutions around the world can securely connect to the WLAN.

If my understanding of Hotspot 2.0 is correct, the future for eduroam may be very bright. In a HS2 WLAN, a separate eduroam SSID isn’t needed. eduroam could register to become a HS2 roaming hub, then WLAN operators advertise eduroam through ANQP as a supported roaming hub on their existing 802.1X SSID, and then eduroam users will automatically connect to it. Fewer SSID’s is always better.

While all the talk about HS2 is about offloading cellular data onto Wi-Fi networks, there is real potential here for more useful federated authentication for everyone-not just cellular subscribers. eduroam is the model for that.

Hotspot 2.0: The Future of Guest Wi-Fi?

Hotspot 2.0 is a technology that leverages 802.11u and service provider authentication systems to connect clients to WLAN’s securely and automatically. For example, an owner of a Verizon Samsung Galaxy S5 with Passpoint enabled who comes within range of a Hotspot 2.0-enabled SSID which can serve Verizon customers will automatically connect to the WLAN, secured by WPA2, with no user interaction.

At least, that’s how I understand the most common use case for Hotspot 2.0 and 802.11u. Personally, I have other ambitions for the program and currently it isn’t at all clear what else Hotspot 2.0 is capable of.

I’m encouraged to see that Hotspot 2.0 Release 2 provides a public key infrastructure and pre-installed trusted root certificates on clients for use when forming secure connections to WLAN infrastructure components.

What I’d really like to see if that PKI infrastructure used in a manner similar to HTTPS, so that clients securely connect to an “open” SSID, use EAP-TLS to evaluate the server certificate against its trusted roots, and establish a WPA2 protected connection without any client-side credentials or cumbersome captive portal registration process. 802.11u data can be presented to the client for use in evaluating the certificate. To me, that is the holy grail for WLAN guest networks.

Authenticating users through carrier AAA isn’t important because very few WLAN operators want/need to know the identity of users on their guest networks (with the exception of retail, I suppose).

I must say that I cringed when I read that Release 2 includes “portal based signup.” Hopefully this is substantially different from the extremely mobile-unfriendly process of current captive portal technology. Either way it will be an obstacle to onboarding users. Guest Wi-Fi should be frictionless.

I’m not interested in authenticating guest users on the WLAN, but I do want them to have a secure connection. It would be awesome if WLAN operators could opt-out of all that AAA integration complexity required by Hotspot 2.0 and just use the PKI infrastructure to run an open, encrypted WLAN for guests. This would allow more clients to connect securely as well, rather than only smartphones with with carrier agreements and users that suffer through a portal-based signup process. Will this be possible? I certainly hope so.