Minutes interim-2021-iotops-01: Tue 15:00
minutes-interim-2021-iotops-01-202104201500-02

# IOTOPS WG Virtual Interim 2021-01 Minutes

When: 15:00-17:00 UTC, Tuesday, April 20, 2021

Where: https://ietf.webex.com/ietf/j.php?MTID=m633bd0ec88130283104fb7cd84156f3e

Minutes: https://codimd.ietf.org/notes-ietf-interim-2021-iotops-01-iotops

Chairs:  Alexey Melnikov and Henk Birkholz

Minute Takers: Wliot Lear (first half) and Rob Wilton (second half)

## Intro & Logistics - Chairs

Chairs opened the meeting at 3:00pm GMT.  There were some issues with WebEx,
that caused difficulty for some of the speakers (apparently those trying to
join from Linux systems). (It appears that webex no longer does cross-platform
webrtc)

Note Well was presented.
Eliot and Rob agreed to take minutes (Eliot for the first 45 minutes)
Corrections by anyone :-)

## IoT Taxonomies @ NIST - Tim Polk for Paul Watrobski and Susan Symington

This is the result of a project at the NCCOE, it is not submitted as an Internet
Draft but available on NIST's web site.
https://www.nccoe.nist.gov/projects/building-blocks/iot-network-layer-onboarding

Tim then motivated the work as being core to security of IoT.  He pointed out
that there are a lot of solutions by a number of organizations, and that we
needed a common framework to compare them, to avoid apples/oranges comparisons.

NIST is very focused on what the security characteristics are.

The paper is 88 pages, which covers functional roles, what does onboarding
mean, how does onboarding fit into the greater lifecycle?  Some recommended
security capabilities.

Tim then differentiated network onboarding versus application onboarding.  How
is ownership transfered? How is a device decommissioned?  And more.

The paper covers a "supply chain phase".  This includes all the tasks that have
to happen to achieve trusted onboarding.  What are the hardware and software
features that are needed?

Once the supply chain phase is complete, there is the "use phase".  This
includes initial connect, maintenance, resale, repurposing.

Lots of security characteristics are identified.  Some are mandatory, and
others are a requirement for certain types of downstream features.  There are
also non-security characteristics that are needed to handle different parts of
the lifecycle, in order to make things operationally practical.

They differentiate enterprise versus home use.  The world is different for
installing a thermostat at home versus at, say, NIST.

### What about t2trg-secure-bootstrapping?

Perhaps we can reconcile terminology.

t2trg-secure-bootstrapping focuses on network layer onboarding.  Core
recommendations are consistent wrt provisioning/configuring and bootstrapping. 
Nothing broken there.  Document is pretty agnostic.

NCCOE's document establishes requirements.  The scope is quite a bit larger.

Please look at this document as at least one source of material.

Also looked at RFC 8576, and didn't see any particular conflict.

### Advertisement for NCCoE IoT Onboarding Project

Planning to work with vendors on onboarding technologies discussed in the
document.

Can we leverage MUD?  Can we do attestation?

Timeline.  May-June 2021 there will be a solicitation.

Feedback to iot-onboarding@nist.gov.

Alexey then opened up the floor for quick questions on the presentation, but
there were none.

## IoT Initial Security Setup: Players, Beliefs, and Processes - Carsten Bormann

This presentation is not intended to replace or compete with Tim's doc, but to
consider an alternate view.

"Initial security setup" is a key term, with bootstrapping being just one
aspect. Devices need to know their purpose in life, and they need to know how
to fulfill that purpose in a secure way.  And the environment needs to know
something about the devices.

There are three levels of security setup: players, beliefs, and processes.
Some parties are only relevant during setup, and not during operation, some
that are only relevant during operation and not during setup, and some that are
relevant during both.

Beliefs: what information is being installed?
And what are the processes to get us there?

In the end we need to be able to talk about the taxonomy for players, beliefs,
and processes, not just bootstrapping.

### More details on players

We need to be able to talk about partitions of things, and shielded parts like
TEEs. Assuming for now we have a device in a highly structured environment, we
can identify the network, the application, and a platform –– an application
layer network.

