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

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Sep 2019 03:45:08 -0400

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

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Kent Watsen <[email-masked]>
Date: Wed, 4 Sep 2019 13:47:10 +0000

I'm still not 100% sure if this working group is needed but, if such a working group is to be formed, I object to it being BRSKI-oriented, as already there is ANIMA for that.  I appreciate that the first paragraph enumerates a number of efforts (BTW, it should be just "SZTP", without the NETCONF qualifier), and later the text says that it's "not limited to just that protocol" (being BRSKI), but the general tone, and specifically the Milestones, are very BRSKI-specific.  To be clear, if such a working group were formed, I would like to submit a document entitled something like "SZTP for IoT and other Constrained Devices".  In this document I could show how SZTP could be extended to use DTLS, CBOR, and CoAP and further, that it achieves bootstrap state with fewer message exchanges and greater flexibility, not to mention that it already supports the offline/cloudless use-case and a peusdo-NOOB approach (already implemented by Juniper).  SZTP-TEAP could also be provided for.

Thanks,
Kent

> On Sep 4, 2019, at 3:45 AM, Michael Richardson <[email-masked]> wrote:
> 
> 
> ....
> Iot-onboarding mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iot-onboarding

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Sep 2019 18:12:12 +0300

Kent: I am feeling a bit of "my protocol vs your protocol" in your reply.
      It is not my intention to do that.  I think that we did an awesome
      job getting to the commonalities with 8366.  I'm not sure that this
      is as visible to others.

Kent Watsen <[email-masked]> wrote:
    > I'm still not 100% sure if this working group is needed but, if such a
    > working group is to be formed, I object to it being BRSKI-oriented, as
    > already there is ANIMA for that.

Yes, but is that really appropriate?  Are the right people there in ANIMA,
and is it actually disruptive to the ANIMA effort beyond onboarding?
In particular the constrained document is not getting enough attention.

    > I appreciate that the first paragraph
    > enumerates a number of efforts (BTW, it should be just "SZTP", without
    > the NETCONF qualifier),

Sure.  I put it there so that people could find it.

    > and later the text says that it's "not limited
    > to just that protocol" (being BRSKI), but the general tone, and
    > specifically the Milestones, are very BRSKI-specific.

I would very much like to have more, but I don't know what the next steps for
SZTP are.

    > To be clear, if
    > such a working group were formed, I would like to submit a document
    > entitled something like "SZTP for IoT and other Constrained
    > Devices".
    > In this document I could show how SZTP could be extended to
    > use DTLS, CBOR, and CoAP and further, that it achieves bootstrap state
    > with fewer message exchanges and greater flexibility, not to mention
    > that it already supports the offline/cloudless use-case and a
    > peusdo-NOOB approach (already implemented by Juniper).
    
I actually rather believe that SZTP is probably a better starting point for a
cloudless solution.
If SZTP can do a better job for constrained environments, it is *precisely*
this kind of stuff that I'd like to have in this group.

I'm okay with the WG producing 3 or 4 mechanisms, (and then, of course, an
n+1th in four years to converge them, applying
https://www.explainxkcd.com/wiki/index.php/927:_Standards)
Some have attributed this method to Scott Bradner, imaging a meadow of
many wild flowers.

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 4 Sep 2019 16:18:30 +0000

> Kent: I am feeling a bit of "my protocol vs your protocol" in your reply.

Fair point.  I just want to ensure what you say at bottom...

> In particular the constrained document is not getting enough attention.

Unsure.  It's a blurred line to me where ANIMA stops and this might begin...

> Sure.  I put it there so that people could find it.

Okay, but folks should know that, while produced by NETCONF WG, it really has nothing to do with NETCONF protocol.

> I would very much like to have more, but I don't know what the next steps for

Mapping to DTLS, CBOR, CoAP, and MUD would be a good milestones.  Unsure how many drafts that might entail.  Each topic is likely a small document, since it's mostly mapping onto other existing work.

> this kind of stuff that I'd like to have in this group.

Yes, it would be good if this group could cast a wide net.

> I'm okay with the WG producing 3 or 4 mechanisms

Perfect.   Importantly, some of these mechanisms can be run in parallel, as they offer similar level of security, and hence a DoS doesn't result in a degradation attack.

> (and then, of course, an

Never heard the meadow part before, but the "wild" part seems apt.  ;)

Kent

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 11 Sep 2019 19:21:30 +0000

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). EMU is currently going over the re-charter text.

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:

This includes:

Milestones

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 11 Sep 2019 19:26:52 +0000

Hi Kent,

Could you explain the high-level differences between BRSKI and SZTP for those like me who are not extremely familiar.

