Re: [Mud] [Iot-onboarding] administrative control of devices --- thinking again about an IoT security WG

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 24 September 2020 17:44 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: mud@ietfa.amsl.com
Delivered-To: mud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAB63A11DD; Thu, 24 Sep 2020 10:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2f5Gw1Lz_CXg; Thu, 24 Sep 2020 10:44:16 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043043A11CC; Thu, 24 Sep 2020 10:44:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id ECAAE389BD; Thu, 24 Sep 2020 13:22:40 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id K5svNG6TnmQ8; Thu, 24 Sep 2020 13:22:30 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8E70C389B4; Thu, 24 Sep 2020 13:22:30 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 64BD84DB; Thu, 24 Sep 2020 13:43:54 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Qin Wu <bill.wu@huawei.com>, "mud@ietf.org" <mud@ietf.org>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAADA0A12F@dggeml511-mbs.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABAADA0A12F@dggeml511-mbs.china.huawei.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 24 Sep 2020 13:43:54 -0400
Message-ID: <17858.1600969434@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/15juoWD0oZpsiMpE58FaRzQ_ClA>
Subject: Re: [Mud] [Iot-onboarding] administrative control of devices --- thinking again about an IoT security WG
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2020 17:44:18 -0000

Qin Wu <bill.wu@huawei.com> wrote:
    > Have we considered to manage multiple devices on boarding at one time?
    > These devices might be placed behind the same gateway device. In some
    > cases, there is no DNS infrastructure or DHCP.

BRSKI and the 802.1X EAP methods (EAP-NOOB, BRSKI-TEAP) do not need DHCP or
DNS in order to onboard devices.
Multiple devices is not more difficult than a single device.

I had some contact with some Google IoT people who were considering how
a home owner might onboard dozens to hundreds of devices.
Consider a person who has just moved into a new apartment, or installers
setting up an office building.

The issue primarily about be sure that the device in your "hand" is actually
the device being controlled.  Given a mess of boxes on the floor, even NFC
could see many devices.

There is an advantage to having an integrated API, because one can make the
device "do" something to confirm it's the right device.  That's a bit of
slippery slope of APIs, but "identify self" is a reasonable administrative
API that could be in common.

(Some 1U servers have a blue LED with a button just so that you match the
front/back of a given 1U server in a cabinet full of ~48 of them...  Some
versions could also turn this on via software, or can query the state of the
button via software)

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide