Re: [Iot-onboarding] thinking again about an IoT security WG

Qin Wu <bill.wu@huawei.com> Thu, 17 September 2020 12:17 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA3A3A090C; Thu, 17 Sep 2020 05:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 nsN1Egz3TaQ3; Thu, 17 Sep 2020 05:17:39 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE2EA3A08DC; Thu, 17 Sep 2020 05:17:38 -0700 (PDT)
Received: from lhreml731-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id CBA74A21DBA6A1E29BA3; Thu, 17 Sep 2020 13:17:36 +0100 (IST)
Received: from lhreml731-chm.china.huawei.com (10.201.108.82) by lhreml731-chm.china.huawei.com (10.201.108.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 17 Sep 2020 13:17:36 +0100
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml731-chm.china.huawei.com (10.201.108.82) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 17 Sep 2020 13:17:36 +0100
Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.93]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Thu, 17 Sep 2020 20:17:32 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Michael Richardson <mcr@sandelman.ca>
CC: "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, "mud@ietf.org" <mud@ietf.org>
Thread-Topic: [Iot-onboarding] thinking again about an IoT security WG
Thread-Index: AdaMvkQMZyBNVAUjRnKZo4dDsDXtuw==
Date: Thu, 17 Sep 2020 12:17:32 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD9DC412@dggeml531-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.101.103]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/p77ME_Aln2fcDj1_i-2dEVRYfCE>
Subject: Re: [Iot-onboarding] thinking again about an IoT security WG
X-BeenThere: iot-onboarding@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <iot-onboarding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-onboarding/>
List-Post: <mailto:iot-onboarding@ietf.org>
List-Help: <mailto:iot-onboarding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2020 12:17:41 -0000

Michael:
Interesting work, I feel this is a cross area topic, it requires a lot of coordination with SUIT, EMU, T2TRG other WGs within IETF and industry alliances in the outside of IETF.
one quick comment to charter proposal is related to administration control of device,
it is not clear how do you define administration control for IoT device?

