[Ow-tech] Open Secure Wireless discussion

Christopher Byrd chris at riosec.com
Mon May 26 22:10:56 PDT 2014

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.


chris at riosec.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/mailman/private/ow-tech/attachments/20140527/bf9a848f/attachment.html>

More information about the Ow-tech mailing list