On Fri, Aug 19, 2022 at 10:50 AM M Montemurro <montemurro.mich...@gmail.com> wrote:
> Hi Behcet and Dan, > > There is a v2 of the DPP specification. The only difference is that Wi-Fi > Alliance has a adopted the program name for the specification rather than > DPP. So the reference would be Wi-Fi Easy Connect Specification v2.0. > > If you look back on this thread, in my mail 5 days ago, I alluded to this already. Behcet > You can find the document here: > https://www.wi-fi.org/download.php?file=/sites/default/files/private/Wi-Fi_Easy_Connect_Specification_v2.0.pdf > > Cheers, > > Mike > > On Fri, Aug 19, 2022 at 11:23 AM Behcet Sarikaya <sarikaya2...@gmail.com> > wrote: > >> Hi Dan, >> >> >> On Thu, Aug 18, 2022 at 9:54 AM Dan Harkins <dhark...@lounge.org> wrote: >> >>> >>> Hi Behcet, >>> >>> On 8/17/22 2:36 PM, Behcet Sarikaya wrote: >>> >>> Hi Peter, >>> >>> I quickly read this short document and have some comments. >>> >>> In the informative references section, DPP is listed as Device >>> Provisioning Profile while it should be Device Provisioning Protocol. >>> Actually, in the acronyms section the name is correctly given. However, >>> the DPP acronym is not properly expanded in the first use of the acronym >>> which is in Section 1. Also the same could be said of the other acronyms >>> >>> >>> Good catch. We'll fix that. >>> >>> Also the date of DPP document seems to be wrong, I think the version 1.1 >>> was dated 2018. >>> >>> >>> I think the Wi-Fi Alliance has released v2. I'll check and we'll fix >>> this if needed. >>> >>> >> I think there is no v2. >> >> >>> Probably more seriously though, the document says DPP does not support >>> wired network access in Section 1 but maybe the authors are not aware that >>> there is something called wired only DPP which is defined in another WiFi >>> Alliance document in Section 2.3.5 of >>> >>> Wi-i Easy ConnectTM Specification v2.0 >>> This document is dated 2020, maybe the authors should reference this >>> document then the date will be correct 👍🏻. >>> >>> >>> The DPP-over-TCP solution will not work. DPP-over-TCP was added to >>> enable centralization >>> of DPP services in devices which might not have an 802.11 interface. >>> Think of a central network >>> server that implements a DPP Configurator that is connected to multiple >>> access points in an ESS. >>> The APs will just de-capsulate the 802.11 frames they receive, >>> re-encapsulate them in TCP/IP >>> headers and send them to the central network server who processes them >>> and responds with >>> TCP packets to which the inverse operation is performed by the AP. That >>> said, it is certainly >>> possible for two entities to speak a complete DPP conversation over TCP >>> without the use of >>> 802.11. But as I said this won't work here. >>> >>> The reason this won't work is the "Onboarding Catch-22" where you need >>> a credential to get >>> on the network but need to get on the network to get a credential. >>> DPP-over-TCP requires an >>> IP address. How do you get an IP address? Well, after "link up" on your >>> wired connection you do >>> EAP and authenticate, and then do DHCP. But how do you do EAP? >>> >>> >> Yes it is a good question but it is answered in detail in Section 2.3.5 >> of WiFi Easy Connect Specification. Fig. 9 there on page 40 shows the >> message flow. >> The client there already has an IP address. The issue there is how will >> the client get IP address of DPP controller. They propose several >> solutions including DNS. >> Authentication is based on these three messages exchanged: DPP Auth >> Req/DPP Aut Res/DPP Auth Conf >> There is no EAP. EAP in DPP is used in 802.11X with EAP-OL Key message. >> >> Behcet >> >> regards, >>> >>> Dan. >>> >>> Behcet >>> >>> On Tue, Aug 16, 2022 at 3:12 PM Peter Yee <pe...@akayla.com> wrote: >>> >>>> 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 >>>> Emu@ietf.org >>>> https://www.ietf.org/mailman/listinfo/emu >>>> >>> >>> _______________________________________________ >>> Emu mailing listEmu@ietf.orghttps://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 >>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu >>> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >> >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
