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

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Aug 2015 10:53:07 -0400

Hi there all,

I'd appreciate it if folk could have a look at this draft and provide
any feedback.
I'm not sure that SAAG is the right place for it, but I couldn't think
of anywhere better.

https://tools.ietf.org/html/draft-wkumari-owe-01

Note that this is NOT intended to be the be all and end all of secure
wireless, it is simply intended to make open wifi suck somewhat less.
We are not claiming great security (the WPA2 4-way handshake
significantly limits what can be achieved), and so much of the draft /
idea is making sure that users do not get a false (or any) sense of
security - this should be transparent to them.

We also want it to be *really* simple, so that commodity CPE vendors
will include "support" (basically a flag in the beacon) - this removes
other solutions like .1X, etc.

Appreciate your time,
W

-- 
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: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Aug 2015 17:01:38 +0000

> https://tools.ietf.org/html/draft-wkumari-owe-01

I'm concerned that the proposal still leaves even purely passive
adversaries able to decrypt all traffic that begin during the
passive traffic collection interval.  This is considerably weaker
than many other opportunistic security protocols.  With no protection
against a passive adversary who started monitoring before the victim
joins the network, is this still worth doing?

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Aug 2015 13:36:21 -0400

> joins the network, is this still worth doing?

I believe that it is -- I think that the cost to implement this is really
really low (I added PoC "support" to OpenWRT in less than an hour, and
almost all of that was finding a suitable access point in my basement :-)).

I fully acknowledge that this doesn't solve all issues, and doesn't claim
to - but I think that for the negligible cost, the incremental security win
is worth it.

W

>
> --
>         Viktor.
>
> _______________________________________________
> saag mailing list
> [email-masked] <javascript:;>
> 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: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Wed, 26 Aug 2015 11:30:23 -0700

> On Aug 26, 2015, at 7:53 AM, Warren Kumari <[email-masked]> wrote:
> 

I agree with the argument that the minimal effort makes it worth doing.

OTOH, I also agree that something you can’t break passively would be better. How about a connection that’s negotiated with D-H key exchange, but you never verify identities? (Hmmm, is there an EAP mech that would effectively do that?)

How hard will it be to get AP makers to adopt whatever is proposed? Is the additional difficulty of DH really a dealbreaker?

Personal:  [email-masked]
Business: [email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Wed, 26 Aug 2015 18:51:57 +0000

On Wednesday, August 26, 2015 10:36 AM, Warren Kumari wrote:
>
> On Wednesday, August 26, 2015, Viktor Dukhovni <[email-masked]> wrote:
>> ...  This is considerably weaker
> I believe that it is -- I think that the cost to implement this is really really low (I added PoC 
> "support" to OpenWRT in less than an hour, and almost all of that was finding a 
> suitable access point in my basement :-)).
>
> I fully acknowledge that this doesn't solve all issues, and doesn't claim to - but I think that for 
> the negligible cost, the incremental security win is worth it.

You have to decide who you are optimizing for. The administrators would cannot be bothered to set a password for the Wi-Fi? If the router starts doing OWE without their knowledge, there will be a great deal of confusion when legacy UI shows the network as encrypted and users asks the bartender for the password.

So let's assume that OWE is explicitly turned on by the administrators. They take the pain to activate the option in the UI. Why is it simpler than just setting a password? The bartender will still get asked for the password by all the legacy customers, and at that point it does not make any difference whether he has to answer "use the name of the network" or "Open Sesame."

-- Christian Huitema

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 26 Aug 2015 15:11:17 -0700 (PDT)

Hi Warren,

> security - this should be transparent to them.

  It might suck less but it still kind of sucks. You could make it
suck even less by using SAE (an 802.11 authentication protocol that
uses a PAKE to establish pairwise keys). This would address the
limitations you mention in your draft that have to do with WPA2-PSK.

> other solutions like .1X, etc.

  Another option might be to define another vendor-specific Element
to carry DH exponentials. Just tag one on the end of the first two
messages of the 4-way handshake and have each side derive a "pairwise
master key" (PMK, the thing used with the nonces in the 4-way handshake
to derive the data encryption keys) from the DH shared secret. Instead
of having everyone use the SSID as the password, just get rid of the
password!

  regards,

  Dan.