These players are usually controlled by entities that *could* be different. 
This is a key issue.

Different roles such as manufacturers, owners, and facilitators may need to
interact with the device.

A device has some identities -- not just one.  These identities are meant to be
used in a specific context, and they each have a root of trust.

Trust anchors are a weird term.  There are specific authorizations tied to
those anchors.  There are three types of authorizations:

 - what the device is authorized by the owner to do
 - another player authorizes an identity held by the device to do something
 - device authorizes others to perform certain functions

These are *beliefs*.

Important milestones:

 - network onboarding
 - platform onboarding
 - application onboarding

Device has:
 - Owner (not in legal sense)
 - original owner (manufacturer)
 - facilitators (handing over control of the device)

Important milestones:
 - Ownership transfer
 - Software update (original owners are delegating some responsibilies to the
 s/w provider) - Also other milestones (e.g. see RFC 8576)

Processes:
 - May be derived from authorizations.
 - Some form of bootstrapping (and perhaps leaf of faith) is needed.
 - Some is also done in the environment (e.g., network, application)
 - Also need to remove authorizations (e.g., factory reset)
 - Can also need to create a temporary key to preserve privacy properties.

Different ways to describe different flavours:
 - Managed vs unmanaged.
 - Who controls what, e.g., which players are under the same ownership (which
 may allow for some back channel communications). - Also, which of these
 players are being swapped in and out in regular use.  E.g., when a device
 moves between networks.  Or integrated with multiple applications. - Also need
 to consider whether physical access implies full authorization.

Hence, we want to create a Taxonomy:
 - Terms for recurring design patterns.
 - Use these terms for specifications and proposals.
 - How useful will this be for IOTOPS?
 - If we manage to pull this off then it will be useful to understand these
 specifications and proposals. - Would help everyone understand what folks are
 talking about.

Alexey: Carsten, do you have a draft, or is it a proposal for new work.
Carsten: No draft, proposal for new work.

Tim: Would you expert T2TRG to be the location for the work.
Carsten: Yes, I think that T2TRG would be a good fit.

Henk: Any other questions on this presentation?
 - No more questions.

## Getting to Know You: Secured Iot Onboarding
 Steve Hanna presenting.

Many different challenges for IOT operations.  Includes onboarding, management,
maintenance, and device disposition (e.g., when transitioning to a new owner).
Value the work that is being done in NIST and T2TRG, terminology does not align.

Device onboarding steps (verificaiton of the device - should it be onboarded,
establishing credentials on the device, configuration of the device (security
and operational parameters), network configuration, user-visible naming of the
device).

Management of the device (e.g., monitoring the device, changing the
configuraiton of the device, which could include credentials, firmware or
software updates to the device, don't just need to fix vulnerabilities, but
also need to add features.)  Very useful if this can be done in a standard way,
otherwise costs are high.  Many techniques that have been used previously don't
apply.

Disposition of the device: Need to remove sensitive data and credentials on the
device.

All of these are challenges to IOT operations, which depend on the environment
on where the IOT device is going to be used.

Project Connected Home over IP (CHIP):
  - Effort to try and create widely supported IOT communications standards.
  - Runs over any media that supports IP (Wi-FI, thread, BLE)
  - Focus is on Smart Home.

  - Is a Working Group as part of the Zigbee Alliance.
  - Lots of companies are participating, including market leaders.
  - Intellectual property is being contributed by many members.
  - Semi-open (need to be a Zigbee member), but specs are open.

Why CHIP:
 - Consumers want smarter homes, especially with Work From Home and Remote
 Learning, but existing devices are too complicated, not secure, and
 incompatible. - CHIP aims to deliver a better experience to the consumer and
 the manufacturer as well. - Can even be used for peer-peer communications
 between devices. - Aim to reuse as many standards as possible.

Chip onboarding process:
 - Bring device home.
 - Scan QR code.
 - Then verification, provisioning, and connect to the home network (without
 needing to enter network passwords or SSIDs) - Will automatically be
 configured with information about other devices that it needs to be connect
 with (so that they can control it, if required)

