Re: [Emu] Adoption call for EAP-DPP

On Fri, Aug 19, 2022 at 10:50 AM M Montemurro <montemurro.michael@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 <sarikaya2012@gmail.com>
> wrote:
>
>> Hi Dan,
>>
>>
>> On Thu, Aug 18, 2022 at 9:54 AM Dan Harkins <dharkins@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 <peter@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
>>
>