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

From: Warren Kumari <[email-masked]>
Date: Mon, 9 Nov 2015 09:27:19 +0900

On Sat, Aug 29, 2015 at 4:13 AM, Christian Huitema
<[email-masked]> wrote:
> On Friday, August 28, 2015 2:25 AM, Stefan Winter wrote:
>> To: [email-masked]
>> 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
> [email-masked]
> 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

---

From: David Bird <[email-masked]>
Date: Thu, 12 Nov 2015 05:01:58 +0900

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 <[email-masked]> wrote:

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