Hacker News Reader

Comment by trollian | Hacker News Reader

I spent a long time in the past couple of years trying to work out how to deploy secure WiFi and failed to come up with anything great. The biggest challenge is that client support for anything beyond wpa2 psk is virtually nonexistent. The Hotspot 2.0 spec is supposed to make all this easier but it's not widely supported and heavily influenced by carriers whose goals don't always align with everyone else in the space.

View on HN

Here is a nice write-up on how 802.11x security was provided to attendees at 32C3 (they used TTLS with no client certs and users could choose their own user/passwords anonymously)

http://mobilesociety.typepad.com/mobile_life/2016/01/wifi-ce...

Thanks. That's really cool.

Care to elaborate on the client support? AFAIK, all major operating systems support WPA Enterprise (I've used it with Mac, Linux, Windows, iOS and Android).

There is no consistent approach to provisioning. It's possible with high-touch IT staff, but hard to automate in a reliable way.

Unlike WPA PSK, all of the real-world-usable EAP methods used in IEEE 802.1X EAPOL ("WPA Enterprise") require client authentication, which must be provisioned out-of-band. Thus, effectively, they cannot be used for such deployments being discussed.

For example, EAP-TLS, unlike the TLS used in HTTPS, requires a client to provide a X.509 certificate signed by an AP-side trusted authority. This is because people like Jouni Malinen (hostapd/wpa_supplicant), in all their wisdom, decided to spurn RFC 5216 ("While the EAP server SHOULD require peer authentication, this is not mandatory, since there are circumstances...") and completely disallow any and all configuration to disable the client-cert requirement, regardless of any circumstances (such as those behind HTTPS). NYC DoITT is no more equipped to provision X.509 certs for free wifi users than the NYS DMV is to provision X.509 certs for $80 DL/ID card holders (so people can securely prove their identity everywhere).

As trollian stated, Wi-Fi Alliance's "Passpoint" (Hotspot 2.0) does allow for such setups, technically. E.g., the vendor-specific WFA-UNAUTH-TLS version of EAP-TLS does not do client-side authentication at the WPA-level, as per RFC 5216. But WFA-UNAUTH-TLS, even among Passpoint-aware devices, is likely not widely supported.

> Unlike WPA PSK, all of the real-world-usable EAP methods used in IEEE 802.1X EAPOL ("WPA Enterprise") require client authentication, which must be provisioned out-of-band. Thus, effectively, they cannot be used for such deployments being discussed.

I'm not convinced that is really true. Sure, some sort of client authentication is technically required, but I think you can configure the authentication server to accept any authentication without compromising the link security. Or you could auto-provision users on first login or something like that depending on what sort of access you want to give.

> Sure, some sort of client authentication is technically required, but I think you can configure the authentication server to accept any authentication without compromising the link security.

It this supported anywhere? Hence the mention of HS2.0 and my jab at Jouni. (In Jouni's defense, hostapd has made really good progress on this.)

> Or you could auto-provision users on first login or something like that depending on what sort of access you want to give.

This may be supported by Hotspot 2.0 Release 2 (IEEE 802.11u) Online Sign Up (OSU) Server-Only Authenticated L2 Encryption Network (OSEN). I would like to know if OSEN is usable for this scenario.

>> configure the authentication server to accept any authentication

> It this supported anywhere?

Yes. FreeRADIUS can do it. The clients don't notice. I've seen it work. The configuration is a bit tricky though. Not sure about hostapds radius server.

> It this supported anywhere?

I've seen it in place at the Chaos Communication Congress in 2014, I used it with a couple of clients without issues. Not sure what was used or how much effort the configuration was.

Reply on news.ycombinator.com