Re: [Iot-onboarding] OPC and BRSKI

[Michael Richardson <[e-mail]>]

Randy Armstrong (OPC) <[e-mail]> wrote:
    > I will start with the main trouble spots. Some of these may be already
    > covered by BRKSI but I missed the implications of some of the text:

    > 1) Low end devices that only support OPC; this means no TLS client
    > capabilities and no ability to initiate network communication
    > (i.e. server only mode);

What is "OPC", from a transport and security point of view?
When I looked through the web site, I'm afraid I came up empty.

BRSKI can be made to work when the pledge is a responder, but there are
details that need to be worked out for specific use cases.

You may prefer https://datatracker.ietf.org/doc/rfc8572/
Secure Zero-Touch Provisioning, which uses the same format vouchers,
but has different flows.

    > 2) Machine builders that combine devices into a machine that is sold as
    > a unit. These device still have a unique network identity but the
    > effective manufacturer has changed; How to deal with the DeviceID?

What an appropriate answer is depends upon who will be responsible for
the components.  Is it the manufacturer of the aggregate or the manufacturer
of the devices. One way to think of this as an initial sale to the
aggregator, and then to replace the trust anchors for a second sale.

Another way is to think of this is that the aggregator runs a mini-registrar,
onboards the devices into the aggregate, and then takes care of the devices
itself.

    > 3) Devices may be reset to factory defaults and sold/transferred to
    > another organization. This needs to be possible even if the MASA is no
    > longer available (i.e. the original manufacturer has gone out of
    > business).

There are a number of different ways to do this; every single one of them
requires some advance planning (coding) by the device manufacturer.

    > 4) Offline operation is the norm with pre-issued vouchers delivered out
    > of band. The pre-issued vouchers will need to have reasonably long
    > lifetime (i..e. years not hours).

This has already been taken into account.
The question is whether the end-owner is known at time of voucher issue or
not.

If not, then you either need a bearer voucher (which RFC8366 declined to
define, as it's so powerful, we were afraid of the security considerations),
or you need to pin to a temporary key which is turned over the operator.
But, that is effectively a bearer voucher with multiple components.

    > The lifecycle of a device is shown in the following diagram. The
    > expectation is we would need to add links to the MASA at each step in
    > the lifetime.

I don't think you need a connection to the MASA until provisioning box, nor
after that either.

I think that the hardest part is (1), and then it's just an applicability statement.

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