Re: [Iot-onboarding] OPC and BRSKI

["Randy Armstrong (OPC)" <[e-mail]>]

Hi Michael,



1) What is "OPC", from a transport and security point of view?



My initial post was terse because I was not sure it was the right group.

The complete set of specifications are here: https://opcfoundation.org/developer-tools/specifications-unified-architecture

Part 2 provides the overview of the security architecture.

Part 6 defines the layered transport model.



However, it is a lot of text to get through.



2) Secure Zero-Touch Provisioning, which uses the same format vouchers, but has different flows.



Interesting. One solution that works for us is to allow the registrar to use OPC UA instead of TLS which would allow use to define that flows that address all of the OPC requirements. The registrar would then follow BRSKI for interactions with the MASA.



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



Ok, so the device certificate can be replaced by a machine builder? If that is OK then it would address this concern.



4) 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), 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),



We will need bearer vouchers. The registrar is the entity that should decide if a given device belongs on a network as long as the bearer vouchers allow the registrar to verify the origin of the device (i.e. only bearer vouchers issued by a trusted source would be accepted).



Regards,



Randy





-----Original Message-----

From: Iot-onboarding <[e-mail]> On Behalf Of Michael Richardson

Sent: August 6, 2019 2:11 PM

To: Randy Armstrong (OPC) <[e-mail]>

Cc: [e-mail]

Subject: Re: [Iot-onboarding] OPC and BRSKI





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 =-