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

From: Paul Wouters <[email-masked]>
Date: Fri, 2 Sep 2016 09:38:08 -0400

On 08/31/2016 07:37 AM, Tero Kivinen wrote:
> Warren Kumari writes:
>> 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").

So at the coffe eshop, where everybody knows (my name) the essid and the password,
do I not get protection against passive attacks already?

How much harder are we actually making it for the attacker to switch from attacking
this WPA-PSK with known psk to OWA? Since we are not even causing the attacker to
go from passive to active if I understand things correctly (which I might not, as I'm
not very knowledgeable with IEEE protocols)

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

> IANA registries are cheap, there is no point of reusing registries for
> something that are not releated to the original intention of the
> registry. 

I agree with Tero that you should probably not use the IKE registry. You
could make your own.

If you really want IKEv2 Opportunistic IPsec, I gave a demo last week at the Linux Security
Summit, using IKEv2 with anonymous clients to letsencrypt based server authentication.

http://events.linuxfoundation.org/sites/events/files/slides/LinuxSecuritySummit-2016-OE-16x9.pdf

Code and install instructions while not yet merged in upstream: https://nohats.ca/LE/

Demo server available: letsencrypt.libreswan.org

Next step for Opportunistic IPsec is DNSSEC based authentication.

Paul

---

From: Warren Kumari <[email-masked]>
Date: Fri, 2 Sep 2016 12:14:34 -0400

> do I not get protection against passive attacks already?

​Actually, not really -- the WPA2-PSK four way handshake has some issues -
if the attacker is around when you associate (or can force you to
disass​ociate and reassociate), and knows the PSK, they can derive the same
key as you, and so (passively) watch all yer traffic...

https://en.wikipedia.org/wiki/IEEE_802.11i-2004
Or, for the lazy, https://wiki.wireshark.org/HowToDecrypt802.11

> this WPA-PSK with known psk to OWA?

My main motivation for this is not to replace / whatever WPA-PSK.
I'm not sure what coffeeshops you are going to, but the ones I frequent
(and my dentist, and "ietf-hotel", and "hhonors", and "DullesAirport_Free",
and Schipol "Airport_Free_Wi-Fi", and ...) don't do WPA2-PSK -- this is
simply designed to make "open" WiFi suck less.
Sure, perhaps there shouldn't be open Wifi -- but there is, and there will
continue to be for a long time. Perhaps everyone should use Hotspot, but,
well they don't...

OWE doesn't remove the need to end-to-end encryption, and doesn't claim to
-- we should continue to work on end-to-end. But lots of users don't (and
won't) run a VPN, and many protocols, including common ones like DNS (Hi,
DPRIVE!) are not encrypted yet.

We don't intend the user to get any sort of notification / feedback that
they are getting encryption, and so they should not get any sort of false
sense of security. This should all happen "under the hood" - the users
should not get a "lock icon" when scanning (or when connected), and so
should still feel just as unsafe as they currently do :-)

> Since we are not even causing the attacker to

​Okey dokey. Asking for a registry is easy - it just seems like a waste if
it is only going to have a value or two...

-- 
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: Fri, 2 Sep 2016 10:51:18 -0700

> do I not get protection against passive attacks already?

[BA] Some coffee shops use WPA2 with a password, but most do not, so traffic is sent in the clear. That is the scenario this proposal is addressing.

> this WPA-PSK with known psk to OWA?

[BA] I do not believe this proposal provides benefits in WPA2 or WPA2/enterprise scenarios, since no protection is provided for metadata exchanged prior to WPA2/enterprise key derivation or for the 4-way handshake itself.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 2 Sep 2016 10:54:56 -0700

On Sep 2, 2016, at 9:14 AM, Warren Kumari <[email-masked]> wrote:
> 
> ​Actually, not really -- the WPA2-PSK four way handshake has some issues - if the attacker is around when you associate (or can force you to disass​ociate and reassociate), and knows the PSK, they can derive the same key as you, and so (passively) watch all yer traffic...
> 

[BA] This attack could potentially be partially addressed by doing the DH exchange earlier (e.g. as part of Authentication) so that the Association exchange and the 4-way handshake could be protected.

---

From: Paul Lambert <[email-masked]>
Date: Fri, 2 Sep 2016 20:27:47 +0000

>
>On 31/08/16 03:09, Bernard Aboba wrote:
>> 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).
>
>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.)

