Re: [Iot-onboarding] OPC and BRSKI

[Toerless Eckert <[e-mail]>]

Randy: These are all excellent points about the BRSKI architecture,
but i would really strongly sugest you bring them up on the ANIMA
mailing list (Cc'ed), which is there to discuss BRSKI.

On Tue, Aug 06, 2019 at 06:58:15PM +0000, Randy Armstrong (OPC) 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);

Whatever more appropriate transport protocol mechanism is needed should
be fine to define. There was/is already work on using CoAP for example,
but maybe there are other protocols too you're interested in ?

"no ability to initiate network communication". Not sure exactly what
you mean to say, but i guess you want so save bytes in the firmware
of the device for discovery protocols ? Thats fine too, as long as
the device has a way to be discovered by subnet adjacend devices. 

The main place where this degree of code optimization becomes an
issue is when the device needs to be connectable to a subnet where
you can not expect a neighbor to be intelligent. Like e.g.: when you
want to allow connecting it to _any_ IP connectivity and get
bootstrapped there. In that case the device needs to do some
dial-home to a MASA or the like.

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

I think to remember that this topic might have been discussed
elswhere, i'll ping. But i fear that the solutions will have
to vary widely based on what the system integrator wants:
E.g.: does the system integrtor wants to be seen as the
customer of the device ? Which would be ideal when the
system integrator effectively resells the device as part of the
larger machine he builds. Or does he wants the customer
of the machine to be the customer of the device ? I could
see how this is necessary to support for regulatory/security
reasons in certain cases.

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

One simple requirement would be the ability for
devices to be "Factor-reset++", where the ++ means that
the current owner can add new trust-anchors to the
factory state.

Simple workflow would be that i sell device aa new
owner, i then pick one of multiple cloud-MASA-services
(independent of vendor). The resale app makes
factor-reset++, burns that reseller-service Trust Anchor
to the device nd provides any form of ownership token
which i send back to the new owner, separate from
shipping the device to the new owner.

To the new owner the enrollment works as if the MASA
was from the original manufactorer, except that its
intead using some MASA from a cloud service tht the
prior owner seleccted. And some details such that the
URL for the MASA would have to be part of the TA
info flashed during firmware-reset++.

At least this model maintains all the benefits of the
MASA process for secure enrollment but give full 
power to the owner and takes the original vendor
out of the loop.

Just one example. Pretty sure there are many possible
workflows desirable.

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

Yepp. That IMHO not not an issue, but rathre" how
do you want to handle these type of long-term vouchers ?

IMHO, here shuold be some block-chain method to store
these vouchers so they can't get lost and don't need
to be reemembered by the owner individually, but that
they can only be used by the owner.

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


Ack.

Cheers
    Toerless

> [cid:[e-mail]708BD0]
> 
> Regards,
> 
> Randy
> 
> From: Eliot Lear <[e-mail]>
> Sent: August 6, 2019 11:08 AM
> To: Randy Armstrong (OPC) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> Yes it is, and it is timely.  I want to stress that what would help greatly would be a step through of the OPC UA use case.
> 
> In particular, one of the issues we want to solve for is when system integrators are in the flow.  The question for us, and this is particularly important as you evolve your TSN approaches, is how should ownership transfer transfer or proof of knowledge occur along the path of SIs.  What is a day in the life of onboarding that you envision?  For a PLC or a POD, how hands free do you want to go?
> 
> Eliot
> 
> 
> 
> 
> On 6 Aug 2019, at 16:57, Randy Armstrong (OPC) <[e-mail]<mailto:[e-mail]>> wrote:
> 
> Hello All,
> 
> I work with the OPC Foundation and we are currently trying to solve a problem similar to what BRSKI is trying to solve for industrial automation devices. However, there are a number of unique requirements in our space which appear to create impedance mismatches between what BRKSI assumes and what we need. I would like to start a discussion on those differences and see if they can be resolved in a way to allow OPC Specifications to incorporate BRSKI.
> 
> Is this the right forum for such discussions?
> 
> Regards,
> 
> Randy Armstrong
> https://opcfoundation.org/
> 
> From: Iot-onboarding <[e-mail]<mailto:[e-mail]>> On Behalf Of Owen Friel (ofriel)
> Sent: August 6, 2019 7:38 AM
> To: Owen Friel (ofriel) <[e-mail]<mailto:[e-mail]>>; Rifaat Shekh-Yusef <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: Re: [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI
> 
> FYI, Its up on github now:
> 
> https://github.com/upros/brski-cloud
> 
> 
> From: Anima <[e-mail]<mailto:[e-mail]>> On Behalf Of Owen Friel (ofriel)
> Sent: 06 August 2019 14:05
> To: Rifaat Shekh-Yusef <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI
> 
> Hi guys,
> 
> After the meeting and from corridor conversations with Toerless, I had actually already started on such a draft.
> 
> What I have started so far is attached. Its not on a public repo yet, but will put it there. You are already named on it Rifaat, happy to add you too Michael and you can help figure out some of the open redirect options outlined in it :)
> 
> My high level thoughts on this were to keep the ACME specifics out of the draft, and use the draft to define the cloud RA behaviour, and the pledge behaviour when interacting with the cloud RA, and the various cert, CA, TLS, redirect, etc. details. The fact that the RA (whether cloud or local) *may* use ACME to talk to the CA is transparent to the pledge.
> 
> I was thinking that the ACME specifics could be covered in a different draft based on merging draft-yusef-acme-3rd-party-device-attestation and draft-friel-acme-integrations, but leave the BRSKI clarifications/specifics in this one.
> 
> Thoughts?
> Owen
> 
> 
> 
> 
> From: Iot-onboarding <[e-mail]<mailto:[e-mail]>> On Behalf Of Rifaat Shekh-Yusef
> Sent: 02 August 2019 19:09
> To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI
> 
> All,
> 
> During the last IETF meeting in Montreal we had a side meeting to discuss the
> deployment automation of ACME issued certificates to devices, and the potential
> use of the BRSKI mechanism to help with this. It was clear from the discussion
> that BRSKI can be used to help address this use case, and that further discussion is
> needed to define the needed enhancements to BRSKI.
> 
> The current BRSKI mechanism only briefly discusses the Cloud Registrar option in
> section 2.7, which could be used to help address this use case.
> 
> Michael Richardson and I had another meeting over lunch yesterday to further
> discuss this and we decided to work on a new draft to describe the issue and
> define a solution.
> 
> Because of vacations and other commitments, we will try to publish the first
> version of the draft early October.
> 
> Regards,
>  Rifaat & Michael
> --
> Iot-onboarding mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/iot-onboarding
> 





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


-- 
---
[e-mail]