[OpenWireless Tech] EAP-UNAUTH-TLS (EAP-SSL, really) and IEEE 802.11u

Tue Dec 18 21:44:10 PST 2012

Greetings,

As it turns out, this "other guy on the Internet" is lurking on here as
well. I really appreciate your time reading my blog posts, and thank you
for sharing this idea and the potential promise of the approach with the
list.

I agree that unauthenticated EAP-TLS (what I've labeled Open Secure
Wireless) could be a real solution to providing easy to use open and secure
wireless access. In addition to providing a secure way to implement EFF's
Open Wireless movement, it could help secure millions of users of open
commercial hotspots and guest wireless networks as well.

It's encouraging to see an initial implementation in hostap. I think
setting the EAP Method subfield to EAP-TLS [13] and the authentication
parameter Credential Type [5] to None [8] might be better than a hostap
vendor-specific EAP type to indicate Anonymous TLS connection, but this is
a minor detail. My biggest hurdle has been trying to get vendors to add
support in commercial products; for Open Secure Wireless to be
realistically viable, changes to closed-source client supplicants and
authentication servers would be needed in addition to rounding out support
in FOSS wireless software.

Also as you mention the 802.11u amendment (now incorporated as part of the
802.11-2012 standard) added several features that are desirable for Open
Secure Wireless. For anyone reading that is curious to see the standard,
the entire standard is now available for free on IEEE's web site under the
GET IEEE 802 program at http://standards.ieee.org/about/get/802/802.11.html.

One of the most frequently asked questions about Open Secure Wireless is
about certificate validation and the potential for evil twin hotspots. It
is important to note that this same concern exists for current EAP-TLS and
EAP-PEAP deployments where the server name is not manually configured on
clients. However, with 802.11-2012 a wireless supplicant could compare the
interworking domain name with the x.509 certificate CN or SubAltNames, just
as web browsers compare the hostname in the URL with the x.509 certificate
when connecting to HTTPS sites. This would solve this issue both for Open
Secure Wireless, and improve security for existing EAP-TLS and EAP-PEAP
enterprise uses.

I hope that the Open Wireless movement considers embracing Open Secure
Wireless, and I further hope that someone reading this list has connections
with the vendors and/or the Wi-Fi Alliance to help raise visibility and
gain support in commercial products. I would be glad to answer any
questions about the proposed solution.

Thanks,

Christopher Byrd
twitter.com/@cbyrd01
www.riosec.com

On Tue, Dec 18, 2012 at 4:04 AM, <californiajack at tormail.org> wrote:

