Re: [Emu] Adoption call for EAP-DPP

M Montemurro <montemurro.michael@gmail.com> Fri, 19 August 2022 15:50 UTC

Return-Path: <montemurro.michael@gmail.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C451C15948A for <emu@ietfa.amsl.com>; Fri, 19 Aug 2022 08:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM98S133wd1t for <emu@ietfa.amsl.com>; Fri, 19 Aug 2022 08:50:37 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE06C1522B6 for <emu@ietf.org>; Fri, 19 Aug 2022 08:50:37 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id y18so3625854qtv.5 for <emu@ietf.org>; Fri, 19 Aug 2022 08:50:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=S9JbQLdaucU4i2FgG8YzQ9+uFfG0OqUB1lqH/7xMqd4=; b=kpLPg8OGlng7it4e5fb0j0U+yDCN+1+rjtHGpsho3Z1DMviKeB8h9rzunR7ZaxfodW Ww3O/4i5mOjfHLpkFa9t6wBP6NrWuA9XVPQ0QAxjiFUWuyIBanMiYuzC0OOslvCk5lES ayNiyZFBEas9yvkDMM81OT07BWM/lmDgr1lxzm/Fowg8J3rQA1xSrqZmCRB0ycFBiDNi 0nJPTlq+xV4NhqXONhpw72pR74WMN1HQOYk2MDZuKCjFk0eNkMTltxos7k/PYRsTDSWd UPtCTJFxD1FZ3J0WK5wFy3e4w5WNQ8VpjZOPqxKMKMsfnx4GwQjcwpgJSU6+N3M5hWM9 x+6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=S9JbQLdaucU4i2FgG8YzQ9+uFfG0OqUB1lqH/7xMqd4=; b=V168zsG+lNlJbBfoeAaF/tkhWISn60BR4TxCHw5Fdm5UyZsXOlGqmxmNwbdcA5TeIs k7bT3dSywHTK6NcNBu055zw+eFy079KQX3eY+6bHYZCREqS/VUtu2eMBBLJbf+lih3yP jThzvGF+E0Fw6rkHY22sLSx7dLrxU5yoqpJVx23gsNFetByT9AhPr8Qx7OS/QO/i5xWh j2cIRHIOWOJBGulGoJdT6qfTL7iERKW/+KHytOrpxycSWHcswxtXhbzHD5l2mfIgAbzU 0xEHsJj6QFxiSwkAo8UPhi2nLZjg+C2DxBYbDUVXfTDGwpPPnik66l/27zd9EVKsH1iN BZwg==
X-Gm-Message-State: ACgBeo3SmfU9vX9h1VQ17ZkypZ/5lxW/SEge0Crll7VYKjkZBopYavjB kw1UvL1IPRfelxiSKb3eeOY6gxDC/WL0Ex2aWHnKE5PVu1s=
X-Google-Smtp-Source: AA6agR4lklWPrHn/AilqZy4OYJZL/6LRCe7ijoKFiUlLiJD8iOm6nNXA2fSuXOd7ND270PA9JEp85xca4Urzt7J5cPo=
X-Received: by 2002:ac8:5a91:0:b0:344:69eb:9fa1 with SMTP id c17-20020ac85a91000000b0034469eb9fa1mr7014268qtc.97.1660924236592; Fri, 19 Aug 2022 08:50:36 -0700 (PDT)
MIME-Version: 1.0
References: <01bf01d8b1ac$81233890$8369a9b0$@akayla.com> <CAC8QAcfzQHQg4GQNaqG5k9QJ00-CBCPnwdseLUSYQ=me4rGXEQ@mail.gmail.com> <a9dc5a50-1dbe-614a-1453-63be90286c65@lounge.org> <CAC8QAcdZqcYEoaxVU=G6hWmgkrrgPZO1r-8r=rp38MR5mm5k=w@mail.gmail.com>
In-Reply-To: <CAC8QAcdZqcYEoaxVU=G6hWmgkrrgPZO1r-8r=rp38MR5mm5k=w@mail.gmail.com>
From: M Montemurro <montemurro.michael@gmail.com>
Date: Fri, 19 Aug 2022 11:50:26 -0400
Message-ID: <CALxLnWrukM7DaqKFXmhQuRehC2z_UZOnbRtu82aoY8DajOC0aQ@mail.gmail.com>
To: sarikaya@ieee.org
Cc: Dan Harkins <dharkins@lounge.org>, emu@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001ef8d105e69a0f47"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/sF9Y7LyWCqAwRs6ulSr00OHHsYU>
Subject: Re: [Emu] Adoption call for EAP-DPP
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2022 15:50:41 -0000

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.

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
>