Subject: Re: [saag] opportunistic wireless encryption...

From: Warren Kumari <[email-masked]>
Date: Tue, 30 Aug 2016 21:36:26 -0400

On Wed, Jul 27, 2016 at 5:55 PM, Stephen Farrell
<[email-masked]> wrote:
>
> Hiya,
>
> We had a thread about a year ago on this topic. [1] The feedback iirc
> was "go do it right and use D-H." The authors figure they've now gone
> and done that [2] and have asked me to consider AD sponsoring the work.
>
> I've told them I would so long as we don't find any gotchas and it
> doesn't cause an IETF/IEEE kerfuffle. We're working with IEEE folks
> to check/ensure that that latter is ok via lots of lovely liaising;-)
>
> In the meantime, comments here on the technical meat of this would be
> appreciated if you have time to review.

Having heard no comments in ~1month, Dan and I are forced to assume
that the document is absolutely perfect in every way.
Now, I'm a little surprised by this - I was thinking that there would
be at least one minor typo or something, but apparently not...

Seriously, please review -- it is short, and (I believe) a really good idea.
This gets you (unauthenticated) encryption wherever people use "open"
Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID),
coffeeshops, airports, etc.
Now, like much opportunistic stuff, it doesn't protect against active
attacker - but it does force the attacker to be active (and many
controller based wifi deployments will notice and try protect against
"rouge APs").

It explicitly does *NOT* solve all the worlds ills - we are not
claiming that it does; it doesn't remove the need for things like
VPNs, TLS, etc -- but it does make open wifi suck a bit less, and
that's a good incremental step.
We suggest that users not be informed that they are getting this
protection, so that they don't think that they are getting more than
they actually are...

So, please, thoughts, feedback, etc.

W

>
> Cheers,
> S.
>
> [1] https://www.ietf.org/mail-archive/web/saag/current/msg06595.html
> [2] https://tools.ietf.org/html/draft-harkins-owe
>

-- 
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: Bernard Aboba <[email-masked]>
Date: Tue, 30 Aug 2016 19:09:18 -0700

I have read the document.

It is not a bad idea.  As things stand, IEEE 802.11 security/.1X leaks
meta-data (e.g. the initial EAP-Request/Identity exchange) that the
proposal would protect.  So it has benefits beyond "opportunistic
security", such as in WPA2/Enterprise scenarios.

The problem is something very much like this was originally suggested for
IEEE 802.11 (and rejected) years ago, as part of the work on IEEE 802.11i.
The reason for the rejection at the time was the claim that it was too
"heavy weight" - that a circa 2004 AP implementing the proposal would
consume too much CPU.  Processing power has increased considerably in the
10+ years since then so one could make the claim that the original
objections are no longer valid (if they were even valid at the time).

So to make this more than just "words for the wind" it would be nice to
have a path not just to publishing this document in the RFC series, but
getting it implemented within IEEE 802.11 STAs and APs, which typically
requires  inclusion in the IEEE 802.11 standards (or at least work within
WFA).

Given the upcoming IETF/IEEE 802.11 cooperation meeting, I'm assuming that
this draft has been put on the agenda so that some progress can be made in
that direction, and that discussions have been initiated with the IEEE 802
leadership as described in RFC 7241.   If not, Dan Romascanu (the IETF's
liaison to IEEE 802) can make that happen.

On Aug 30, 2016 6:37 PM, "Warren Kumari" <[email-masked]> wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Aug 2016 10:09:05 +0100

Hi Bernard,

> requires  inclusion in the IEEE 802.11 standards (or at least work within

I agree about implementation and deployment being the key here.

In terms of getting IEEE's "blessing" as a part of that, we did
a chunk of that in and around the last IETF meeting, sent IEEE a
liaison [1] and Dan went to the subsequent IEEE meeting where
they agreed to allocate ANA codepoints for the OWE scheme. (Dan can
elaborate if needed and I'm sure the document will need at least
that update.)

So I think we have the formal inter-SDO bits well in hand. Any
ideas as to how to get running code would be most welcome though.

(BTW, in terms of AD sponsoring this, IEEE's reaction to [1] is
enough to make me sanguine that we're not causing a fuss by doing
this.)

> liaison to IEEE 802) can make that happen.

Yep, that was done, and the topic is on Dan's list of things to
monitor I think.

Cheers,
S.

[1] https://datatracker.ietf.org/liaison/1486/

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 31 Aug 2016 14:37:42 +0300

> controller based wifi deployments will notice and try protect against

This protocol seems to be using IKEv2 IANA registry, but the protocol
does not look like IKEv2, so I think you should fix that by replacing
the protocol and just reuse IKEv2 in OWE, in similar ways than
802.15.9 does for 802.15.4.

Or the other option would be to make your own IANA registry for
this protocol, and not reuse the IKEv2 registry for some protocol that
does not have anything to do with IKEv2 or IPsec, then there would be
no need to change the protocol.

IANA registries are cheap, there is no point of reusing registries for
something that are not releated to the original intention of the
registry. 
-- 
[email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 31 Aug 2016 10:12:10 -0700

On Aug 31, 2016, at 2:09 AM, Stephen Farrell <[email-masked]> wrote:
> So I think we have the formal inter-SDO bits well in hand.

[BA] Traditionally the trickiest part of modifications to IEEE 802.11 security has been the state machine analysis. From what I read in the liaison notes the folks from UM and Stanford who did the validation of the 802.11i state machines have not reviewed this draft. 

As an example, their previous analysis suggested that key exchange occur in authentication so it could provide DoS protection. The way DH is integrated in the draft does not protect against either DoS against the Association exchange or metadata collection. Also adding unauthenticated PMKs to the same cache as authenticated ones could create new vulnerabilities if authorizations are not correctly handled.

> Any ideas as to how to get running code would be most welcome though.

[BA] In practice, the quickest way to get running code would be to introduce it into one of the open source AP distributions. Getting it deployed in existing STAs will be more complicated since this typically requires updates to drivers, many of which are closed source. But perhaps an implementation could be done to an open source driver.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Aug 2016 19:31:21 +0100

On 31/08/16 18:12, Bernard Aboba wrote:
> [BA] Traditionally the trickiest part of modifications to IEEE 802.11
> security has been the state machine analysis. From what I read in the
> liaison notes the folks from UM and Stanford who did the validation
> of the 802.11i state machines have not reviewed this draft.

Ah, didn't know about that. If you could ask 'em to review that draft
or send me contact info, that'd be great. One of the concerns I had
was how to get good review for this if we process it in the IETF and
that sounds like it'd help

Cheers,
S.