I know there are probably many differences. For example, I see that the SZTP spec says that devices can receive initial bootstrap information over DNS or from a bootstrap server.

What I am trying to understand is what does a device start from (shared-secret/ephemeral key pair/manufacturer certificate), and what does it end with? Do we need both SZTP and BRSKI?

--Mohit

On 9/4/19 4:47 PM, Kent Watsen wrote:
I'm still not 100% sure if this working group is needed but, if such a working group is to be formed, I object to it being BRSKI-oriented, as already there is ANIMA for that.  I appreciate that the first paragraph enumerates a number of efforts (BTW, it should be just "SZTP", without the NETCONF qualifier), and later the text says that it's "not limited to just that protocol" (being BRSKI), but the general tone, and specifically the Milestones, are very BRSKI-specific.  To be clear, if such a working group were formed, I would like to submit a document entitled something like "SZTP for IoT and other Constrained Devices".  In this document I could show how SZTP could be extended to use DTLS, CBOR, and CoAP and further, that it achieves bootstrap state with fewer message exchanges and greater flexibility, not to mention that it already supports the offline/cloudless use-case and a peusdo-NOOB approach (already implemented by Juniper).  SZTP-TEAP could also be provided for.

Thanks,
Kent

On Sep 4, 2019, at 3:45 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

This includes:

Milestones

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
-= IPv6 IoT consulting =-

--
Iot-onboarding mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/iot-onboarding

---

From: Kent Watsen <[email-masked]>
Date: Wed, 11 Sep 2019 20:30:18 +0000

Hi Mohit,

> What I am trying to understand is what does a device start from (shared-secret/ephemeral key pair/manufacturer certificate), and what does it end with? Do we need both SZTP and BRSKI?
Top of mind.

Preconditions:
- SZTP: secure device identity certificate SHOULD (e.g., IDevID RECOMMENDED), alternate credentials possible.  Optional list of TA certs for validating SZTP servers.  Optional list of TA certs for validating vouchers.
- BRSKI: IDevID MUST.  List of TA certs for validating vouchers MUST.

Normal Operations:
- SZTP: many modes here, some doesn't require networking.  Vouchers only needed when TLS can't be used or trusted.   Vouchers, when used, are primarily long-lived, but MAY be ephemeral (e.g., nonced).  Primarily with strong ownership verification, but weaker forms are possible.
- BRSKI: singular mode (pledge looks for a Registrar).  Vouchers are always used and are primarily conceived to be ephemeral (nonced) with a MASA that maintains a log; long-lived Vouchers and strong ownership-verification are possible.

Postconditions:
- SZTP: a "payload" that could be as small as a script or as large as instructions for updating the OS image + setting an initial configuration.
- BRSKI: a domain certificate.  Additional mechanisms needed to get device into a managed state (this is what some of the other ANIMA drafts are for)

I think I got the BRSKI parts right, but hope folks will chime in if anything is misrepresented or underrepresented.

Kent

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Sep 2019 08:35:32 +1200

Hi Mohit,

On 12-Sep-19 07:21, Mohit Sethi M wrote:
> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Sep 2019 08:57:48 +1200

I think it's worth adding that BRSKI was designed for a specific purpose, namely enrolling *only* a set of authorised autonomic nodes into an autonomic control plane, not for enrolling everything in sight (or do I mean "in site"?) into a data plane. It was designed as an integral part of the ANIMA framework (see https://tools.ietf.org/html/draft-ietf-anima-reference-model). BRSKI may prove to have more generality than that, but it wasn't an explicit goal.

We were always aware of SZTP while BRSKI was developed, and vice versa, but it wasn't a competition.

Regards
   Brian Carpenter

---

From: Mohit Sethi M <[email-masked]>
Date: Thu, 12 Sep 2019 11:05:06 +0000

Hi Kent,

Thanks for this. It is very helpful. I may still need some hand-holding to understand all the aspects. There is quite a lot to digest here.

You mention that SZTP can give a payload to the device that could be a script or more complex instructions. Can this payload be a certificate?

I understand that people will have different opinions about their own work and it can be hard to compare protocols. But are there use-cases that are addressed by BRSKI but not by SZTP? Is it the case that BRSKI addresses some scenarios more efficiently?

--Mohit

On 9/11/19 11:30 PM, Kent Watsen wrote:

Hi Mohit,

Top of mind.

Preconditions:

Normal Operations:

Postconditions:

Kent

---

From: Mohit Sethi M <[email-masked]>
Date: Thu, 12 Sep 2019 11:33:34 +0000

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Sep 2019 13:30:35 +0100

