Re: [Anima] [Iot-onboarding] EXTERNAL: Re: OPC and BRSKI

[Michael Richardson <[e-mail]>]

Randy Armstrong (OPC) <[e-mail]> wrote:
    > 1) As it stands today BRSKI is pull model only and the push model is
    > out of scope but I don't see why that has to be the case once you allow
    > for different protocols between the Device and the Registrar. With our
    > proposed OPC mapping we would define a Registrar that supports both
    > models. Is this of any interest to the IETF or would it be an OPC only
    > thing?

There are a number of reasons to think a push model is also workable.
I'm unclear if OPC needs to onboard devices into a wireless network or if
everything is wired.  This matters because the new device has to announce
its presence to the Registrar for push to work.

For instance, you could take a look at:
  https://tools.ietf.org/html/draft-richardson-6tisch-dtsecurity-secure-join-01

which is an old version of the constrained-BRSKI mechanism.
Section 3, (3.2) explains how the Registrar would reach out to the
Pledge using the 6tisch 6p protocol (when it ran over IPv6).

    > 2) Perhaps the most value from BRSKI comes not from the MASA per se but
    > the voucher format (i.e. a digitally signed document with a standard
    > format). We could meet a lot of our requirements if we had a voucher
    > which has a list of nonce-less or bearer vouchers shipped to a
    > particular location for use by a particular end user. We could create
    > workflows where the manufacturer/distributor has to create this
    > document when devices are delivered. The document could be delivered
    > via the MASA or via some other B2B exchange or even on a USB
    > stick. However it is delivered it can then be read by the Registrar and
    > use it to build a whitelist of Devices allowed on the network.

RFC 8572 -- Secure Zero Touch Provisioning (SZTP)
may suit you better. It also uses RFC8366 vouchers.

    > I am also thinking that this voucher would be a good application for
    > block chain where instead of a bearer voucher we define a mechanism
    > where the owner the device could append a "block" to the original
    > voucher which authorizes the transfer to new owner.

We considered distributed ledgers for the audit log.
In all distributed ledgers, you have to ask:
  1) are there mutually distrusting parties?
  2) what do they need to agree upon?
  3) what is the incentive for a third party to validate the chain?

What you have described above, however, is just a certificate chain.
No Block Required.
  https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00

Describes an early notion of how vouchers work, and notice how it delegates
at each step.  Subsequent sales just extend the chain.  We didn't go this
way because:
  1) it mandates sales channel integration, and we think that this will be
     rare at the beginning.
  2) any party in the chain can issue a new sale certificate, effectively
     stealing the device from the current owner.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-