Re: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG

Brian E Carpenter <> Wed, 11 September 2019 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCDBC120271; Wed, 11 Sep 2019 13:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mvUyufJUYYu6; Wed, 11 Sep 2019 13:35:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45058120803; Wed, 11 Sep 2019 13:35:37 -0700 (PDT)
Received: by with SMTP id n4so12134277pgv.2; Wed, 11 Sep 2019 13:35:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=zKWZiE5Hun4lW7/yaa48cCoieFRsuAqBeZyImJJraNs=; b=XuqXKL9rYIh5hqARq3Yq7p+wC8qsJZ1UCEvVZq4kRnuXl40levshLIuIInWNZbs/bO pq+hnd+8Y5QHB0qWgVPI2ZDIZQgsdPVq53rXZezQscwhJzbVEAeK6Wue6moiFkjEgCP2 MzQBtReTizVIVzdDJQOoBR1PwJZjR00sngtwxKQuefFSHSBriW+Q4HlKlgTzLpBQfQ8U pJOQCk90ZLneuUaGp4QIJGvIcXAaVUGF6b2U8HXU0PLnFwhcWQfHGxZO/c81WieyYDV4 FNhG6dC1gvRHM73lG3AN8eCu94KRt+EFYuX564sR8jnH0VQdKi3XX0pU3NZXboIergmU Z4IA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zKWZiE5Hun4lW7/yaa48cCoieFRsuAqBeZyImJJraNs=; b=fxZPLsAHZcdDUMWV50k474NqybBcO/Ntag/1bAInGNRfDB1qEil6oj/BXNcOQ80VPc RBrfpBGR6itHBacsbMVUWzsjm76cVgMr+Nu/cFih3WoZrXaDyeHDFTy+NRxu609oc83j YEaJZQc6KEr0PyNS/iQ7g4S/XwLLvQsBvOHbNgAbZ/LJ14AQz6eb/tRg7w0edjp5jvo9 nHq/zGp3GNx6h1fVRDFj6D3gGKPv46nu7P58OlzjwDx+i+F5dhUA5l2yNEOT1vBX9N3t 0hnEGfMn2l6JhF3wNNc5wmZ1ThkKLNKz2lNY+HfOhQW9GBfvWJEOsak9YbG7r/OP6up/ hlJw==
X-Gm-Message-State: APjAAAUeYIJKSRLRGsWbN7Cnx0/kHJ+b4abo19MyjQE/R+36uXe5rm8j alo0MxNOJZSFHg/pZ5BTSydIyh0N
X-Google-Smtp-Source: APXvYqw27NO1rh6fegtqL/P91o3zU+u1vMiKqcBvCdkCeih4AO0OFws3Pg+nu/KLfqXTty99VgTbfg==
X-Received: by 2002:aa7:8d12:: with SMTP id j18mr45484804pfe.33.1568234136412; Wed, 11 Sep 2019 13:35:36 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j23sm8023356pfn.75.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Sep 2019 13:35:35 -0700 (PDT)
To: Mohit Sethi M <>, Michael Richardson <>, "" <>, "" <>
References: <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Thu, 12 Sep 2019 08:35:32 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Iot-onboarding] some straw-man charter text for an IoT Operational Security WG
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Sep 2019 20:35:40 -0000

Hi Mohit,

On 12-Sep-19 07:21, Mohit Sethi M wrote:
> Hi Michael,
> I wonder why a new working group is needed and why this work cannot be pursued in some of the existing working groups?
> I suppose ANIMA was recently re-chartered (and can be re-chartered again). 

We've been very insistent that ANIMA is scoped for professionally managed networks. That is not, IMHO, a reasonable restriction for IoT; so the ANIMA scope is narrower. Also, ANIMA is scoped for autonomic management, with bootstrap and security being only part of the requirements; in that sense, the ANIMA scope is broader.

> EMU is currently going over the re-charter text. 

I know little about EAP, but it seems to me that although it may well be a primary tool for on-boarding, it is only a tool, and not a complete ecosystem. The "Thinking through onboarding" thread scopes the wider problem nicely.

> Also, you write:
>> adopt a cloud-less (MASA-less, AAA-less) onboarding mechanism (possibly a version of EAP-NOOB),
> There is clearly some misunderstanding about EAP-NOOB here. EAP-NOOB is specifically intended for registering new IoT devices on a server (and associating it with a user account). The fact that it provides network-access credentials is a bonus. Please have a look at slides 3-10 here:
> You clearly see a AAA server in the figures. So calling it AAA-less doesn't make sense.
> --Mohit
> On 9/4/19 10:45 AM, Michael Richardson wrote:
>> I wrote this last week, and passed it around for obvious objections.
>> You can use the crayon/edit button on github to suggest changes, or email.
>> 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.
>> 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. 
>> 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).
>> ....