On blessings Š I¹ve observed that this specific OWE proposal was
rejected multiple times by IEEE 802.11. The creation of an
Internet Draft in this forum is a side-channel being used
to side-step the IEEE process.
      https://mentor.ieee.org/802.11/documents?is_dcn=Harkins

The concerns expressed in the IEEE forum included:
 - OWE is not a good/complete solution
   - it does not prevent spoofing/active attacks
   - adds complexity without preventing attacks
 - inclusion of OWE would detract from the development
   and fielding of a Œgood¹ solution.

Using the IETF as a side-channel for developing Wi-Fi specifications
may actually be a good thing (IMHO). However, the successful creation
of a liaison agreement should not be construed as acceptance or
interest to adopt a specification by the Wi-Fi industry.

The Wi-Fi industry has a long list of emerging special
purpose security protocols that include:
 - SAE (a PAKE based on rfc7664 that may be used to strength WPA2-Personal)
 - Hotspot 2.0 (special X.509 certificates and
   infrastructure for secure enrollment and AP authentication)
 - Fast Initial Link Setup (FILS IEEE 802.11ai)
    - PKEX (PAKE-like key introduction)
      
https://mentor.ieee.org/802.11/dcn/16/11-16-1100-03-00ai-mods-to-pkex.docx
    - EAP-RP based fast authentication
      https://www.qualcomm.com/invention/research/projects/wi-fi/80211ai
      See figure 10 of:
http://www.cisco.com/c/en/us/solutions/collateral/service-provider/service-
provider-wi-fi/white-paper-c11-731038.pdf
 - Wi-Fi Alliance DPP
     http://www.wi-fi.org/who-we-are/current-work-areas
     Includes: several authentication protocols (PKEX, DPP Auth, Connector
Exchange)
 - OCF Security (IoT related, but would be used by Wi-Fi devices)
   https://openconnectivity.org/resources/specifications
 - and now OWE 
 
Paul

>
>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.)
>
>> 
>> 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.
>
>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: Dan Harkins <[email-masked]>
Date: Fri, 2 Sep 2016 20:44:00 -0700

Hi Bernard,

On 8/30/16 7:09 PM, Bernard Aboba wrote:
>
> 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).
>

This will probably appear in hostapd/wpa_supplicant a very short
time after the draft is stable. That will make it naturally appear
in AP and client implementations through code syncing. Once that
happens there will be some additional work to enable it. For
instance, some java goo will have to be added to Android so it
appears in the list of APs appropriately and AP vendors will need
to add a knob and/or some UI interface to turn it on an SSID.

   There is discussion within WFA on some "lightweight" hotspot
usage and the subject of OWE has been brought up. The secretive
nature of that organization makes the whole process a bit opaque
but I'm hopeful OWE implementations will be able to go through
the WFA certification process.

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

   There's an upcoming IETF/IEEE802 meeting next Friday I believe and
this is on the agenda.

   regards,

   Dan.

> On Aug 30, 2016 6:37 PM, "Warren Kumari" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Wed, Jul 27, 2016 at 5:55 PM, Stephen Farrell
>     <[email-masked] <mailto:[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...
>
>     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
>     <https://www.ietf.org/mail-archive/web/saag/current/msg06595.html>
>     > [2] https://tools.ietf.org/html/draft-harkins-owe
>     <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.
>     regret at having chosen those particular rabid weasels and that pair
>     of pants.
>        ---maf
>
>     _______________________________________________
>     saag mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/saag
>     <https://www.ietf.org/mailman/listinfo/saag>
>
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Dan Harkins <[email-masked]>
Date: Fri, 2 Sep 2016 20:50:29 -0700

HI Tero,

On 8/31/16 4:37 AM, Tero Kivinen wrote:
> the protocol and just reuse IKEv2 in OWE, in similar ways than
> 802.15.9 does for 802.15.4.

   That's waaaaay too heavyweight. And the authentication options that
IKE provides-- certs, PSKs, PAKEs-- are mostly already supported in
802.11. It would be a very heavy lift to cram IKE into the 802.11
handshake. Doing a simple DH on top of existing association is a very
clean and simple way of adding opportunistic encryption to 802.11.
> 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.

   IEEE 802.11 already uses the IKE DH group registry for its needs.
Client and AP implementations of 802.11 already have code that maps
the numbers in that registry to complete domain parameter sets and
it makes sense to just continue to use what's there.
> something that are not releated to the original intention of the
   Yes, unfortunately they are cheap. It would've been nicer if it was not
so easy to make a second DH group registry for IKE when the first one was
just fine. Now we have two for no purpose. Sigh.

   Dan.

---

From: Dan Harkins <[email-masked]>
Date: Fri, 2 Sep 2016 20:58:16 -0700

Hi Paul,

> do I not get protection against passive attacks already?

   No you don't! If a passive adversary observes your handshake with the
AP it can do an off-line dictionary attack to obtain the PSK and then
decrypt your traffic (people have thrown a lot of HW at this task too
and there are sites where you can pay $25 and give them a pcap file and
get the PSK back, sometimes in less than an hour). If the adversary doesn't
observe your handshake he can easily forge a frame to your client and
cause it to reset its state machine and go do the handshake again with
the AP.

   On top of that, many coffee shops and bars put the PSK on menus or
sandwich boards so a dictionary attack is not even necessary!

> not very knowledgeable with IEEE protocols)

   We're making the attacker do an active attack which is not impossible
