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

Brian E Carpenter <> Thu, 12 September 2019 20:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B88C1208C5; Thu, 12 Sep 2019 13:28:17 -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 m2KtTVPHFtoo; Thu, 12 Sep 2019 13:28:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::644]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E804912086A; Thu, 12 Sep 2019 13:28:14 -0700 (PDT)
Received: by with SMTP id s17so7349312plp.2; Thu, 12 Sep 2019 13:28:14 -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=zUSUa+c86ENUOdQtQ3wQQ7ooyB88WH8sVr6a08pGJKM=; b=LVv8vadYoaloMhRjkSf94B+S55GYDDDaaAuYyLA4VoqjD//58pE2AfDU2Gf6v3jdtn Hp03zeVuOHCvbdVxNhIK9S9Mf3NOq7s8NXG5n9wyjCgX+RQOV5MvVDfRB11FP3B/V/Hv YUU1QtWIWQjO3Tz72oif+tSlNb5hfbwDPS16QWbMLX/5gDxmUemRXlBqmIhGgHr/8aoh l9zWm7ajJFMUj4rXOCizbMOsaUsO//g9fnM+yR9+Gx6jg7AM3MP+4fV5JbQstKjGDqB4 tMGUPT0w992SRCxNuZfRXHKBmB2V3PYJ4dMIZoCWABf6R/2cU70Opdl3WL8McwxEPSy9 cHcA==
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=zUSUa+c86ENUOdQtQ3wQQ7ooyB88WH8sVr6a08pGJKM=; b=N3kgqRFH9b/dAFibJitU0yJcYgoM3JC5/7wYn8wsHtL2BPRGKMZrRcAXJbOwYRf1d9 FoaICE3u9gM3BU9JjiUVAuAvVd2rnMmm078I5DB9jlGp252NHXYfMdNHfHQJKQC7W/9O KHUIumx4reK6aG9who53rikgkrodOoaiduACDh1wi4xCaq2TAz+SCq9OBMYfbZ/ruM5X nLkokHl7AR10sp1H1NwSVo4iT3g2cmlXu+Q2nKsW8/H1SpUte2TpYM+ywWheh+O8gURT B7l6CMRFFzI2/n1AOY1iqm236SQKry7C+hPfwoVz9Zdn179HGuJqqr9fqrDcGMjorIUe bt6Q==
X-Gm-Message-State: APjAAAVS9coWIiRPFJHGIYeVw7PJ8Muv8c6VizgkPB4Hy497gb0EWJ3Y 9nuie7eBIgixENOwtUjHF9p+M77n
X-Google-Smtp-Source: APXvYqwcWnQpXnIlWv9kvrKvROaK+aT3KjcRN1X3O6YIooFizzxO4Q6ku8lh1xWH2Vfeuq/0gjMZkg==
X-Received: by 2002:a17:902:8a84:: with SMTP id p4mr3419948plo.36.1568320093965; Thu, 12 Sep 2019 13:28:13 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id r185sm33698369pfr.68.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Sep 2019 13:28:12 -0700 (PDT)
To: Mohit Sethi M <>, Michael Richardson <>, "" <>, "" <>
References: <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Fri, 13 Sep 2019 08:28:10 +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: Thu, 12 Sep 2019 20:28:21 -0000

Hi Mohit,

> With my limited 
> experience of IETF, I certainly don't think IETF is in the business of 
> building ecosystems

No, but the open source community that uses our standards definitely is in
that business, so interoperable standards need to help such work.

> (and neither should it be).

However, the IETF should not produce standards with gaps that encourage
proprietary ecosystems that allow customer capture. That's exactly why ANIMA
includes a reference model as well as specific standards. It encourages each
vendor to provide a MASA and encourages network operators to mix and match
products from multiple vendors.

Whether the BRSKI/MASA model generalises beyond autonomic networks remains to
seen, but again: it was not designed for IoT.

   Brian Carpenter

On 12-Sep-19 23:33, Mohit Sethi M wrote:
> Hi Brian,
> IETF is in the business of building tools (i.e. open specifications with 
> running code) for developers. And these tools are best built in working 
> groups which have the expertise on them. Most people outside the ANIMA 
> community would not know what is a MASA. Similarly, most people outside 
> the EMU community would not know that Session-Ids for fast 
> re-authentication must be exported by all EAP methods.
> I agree with folks that there may be multiple solutions that are 
> relevant to the bootstrapping problem. But each of those should 
> developed in working groups where the relevant expertise is present. One 
> could argue that that we would end up developing different solutions for 
> the same problem in silos. However this why we have the IESG ,the 
> directorates, and liaisons to other standards bodies. It ensures that we 
> are aware of related work ongoing in different fora. With my limited 
> experience of IETF, I certainly don't think IETF is in the business of 
> building ecosystems (and neither should it be).
> --Mohit
> On 9/11/19 11:35 PM, Brian E Carpenter wrote:
>> 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.
>> Regards
>>     Brian
>>> 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).
>>>> ....