> [email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 26 Aug 2015 22:44:27 -0700 (PDT)

Hi Warren,

  One more thing...

> other solutions like .1X, etc.

  Typically, the AP advertises its security policy with an "RSN element"
in its beacons and probe responses. This lists the unicast and broadcast
ciphers it supports, the capabilities (current broadcast replay counter,
whether an extended key ID is used, etc) and some other stuff. The
client selects a complete subset and adds the "RSN element" when
associating to indicate it is agreeing to do that particular set of
policy and the AP acks it back in the associate response. The policy
offer and selection are confirmed in the 4-way handshake to prevent
downgrade attacks.

  If you're gonna make this look like an open network you're gonna
have to somehow plumb this information into other components of the
frames since the presence of an "RSN element" would mean the SSID is
not open. You could include an "RSN element" in the OWE Vendor-Specific
OWE Support Advertisement element you define but you're gonna need to
somehow get the client to select a proper subset and the AP to ack it
prior to beginning the 4-way handshake. You may want to add the OWE
Support Advertisement (with the "RSN element" embedded in it) to
associate requests and associate responses too. This is getting a
bit ungainly.

  You might want to reconsider making it an open network. You could
specify an encrypted network but use a Vendor-specific "AKM Suite"
in the "RSN element" to indicate OWE. That way it won't show up on
legacy clients as a network that needs a password. Legacy clients
just won't know what the hell it is. This would allow you to keep
the existing "RSN element" in the beacons, probe responses, associate
request/responses, and 4-way handshake. Add on the Vendor-specific
element to pass DH exponentials (what I suggested in my previous
email) and do a DH in the 4-way handshake and I think you've got
something workable. No password needed, resistant to passive attack,
still susceptible to an active MiTH (which is problematic because it
requires the MiTM to impersonate the AP while in range of it),
better than WPA2-PSK, genuinely sucks less.

  regards,

  Dan.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 27 Aug 2015 19:49:21 -0400

On Wed, Aug 26, 2015 at 2:51 PM, Christian Huitema
<[email-masked]> wrote:
> So let's assume that OWE is explicitly turned on by the administrators. They take the pain to activate the option in the UI.

Yup -- the expectation is that my e.g Netgear 42Foo will have 3 radio buttons:
[ ] WPA2-PSK (Enter password here ________)
[X] OWE: A slightly less insecure, but still open network.
[ ] Open: No encryption.

> Why is it simpler than just setting a password? The bartender will still get asked for the password by all the legacy customers, and at that point it does not make any difference whether he has to answer "use the name of the network" or "Open Sesame."

This issue for many places is that they specifically do not *want* a
password, not that they simply cannot be bothered to set a password --
for example, in the Prague Hilton lobby there was a network
("Hilton-guest" or "Hilton-lobby" or something like that). It was
intentionally unsecured, so that people didn't have to go along, stand
in the long line for registration and then be told "Oh, yeah, the
password is Password"".

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) we could get the *huge* majority of devices doing this before
the document is published, and way before CPE starts including the
button.
Even for devices that don't get support added -- after I've asked at 3
coffeeshops what the password is, and they all say "It's the same as
the network name..." I'm likely to start trying the network name if
the SSID name sounds like it may be open (e.g is the name of the
establishment, contains -guest, -public, or better yet, -owe).

---

From: Warren Kumari <[email-masked]>
Date: Thu, 27 Aug 2015 20:09:51 -0400

> How hard will it be to get AP makers to adopt whatever is proposed? Is the additional difficulty of DH really a dealbreaker?

Unfortunately I believe that it probably is a deal breaker, or, at
least, would take so much time that it wouldn't be worth doing.

I believe that the right place to do this sort of work (adding public
key agreement) is in the IEEE, probably in the 802.11 group. I am not
participating in the IEEE at the moment, but am beginning to wonder if
I should participate and see if a public key agreement can be added to
WPA. Adhoc / mesh networks already have a solution to this
("Simultaneous Authentication of Equals" (SAE - 802.1s)). I'm guessing
that there is a good reason that is isn't also in normal wifi; I
believe that Dan Harkins was deeply involved in the development of SAE
- perhaps he can shed some light on this?

W

---

From: Warren Kumari <[email-masked]>
Date: Thu, 27 Aug 2015 20:35:21 -0400

