I am currently working on a major revision to my Open Secure Wireless project to incorporate changes introduced with IEEE 802.11u.

The changes to 802.11 are part of what the Wi-Fi Alliance is calling "Hotspot 2.0", which they plan to launch in 2012. It appears that the Wi-Fi Alliance and Wireless Broadband Alliance may be currently focusing this effort on mobile carriers and service providers rather than smaller open and public hotspots. However, the changes introduced in 802.11u could also be used to enable a hotspot to be both open and secure. I am referring to this project as Open Secure Wireless 2.0 (OSW2), and I encourage the Wi-Fi Alliance to consider adopting this as a component of Hotspot 2.0.

A paper (and hopefully code!) will be forthcoming soon, but read on for the background and overview of how this might work.

Background on Open Secure Wireless

In May 2010 I posted a paper on "Open Secure Wireless" - a method by which wireless hotspots can be both open and secure simultaneously. A few months later Tom Cross and Takehiro Takahashi with IBM X-Force posted an article introducing similar method they called "Secure Open Wireless Access". Although we developed these approaches independently, both proposals utilize EAP-TLS without client authentication and other similar features. Since discovering that we were working on similar projects, we have been working together to try to get acceptance and deployment of secure and open hotspots.

Although both methods are RFC compliant and have been shown to work in lab testing, they still require modifications to the behavior of wireless authentication servers and supplicants. One of the biggest sticking points for most people is validation of the server certificate to prevent man in the middle attacks. Although this is an existing challenge with EAP-TLS and PEAP networks, the use of TLS in public hotspot networks exasperates the concern.

In my paper I suggested under “Future Work” that the SSID could be compared to the CN or SAN of the x.509 certificate, similar to how web browsers compare host name to CN and/or SAN. Unfortunately the SSID is limited to 32 octets, which may not be long enough for all domain names. IBM X-Force in their paper proposed an additional information element they called the XSSID (eXtended SSID) to support full length and international domain names.

Since then, IEEE released an update to the 802.11 standard called IEEE 802.11u-2011 in February 2011. Under the IEEE Get program, the 802.11u amendment became publically available six months later. It is published at the IEEE Get program page for 802.11.

Overview of Open Secure Wireless 2.0

802.11u defines several key changes to 802.11 that can help enable the possibility of open and secure wireless hotspots. These include an Interworking information element and several Access Network Query Protocol (ANQP) elements that, put together and combined with EAP-TLS without client authentication, may achieve this purpose.

The Interworking element can be used to advertise the availability of an 802.11u capable network, the access network type (for example, free public network), and that Internet access is available.

802.11u capable clients will query 802.11u capable APs for additional information using ANQP. This can include a request for an element called the Network Access Identifier (NAI) Realm list. The NAI Realm list includes one or more NAI Realms (defined according to RFC-4282) and optional EAP methods and authentication parameters to access associated with the realm.

Using this method, an Open Secure Wireless 2.0 hotspot would respond to the NAI Realm list request with the domain name associated with their public certificate, an EAP type of EAP-TLS, and a credential type of 8 - None (server-side authentication only).

Once the supplicant determines to associate with the network (either through pre-configured profiles or user interaction) and authentication begins, the following process would occur:

1. The authentication server sends it's certificate, and other chained certificates, as part of the TLS Server Hello. The server does NOT send certificate_request to the client.
2. The wireless supplicant would then compare the domain portion of the CN and SANs contained in the x.509 certificate with the NAI Realm to verify that the NAI Realm is associated with the x.509 certificate.
3. The client would also perform the rest of standard x.509 validity checking, including compare the issuer with its list of trusted root certificate authorities
4. Optionally the wireless supplicant would process a stapled OCSP certificate to enable certificate revocation checking.

The user interface during this process is key. It is obvious that there will be UI changes for 802.11u clients for listing and connecting to hotspots. It is important that the domain name be prominent in the UI as this is the part that is verified against the certificate. As part of this research I will also be looking into using parts of validated Extended Validation (EV) information from EV certificates.

This process would allow a wireless client to establish a secure connection to an open public hotspot without authentication and without a prior trust relationship. Open Secure Wireless 2.0 leverages existing standards (EAP-TLS and 802.11 amended by 802.11u), and could, if adopted as part of the Wi-Fi Alliance Hotspot 2.0 program, be widely deployed by vendors. With Wi-Fi Alliance and vendor support, it could potentially improve the security of millions of public hotspot users worldwide.

(originally published 2011-11-01)