Re: [Secdispatch] [Iot-onboarding] DANE IOT proposed outcome
Ash Wilson <ash.wilson@valimail.com> Mon, 16 November 2020 19:13 UTC
Return-Path: <ash.wilson@valimail.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 92CDD3A07C3 for <secdispatch@ietfa.amsl.com>; Mon, 16 Nov 2020 11:13:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=valimail.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 B5Rf7r8_EEEU for <secdispatch@ietfa.amsl.com>; Mon, 16 Nov 2020 11:13:18 -0800 (PST)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 F16203A0779 for <secdispatch@ietf.org>; Mon, 16 Nov 2020 11:13:17 -0800 (PST)
Received: by mail-qk1-x730.google.com with SMTP id o66so4535363qkd.4 for <secdispatch@ietf.org>; Mon, 16 Nov 2020 11:13:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CorexOEcIr2fXlzw20mviJuoOSTgQQk3UtascQwv1wQ=; b=fbJ12J/8YKLBsw6JBH9nWGL4Eh0xBPPDgml4GoOI06j0wmfsMmfah8JO35YLvV3ooh vbD2sU6RJfE/DTwwOiM2BOcgi7gpKQE6NyRwVyft62Wl7jE5kN3mbwY8HGacBJCe+Pty utDSE2Ysxbtmymrq4suepqGM708OLgRhV/u1Y43D8c4yb6P8ZB8Mg7wYXBAX/SfY0Bei kYZsrq5/KIKkrOYXCMWXRsExycw0tfl27k3Mz7EZeeAJC6L/m4H6cmcaUbpsF7kKWVSr 9AhkW/WfgGPr6H0ybwq4bJ4jWzn6koOdl4uimckMC6h1WshdO6nwjrSqeHqvMzEYyHp/ RUWw==
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=CorexOEcIr2fXlzw20mviJuoOSTgQQk3UtascQwv1wQ=; b=OWzv6Z7xCcs9och5roOUUavdfuMzFS33G+J773FKb1Su+dFIMYFFlpXeC4H6FqsD0p M1ARPSifT0k77gjK0kS4Wju2Lpb9MAEdxQlu+zMgY61UqMkca9jXCRaY4nX0grDOmD7P UEGKvt1eHN2iBU8e/1ZRqQqlid9frdhsPr1TAmH6ERbUpidxyBa7aPA3D0dbpaMocOpu +lXWFTruZojLXJ5w/kPRxzvhZmLfRZRVM/GHRZjgq9TT9CAZ90RlGtc0aZHPd208faS7 SDvMKS1lC7YNNErnSuvGugAPI6IwUMeHEtZpkN8VvecA3CY4lZB7W+JLB6Y9oJ03hKTa iT/Q==
X-Gm-Message-State: AOAM5337PWiNluzIJUyWIxVwxVpewBvJ5yGKNv5KzROBWNo7vG1xS/NO K6EboRorU9a4ix6CEQXyudv0hP0JY5Yz/OGK4tMQ8Q==
X-Google-Smtp-Source: ABdhPJxhd81ucp+Q5Feq9wncO8xH5brPwBTlAyPdmWuntt0XG9eEcDgNup2wUOkY9V5BPt74XOmqfMfo82+PlJlWi0E=
X-Received: by 2002:a37:6554:: with SMTP id z81mr15606606qkb.423.1605553996624; Mon, 16 Nov 2020 11:13:16 -0800 (PST)
MIME-Version: 1.0
References: <2786E31F-2A4F-4901-8ECC-7AEF4B4D81E2@cisco.com> <b178d5066d6b4371a59ffe59bb6d6447@huawei.com> <CAHPuVdXo1o0d_WzLqTZ5s9+JNG=3kbNdTO1BrS7BdEBDd2F1Lw@mail.gmail.com>
In-Reply-To: <CAHPuVdXo1o0d_WzLqTZ5s9+JNG=3kbNdTO1BrS7BdEBDd2F1Lw@mail.gmail.com>
From: Ash Wilson <ash.wilson@valimail.com>
Date: Mon, 16 Nov 2020 11:13:05 -0800
Message-ID: <CAEfM=vRotGf-SuYz8PKNop8zdCCA_-x+3xU81rMS6Le6EUOOFw@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
Cc: "Panwei (William)" <william.panwei@huawei.com>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, "secdispatch@ietf.org" <secdispatch@ietf.org>, Eliot Lear <lear=40cisco.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a3094305b43e2b0d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/28SQVrUkT4CwbDyvDBUu_cyATMk>
Subject: Re: [Secdispatch] [Iot-onboarding] 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 19:13:21 -0000
Hi Wei Pan, The process of bootstrapping the device's identity is outside the scope of our drafts, but I completely agree that getting the bootstrapping process right is important. We think that using DANE like this doesn't conflict with other bootstrapping processes; it just adds a DNS-discoverable public key to the identity of the device when it is provisioned. One of the processes we are seeking to simplify is that of establishing trust directly between devices in the field, both of which may have only a keypair, and not the benefit of PKI that chains to a publicly trusted CA. Supporting x.509 certificates is in the interest of providing broad protocol compatibility (including the support of other adjacent standards like MUD: https://tools.ietf.org/id/draft-ietf-opsawg-mud-22.html#mudx509). By using TLSA for client auth, we allow devices with only a raw public key in DNS, as well as devices with metadata-rich x.509 certificates, to mutually authenticate without requiring the distribution of CA certificates, just based on knowledge of the communicating peer's DNS name. SIM/UICC identity providers may provision public keys in DNS, and leave a record of the device's DNS name in the SIM card (likely to be found in the certificate). This gives the device that receives the SIM card the ability to do all the things that the PKI ecosystem supports now, with the additional benefit of being able to mutually authenticate without the other side of the handshake needing to possess and trust the CA certificate used to sign the certificate that ships with the SIM card. Naming collisions are prevented by binding the public key to the DNS name- only the possessor of the private key corresponding to the TLSA record is the 'real' identity holder. In a similar fashion, device manufacturers may provision a DANE identity for devices before they ship. These device identities may reside in a DNS zone under the manufacturer's control, or the implementer may present the device certificates in a DNS zone under the implementer's control. This allows the identity to more naturally indicate the party responsible for the device's behavior, and can make the mitigation of some types of network abuse a little more straightforward. On Mon, Nov 16, 2020 at 8:04 AM Shumon Huque <shuque@gmail.com> wrote: > 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 >> > -- > Iot-onboarding mailing list > Iot-onboarding@ietf.org > https://www.ietf.org/mailman/listinfo/iot-onboarding > -- *Ash Wilson* | Technical Director *e:* ash.wilson@valimail.com This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
- [Secdispatch] DANE IOT proposed outcome Eliot Lear
- Re: [Secdispatch] DANE IOT proposed outcome Panwei (William)
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Eliot Lear
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Panwei (William)
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Toerless Eckert
- Re: [Secdispatch] DANE IOT proposed outcome Shumon Huque
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Panwei (William)
- Re: [Secdispatch] DANE IOT proposed outcome Shumon Huque
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Shumon Huque
- Re: [Secdispatch] DANE IOT proposed outcome Panwei (William)
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Ash Wilson
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Panwei (William)
- Re: [Secdispatch] DANE IOT proposed outcome Michael Richardson
- [Secdispatch] Confusing terminology was Re: [Iot-… Mohit Sethi M
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Mohit Sethi M
- Re: [Secdispatch] Confusing terminology was Re: [… Eliot Lear
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Shumon Huque
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Mohit Sethi M
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Shumon Huque
- Re: [Secdispatch] [Iot-onboarding] DANE IOT propo… Ash Wilson
- Re: [Secdispatch] DANE IOT proposed outcome Michael Richardson