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

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

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.

Regards
   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: 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).
>>>> ....
>>>>
>>>>
>>>>
>>>>
>>>>