[Ow-tech] Open Secure Wireless discussion

Christopher Byrd chris at riosec.com
Mon May 26 22:17:47 PDT 2014


In order for Open Secure Wireless to be viable, changes to the wireless
supplicants would be necessary. This includes both open source clients
(like wpa_supplicant) as well as closed source products.

First, support for 802.11u interworking discovery features must be enabled.
Second, clients must be able to attempt to connect to EAP-TLS networks
(perhaps just those that indicate Open Secure Wireless support) even when
they don't have a client certificate available. Third, visual changes
should be made to make it a better user experience.

For visual changes, when looking at the list of available wireless
networks, the supplicant should use a new icon to indicate Open Secure
Wireless networks. Ideally, it would also present a visible indicator for
whether the network is private, public, or allows guest access. Also,
because validation of the domain name is important, the NAI Realm received
in response to the ANQP query should be displayed prominently in addition
to the SSID.

For example, in the available wireless networks list, the wireless client
might display "demo.riosec.com (via SSID: RioSec)" alongside an icon to
indicate that this is a Open Secure Wireless network, and that it provides
public Internet access. Once the user selects to connect, the client should
compare the NAI Realm to the CN or SubAltName for a matching name or
wildcard (e.g. SubAltName contains *.riosec.com, CN contains demo.riosec.com,
etc.) If they match and the rest of validation succeeds, connection should
proceed silently. If they do not match, the user should be presented with
an appropriately dire warning message.

Please let me know if you have feedback or ideas where this could be
further expanded.

Thanks!

Christopher
chris at riosec.com
twitter.com/cbyrd01


On Tue, May 27, 2014 at 12:10 AM, Christopher Byrd <chris at riosec.com> wrote:

> Because of some renewed interest in Open Secure Wireless as a potential
> technology for the Open Wireless project, I am recapping a summary of what
> I am calling Open Secure Wireless below. You might want to also look at my
> previous blog posts, here: http://riosec.com/open-secure-wireless-2.0.
>
> Open Secure Wireless is the application of existing wireless security
> protocols in an uncommon configuration to allow for secure guest or public
> wireless hotspots.  There are three main problems to be addressed: First,
> current wireless technology allows for a connection to be open or secure,
> but not both. Second, existing enterprise wireless protocols lack default
> server authentication. Third, currently wireless hotspots operators are
> unable to communicate whether their network is intended for public access.
> The Open Secure Wireless information that I have published attempts to
> address these concerns.
>
> To address the lack of encryption of open (defined as not requiring
> network-level client authentication) wireless networks, I propose to
> consider using EAP-TLS without client authentication. This is specifically
> allowed for under the existing EAP-TLS protocol standards. In this mode,
> the authentication server proves it's identity (using standard TLS
> certificate authentication), but does not request the client to
> authenticate prior to establishing a secure connection. This is identical
> to the way that TLS commonly works with most HTTPS web sites. Client
> authentication is an option with HTTPS web sites, just like it is with
> wireless EAP-TLS, the difference being that it's rarely used with HTTPS,
> but ubiquitous with EAP-TLS.
>
> For default server authentication, it may be possible to tie server
> authentication to the 802.11 Interworking network selection process; when a
> client selects to connect to a NAI Realm presented in the list of available
> NAI Realms (in response to the client's ANQP query), the client should
> validate that the server certificate presented by the authentication server
> matches the name of the NAI Realm by default. As a default behavior this
> should be able to be changed in the client configuration. By validating
> that the NAI Realm matches the CN or SubAltNames from the server
> certificate by default, the client can be assured that the person operating
> the wireless network was able to verify domain ownership when obtaining the
> signed server certificate.
>
> Hotspot operators may be able to further utilize interworking features of
> 802.11-2012 (as introduced in 802.11u) to advertise open secure wireless
> networks.  For example, to communicate the intention the access network
> type element can be configured as "Free public network" or "Private network
> with guest access".  To identify the network as Open Secure Wireless, the
> hotspot operator could set EAP-Method subfield as EAP-TLS, and
> authentication parameter set to "8 - None".
>
> Support for these features would require changes in wireless supplicants,
> which I'll cover further in my next post.
>
> Please let me know if you have any questions or feedback.
>
> Thanks,
>
> Christopher
> chris at riosec.com
> twitter.com/cbyrd01
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/mailman/private/ow-tech/attachments/20140527/da02eb43/attachment.html>


More information about the Ow-tech mailing list