[Ow-tech] Open Secure Wireless discussion

[Christopher Byrd]

Previously I had tested modifications to the open source hostapd, and both
open source clients (wpa_supplicant) and closed source clients. Because it
had been some time since I last tested this, I recently performed updated
testing.

Hostapd (authentication server)
I was able to patch Hostapd and compile with modifications that cause
Hostapd not to require client authentication for EAP-TLS. This worked
successfully on the current trunk version of Hostapd.

wpa_supplicant (wireless supplicant)
I was able to patch wpa_supplication and compile to remove the if statement
that requires a client certificate to be present before attempting to
connect to a EAP-TLS network. I was able to connect from wpa_supplicant to
hostapd successfully without a client certificate configured in
wpa_supplicant.

Windows 8.1 update 1
I was able to connect from the latest version of Windows (8.1 update 1) to
the modified hostapd. Windows required me to manually configure the
wireless profile to select "smart card or other certificate", and required
that the user have a certificate prior to attempting to connect. However I
tested with a client certificate that was not trusted by the authentication
server, and the connection was successful.

iOS 7.1.1
I was able to connect from the latest version of iOS (7.1.1) to the
modified hostapd. iOS required that the user have a certificate prior to
attempting to connect. However I tested with a client certificate that was
not trusted by the authentication server, and the connection was successful.

If you'd like to try to replicate this yourself or test with additional
clients, you can patch hostapd using the method outlined in my article at
http://riosec.com/files/Open-Secure-Wireless.pdf. Please note that the file
name has changed to 'src/eap_server/eap_server_tls.c', otherwise the change
is the same.

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/cc7a603f/attachment-0001.html>