Chip can be used on different media: Wi-Fi, along with other low power networks
(e.g., thread).  Shouldn't assume that everyone can use a Wi-Fi network.  Many
of the small devices can't use Wi-Fi, but can use IP.  Connectivity to the
cloud is enabled by IP (if required)

Chip includes:
 - Standard communication protocols.
 - Works over IP.
 - Some custom handling for BLE, thread, and Wi-Fi.
 - Practical experience of group members is useful/important.

There is an Open source reference implementation of CHIP
 - Designed for maximum reuseability.

Hence, aim to address all of the IoT operations raised previosuly.

Possible next steps:
 - Specs should be published soon.
 - Products should be shipping by the end of the year.
 - Welcome colaboration with other SDOs (such as IETF), either via liaison
 statements, or dual participation.

Any questions?
None at this time.

## IoT Device Ownership and its Coordinated Hand-Over - Michael Richardson

RFC 8576 provides a great diagram.  Want to talk about operations that comes
after onboarding.
  Want to consider a multi-tenant building.
  Everyone needs to be able to lock the front door (and unlockable by emergency
  services) Sublease arrangements can happen (can be quite short.  e.g., common
  boardrooms) When buying new home, took all tumblers out and get all doors
  rekeyed.  How do we do that for IOT devices.  Need to build this in upfront.

Ownership is known by a signed LDevID.  FIDO does something similar.  CHIP -
Not sure.  Everyone has a crypto identity.  Need to think this all the way
through.

LDevID helps workout which device is which.  Much better soln than WPA key (due
to MAC randomization). Can only assign a per-WPSK key if you know the device
MAC address.  MAC randomization won't work.  Can't have a per-WPSK key, so
cannot kick devices off the network.  Need to get past PSK.

Need to write down what the privacy issues are, and whether they are already
solved by existing approaches (TLS 1.3).

This gives a method for ownership transfer, old owner signs the iDevId of the
new owner.  Figure out how we will process this.  Need to work out which
direction certificates? are pushed.

Disorderly change of ownership:
 - Might be because the CA has gone (e.g., died).  Needs to reset every device.
 Question, is that authorized.  Probably a problem in your home (e.g., if guest
 can press the onboard button on your smart speaker). - What happens if device
 has to continue to operate whilst their ownership is changing.  What about if
 this is for critical devices.  Works for things that can backups.  But what
 about things like elevators, probably cannot turn them all off at the same
 time.  Expect that there will be devices that must work in a continuous
 fashion.

Questions slide:
 - Do we do long lived certificated (with frequent checking)
 - Or short lives certificates, always renewing (STAR)
 - Can be revive enterprise CA so that it is every major/minor building.

Henk: Any questions on this topic?

Warren (no hats): Lots of these things are trying to mitigate problems that
users don't currently have.  Need to make sure that the user doesn't get a
worse user experience.

Michael: Know people who have smart furnaces and have this ownership transfer
problem today, but they just don't know that they have this issue.  IETFer's
perhaps avoid these problems, but many other folks do have this problem.

Eliot: Thanks to presenters.  Question to Steve Hanna.  Does the spec take into
account that their might not be a button to push to initiate a provisioning
process. Steve: No, you don't need a button, there are other ways.

Henk: What do we do next?

Michael:  (1) Do we understand the problem well? (2) What is the model of the
solution?  Can we get devices to check back in with EST servers so that we
allocate multi-decade certificates, but still get devices to check in on a
weekly basis.  Might only be a 1 page RFC.  Or perhaps we leverage the work in
NETCONF, might be easy to say, but perhaps much harder to implement.

Eliot: Different classes of devices.  Likely non cooperative model (e.g., house
foreclosed).  Ramifications is not that you might lose functionality, but also
that others may keep functionality that they should not have.  It might be
useful to document this.  Perhaps different approaches apply for different
types of devices (depending on how valuable they are).

## Phrasing & Scoping of Deliverables - Chairs

Henk: Let's move to phrasing & Scope of Delivarables.
Henk: What work would you like to work on as initial deliverables.

Eliot: My previous suggestion (above).

