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

[Brian E Carpenter <[e-mail]>]

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: https://datatracker.ietf.org/meeting/103/materials/slides-103-secdispatch-nimble-out-of-band-authentication-for-eap-eap-noob-draft-aura-eap-noob-04-01
> 
> 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.
>>    https://github.com/mcr/iotwg-charter/blob/master/iotwg-charter.md
>> 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).
>> ....
>>
>>
>>
>>
>>
>