Hi Stephen,
(an outlook update has fubar'd my mail response formatting so sorry for
any confusion that arises below, I'll preface with a [DNH])
On 1/16/17, 8:35 AM, "Stephen Farrell"
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
Hi Dan, Warren,
The (extended) last call for this is now over.
There were minor comments from the gen-art [1] and opsdir
reviews (not sent to a list?) and some additional editorial
comments received offlist (from IEEE folks I believe).
As promised, I also asked some IEEE folks about this and got
one substantive comment, which is below. (The author of that
didn't yet say yes when I asked if it was ok to forward their
email, so I'll post the comment itself and send a link to this
to the author, who can then decide to engage or not.) The
comment was:
"It's possible to do this via EAP, either as a new EAP method
implementing OWE or as an extension to EAP-TLS wherein client certs are
not required and a DH/DHE TLS ciphersuite is used. These approaches are
squarely within IETF's jurisdiction. Why not go that route? Indeed
there are a couple extra round trips required in the protocol, but you
don't commit any standardization cardinal sins along the way. "
[DNH]There are a number of reasons not to do this with EAP. I present
them in no particular order:
1. EAP sucks :-)
2. What would the client put in the Identity response? Nothing?
Typically that is used to decide which EAP method to proffer. While
it would be possible to define how to proceed, it would be
arbitrary and seem kind of a hackish (put "anonymous@owe" in
the response and hope that owe is never used in a RADIUS
routing message, or put "owe" in the response and hope that
there are no users in the world whose username is "owe").
3. The network would show up as "WPA-2 Enterprise" and many
supplicants will immediately ask for a username/password. We
want this to show up as "Open" and the client is not bothered
in order to get opportunistic encryption. Doing EAP might cause
the user to have to do something and that defeats the whole
purpose.
4. There's a bunch of pointless encapsulations (TLS encapsulation,
EAP encapsulation, dot1x encapsulation) and pointless negotiations
(TLS negotiation, EAP "negotiation") on top of the simple DH that
OWE is doing. See #1.
5. This is for small cafes and the like and these people don't know
EAP from shinola and they certainly don't want to learn just to
deploy OWE. While lots of the EAP-specific goo can be hidden from
the admin it does get messy. See #4.
6. It would require an EAP server on the AP (since we're not going to
require AAA servers deployed in cafes just to do OWE!) which is
more code that some low-end APs do not have. See #1.
7. I do not believe any cardinal sins of standardization are being
committed with OWE and therefore there is no need to solve the
problem using a new EAP method.
I don't think any of the above are fatal to proceeding but would
like if Dan and/or Warren can respond to those comments and submit
a revised ID if one is needed. Assuming nothing major ensues as a
result I'll put this draft on an upcoming IESG telechat.
[DNH] I don't believe a revised ID is needed based on this comment but
there is a need for a revised ID from the other comments received. Warren
and I will produce a revised ID.
thanks,
Dan.
Cheers,
S.
[1] https://www.ietf.org/mail-archive/web/ietf/current/msg100064.html
On 05/12/16 16:48, The IESG wrote:
>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Opportunistic Wireless Encryption'
> <draft-harkins-owe-05.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf(_at_)ietf(_dot_)org mailing lists by 2017-01-13. Exceptionally,
comments may be
> sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain
the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> This memo specifies an extension to IEEE Std 802.11 to provide for
> opportunistic (unauthenticated) encryption to the wireless media.
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-harkins-owe/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-harkins-owe/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>