Carsten: Key escrow.  Anything that we do with involutary transfer will have
some of the properties when key escrow was discussed.  It would be an
interesting discussion.

Michael: Propose that we write doc on Involuntary transfer, work out
boundaries.  May not want to publish, but perhaps something that NIST may wish
to take over.

Carsten: We should do some brainstorming as to whether there is something
better than key escrow before we decide to hand this over to the lawyers.

Tim: I would support the technologist discuss in public would be good (i.e., in
this venue).

Michael: Proposal is to create a doc that describes a pallet of different
mechanisms (key escrow on one side to ...).  Sometimes vendor may help to
recover, other manufactures have said that they won't.

Spencer: If I were going to try and do a BCP on this, I would try and do an
outline first with the problems, then fill in the content on solutions.  Format
of the work, might help a considered discussion of alternatives, and (one
hopes) declare a winner.  Point (2): I think that it is fine for a BCP to say
these are some problems that we don't have a good solution for, for example
"does not involve key escrow that we think is problematic".  Really, think that
you are heading towards a document that should be published as an RFC, likely a
BCP, so that it can be referenced by other bodies, whether SDOs or even
regulatory bodies.

Warren: Agree with Spencer.  Perhaps need an overview architecture before
discussing possible solutions.

Doug (on chat): Should secure onboarding be something users can opt-in /
opt-out of?   Or an inherent property of the device / use?

Eliot: Like to use the phrase "secure by design".  Shouldn't be aiming society
for solutions that require "outs".  Don't want to allow downgrade attacks. 
Everything should happen in a secure way if possible.  Always want to set the
Northstar.  Don't need to worry about laggards, since we all are.

Alexey: Michael you proposed one topic, are you volunteering to co-edit.

Michael: Will certainly be involved.  Not really sure how to organize the
document.  Spencer has got me thinking.

Alexey: Sounds like a plan.

Henk: Commenting on the content. Carsten introduced the term player.  Sometimes
the owner is the player, but sometimes have to involve others.  Might be a good
idea to name these parties.

Eliot: Might want to consider testing for possession of the device.

Michael: What about someone who steals your car?

Eliot: Need to differentiate between theft and repossession.

Michael: Another example of ex-spouse abuse, e.g., through control of a device
after a breakup.

Henk: Will take the suggestion of the proposed work to the list.

Michael: What was the conclusion on Carsten's presentation.

Henk: Where would this taxonomy go?  Should that be in a research group,
buhttps://zoom.us/j/9572446853?pwd=RThaZlBaL0YrZ1FYcVhSWCs5Wm1Cdz09t would
expect it to be used here.

Carsten: Would like to discuss with authors of the current documents.  Have a
varient of mechanisms.  E.g., internet drafts, or wikis.  Might develop a
client/server relationship.  IOTOPs states where terminology is needed, where
the research group may then come up with the terminology.

Henk: A document can also be a useful way for discussion.  Gathering work in
drafts is a useful way forward, even if it doesn't need to be published in the
end.

Chairs: Thanks for having a productive meeting.

Virtual Bluesheet
---
**N.B. These names were recorded at the beginning of the meeting.**

Sean Turner, sn3rd
Eliot Lear, Cisco
Ash Wilson
Bruce Nordman
David Millman
Eric Vyncke, Cisco
Hannes Tschofenig, ARM
Luis Frazao, CIIC-IPLeiria
Mohit Sethi
Murugiah Souppaya, NIST
Rene Struik
Rikard Höglund, RISE
Robert Wilton, Cisco
Scott Rose, NIST
Shuai Zhao, Tencent
Stephen Hanna, Infineon
Tim Polk, NIST
Warren Kumari, Google
Wei Pan, Huawei
Spencer Dawkins, Tencent America,
Oliver Borchert, NIST
Doug Montgomer, NIST
Malisa Vucinic, Inria
Scott Rose, NIST
Marco Tiloca, RISE
Barbara Stark, AT&T
Carsten Bormann, TZI
Michael Richardson, Sandelman Software Works
Alexey Melnikov, Isode Ltd
Henk Birkholz, Fraunhofer SIT