-Qin
> -----Original Message-----
> From: Iot-onboarding [mailto:iot-onboarding-bounces@ietf.org] On 
> Behalf Of Michael Richardson
> Sent: Tuesday, September 8, 2020 9:42 AM
> To: mud@ietf.org; iot-onboarding@ietf.org
> Subject: [Iot-onboarding] thinking again about an IoT security WG
> 
> 
> Last year, I wrote:
>      https://github.com/mcr/iotwg-charter/blob/master/iotwg-charter.md
> which I also attach below.  Pull requests and edits would be most welcome.
> Rip it to shreds, please.
> 
> It was discussed in a thread:
> 
> https://mailarchive.ietf.org/arch/msg/iot-onboarding/CWJfPD3mSUz_chZR
> 8FmWuKGVaEk/
> 
> The main criticism involved attempts to boil oceans.
> I believe that the effort is manageable, because it simply involves a 
> number of small steps forward.  We just need to coordinate some of the steps.
> 
> Meanwhile, I have received a number of encouraging remarks.
> 
> I have CC'ed mud@ietf.org, and iot-onboarding, but let's just use 
> mud@ietf.org.  The Reply-To I put in will likely get stripped by the 
> IETF mailman.
> 
> I would like to propose an online virtual discussion at the end of September
> to discuss next steps.   Whether we should call this a virtual non-WG
> forming
> BOF is a discussion that I think we should have, and perhaps some ADs 
> will comment.
> 
> ---
> 
> 
> # Charter for Working Group
> 
> The words "Internet of Things" or IoT have come to mean anything and 
> everything  to a wide group of technology players.  The IETF has been 
> working on a wide variety of protocols for use by machine to machine 
> communication.
> This include CoAP, CBOR, 6TISCH, ROLL, SUIT, NETCONF SZTP, T2TRG, 
> ANIMA's BRSKI onboarding protocol, and most recently RFC8520, the 
> Manufacturer Usage Description.
> 
> The IETF has tried to focus on categories of what limited things can 
> do, and this has resulted in a number of useful documents from the 
> Light-Weight Implementation Guide (LWIG).  RFC7228 is a key product, 
> having provided terminology and scaling understanding to the entire industry.
> All of this has been about scaling the Internet technologies to small 
> devices and constrained networks.  In aggregate, these devices on 
> small networks present a significant operational risk to the Internet 
> as a whole, and even to individual Enterprise, simply due to their 
> numbers, and lack of opportunity for regular human supervision.
> 
> IoT devices already exist today in vast numbers.  Most devices that 
> people are personally familiar with are in the BlueTooth Connected 
> devices, or Web-Connected devices that use WiFi to reach servers on 
> the Internet ("the Cloud").
> Increasingly, the IETF view of machine to machine communications are 
> colinizing new greenfield situations.  The IETF notion of autonomous 
> networks of devices is still a minority view compared to the market 
> IoT industry of cloud-only connected devices, but the transition is occuring.
> 
> RFC8520 was created to bridge the gap between devices wholly 
> controlled by a local operator (such as Enterprise IT), and devices 
> which can not assume any infrastructure at all, and must rely entirely 
> on cloud communications for command and control.
> 
> This working group concerns itself with Operational Security of IoT systems.
> 
> This includes:
>   * factory provisioning of devices
>   * onboarding of devices
>   * access control of devices to network resources
>   * administrative control of devices
>   * asset management of devices, as it pertains to software/firmware 
> versions
>   * isolation/quarantine of devices
>   * remediation of broken devices
>   * end of life management of devices
> 
> The WG is chartered explicitely to work on MUD (RFC8520) and 
> extensions to it within the point ("access control of devices...")
> 
> The WG is chartered to work on onboarding protocols, specifically 
> including derivaties of BRSKI (RFC-tbd), but not limited to just that 
> protocol.
> The WG is not expected to pick a winner, and is encouraged to work on 
> a multitude of use-case specific protocols: better to get one use case 
> right, than to be too-complex jack of all trades.
> 
> The WG is expected to articulate clear applicability statements for 
> each protocol.  The WG is expected to produce concise Roadmap 
> documents that explain how a variety of IETF (and other) protocols can 
> work together to satisfy the Operational needs of specific IoT areas.
> These roadmap documents needn’t result in RFCs, the WG will decide 
> with advice from the responsible Area Director.
> 
> Neither the WG nor the IETF has exclusivity here, and an ideal 
> document would be one that the WG helps to start, but a specific 
> industry alliance becomes the lead editor for.
> 
> There will be coordination with many other WGs beyond the list above, 
> and this WG may accept applicability statement work from other WGs 
> about specific ways to deploy their protocols.
> 
> The WG will operate through a series of virtual interim meetings. This 
> is driven by a need to interact regularly with other industry grouops, 
> and due to the variety of topics which will not always be able to get 
> quorum as a committee of the whole.
> 
> {unusual, maybe not charter appropriate, but rather saag-like} During 
> in-person meetings, the WG will deal with typical status and document 
> progress issues during one hour (or less) of the time, and during 
> another hour, will be open to slideware presentations and tutorials on 
> current IETF or other-SDO IoT efforts.  The goal of these 
> presentations is to quickly communicate current IoT *systems* state to the rest of the IETF.
> It is acknowledged that part of the value is in YouTube content, and 
> some content should be done at IAB tech plenaries rather than at the WG.
> 
> The initial set of work items is included below as milestones, which 
> only require AD approval.
> 
> Milestones
> 
> * adopt the constrained-voucher/constrained-BRSKI work from ANIMA.
> * adopt the dtsecurity-zero-touch work from 6tisch, which can not 
> finish before a LAKE finishes.
> * create a list of a series of MUD extensions, and revise this 
> milestone
> * adopt a cloud-less (MASA-less, AAA-less) onboarding mechanism 
> (possibly a version of EAP-NOOB), that can be used at the retail level.
> * negotiate with EMU WG on how to proceed with TEAP-BRSKI, and revise 
> this milestone.
> * adopt a cloud-driven onboarding mechanism that can be used in 
> completely
>   offline situations without requiring renewals (perhaps revising RFC8366).
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT
> consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>