Re: [saag] Would love some feedback on Opportunistic Wireless Encryption

[David Bird <[e-mail]>]

I believe hostapd already has support for an EAP "UNAUTH-TLS" method
whereby the client station doesn't authenticate itself, but can
"authenticate" the server (much like your typical HTTPS connection). The
keying material, like any EAP-TLS based method, comes from the TLS layer.
This method could be used with or without a RADIUS server (assuming the
authenticator has an EAP engine, like hostapd optionally does).

A limitation, however, is that the client can't distinguish between
UNAUTH-TLS and other more secure EAP methods until it tries to connect -
and will show the network as being secure. And, having a certificate
warning/acceptance dialog perhaps with a "You are really joining a public
access network, not a 'secure' network" warning might be scary for users.

Maybe if the beacon (RSN IE) could indicate 802.1X -and- 'public access'...


On Mon, Nov 9, 2015 at 9:27 AM, Warren Kumari <[e-mail]> wrote:

> On Sat, Aug 29, 2015 at 4:13 AM, Christian Huitema
> <[e-mail]> wrote:
> > On Friday, August 28, 2015 2:25 AM, Stefan Winter wrote:
> >> To: [e-mail]
> >> Subject: Re: [saag] Would love some feedback on Opportunistic Wireless
> >> Encryption
> >>
> >> Hi,
> >>
> >> > You are right that there will be some initial legacy issues -- but if
> >> > we can convince Windows 10 Mobile, Apple iOS, and Android willing to
> >> > include support (which seems likely, "support" is trivial - basically
> >> > 1: try the SSID as the passphrase and 2: don't bother showing a lock
> >> > icon)
> >>
> >> Or, for wireless sniffing kit of your choice:
> >>
> >> 1) try to decrypt with the SSID as the password
> >> 2) win!
> >
> > It is a bit more complicated than that, but not much. With WPA2, the
> traffic is not directly encrypted with the password, but instead with a key
> derived from the password, the SSID, an Access Point nonce, and a Station
> nonce. Even if the password is shared, each client uses a different set of
> nonce, and thus a different key. However, the nonce are transmitted in
> clear-text during the initial exchange. That means the attack goes as:
> >
> > 1) Capture the initial exchange between Station and Access point, and
> remember the nonce.
> > 2) Assume that the SSID is the password and try to derive the per
> station key using the nonce.
> > 3) Win!
> >
> > This is in fact the main limitation to Warren's approach. The proposed
> OWE system will still be vulnerable to passive listener attacks, and is
> thus not much of an improvement over open networks.
> >
> > Note that this is also a limitation of the "public password" approach,
> as in "ask the password to the bartender." We can hypothesize that mass
> surveillance systems will quickly build a database linking networks, SSID
> and public passwords. After all, the initial WPA2 exchange carries
> authentication codes that are the hash of the nonce and the password, which
> trivially enables dictionary attacks. That means the procedure will be:
> >
> > 1) Capture the initial exchange between Station and Access point, and
> remember the nonce.
> > 2) Retrieve the password associated to the SSID from the database.
> > 3) Derive the per station key using the nonce.
> > 4) Win!
> >
> > Thinks would be different if instead of just sending the nonce in clear
> text the WPA2 exchange used some variation of Diffie-Hellman or EKE.
> Attackers would need to move from "passive listening" to "actively
> implement MITM attack," and we believe that might curtail mass surveillance
> efforts. But that's not the case.
>
>
>
> ... and a quick update (which I thought I'd sent earlier, but
> apparently not) - when we wrote the initial document, we were well
> aware of the issues with the 4 way handshake, but decided to write the
> document in the IETF context anyway. This was because I figured that a
> better than nothing approach was, well, better than nothing. We were
> aware that the IEEE was the correct layer to get this done, but, well,
> I don't participate there much, and figured that it would be a hard /
> very slow process.
>
> Dan Harkins (who most of you know), is an IEEE regular, has nicely
> rewritten this into IEEE language, and is getting strong interest /
> making progress there. This basically does what everyone has been
> suggesting (and I'd originally wanted to do, but couldn't) -- a public
> key exchange between the AP and STAtion (think DH).
>
> This is obviously much much less hacky than the "just pretend that the
> user typed the SSID as the passphrase, and don't show any indications
> (to avoid having the user believe that they have "security")".
>
> W
>
> >
> > -- Christian Huitema
> >
> >
> >
> >
> >
> > _______________________________________________
> > saag mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/saag
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>