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

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Sep 2020 21:41:50 -0400

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_chZR8FmWuKGVaEk/

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 [email-masked], and iot-onboarding, but let's just use
[email-masked].  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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 17:57:48 -0400

> * administrative control of devices

Some have asked how big this effort would be.
I think that it might rather small, and it does not have to a single solution
either.  90% of the challenge in building administrative interfaces is the
authorization side.  This is something that can be handled during onboarding.

A RESTCONF interface might be enough.
  1) https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/ provides
     a way to update a WPA-PSK key for network access.

  2) https://datatracker.ietf.org/doc/rfc8341/ and/or
     https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/
     provides a way to update who can manage the device.  

  3) I looked for a way to statically configure DNS server IPs into a device,
     should one not be willing to use the Do53 ones from DHCP.  There isn't
     such a thing, but I'll bet ADD WG would comment on such a document.
     I was actually looking for some network configuration ("MIB") YANG module, which
     I'm sure exists, but I'm not YANG expert.
     
  4) https://datatracker.ietf.org/doc/draft-kwatsen-netconf-sztp-csr/
     can be used to renew management interface certificates.  Or the
     onboarding system might have an LDevID renewal process.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [