Re: [Iot-onboarding] OPC and BRSKI

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

>   Indeed! One of the by-products of this effort by Eliot to enumerate all these on-boarding techniques might be some common lingo so we can all talk to each other :-)

One of my objectives from this conversation to find out what common terminology should be used in the OPC specifications.

-----Original Message-----
From: Iot-onboarding <[e-mail]> On Behalf Of Dan Harkins
Sent: August 9, 2019 9:56 AM
To: Toerless Eckert <[e-mail]>
Cc: [e-mail]
Subject: Re: [Iot-onboarding] OPC and BRSKI


   Hi Toerless,

On 8/8/19 9:25 AM, Toerless Eckert wrote:
> On Wed, Aug 07, 2019 at 10:40:54PM -0700, Dan Harkins wrote:
>>    The problematic nature of voucher-less trust can be offset 
>> somewhat by limiting knowledge of the device's credential. DPP 
>> attempts to do this. The DPP device will only accept a provisioning agent that knows its public key.
> What is DPP ?

   The Device Provisioning Protocol. A quick google search discovers that Michael has graciously placed the spec on his server. Thanks Michael!

    http://www.sandelman.ca/tmp/ieee/dev-prov.pdf

It's a way to provision 802.11 devices before they get on the 802.11 network.
It doesn't require a backend like a MASA but such a thing could be used if need be. Check it out.

> Interesting scheme. I wonder how problematic security experts would 
> find this approach. But certainly novel to me to use a public key as a 
> shared secret with one "owner".

   The public key isn't really a secret. It's the identity of the device. And if you know it then you have the ability to provision it. You can talk to the device if you know who it is, if you don't know who it is it will ignore you. For small office or home/apartment situations this is trust-by-possession.
But, as I said, something like a MASA could be used to provide other forms of trust (e.g. trust through legitimate purchase).

>> But that is not the only way of  bootstrapping a device's public key. 
>> The device's public key could be bootstrapped from a cloud service-- 
>> give the serial number of the device (and/or proof-of-ownership) and 
>> get back the device's public key.
> How about resale of such a device. The second owner knows that the 
> first owner always has a key left (because it can always remember the public key).
> Or else it should be possible to erase/recreate this key-pair.

   This identity key, called a bootstrapping key, does not change when the thing is reset to to factory defaults. If the thing is not provisioned it will listen for DPP messages addressed to it (via this identity key) and when it is provisioned it will not listen to DPP messages anymore until it is reset to factory defaults. If you want to resell the device you just need to provide the new owner with the bootstrapping key (it may still be in the form of a QR code on its backside or you may have it in packing materials). The owner can then reset the thing to factory defaults and start sending it DPP messages.

>>    This allows the device to have a modicum of trust in "the network" 
>> based on the steps the network had to go through in order to 
>> bootstrap the device's public key.
>> This way printers (with a relatively low bar on trust of "the 
>> network") can get provisioned for a network that also includes 
>> something like a centrifuge (with a relatively higher bar on trust of "the network" that it will join).
> Not sure i understand that point.

   I'm trying to say that there are multiple ways to obtain a thing's identity key and they all impart different degrees of trust. It is up to a manufacturer to provide bootstrapping of identity keys of the things it produces in a manner that is suitable for those kinds of things-- televisions placed on home networks are different than light arrays placed in stadiums which are different than EKGs put in hospitals which are different than....

>>    I'm not sure how relevant this is to OPC (I have not found the 
>> relevant documents on the OPC website) but I just want to point out 
>> that voucher-less provisioning does  not have to rely solely on blind trust or TOFU.
> A voucher is just a secure digital artefact to pass on authorization 
> of ownership. If you want to give that authorization to some 
> enterprises server/registrar in the shared-secret public-key scheme, 
> you would also need to have some way to pass on that public key to 
> that enterprise server. Just a different type of voucher.
>
> Aka: there is always a voucher, even if you haven't called it that way 
> ;-))

   Indeed! One of the by-products of this effort by Eliot to enumerate all these on-boarding techniques might be some common lingo so we can all talk to each other :-)

   regards,

   Dan.



--
Iot-onboarding mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/iot-onboarding