> Hello,
>
> For some unknown, likely beureacratic and political reason, every EAP-TLS
> implementation in SOHO wireless routers breaks with its HTTP counterpart,
> HTTPS, when implementing SSL/TLS in one spectacularly stupid and invasive
> way: It *requires* client-side X.509 certificates, presumably with a valid
> CA trust chain, with all the beaureacratic and logistical nightmares that
> involves.
>
> So, imagine my amazement when I discovered I was not alone in my
> fustration. It turns out this other guy on the Internet, Christopher Byrd,
> had noticed the same thing, but unlike me went about trying to fix
> it.[1][2] And, in my opinion, he fixed it -- or at least caused it to be
> fixed. He wrote of a breakthrough (but hitherto never published to my
> knowledge) solution to this Wifi-Age question: just implement TLS for EAP
> like TLS for HTTP. I was like ZOMG! He actually said it! I was amazed it
> could be so simple. And it turns out, technically, RFC 5216 (which
> implements EAP-TLS) doesn't really say you can't do it like HTTPS.. And so
> Byrd did it: he implemented it. And I pondered on this newfound
> technological advance for a long time after I saw the posts. What did this
> mean? What was the impact of this? Was it possible? I just could not wrap
> my head around it. Was it me going crazy, seeing some obvious error in
> widespread use, or did these EAP-TLS implementers just know something I
> didn't, some obvious reason, that something was just innate about Wifi
> that required client certificates, like the RFC, or that service like
> HTTPS would just never work for whatever reason, like lack of
> implementation. I was encouraged, motivated, but still somewhat fustrated.
> I kept reading the RFC.. Why? Why? I just don't see why.
>
> And Byrd had other things to say, especially on this new protocol, IEEE
> 802.11u. Sometime around this time I also began to make sense of HS2.0
> commits to the HostAP daemon, and the IEEE 802.11u protocol itself. Byrd's
> post opened up my eyes to the real possibility of an "Open Wireless"
> project. (And here we are.) Going through the Git shortlogs for the HostAP
> daemon, as I often do when I'm bored, I had noticed several changes that
> spurred my interest. The commits of immediate importance were
> d13f9857f8cb7b90e78bf4725f4765f233606eb5 and
> 065d2895b4693e8c923580dbfa31123297c8bb7d on 22 August 2012.[3][4] They
> added support for a new vendor specific EAP type, UNAUTH-TLS, complete
> with a new "SMI Network Management Private Enterprise Code" unique to the
> hostapd/wpa_supplicant project. The changelog explained it thus:
>
> """Add UNAUTH-TLS vendor specific EAP type
>
> This EAP type uses a vendor specific expanded EAP header to encapsulate
> EAP-TLS with a configuration where the EAP server does not authenticate
> the EAP peer. In other words, this method includes only server
> authentication. The peer is configured with only the ca_cert parameter
> (similarly to other TLS-based EAP methods). This method can be used for
> cases where the network provides free access to anyone, but use of RSN
> with a securely derived unique PMK for each station is desired.
>
> The expanded EAP header uses the hostapd/wpa_supplicant vendor
> code 39068 and vendor type 1 to identify the UNAUTH-TLS method.
>
> Signed-hostap: Jouni Malinen <j at w1.fi>
> """
>
> Again, I was like ZOMG, thinking, in sum, we have:
>
> * IEEE 802.11i RSN-secured associations
> * w/ standards-compliant, anonymous TLS authentication
> ** w/o need for burdensome client certificates (server authentication only)
> * IEEE 802.11u
> ** w/ DNS advertisements (NAI Realms) in leiu of BSSIDs
> ** w/ anonymous EAP-TLS/EAP-UNAUTH-TLS and global IPv6 support
> advertisements, among many other
> ** w/ possible sever TLS X.509 / DNS authentication
> * w/ working implementations
> * (w/ required IEEE 802.11w MPF?)
>
> I think this is a breakthrough moment. Technologies will have to get
> upgraded for this new pervasive (and increasingly automated) mobile
> internet age, so why not make Open Wireless ready for it, at the cutting
> edge? Supporting EAP-UNAUTH-TLS would provide RSN-protected but
> server-authentication-only TLS, like the modern WWW HTTPS experience. I
> also think setting the NAI Realm information (nai_realm) to something like
> "0,openwireless.org,13[8,5:9,5:10]" would enable a more useful and
> manageable Wifi experience, and other IEEE 802.11u things like
> advertisements for Terms of Service and globally-routable IPv6 address
> support in lieu of imposing, protocol-breaking (think IPsec and HIP) hacks
> like HTTP-redirects and IPv4-DNAT, could all be part of this new (but old)
> Open Wireless movement.
>
> Using the classic quote: lets "Think Big". Lets make this work.
>
> [1] http://riosec.com/open-secure-wireless
> [2] http://riosec.com/open-secure-wireless-2.0
> [3]
>
> http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commit;h=065d2895b4693e8c923580dbfa31123297c8bb7d
> [4]
>
> http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=commit;h=d13f9857f8cb7b90e78bf4725f4765f233606eb5
>
> --
> californiajack
>
> _______________________________________________
> Tech mailing list
> Tech at srv1.openwireless.org
> https://srv1.openwireless.org/mailman/listinfo/tech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/tech/attachments/20121218/116b93a5/attachment.html>