Re: [Iotops] New draft draft-lear-iotops-onboard-intr-00.txt

[Michael Richardson <[e-mail]>]

Eliot Lear <lear=[e-mail]> wrote:
    > I’ve written a bit of a discussion about some of the blockers for IoT
    > onboarding, particular around real zero touch.  Two different
    > onboarding technologies – BRSKI and DPP – have two different gaps that
    > need to be filled to get to zero touch.  BRSKI has one key gap- how the
    > registrar is known by the MASA to be associated with a particular
    > customer.  DPP has one gap: how to get that key into the configurator.
    > If we view the configurator as a registrar.  These problems can reduce
    > to the same one.

Thank you for the interesting document.

Some general comments first:

I was surprised that you aren't making a key characteristic of DPP being that
the public key is delivered by QRcode.  The protocol is not exactly
zero-touch as you say, but it's based upon physical possession.   It's
zero-touch to me in the sense that nobody needs to do anything specific to
the device, like plugging in a console cable, or typing some commands.

The IETF is in the process of (RFC-EDITOR Q) of standardizing
draft-ietf-6tisch-minimal-security, whereby per-device PSKs are distributed
"somehow" to the operator.    Yes, as envisioned, these are PSKs, not key
pairs, but I suspect we could make the same flow (with the same number of
round trips) work if a key pair instead of a PSK was involved.

In section 3 you ought to mention draft-richardson-anima-voucher-delegation.

You write:

} There are several ways to think about this problem:
}
} (1)o  seller transmits something to the buyer registrar as part of a
}      transaction.
}
} (2)o  seller provides buyer an artifact as part of a sale.

I couldn't quite understand the distinction between these.
I think that you meant in (1) that the something (an artifact), is transfered
electronically, while in (2), it is included physically with the item.

}   o  original manufacturer records the sale.
}
}   o  original manufacturer simply notes the transfer.


What your document hints at, but never actually says, is that there is a
continuum of desired onboarding and ownership policies.  Section 1.2, when it
mentions:

   o  Nothing.  It can just sign the voucher request, logging the
      request.
   o  Validation that a particular device belongs in a particular
      deployment.

misses that these are actually two poles of a spectrum.
At one end are things where possession is 100% indication of control.
For instance, gym equipment comes to mind [Google "Gym Enabled Machines", or
GEM].  It is worth discussing if the process of taking control of an exercise
bicycle is really onboarding.  But, I think that there are still a wide
variety of simple things where having it in your hands is sufficient proof.

Moving away from that end, there are more durable goods: fridges, TVs,
stoves, furnaces, possibly even laptops (not the desktop OS itself, but the
BMC).  These things are bought, resold, lent, rented, leased without
filing any papers with a regulatory agency.  Today, they outlive their
manufacturers (or the division that made them), although this trend has been
declining.

Medical equipment has an interesting niche: it is strongly owned, and
strongly regulated, and yet, some aspect of the machine needs to available to
any medical staff that is in physical possession of the device.   When you
need that infusion pump, you need it.

Cars also have a unique niche: while they are bought and sold, they are also
aggressively stolen.  Possession should *not* be a means to prove onwership.
And, pretty much every country already has a regulator (the "DMV") to which
transfers of ownership are filed.

Continuing out to the other pole are items, surveillance cameras for
instance, which despite being essentially in the hands of adversaries, need
to remain owned by the original deployment.

} 5.  This is really only about network onboarding
...
}   For private shared keys, there currently is no great answer to this
}   question.

so, to my mind, if the private shared keys are not being leveraged to create
a more resilient relationship, then the investment in the PSK has been squandered!

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide