Re: [Secdispatch] DANE IOT proposed outcome

"Panwei (William)" <william.panwei@huawei.com> Mon, 16 November 2020 12:02 UTC

Return-Path: <william.panwei@huawei.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 29A4B3A0DA4; Mon, 16 Nov 2020 04:02:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 32uads4Gim8U; Mon, 16 Nov 2020 04:02:31 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E373A0D9B; Mon, 16 Nov 2020 04:02:31 -0800 (PST)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CZSMX4n0hz67DNS; Mon, 16 Nov 2020 20:00:56 +0800 (CST)
Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 16 Nov 2020 13:02:27 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 16 Nov 2020 20:02:25 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Mon, 16 Nov 2020 20:02:25 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: Eliot Lear <lear=40cisco.com@dmarc.ietf.org>
CC: "secdispatch@ietf.org" <secdispatch@ietf.org>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>
Thread-Topic: [Secdispatch] DANE IOT proposed outcome
Thread-Index: AQHWvAcDj5ATxnClv0CbH9AVFrI7YanKopzg
Date: Mon, 16 Nov 2020 12:02:25 +0000
Message-ID: <b178d5066d6b4371a59ffe59bb6d6447@huawei.com>
References: <2786E31F-2A4F-4901-8ECC-7AEF4B4D81E2@cisco.com>
In-Reply-To: <2786E31F-2A4F-4901-8ECC-7AEF4B4D81E2@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.99.125]
Content-Type: multipart/alternative; boundary="_000_b178d5066d6b4371a59ffe59bb6d6447huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/6weJ6lrRs1IGXNJZpBhIiuJaQg0>
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 12:02:33 -0000

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<mailto: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