Re: [Iot-onboarding] OPC and BRSKI

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

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

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?

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

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

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.

[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