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

[californiajack at tormail.org]

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