Re: [Secdispatch] DANE IOT proposed outcome

Shumon Huque <shuque@gmail.com> Mon, 16 November 2020 15:19 UTC

Return-Path: <shuque@gmail.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04DB3A1174; Mon, 16 Nov 2020 07:19:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3CDPxKYzDKM; Mon, 16 Nov 2020 07:19:36 -0800 (PST)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C493A116E; Mon, 16 Nov 2020 07:19:35 -0800 (PST)
Received: by mail-ed1-x529.google.com with SMTP id a15so19119116edy.1; Mon, 16 Nov 2020 07:19:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9+gmpoaa6OavgOxI1DNWWPwTrbzG3+/AEiNJ7YGd3S8=; b=Nnqmu84EAqnXXtCEyDaKGkbhrNRgn6GMlkN6Cbxw//o/fG3qjwxt+bV0PXBin0DhVV Rsuq2ALSh7M/1x7WJm8algbOpPfHbSIJ4y9q/fxouZzX7aZEEHzPcrY2RRxnojb3EKzl 217R8TPVtoXkHSix4yfVPgKMBpltNGCwRyzWboUT9/OQfmYtaVyFiu4P3GthSCjdqwhk k5xjuuPfzHyfGzR7Uod5It0b9drTHyv7YURoPDEYPl3/ugD9BNdPn0RshNR6aVr51OC9 f3GR3ljK59av33BL+XfYffm38C00tmQRDgloI/Ky1qSLIYcdljkyXtm8SLQ+ykuYblYn OW1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9+gmpoaa6OavgOxI1DNWWPwTrbzG3+/AEiNJ7YGd3S8=; b=rMQ4Z1Wc1fD050jQcBZ11o6+mbnfCaM0BvaJ3JvuHy6afAWJQTAbtv0Wc5QB6Q5y5O RauL41vqN9qPi/9giBshHeGvwUI3LdtSG6BQtTCvqtY9RwyjCgLPNYVfWlogLFg+i4IX YKnvLaOVNf+iasfbrsKGM11bqWCplNn/c7hEfU/dNyyY1TFvsBLQWOjKOZSQhbyyYW31 45ofFJlZTc9tgKc8zVN6A1I++QDZQ8FO60PiryCoV6yBFv0fEEvfhYvlLdVX98x+6da0 SLNjFZRz9RtcqnjU6Cy6RNH7LxfA921M1DmT7GDIpTIJWmWXOvzZcsibfuWVaWW9+bbi LsCQ==
X-Gm-Message-State: AOAM533af4+VqrKCr3dpzYJWpOkslq1Ou5YSYeviIhOccMydgTdxHhXW XKx6XaBRrh8xTFondk6rYy+QCUvo/qPMpuS+lxc=
X-Google-Smtp-Source: ABdhPJwQ6KrUp7ItIhW72p2Ri+tMl/i0J9q/ZqP69lVEA5Vy/MXEhFPBSXk05bsRCujGQHPxFVNw/3R+sJRTIVIxTLw=
X-Received: by 2002:a50:ff05:: with SMTP id a5mr16492444edu.43.1605539974315; Mon, 16 Nov 2020 07:19:34 -0800 (PST)
MIME-Version: 1.0
References: <2786E31F-2A4F-4901-8ECC-7AEF4B4D81E2@cisco.com> <b178d5066d6b4371a59ffe59bb6d6447@huawei.com>
In-Reply-To: <b178d5066d6b4371a59ffe59bb6d6447@huawei.com>
From: Shumon Huque <shuque@gmail.com>
Date: Mon, 16 Nov 2020 10:19:23 -0500
Message-ID: <CAHPuVdXo1o0d_WzLqTZ5s9+JNG=3kbNdTO1BrS7BdEBDd2F1Lw@mail.gmail.com>
To: "Panwei (William)" <william.panwei@huawei.com>
Cc: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, "secdispatch@ietf.org" <secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d7819305b43ae728"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/UDpif3Jchi-UGWIGkL65YeFtjwo>
Subject: Re: [Secdispatch] DANE IOT proposed outcome
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 15:19:39 -0000

Hi Wei Pan,

I'll ask Ash (who is more plugged into the IOT ecosystem than I am) to
confirm .. but yes, our use case expects devices to have IDevID or some
other preconfigured unique value, so it should be possible to work with
BRSKI. For the DNS record format naming, we were initially looking at the
formats defined in draft-friel-pki-for-devices, specifically the LDevID
organization managed form, but have a slightly simpler form currently
specified in the draft.

Shumon.

On Mon, Nov 16, 2020 at 7:02 AM Panwei (William) <william.panwei@huawei.com>
wrote:

> Thanks to Eliot for summarizing these.
>
>
>
> I think the core concept of using DANE in IoT scenario is to get rid of
> certificates and PKIX. The solution of how to securely onboard the IoT
> devices and allocate the DNS domain name, both with and without initial
> certificates, is the key part to figure out.
>
> If the IoT devices have no initial certificates, such as 802.1AR IDevID
> certificate, as their initial identity, then the BRSKI mechanism won’t be
> appropriate for these devices because BRSKI has a requirement of IDevID.
>
> If the IoT devices have an IDevID certificate, I think it can still use
> BRSKI to onboard, but it won’t use EST to request a certificate any more,
> instead, it will apply for a DNS domain name by using some protocols.
>
>
>
> That’s my preliminary thoughts, maybe not right.
>
>
>
> Regards & Thanks!
>
> Wei Pan
>
>
>
> *From:* Secdispatch [mailto:secdispatch-bounces@ietf.org] *On Behalf Of *Eliot
> Lear
> *Sent:* Monday, November 16, 2020 6:55 PM
> *To:* secdispatch@ietf.org
> *Subject:* [Secdispatch] DANE IOT proposed outcome
>
>
>
> Thanks to Shumon for presenting the DANE use case for IOT.
>
>
>
> We discussed taking this to the iot-onboarding@ietf.org list as there
> were a number of rather big open issues that people wanted to discuss.
>
>
>
> We also discussed a non-WG forming BOF to look at, as Ted put it, the
> broader context for onboarding.  To give people a feel for the sort of
> related work that is available, here are a list of related activities:
>
>
>
>    - draft-ietf-anima-bootstrapping-keyinfra (BRSKI) is a
>    request/response mechanism that uses RFC 8366 vouchers to introduce devices
>    and network infrastructure.
>    - Intel’s SDO provides an application level introduction using
>    vouchers as well.  This work has been taken up by the FIDO alliance.
>    - The Wifi Alliance has Device Provisioning Protocol (DPP) which does
>    not attach to a global name space prior to provisioning having occurred,
>    but does represent a minimum case (just public keys).
>    - draft-friel-eap-tls-eap-dpp borrows from DPP, intended mostly for
>    wired use, where DPP is focused on 802.11 networks.
>    - There are a number of BRSKI related drafts by Owen as well, relating
>    to cloud-based registrars.
>    - There is also work by Michael Richardson and Peter Van Der Stock on
>    constrained vouchers.  That work is taking place in ACE.
>
>
>
> Understanding the landscape might help us understand where DANE fits in.
>
>
>
> Regards,
>
>
>
> Eliot
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
>