On Wed, Aug 26, 2015 at 6:11 PM, Dan Harkins <[email-masked]> wrote:
> uses a PAKE to establish pairwise keys).

Hah, this will teach me to read all the mail in a thread before
replying -- I just posted something mentioning you and SAE. :-)

Does SAE work with access points or is it only defined for ad hoc /
mech networks? And if it is defined for APs, does current consumer CPE
(dlink, linksys, netgear, etc) support it?

I'd really like this to be a trivial thing for both APs and clients to
include support for, and would much rather have a crappy but better
than plaintext solution now instead of a great solution many years in
the future. I'd like to see *something* deployed, and then we can work
on improving it as time goes by...

The current document has a Sub-type field ("Sub-type identifies the
version of the OWE protocol. Currently only 0 is defined." ) - my
cunning plan was to use that (if needed) to eventually signal that the
underlying network supports something better than the current 4WHS --
although I'm guessing clients would be able to figure that out from
other information advertised by the AP.

> This would address the

This is probably worth discussing more, but this also feels more like
a larger scale change, and, while worth doing, I think it would be
better done in parallel...

Thank you,
W

---

From: Stefan Winter <[email-masked]>
Date: Fri, 28 Aug 2015 11:24:48 +0200

Hi,

> icon)

Or, for wireless sniffing kit of your choice:

1) try to decrypt with the SSID as the password
2) win!

Seriously, this way of encrypting traffic stops only one attacker group:
people with a Wi-Fi card in promiscuous mode who use Wireshark to look
at packets ("us" :-) ).

Everyone with only a /slightly/ serious attitude just continues to do
what they do with their upgraded sniffing gear.

I don't see how this improves security in a significant enough way. And
the cost for it *is* high - convince all OS manufacturers to do
something && convince AP admins to do something.

> we could get the *huge* majority of devices doing this before

Funny: right now, an attacker would need to go to the shop to get that
same information. In your future deployment, the binding of SSID to
passphrase comes automatically.

(Besides, my guess is that sniffing gear today probably tries the SSID
as a passphrase anyway - simply because it is rather common).

So, what exactly are we winning with this approach?

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Christian Huitema <[email-masked]>
Date: Fri, 28 Aug 2015 19:13:49 +0000

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

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.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Fri, 28 Aug 2015 22:11:17 +0000

On Friday, August 28, 2015 12:14 PM, Christian Huitema wrote:
> ...
> 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.

In fact, there is a way out, but it requires a bit more coding than Warren's simple hack.

Suppose that instead of using WPA2-PSK, the access point would be using 802.1x and EAP-Password (RFC 5931). 

Suppose that in addition, the AP will send an information element explaining that it uses the OWE convention, which means that the user name is "anonymous" and the password is the name of the SSID.

The updated station automatically proceeds with the authentication. This results in the derivation of a one-time session key, which is not vulnerable to dictionary attacks and the like. It is still vulnerable to MITM attacks, but that's kind of the definition of opportunistic security.

A variation of the implementation would define that the user name is "anonymous" and that the user needs to enter a password. That variation would be as easy to use as WPA2-PSK, but would be protected against dictionary attacks.

Now of course that requires a fair amount of coding: implement this EAP Password variation in the AP, and make sure it is available in the clients. But we would have actually improved Wi-Fi security, without compromising the user experience.

-- Christian Huitema

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Aug 2015 21:24:26 -0400

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

I wish we'd stop trying to solve layer-5 problems at layer-2.

Due to the proliferation of the belief that access to the network is
"controlled", we have endless devices that lack proper authorization
interfaces.

I'd much rather we bought every starbucks as project and a sniffer, so that
everyone could see what information they are disclosing.

That's why I don't care about making wifi more "secure".

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Josh Howlett <[email-masked]>
Date: Fri, 28 Aug 2015 10:47:22 +0100

> So, what exactly are we winning with this approach?

+1

I would also be concerned around with unintended consequences arising from users drawing incorrect expectations of the security yielded by this approach. It does confer some additional protection but in a very qualified way; and in ways that are impossible for a layman to understand. It could encourage users to attribute too much trust in the network, in ways that they wouldn't with an "open" network. This is a general issue with OE, of course.

FWIW, at least in the UK most public WiFi access is captive portal, provided by a relatively small number of operators. In practice therefore I doubt there would be a market for this.

Josh.

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.