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

[californiajack at tormail.org]

I am glad to see you respond, and I am even gladder to see this list get a
more of a protocol-level discussion. It is at this protocol and
implementation-level that Open Wireless will be made, or will fade. These
discussions are important, because at the protocol-level, we have the
benefit (and pain) of dealing with a certain amount of academic and
mathematical rigour, no doubt to the influence of those early members of
ISOC like Jon Postel and Vint Cerf.

-----BEGIN RANT-----
Case in point, a comment from Open Wireless's front page recently jumped
out at me:

"""... that I run an open wireless network at home. There's no password.
There's no encryption. Anyone with wireless capability who can see my
network can use it to access the internet."""

Its just amazing to see that the EAP-TLS implementers messed up so bad we
get to see sentences like "Bruce Schneier ... run an open wireless network
at home ... no encryption ..." The shame! I can already hear the
detractors. "Who needs SSL or SSH when you have IPsec!" Are we going to
have this debate again? Just because there is HTTPS shouldn't mean
abandoning encryption at the other OSI layers. The solution is "defense in
depth". This solution could provide it. And what is no one uses IPsec?
This is the missing link. Here, we see the widespread impact of the poor
implementation of EAP-TLS which has contributed to a common fustration
that you must have *all* of the following:

1. Identification ("Hey! Who are you!")
2. Authorization ("And what are you doing in my yard!")
3. Privacy ("I'm in the middle of something here!")
4. Authentication ("Oh yeah!? And I'm Santa Claus! Let me see some ID,
buddy!")

... Or you can't have *any*. People don't understand that you can have
privacy ("encryption") without requiring authorization or authenticed
identities. (Or at least according to the IETF standards.) I assume that's
what Open Wireless had in mind, as to the client/user:

1. no identity needed (anonymous, like WPA-PSK or w/ RSN disabled)
2. implicit authorization (the "open" in "Open Wireless")
3. encryption (yes, HTTPS is fine, IPsec is swell, Tor is awesome, but
802.11w MFP are nice too)
4. no authentication needed, because its anonymous

But, since current EAP-TLS implementations don't allow goal 1 and 4, they
can't use it, and the only other mechanism that do are WPA-PSK, which
doesn't support 2, and with RSN completely disabled (Bruce Schneier's
solution, LOL), which doesn't support 3. Given this EAP-TLS breakage,
people have to choose between implicit authorization or encryption, but
never both. That's horrible. Its even more horrible that the IETF can't
fix it, because IETF did their job correctly, with a rigour that we
expect. Its just an implementation detail. Ouch. *That* is a problem,
indeed, especially when your talking "telecom" and "implementation" in the
same sentence. Nothing speaks "GTFO, tits or no tits" and "we watch you
while you sleep -- then sell the information to the Department of Defense
aka NSA" quite like telecom.
-----END RANT-----

So, what to do? I think the supplicant issue could possibly be easy: a
singleton client certificate, any really, distributed to everyone. The
real issue is getting the 802.1X Port Authenticator (the AP) to just
ignore the certificate and identity, to accept any certificate from any
identity, or to allow this singleton certificate with a singleton
identity/any identity. (Or, the best solution, just not ask for it in the
TLS exchange.) In addition, the hostapd/wpa_supplicant project seems to
have many Android related commits; they likely have considerable input
into Android's next-generation wireless support. (This may be the impetus
behind the UNAUTH-TLS move as well, as part of a classic strategy for
marketing purposes.) Android and UNAUTH-TLS could solve the problem of UI,
but also would bind the solution to the hostapd/wpa_supplicant project
instead of to the IETF and IANA. And since the EAP-UNAUTH-TLS
implementation is a EAP-TLS RFC-standards-compliant implementation, there
is not hope of a separate RFC and IANA assignment for it; it will always
be a vendor hack. The shame!

And although you and I know, many may ask: "why not just use PSK"? It begs
repeating: with EAP-TLS you get forward secrecy and authentication of the
AP. Why should you care about athenticating the AP in Open Wireless?
Because what you really want isn't strong authentication, but what the
Better-Than-Nothing-Security (BTNS) WG called "continuity of association"
in RFC 5387. (BTNS completely ignored EAP for its protocol, for the same
reason that the ABFAB WG may choose to just change the EAP standard, as in
draft-winter-abfab-eapapplicability.) This "continuity of association"
just gaurantees that the client is talking to the same AP it was a minute
ago, something WPA-PSK cannot provide, and which without (and 802.11w MFP)
any five year-old (read "script kiddie") with aireplay-ng can wreak havok
with.

As I understand it, Open Wireless is just a movement, not an implementor.
That is to say, each and every person who puts up an Open Wireless hotspot
is doing so on his own initiative, without very much collaberation or
coordination with the OpenWireless.org team. This means they may have to
generate + configure their own X.509 certificate. And this is where the CN
/ SubAltNames solution may cause problems. What should the independent
operator use for these values? Should they match the 802.11u NAI Realm?
Could Open Wireless act as a X.509 CA for these networks, with appropriate
constraints? Should it? If they use OpenWireless.org in the X.509 and the
NAI Realm, then they would match but conflict with each other. If they use
some other DNS in both, they would match and not conflict with each other,
but not be linked to OpenWireless.org and require their own PKI. Also,
wasn't there something in the 802.11u specifications that discusses some
sort of federated networking model, something about roaming consortiums?
How could that model be fit for use with the OpenWireless.org model?

Because even with this new EAP-TLS, there is a question of
zero-configuration. My grandma cannot generate X.509 certificates, or
configure OpenWireless.org as a CA. We really need EAP-BTNS here. (Dammit,
BTNS! "The following areas are outside this scope of BTNS ... Use of the
Extensible Authentication Protocol (EAP) ... In contrast, the BTNS goal of
general applicability encompasses many areas other than network access
..." This makes no sense! A problem area is more specific than, BUT
WITHIN, your scope, so you fucking unscope it?! SHAME! Same goes for the
DANE WG and IPsec! TLS isn't the only protocol that could use DNSSEC for
X.509 authentication! No, IPsec cannot use DNSSEC to authenticate
IN-BAND-provided credentials without TLSA records! Quit specifically
unscoping particular sub-problem domains! OK, I just had to say that..
Because now only IPsec has BTNS and only TLS has DNSSEC-secured X.509
certificate *attestations* via TLSA RRs. Imagine if only PPP had EAP!)
BTNS has an explicit lack of a rigid authentication infrastructure, eg the
"continuity of association", which is exactly what Open Wireless wants.
This, however, is an even harder solution that just following RFC 5216 by
not having the EAP-TLS implementation make policy decisions that client
certificates are needed for Open Wireless..

> 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
>>
>