> There is clearly some misunderstanding about EAP-NOOB here. EAP-NOOB is
    > specifically intended for registering new IoT devices on a server (and

...

    > You clearly see a AAA server in the figures. So calling it AAA-less

Thus, why it says, a *version*, but maybe it should have said "variation" of
EAP-NOOB.

I would ask for your help on getting this text correct, but it seems that
you'd rather IoT work was fragmented among many groups? 

My impression is that this makes it very difficult to involve people from
other organizations, and it also results in very uneven reviews.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Sep 2019 13:34:29 +0100

Kent Watsen <[email-masked]> wrote:
    > I think I got the BRSKI parts right, but hope folks will chime in if
    > anything is misrepresented or underrepresented.
    
I think you are exactly on.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 Sep 2019 13:33:20 +0100

Mohit Sethi M <[email-masked]> wrote:
    > I know there are probably many differences. For example, I see that the
    > SZTP spec says that devices can receive initial bootstrap information
    > over DNS or from a bootstrap server.

SZTP does not have voucher-requests.
Or at least, does not do them inband in a specific way detailed by a standard.
Both use RFC8366 vouchers to convey ownership.

    > What I am trying to understand is what does a device start from
    > (shared-secret/ephemeral key pair/manufacturer certificate), and what
    > does it end with? Do we need both SZTP and BRSKI?

They serve different parts of the ecosystem.
SZTP does not mandate an IDevID, but many ways of using it would seem to
benefit from having one.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 12 Sep 2019 17:27:19 +0000

> SZTP does not have voucher-requests.

Indeed.  The tradeoff here is that, in BRSKI, the pledge signs the request and then the local Registrar signs it again, enabling the MASA to verify both.  It's unclear to me what additional security benefits this affords beyond having the request signed by just the Registrar.

> Or at least, does not do them inband in a specific way detailed by a standard.

Correct.  SZTP does not define how the remote peer obtains vouchers.  Voucher's could be prestaged (e.g., on a USB flash drive) or obtained just-in-time via some undefined API.   The SZTP RFC leaves this northbound interaction undefined.   If it is important, an API for just-in-time voucher fetching could be defined.

Another extra thing BRSKI does is using some TLS layer information within the protocol.  I think this is called "channel binding".

Kent

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Sep 2019 08:28:10 +1200

Hi Mohit,

> With my limited 
> 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

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 16 Sep 2019 09:19:54 +0000

Hi Brian,

A protocol that has many dependencies (or gaps) is not ideal from my perspective. A protocol that requires V from chip vendor, W from the device manufacturer, X from certificate authorities, Y from the network administrator, and Z from the user is not a good protocol.

Note that this is a hypothetical protocol that thankfully doesn't exist.

I agree with your statement that IETF should not produce standards with gaps. But the solution is not to fill those gaps. A better solution is that our protocols shouldn't have too many dependencies in the first place.

--Mohit

On 9/12/19 11:28 PM, Brian E Carpenter wrote:

Hi Mohit,

With my limited

Regards
   Brian Carpenter

Hi Brian,

--Mohit

Hi Mohit,

Hi Michael,

Regards
    Brian

Also, you write:

--Mohit

This includes:

Milestones

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Sep 2019 13:25:54 +0200

> On 16 Sep 2019, at 11:19, Mohit Sethi M <mohit.m.sethi=[email-masked]> wrote:
> 
> Hi Brian,
> 

To a point I agree, depending on what V, W, X, Y, and Z are.  If they are things that are at all painful for any player to provide, the &ing of those conditions make success highly unlikely.
> I agree with your statement that IETF should not produce standards with gaps. But the solution is not to fill those gaps. A better solution is that our protocols shouldn't have too many dependencie…

To me I think we are still in early days, all of us, on this problem. Protocols like SZTP or BRSKI or the TEAP extensions we are doing probably require a bit of reconciliation.  What is key, at least for cloud-based provisioning, is the voucher.  What is also key, it seems to me, is an interface like EST.

What we heard in our call with Randy, for instance, was that in that vertical, we have to take into account lengthy SI chains, and we have to do so without client interactions.  One way to address this from an onboarding perspective is to really drive an architecture document such that the components can be shown to fit well together, in a bit of a plug and play mode.

That discussion, it seems to me, could easily drown out all other discussions and seems quite disparate from MUD in particular, which leads me to wonder again if we are being too broad.

Eliot

>>>>> 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 <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>
>>>>> 
>>>>>>     https://github.com/mcr/iotwg-charter/blob/master/iotwg-charter.md <https://github.com/mcr/iotwg-charter/blob/master/iotwg-charter.md>