but they are a bit easier to detect since the attacker has to spoof the
AP.

   regards,

   Dan.

---

From: Dan Harkins <[email-masked]>
Date: Fri, 2 Sep 2016 21:26:38 -0700

>        https://mentor.ieee.org/802.11/documents?is_dcn=Harkins

   That's a strong accusation to make by just observing a document
repository!

>     and fielding of a Œgood¹ solution.

To say that it does not prevent attacks is clearly false. It
prevents passive attacks that are possible against WPA(2)-PSK!

   Not sure why you can't field a "good" solution that includes
OWE. It does not preclude using other 802.11 security options
nor is it a heavy or intrusive addition.

   Yes, OWE was presented multiple times at 802.11. It received
comments each time the vote did not obtain 75% approval (the requirement
for IEEE 802.11). Some of those were based on a misunderstanding of
what it was trying to do ("this doesn't provide authentication!", yes
I know that's the whole point), some was based on the belief that it
was being a proposed replacement for the PSK mode of 802.11 (it is
decidedly not, it is an alternative to Open), and finally it failed
because it was deemed too late in the process of stabilizing the
maintenance draft that was rolling up all the amendments since the
last publication of the 802.11 standard. Each time it failed clarify
text was added but the fundamental technical proposal never changed
since there were never any substantive technical comments against it.

> interest to adopt a specification by the Wi-Fi industry.

   Nor should your statements be construed as a rejection or lack of
interest to adopt OWE by the Wi-Fi industry.

   The IEEE 802.11 Working Group, both leadership and members at large,
are well aware of this effort. There is no feeling among _active_
members of the IEEE 802.11 Working Group that this is some "side step
of the IEEE process." In fact, at the last meeting there was a vote
among members to allocate the necessary code points from 802.11's
registry for OWE and the vote was 44-0-2, if memory serves. Such an
overwhelming approval certainly represents a strong rebuke to your
accusation.

   Dan.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 4 Sep 2016 09:28:22 -0700

Dan said:

"  This will probably appear in hostapd/wpa_supplicant a very short time
after the draft is stable."

[BA] Is any change required in drivers or can the proposal be deployed just
with modified APs and supplicants?

Paul Lambert said:

"I¹ve observed that this specific OWE proposal was rejected multiple times
by IEEE 802.11. The creation of an
Internet Draft in this forum is a side-channel being used
to side-step the IEEE process.
       https://mentor.ieee.org/802.11/documents?is_dcn=Harkins"

[BA] Given that Dan first proposed something along these lines 10+ years
ago, if this is an end-run it is an *extremely* slow one.

Over those 10 years, attacks which were originally not regarded as feasible
(brute force password recovery from a 4-way handshake), were ignored in the
original IEEE 802.11i design (DoS attacks) or were not regarded as
important (meta-data recovery from a WPA2/enterprise exchange) now have
become recognized as more serious threats.

Given all the difficulties that have been encountered in getting new IEEE
802.11 security technology widely deployed since WPA/WPA2, it therefore
seems reasonable to consider proposals with a potential path to
implementation via open-source, as long as they don't create new
vulnerabilities or don't preclude alternative approaches under development
in IEEE 802.11.

Paul Lambert also said:

"The concerns expressed in the IEEE forum included:
  - OWE is not a good/complete solution

[BA] It would appear to me that there has been some evolution between Dan's
original proposals (which ran pre-association) and the IETF draft (which
runs after Association).  While neither attempt to be a "complete
solution", the pre-association proposals do appear to potentially address a
range of passive attacks.  The IETF draft is more targeted, but appears to
focus purely on the coffee shop scenario.  I'd be interested to hear from
Dan on the evolution of his thinking over time.

[BA] While Dan's proposals do not prevent spoofing/active attacks, they do
make them more expensive.  And they do address passive attacks.

[BA] There is some addition in complexity, but apparently not enough to
preclude open source implementation within existing APs/STAs.  And passive
attacks are prevented.

  - inclusion of OWE would detract from the development and fielding of a
"good¹ solution."

[BA] It has been 10+ years since the widespread deployment of WPA/WPA2.  In
that time, how much additional IEEE 802.11 security technology (e.g. 11r,
11w, etc.) has been widely deployed?  Given that record, is OWE really
likely to detract further?

Dan Harkins said:

" Nor should your statements be construed as a rejection or lack of interest
to adopt OWE by the Wi-Fi industry."

[BA] The state of security within much of  "the WiFi industry" not very
good, to put it mildly.  Between consumer APs containing serious security
vulnerabilities (many no longer maintained by their manufacturers), the
widespread use of "Open" hotspots, and the advance of attacking technology,
"the WiFi industry" would appear to need all the security help it can get.
Therefore proposals that "do no harm" and have a potentially credible path
to deployment seem worthy of consideration.

On Fri, Sep 2, 2016 at 8:44 PM, Dan Harkins <[email-masked]> wrote:

> 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
> On Aug 30, 2016 6:37 PM, "Warren Kumari" <[email-masked]> wrote:
>
>> <[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.
>> >
>> > 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
>> > [1] https://www.ietf.org/mail-archive/web/saag/current/msg06595.html
> saag mailing [email-masked]://www.ietf.org/mailman/listinfo/saag
>
>
>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 5 Sep 2016 16:46:07 +0300

Warren Kumari writes:
> ​Okey dokey. Asking for a registry is easy - it just seems like a waste if it
> is only going to have a value or two...

If you reuse existing registry, then you should accept the fact, that
you have no control on the registry. I.e., if at one point IPsec
people would decide to obsolete all MODP and ECP based groups, and
only leave Curve25519 and Curve448 there, there is nothing you can
do... Or if you want to add new group there, and IPsec people consider
that we already too many groups, and do not want to add more stuff
there. We already had this problem earlier, when IEEE specifications
reused the IANA registry for the obsoleted protocol (IKEv1), and they
wanted to add new numbers there and IPsec people did not want to
modify registers for protocols which are already obsoleted.

If you only have few numbers, and if you do not expect there to be any
new ones, just list the numbers in the document, but then you better
be sure no new ones are going to be added. I think making new IANA
registry is better option.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 5 Sep 2016 17:01:35 +0300

>    IEEE 802.11 already uses the IKE DH group registry for its needs.

Does it use the IKEv2 DH registry, or only the no more allocations
allowed DH registry for obsoleted IKEv1?

Last time I checked it only used IKEv1 registry. This would be the
first one trying to reuse IKEv2 registry. 

> just fine. Now we have two for no purpose. Sigh.

The other no more allocations allowed, and only there as there is
still need to support IKEv1 in implementaions even when it was
obsoleted in 2005.

The registry does not only map the number to group, it also maps the
number to the specification, and the checks that needs to be done for
the group and so on. 

And I think we have more than two, I think we have about 7 or so
(eap-pax, eap-eke, ikev1, ikev2, tls, ssh, dnskey) registries having
Diffie-Hellman groups to some number or name. Having one per protocol
is good thing, as each protocol do have different needs for registry,
and also might have different policies to add things to registry.
-- 
[email-masked]

---

From: Dan Harkins <[email-masked]>
Date: Mon, 5 Sep 2016 11:22:49 -0700

Hi Bernard,

On 9/4/16 9:28 AM, Bernard Aboba wrote:
> Dan said:
>
> "This will probably appear in hostapd/wpa_supplicant a very short time 
> [BA] Is any change required in drivers or can the proposal be deployed 
> just with modified APs and supplicants?

   Quite often 802.11 authentication and 802.11 association frames
are done in a driver. Many drivers provide partial programmatic
("application"/user space/supplicant) access to to association frames
where APIs exist to add custom TLVs ("elements" in 802.11 parlance)
to the frame and also get the driver to deliver a copy of received
frames up to the application for processing.

   OWE adds TLVs to association frames. So if one has written the
driver it's a simple mod. If one uses a reference design or just takes
a pre-built driver to slap onto some hardware there should be an API to
add the DH TLVs.

   I think because OWE uses association frames instead of authentication
frames it will be easier to be added to existing products, many of which
use a driver the vendor does not write.

> Paul Lambert said:
>
> "I¹ve observed that this specific OWE proposal was rejected multiple 
> times by IEEE 802.11. The creation of an
> <https://mentor.ieee.org/802.11/documents?is_dcn=Harkins>"
>
> [BA] Given that Dan first proposed something along these lines 10+ 
> years ago, if this is an end-run it is an *extremely* slow one.
>
> Over those 10 years, attacks which were originally not regarded as 
> feasible (brute force password recovery from a 4-way handshake), were 
> ignored in the original IEEE 802.11i design (DoS attacks) or were not 
> regarded as important (meta-data recovery from a WPA2/enterprise 
> exchange) now have become recognized as more serious threats.
>
> Given all the difficulties that have been encountered in getting new 
> IEEE 802.11 security technology widely deployed since WPA/WPA2, it 
> therefore seems reasonable to consider proposals with a potential path 
> to implementation via open-source, as long as they don't create new 
> vulnerabilities or don't preclude alternative approaches under 
> development in IEEE 802.11.
>
> Paul Lambert also said:
>
> [BA] It would appear to me that there has been some evolution between 
> Dan's original proposals (which ran pre-association) and the IETF 
> draft (which runs after Association).  While neither attempt to be a 
> "complete solution", the pre-association proposals do appear to 
> potentially address a range of passive attacks.  The IETF draft is 
> more targeted, but appears to focus purely on the coffee shop 
> scenario.  I'd be interested to hear from Dan on the evolution of his 
> thinking over time.
>

   Well my other (pre-association) idea evolved into SAE. That is a PAKE 
that
is supposed to be a drop-in replacement for WPA2-PSK. Sadly that has not 
taken
off in the way I had hoped. I believe this is due to it using 802.11 
authentication
frames and, as I note above, many vendors don't have a way to customize the
contents of those frames or get the driver to pass them up to "user 
space" for
processing.
> [BA] While Dan's proposals do not prevent spoofing/active attacks, 
> they do make them more expensive.  And they do address passive attacks.

   Very true.

> [BA] There is some addition in complexity, but apparently not enough 
> to preclude open source implementation within existing APs/STAs.  And 
> passive attacks are prevented.
>
>   - inclusion of OWE would detract from the development and fielding 
> of a "good¹ solution."
>
> [BA] It has been 10+ years since the widespread deployment of 
> WPA/WPA2.  In that time, how much additional IEEE 802.11 security 
> technology (e.g. 11r, 11w, etc.) has been widely deployed?  Given that 
> record, is OWE really likely to detract further?

   I'm glad you mentioned 11r. That has not had a very big uptick 
either, just like
SAE. And like SAE that is due, IMHO, to its reliance on 802.11 
authentication
frames. Too many wireless product vendors do not have programmatic 
access to those
frames and chipset vendors aren't providing APIs in their (reference) 
drivers.
Perhaps Paul can comment on why that is.

> Dan Harkins said:
>
> " Nor should your statements be construed as a rejection or lack of 
> interest to adopt OWE by the Wi-Fi industry."
>
> [BA] The state of security within much of  "the WiFi industry" not 
> very good, to put it mildly.  Between consumer APs containing serious 
> security vulnerabilities (many no longer maintained by their 
> manufacturers), the widespread use of "Open" hotspots, and the advance 
> of attacking technology, "the WiFi industry" would appear to need all 
> the security help it can get. Therefore proposals that "do no harm" 
> and have a potentially credible path to deployment seem worthy of 
> consideration.

   Open hotspots are a huge problem. Even when they have an https 
captive portal
behind them, when the captive portal OKs the client (through entry of some
code or password or clicking terms-and-conditions) any keys generated 
from the
https connection are thrown away and the client continues with an open 
connection.
OWE fixes this. The air is always encrypted and passive attacks are not 
possible.

   There is a huge upside to OWE and I don't see any downside. It was 
consciously
chosen to use an 802.11 frame that experience shows should make it more 
easy to
deploy.

   regards,

   Dan.