[Ow-tech] Open Secure Wireless discussion

Tue May 27 07:02:52 PDT 2014

As this method is based on existing software and protocols, any such
vulnerabilities would be in those original products. In this case, Open
Secure Wireless has been tested with the open source authentication servers
hostapd and freeradius, and a number of wireless supplicants both open
source and proprietary. I would say that security of these products is out
of scope for this discussion; assurance from both intentional and
unintentional vulnerabilities is a larger topic deserving of it's own
discussion.

Thanks,

Christopher

On Tue, May 27, 2014 at 7:47 AM, <dpreed at reed.com> wrote:

> I've become very concerned of late with "planted" insecurities.  How to
> get a vulnerability analysis?
>
>
>
>
>
>
>
> On Tuesday, May 27, 2014 1:22am, "Christopher Byrd" <chris at riosec.com>
> said:
>
>  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/5010afca/attachment-0001.html>