Re: [Emu] Adoption call for EAP-DPP

["Owen Friel (ofriel)" <[e-mail]>]

If necessary we can add clarifying text to the next draft to explain why Wi-Fi Easy Connect 2.0 section 2.3.5 “Wired-Only DPP” does not solve this wired onboarding problem. Hopefully there is no longer any confusion on this point as Dan has clarified here, and previously: https://mailarchive.ietf.org/arch/msg/emu/lboE_o4OfJJtUL_LA6psIpSuHZs/

Regards,
Owen

From: Emu <[e-mail]> On Behalf Of Dan Harkins
Sent: Friday 9 September 2022 07:29
To: [e-mail]
Cc: [e-mail]
Subject: Re: [Emu] Adoption call for EAP-DPP


  Hi Behcet,
On 9/8/22 8:43 AM, Behcet Sarikaya wrote:
Hi Peter, Joe,

We made it clear that DPP R2 has already been published  with a name change:






 Wi-Fi Easy Connect™

Specification

Version 2.0


Wi-Fi Easy Connect is the new DPP, which the authors seemingly did not know about.

  Wi-Fi Easy Connect is the name of a certification program at the Wi-Fi Alliance
for devices that implement the DPP protocol.

  I am well aware of Wi-Fi Easy Connect (having invented the protocols that are used
in it and have contributed to development of the test plan). It seems that you aren't.


Also the problem that this draft deals with and also Elliott mentioned in his mail, Wi-Fi Easy Connect already solves it.

  That is not correct, this draft deals with on-boarding of wired devices on networks
that enforce security. Such networks enforce 802.1x and as soon as a device is plugged
into such a switch an EAP Identity-Request will be sent. No packets other than EAPoL are
allowed. Certainly no TCP frames encapsulating DPP messages! So it is not possible to
do any DPP-over-TCP (or if you will "Wi-Fi Easy Connect over TCP") in such a situation.

  Wi-Fi Easy Connect, which is a certification program, does not solve this problem. Neither
does the DPP protocol which Wi-Fi Easy Connect certifies compliance to.

  The issue that IP connectivity cannot be established until authentication and DPP-over-TCP
requires IP connectivity to perform authentication. It's a classic catch-22. Why don't you
see this obvious problem?

  regards,

  Dan.


Regards,
Behcet



On Wed, Sep 7, 2022 at 11:57 PM Peter Yee <[e-mail]<mailto:[e-mail]>> wrote:
In retrospect, sending the call for adoption at the height of August
vacation season may not have guaranteed the most responses. To be honest,
the level of responses to this call has been a little light, so Joe and I
have decided to extend the call for adoption for one week from today.

We would really like to hear from anyone else who is interested in reviewing
and/or contributing to this specification or anyone who feels that it should
not be adopted. Please speak up by the 14th either way. This specification
would seemingly fit within the WG's existing charter, so let your voice be
heard!

Thanks,

Peter and Joe

-----Original Message-----
From: Peter Yee <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, August 16, 2022 1:12 PM
To: '[e-mail]<mailto:[e-mail]>' <[e-mail]<mailto:[e-mail]>>
Subject: Adoption call for EAP-DPP

This is an adoption call for EAP-DPP (draft-friel-tls-eap-dpp-05)[1]. This
document aligns with the charter item to "Define mechanisms by which EAP
methods can support creation of long-term credentials for the peer based on
initial limited-use credentials." The latest revision incorporates feedback
from both the TLS and EMU working groups. Please review and respond to the
list if you think this document is or is not an appropriate working group
item for EMU by September 1, 2022.

Thanks,

Peter and Joe

[1] https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/


_______________________________________________
Emu mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/emu



_______________________________________________

Emu mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/emu



--

"The object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane." -- Marcus Aurelius