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

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Tue, 6 Aug 2019 14:57:39 +0000

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 <[email-masked]> On Behalf Of Owen Friel (ofriel)
Sent: August 6, 2019 7:38 AM
To: Owen Friel (ofriel) <[email-masked]>; Rifaat Shekh-Yusef <[email-masked]>; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Owen Friel (ofriel)
Sent: 06 August 2019 14:05
To: Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Rifaat Shekh-Yusef
Sent: 02 August 2019 19:09
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Aug 2019 11:55:31 -0400

Randy Armstrong (OPC) <[email-masked]> wrote:
    > 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.

Understood.

    > Is this the right forum for such discussions?

Yes, you are most welcome to explain things here.
The base document is pretty much done; but it is also explicitely defined for
ANIMA ANI applicability, and it may be that you just need an applicability
statement.  If you need more than that, then bringing it up before the end of
August would be timely.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eliot Lear <[email-masked]>
Date: Tue, 6 Aug 2019 20:08:20 +0200

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) <[email-masked]> wrote:
> 
> Hello All,
> 
> https://opcfoundation.org/ <https://opcfoundation.org/>
> 
> From: Iot-onboarding <[email-masked] <mailto:[email-masked]>> On Behalf Of Owen Friel (ofriel)
> To: Owen Friel (ofriel) <[email-masked] <mailto:[email-masked]>>; Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> https://github.com/upros/brski-cloud <https://github.com/upros/brski-cloud>
> 
> 
> From: Anima <[email-masked] <mailto:[email-masked]>> On Behalf Of Owen Friel (ofriel)
> To: Rifaat Shekh-Yusef <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> 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 J
> 
> From: Iot-onboarding <[email-masked] <mailto:[email-masked]>> On Behalf Of Rifaat Shekh-Yusef
> To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Iot-onboarding mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/iot-onboarding <https://www.ietf.org/mailman/listinfo/iot-onboarding>

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Tue, 6 Aug 2019 18:58:15 +0000

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.

Regards,

Randy

From: Eliot Lear <[email-masked]>
Sent: August 6, 2019 11:08 AM
To: Randy Armstrong (OPC) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Iot-onboarding] OPC and BRSKI

Eliot

On 6 Aug 2019, at 16:57, Randy Armstrong (OPC) <[email-masked]<mailto:[email-masked]>> wrote:

Hello All,

Regards,

Randy Armstrong

From: Iot-onboarding <[email-masked]<mailto:[email-masked]>> On Behalf Of Owen Friel (ofriel)
Sent: August 6, 2019 7:38 AM
To: Owen Friel (ofriel) <[email-masked]<mailto:[email-masked]>>; Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI

Hi guys,

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

Thoughts?
Owen

All,

Regards,
 Rifaat & Michael
--
Iot-onboarding mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/iot-onboarding

---

From: Eliot Lear <[email-masked]>
Date: Tue, 6 Aug 2019 22:46:33 +0200

Hi Randy,

Thanks for this.  It’s a great starting point.  I would propose that we do a call so we can get some high bandwidth discussion going.  Please now see below.

> On 6 Aug 2019, at 20:58, Randy Armstrong (OPC) <[email-masked]> wrote:
> 

How does OPC handle such devices?  I think this is also coming up elsewhere.  One question is whether TLS is required.  Without TLS one does lose confidentiality, but so long as the client can sign the request, maybe that’s all you use.

> 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 De…

At some point, the thing decides which part gets an IP address or at least is responsible for the phy.  Can that process be leveraged to establish identity?

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

One possible view here is that the MASA may be offline, and may have provided a voucher via offline means to the join registrar.  This of course would be nonceless with a lengthy expiry time.  In addition, I posited during BRSKI’s review that perhaps the device should be able to generate its own certificate via a higher level interface.

> 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

Thank you for that.  For wired it seems to me that a permissive MASA model (logging only) could provide you a way forward.  For wireless, this is not an option because proper network selection needs to occur.  Another question is whether we need another mechanism is necessary to validate the voucher (aka, a PSK w/ proof of knowledge, or DPP, etc).

Can you say more about what mechanisms OPC is interested in pursuing?

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Aug 2019 17:10:53 -0400

Randy Armstrong (OPC) <[email-masked]> 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.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 6 Aug 2019 23:26:32 +0200

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.

> 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 De…

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…

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

> [email-masked]

-- 
---
[email-masked]

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Tue, 6 Aug 2019 21:32:45 +0000

Hi Eliot,

Do you have regular calls or do you set up a call when you need it?

1) How does OPC handle such devices?  I think this is also coming up elsewhere.  One question is whether TLS is required.  Without TLS one does lose confidentiality, but so long as the client can sign the request, maybe that’s all you use.

OPC is layered to separate the application from the choice of network protocol. TLS/WebSockets is an option but the primary protocol that will be used by low end devices is UA TCP which provides complete message based security framework.  These devices do not need TLS to have security and requiring it would require duplication of code.

2) At some point, the thing decides which part gets an IP address or at least is responsible for the phy.  Can that process be leveraged to establish identity?

Machines may have a separate network for internal Devices which IPs assigned by the machine’s DHCP service. Some of these devices may interact with external equipment via a NAT router which assigns a unique port to each device. This means the individual Devices need to be granted access to the operators network when the machine is installed even though the operator cannot provide them with IPs.

I need to consult with our machine experts to better explain this use case.

3) One possible view here is that the MASA may be offline, and may have provided a voucher via offline means to the join registrar.  This of course would be nonceless with a lengthy expiry time.  In addition, I posited during BRSKI’s review that perhaps the device should be able to generate its own certificate via a higher level interface.

OPC already has APIs needed to manage Certificates on a Device. The link to something like the MASA is what we are missing. Nonceless vouchers that do not expire should allow local registrar to emulate a MASA when the MASA is no longer available. I wanted to make sure that this mode of operation is allowed BRSKI.

4) Can you say more about what mechanisms OPC is interested in pursuing?

With OPC we assume that network selection and IP assignment are out of scope. Wired devices are the primary market at this time but 5G could change that.

Regards,

Randy

Sent: August 6, 2019 1:47 PM

Hi Randy,

On 6 Aug 2019, at 20:58, Randy Armstrong (OPC) <[email-masked]<mailto:[email-masked]>> wrote:

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Aug 2019 00:30:52 +0200

> OPC is layered to separate the application from the choice of network protocol. TLS/WebSockets is an option but the primary protocol that will be used by low end devices is UA TCP which provides co…

Sure, need to understand how TCP UA works wih the minimum
amount of message authentication to allow for BRSKI. Main
challenge may be the need for pledges to receive messages
from registrar that are authenticated by the registar,
but where the pledge has to wait until it can actually
perform the authentication later. Depending on how you
built TCP UA message layer authentication this may be
piece of cake / free or not.

> Machines may have a separate network for internal Devices which IPs assigned by the machine???s DHCP service. Some of these devices may interact with external equipment via a NAT router which assigns a unique port to each device. This means the individual Devices need to be granted access to the operators network when the machine is installed even though the operator cannot provide them with IPs.
> 

Primary questions seem to be whether this is just about authentication
at the TCP UA layer or further below at some implied NAC mechanism.

> 3) One possible view here is that the MASA may be offline, and may have provided a voucher via offline means to the join registrar.  This of course would be nonceless with a lengthy expiry time.  In addition, I posited during BRSKI???s review that perhaps the device should be able to generate its own certificate via a higher level interface.
> 

Yes it is, it may just not be fully specified in the current targeted
BRSKI RFC that we feel everybody who wants to implement it has
everything to do so, but thats would just be subjet to future
small RFC to close any possible gaps.

> With OPC we assume that network selection and IP assignment are out of scope. Wired devices are the primary market at this time but 5G could change that.

BRSKI also does not care about Addressing. Only ACP does, so you can
ignore that part if you're not interested in. We have tried to
separate out ACP specific aspects in the BRSKI document as good
as possible with the somewhat convoluted process we had in the
IETF how to drive those documents.

Cheers
    Toerless

> Thanks for this.  It???s a great starting point.  I would propose that we do a call so we can get some high bandwidth discussion going.  Please now see below.
> 
> 
> How does OPC handle such devices?  I think this is also coming up elsewhere.  One question is whether TLS is required.  Without TLS one does lose confidentiality, but so long as the client can sign the request, maybe that???s all you use.
> 
> 
> 
> One possible view here is that the MASA may be offline, and may have provided a voucher via offline means to the join registrar.  This of course would be nonceless with a lengthy expiry time.  In addition, I posited during BRSKI???s review that perhaps the device should be able to generate its own certificate via a higher level interface.
> 
> 
> 

-- 
---
[email-masked]

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Tue, 6 Aug 2019 22:51:12 +0000

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 <[email-masked]> On Behalf Of Michael Richardson

Sent: August 6, 2019 2:11 PM

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.

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

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

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

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.

    > the lifetime.

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

--

Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Tue, 6 Aug 2019 23:17:08 +0000

Hi

1) Sure, need to understand how TCP UA works wih the minimum amount of message authentication to allow for BRSKI. Main challenge may be the need for pledges to receive messages from registrar that are authenticated by the registar, but where the pledge has to wait until it can actually perform the authentication later. Depending on how you built TCP UA message layer authentication this may be piece of cake / free or not.

It would be easy to drop in a OPC UA aware registrar and implement all of the BRKSI flows back to the MASA. The only nuisance factor is the 'prior-signed-voucher-request'. If MASA's are willing allow this field to be omitted and to trust the Registrar then nothing more needs to done. If MASA's need this field then we could get it from the Device via OPC UA but producing the CMS message adds an additional burden on low end devices (i.e. the need to pull in libraries that provide the same functionality as OPC UA but do it in different format).

The 2 modes of operation with a OPC UA aware registrar (the Certificate Manager is an OPC UA defined entity).

Pull (device initiated)

Push (Registrar initiated)

Regards,

Randy

-----Original Message-----
From: Toerless Eckert <[email-masked]>
Sent: August 6, 2019 3:31 PM
To: Randy Armstrong (OPC) <[email-masked]>
Cc: Eliot Lear <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Iot-onboarding] OPC and BRSKI

> OPC is layered to separate the application from the choice of network protocol. TLS/WebSockets is an option but the primary protocol that will be used by low end devices is UA TCP which provides co…

Sure, need to understand how TCP UA works wih the minimum amount of message authentication to allow for BRSKI. Main challenge may be the need for pledges to receive messages from registrar that are authenticated by the registar, but where the pledge has to wait until it can actually perform the authentication later. Depending on how you built TCP UA message layer authentication this may be piece of cake / free or not.

> I need to consult with our machine experts to better explain this use case.

Primary questions seem to be whether this is just about authentication at the TCP UA layer or further below at some implied NAC mechanism.

> OPC already has APIs needed to manage Certificates on a Device. The link to something like the MASA is what we are missing. Nonceless vouchers that do not expire should allow local registrar to emu…

Yes it is, it may just not be fully specified in the current targeted BRSKI RFC that we feel everybody who wants to implement it has everything to do so, but thats would just be subjet to future small RFC to close any possible gaps.

> With OPC we assume that network selection and IP assignment are out of scope. Wired devices are the primary market at this time but 5G could change that.

BRSKI also does not care about Addressing. Only ACP does, so you can ignore that part if you're not interested in. We have tried to separate out ACP specific aspects in the BRSKI document as good as possible with the somewhat convoluted process we had in the IETF how to drive those documents.

Cheers

    Toerless

> From: Eliot Lear <[email-masked]<mailto:[email-masked]>>

> To: Randy Armstrong (OPC) <[email-masked]<mailto:[email-masked]>>

> Cc: [email-masked]<mailto:[email-masked]>

> On 6 Aug 2019, at 20:58, Randy Armstrong (OPC) <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>> wrote:

> capabilities and no ability to initiate network communication (i.e.

> server only mode);

> the lifetime

--

---

[email-masked]<mailto:[email-masked]>

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Tue, 6 Aug 2019 23:19:59 +0000

Push should be "Certificate Manager initiated"

From: Iot-onboarding <[email-masked]> On Behalf Of Randy Armstrong (OPC)
Sent: August 6, 2019 4:17 PM
To: Toerless Eckert <[email-masked]>
Cc: [email-masked]; [email-masked]; Eliot Lear <[email-masked]>
Subject: Re: [Iot-onboarding] OPC and BRSKI

Hi

It would be easy to drop in a OPC UA aware registrar and implement all of the BRKSI flows back to the MASA. The only nuisance factor is the 'prior-signed-voucher-request'.. If MASA's are willing allow this field to be omitted and to trust the Registrar then nothing more needs to done. If MASA's need this field then we could get it from the Device via OPC UA but producing the CMS message adds an additional burden on low end devices (i.e. the need to pull in libraries that provide the same functionality as OPC UA but do it in different format).

Pull (device initiated)

Regards,

Randy

-----Original Message-----
From: Toerless Eckert <[email-masked]<mailto:[email-masked]>>
Sent: August 6, 2019 3:31 PM
To: Randy Armstrong (OPC) <[email-masked]<mailto:[email-masked]>>
Cc: Eliot Lear <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Iot-onboarding] OPC and BRSKI

Cheers

    Toerless

> From: Eliot Lear <lear@cisco..com<mailto:[email-masked]>>

--

---

---

From: Eliot Lear <[email-masked]>
Date: Wed, 7 Aug 2019 09:33:19 +0200

Randy,

Thanks.  We have irregular calls, but I will poll for one in the 3rd week of August to discuss your use case.

In an OPC UA environment, might one expect that the join registrar and the certificate manager be co-resident?  This would be where EST/SCEP would happen (BRSKI can be viewed as an extension to EST - RFC 7030).  There is no "push mode" for EST.  However, my understanding is that the same capability roughly speaking resides in CIP.

My bigger question is whether you want to use all of this for network authentication to avoid unauthorized devices joining the network in the first place, or whether this is intended solely for application authentication.

Eliot

> On 7 Aug 2019, at 01:19, Randy Armstrong (OPC) <[email-masked]> wrote:
> 
> Push should be “Certificate Manager initiated”
> 
> From: Iot-onboarding <[email-masked] <mailto:[email-masked]>> On Behalf Of Randy Armstrong (OPC)
> To: Toerless Eckert <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Eliot Lear <[email-masked] <mailto:[email-masked]>>
> From: Toerless Eckert <[email-masked] <mailto:[email-masked]>>
> To: Randy Armstrong (OPC) <[email-masked] <mailto:[email-masked]>>
> Cc: Eliot Lear <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> > From: Eliot Lear <lear@cisco..com <mailto:[email-masked]>>
> > To: Randy Armstrong (OPC) <[email-masked] <mailto:[email-masked]>>
> > Cc: [email-masked] <mailto:[email-masked]>
> > On 6 Aug 2019, at 20:58, Randy Armstrong (OPC) <[email-masked]<mailto:[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]>>> wrote:
> >
> [email-masked] <mailto:[email-masked]>

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Wed, 7 Aug 2019 08:32:33 +0000

Hi Eliot,

1) In an OPC UA environment, might one expect that the join registrar and the certificate manager be co-resident?

Yes that is the expectation.

2) My bigger question is whether you want to use all of this for network authentication to avoid unauthorized devices joining the network in the first place, or whether this is intended solely for application authentication.

Counterfeit devices are huge issue in industrial automation. We need this infrastructure so the Operators can assure themselves that the Devices they plug into their network are genuine.

OTOH, Operators don’t need to prove their right to use a Device. If an Operator has a Device they are entitled to use it (i.e. Devices can be sold/transferred without approval from the manufacturer).

Regards,

Randy

From: Eliot Lear <[email-masked]>
Sent: August 7, 2019 12:33 AM
To: Randy Armstrong (OPC) <[email-masked]>
Cc: Toerless Eckert <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Iot-onboarding] OPC and BRSKI

Randy,

Eliot

On 7 Aug 2019, at 01:19, Randy Armstrong (OPC) <[email-masked]<mailto:[email-masked]>> wrote:

From: Iot-onboarding <[email-masked]<mailto:[email-masked]>> On Behalf Of Randy Armstrong (OPC)
Sent: August 6, 2019 4:17 PM
To: Toerless Eckert <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Eliot Lear <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Iot-onboarding] OPC and BRSKI

Hi

Pull (device initiated)

Regards,

Randy

-----Original Message-----
From: Toerless Eckert <[email-masked]<mailto:[email-masked]>>
Sent: August 6, 2019 3:31 PM
To: Randy Armstrong (OPC) <[email-masked]<mailto:[email-masked]>>
Cc: Eliot Lear <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Iot-onboarding] OPC and BRSKI

Cheers
    Toerless

---

From: Eliot Lear <[email-masked]>
Date: Wed, 7 Aug 2019 10:50:19 +0200

Hi Randy,

Thanks again for your comments.  Please see below.

> On 7 Aug 2019, at 10:32, Randy Armstrong (OPC) <[email-masked]> wrote:
> 
> Hi Eliot,
> 

The purpose, as I see it, of the voucher, is simply to provide zero-touch network provisioning.  I was asking a slightly different question: for purposes of network connectivity will operators want to know that only devices they authorized are connecting (e.g., 802.1X and then like)?  This is a natural assumption in the wireless world, but less so in wired.

Eliot

> On 7 Aug 2019, at 01:19, Randy Armstrong (OPC) <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Wed, 7 Aug 2019 08:57:53 +0000

HI Eliot,

Yes, the Operator needs to ensure that only Devices they authorize can connect and the zero touch provisioning is a feature we desire.

Regards,

Randy

Sent: August 7, 2019 1:50 AM

Hi Randy,

On 7 Aug 2019, at 10:32, Randy Armstrong (OPC) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Eliot,

Eliot

Regards,

Randy

Cc: Toerless Eckert <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Randy,

Eliot

Hi

Pull (device initiated)

Regards,

Randy

-----Original Message-----
From: Toerless Eckert <[email-masked]<mailto:[email-masked]>>
Sent: August 6, 2019 3:31 PM
To: Randy Armstrong (OPC) <[email-masked]<mailto:[email-masked]>>
Cc: Eliot Lear <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Iot-onboarding] OPC and BRSKI

Cheers
    Toerless

---

From: Eliot Lear <[email-masked]>
Date: Wed, 7 Aug 2019 12:01:35 +0200

Randy,

Thanks.  I will be away on holiday for the next week.  However, before I go I will kick off a doodle for the week of the 19th for on onboarding meeting to discuss this.  Please everyone indicate your interest in participating by answering the doodle poll.

Eliot

> On 7 Aug 2019, at 10:57, Randy Armstrong (OPC) <[email-masked]> wrote:
> 
> HI Eliot,
> 
> On 7 Aug 2019, at 10:32, Randy Armstrong (OPC) <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Eliot,
> 
> The purpose, as I see it, of the voucher, is simply to provide zero-touch network provisioning.  I was asking a slightly different question: for purposes of network connectivity will operators want to know that only devicesthey authorized are connecting (e.g., 802.1X and then like)?  This is a natural assumption in the wireless world, but less so in wired.
> 
> Eliot
> 
> 
> 
> Regards,
> 
> Randy
> 
> 
> From: Eliot Lear <[email-masked] <mailto:[email-masked]>>
> Cc: Toerless Eckert <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Aug 2019 10:59:17 -0400

> How does OPC handle such devices?  I think this is also coming up
    > elsewhere.  One question is whether TLS is required.  Without TLS one
    > does lose confidentiality, but so long as the client can sign the
    > request, maybe that’s all you use.

The TLS encryption provides confidentiality, yes, and I agree that it
is not critical to onboarding.  The TLS Client and ServerCertificate and
resulting channel is critical though as it provides the cryptographic
hook on which the voucher is attached.

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

    > Thank you for that.  For wired it seems to me that a permissive MASA
    > model (logging only) could provide you a way forward.  For wireless,
    > this is not an option because proper network selection needs to occur.
    > Another question is whether we need another mechanism is necessary to
    > validate the voucher (aka, a PSK w/ proof of knowledge, or DPP, etc).

    > Can you say more about what mechanisms OPC is interested in pursuing?

+1

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Aug 2019 19:22:52 +0200

On Wed, Aug 07, 2019 at 10:59:17AM -0400, Michael Richardson wrote:
>     > request, maybe that???s all you use.
> 

Thats what i referred to in my prior email: We would need to understand
how to most easily duplicate the mutual authentication with certificates
during TLS connection setup with OPC TCP UA messages.:

| Sure, need to understand how TCP UA works wih the minimum
| amount of message authentication to allow for BRSKI. Main
| challenge may be the need for pledges to receive messages
| from registrar that are authenticated by the registar,
| but where the pledge has to wait until it can actually
| perform the authentication later. Depending on how you
| built TCP UA message layer authentication this may be
| piece of cake / free or not.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Aug 2019 17:07:54 -0400

Randy Armstrong (OPC) <[email-masked]> wrote:
    > It would be easy to drop in a OPC UA aware registrar and implement all
    > of the BRKSI flows back to the MASA. The only nuisance factor is the
    > 'prior-signed-voucher-request'. If MASA's are willing allow this field
    > to be omitted and to trust the Registrar then nothing more needs to
    > done. If MASA's need this field then we could get it from the Device
    > via OPC UA but producing the CMS message adds an additional burden on
    > low end devices (i.e. the need to pull in libraries that provide the
    > same functionality as OPC UA but do it in different format).

Please spend some time reading RFC8366 and RFC8572 (SZTP).
prior-signed-voucher-request is how BRSKI establishes proximity over a local
TLS connection, and you seem to want to avoid that technology.

That's not the only kind of *voucher request*, and RFC8366 allows vouchers to
have other kinds of assertions.  It sounds like you would be very happy
with supply-chain integration of vouchers, and the RFC8572 use of "verified"
vouchers would fit well.  In order to support resale, some mechanism of
updating the trust anchors would have to be profiled.

RFC8572 uses CMS signed JSON for vouchers, and for some configuration
assertions, and while RESTCONF is an option, it's not the only option.

I have downloaded the OPC documents, and I'll skim them tomorrow.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Aug 2019 17:15:26 -0400

Randy Armstrong (OPC) <[email-masked]> wrote:
    > Counterfeit devices are huge issue in industrial automation. We need
    > this infrastructure so the Operators can assure themselves that the
    > Devices they plug into their network are genuine.

So, just to inject some existential angst:
   If the MASA goes away or is compromised, then all the devices
   from that manufacturer can not be proved to not be counterfeit.

Note that the MASA going away is not the same as the Manufacturer going away.

    > OTOH, Operators don’t need to prove their right to use a Device. If an
    > Operator has a Device they are entitled to use it (i.e. Devices can be
    > sold/transferred without approval from the manufacturer).

I'm not sure you really mean to say it this way :-)
  That would lead to the conclusion that it is okay for the operator in the
  next suite (or next cabinet in a DC, or adjacent distillation tower in a
  refiner), to use the device in my suite/cabinet/tower.

The key problem is the verb "has" needs to be made very clear.

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Wed, 7 Aug 2019 21:30:21 +0000

>  from that manufacturer can not be proved to not be counterfeit.

If each Device has a manufacturer issued Certificate with the private key in secure storage like a TPM then the verification of a Device can happen as long as the Operator has a copy of the Manufacturer CA.
This was our original model until someone raised BRSKI.

 > refiner), to use the device in my suite/cabinet/tower.

The Operator decides what Devices go on the networks the Operator controls.
As long as a system is in place to allow the Operator (not the Manufacturer or MASA) to block access to a network then the network is secure.
The one risk which exists is theft. i.e. a thief can't be prevented from using a stolen device.
I can see this being a high priority requirement for mobile phones but not for PLCs.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 7 Aug 2019 19:41:07 -0400

> capabilities and no ability to initiate network communication (i.e. 

Thanks for the link to the WIP at: 
https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part2/3.1/

I looked through this document looking for the what you are using that 
isn't TLS.  TLS is clearly mentioned in the document. Section 4 of that 
document at 
https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part2/4.5.2/
refers to a Secure Channel, and references which led me to:

https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part4/6.1.4/
I can't see anything there that says it is TLS, nor can I can see 
anything that is at odds with it being TLS.

https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part6/4/ 
says:"that is built on an existing Layer 5, 6 or 7 protocol such as 
TCP/IP, TLS or HTTP. "

At 
https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part6/6.5.1/ 
  I see that Kerberos is mentioned, and then JWT, and OAUTH2.

Now, at: 
https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part6/7.1.1/ 
  I see your UAPC protocol, finally! And UAPC can run over: TCP, 
SOAP/HTTP (deprecated), HTTPS, WebSockets (HTTP and HTTPS).

So as far as I can see, in the TCP and WebSockets-over-HTTP, there is no 
security at all. In all other cases, there is TLS (or HTTPS).

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Thu, 8 Aug 2019 00:01:38 +0000

Hi Michael,

UA CP includes a complete security handshake which provides end-to-end message security over any transport:
https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part6/6.1/

UA TCP is UA CP over a raw TCP socket. 
When UA CP runs over HTTPS you have the option of using UA CP security in addition to TLS which is useful if you are going through untrusted HTTPS proxies.

For low end devices the only transport will be UA TCP.

Regards,

Randy

Note: the links to the specifications are from a website under development so missing/dead links will show up. The URLs will also change when we go to release.

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: August 7, 2019 4:41 PM
To: Randy Armstrong (OPC) <[email-masked]>; [email-masked]
Subject: Re: [Iot-onboarding] OPC and BRSKI

I looked through this document looking for the what you are using that isn't TLS.  TLS is clearly mentioned in the document. Section 4 of that document at https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part2/4.5.2/
refers to a Secure Channel, and references which led me to:

https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part4/6.1.4/
I can't see anything there that says it is TLS, nor can I can see anything that is at odds with it being TLS.

https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part6/4/
says:"that is built on an existing Layer 5, 6 or 7 protocol such as TCP/IP, TLS or HTTP. "

At

Now, at: 
https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part6/7.1.1/
  I see your UAPC protocol, finally! And UAPC can run over: TCP, SOAP/HTTP (deprecated), HTTPS, WebSockets (HTTP and HTTPS).

So as far as I can see, in the TCP and WebSockets-over-HTTP, there is no security at all. In all other cases, there is TLS (or HTTPS).

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Thu, 8 Aug 2019 00:46:56 +0000

Toerless,

> Thats what i referred to in my prior email: We would need to understand how to most easily duplicate the mutual authentication with certificates during TLS connection setup with OPC TCP UA messages.:

OPC UA CP requires mutual authentication with Certificates bound to the application rather than the machine. It provides everything that you get from TLS.

So when the Pledge Device connects to the Registrar or the Certificate Manager using UA the Device proves it has possession of the Device private key. 

That said, the KeyPair used for communication does not need to be the same as the KeyPair used to authenticate. 

Regards,

Randy

-----Original Message-----
From: Toerless Eckert <[email-masked]> 
Sent: August 7, 2019 10:23 AM
To: Michael Richardson <[email-masked]>
Cc: Eliot Lear <[email-masked]>; Randy Armstrong (OPC) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Iot-onboarding] OPC and BRSKI

On Wed, Aug 07, 2019 at 10:59:17AM -0400, Michael Richardson wrote:
> is not critical to onboarding.  The TLS Client and ServerCertificate 
> and resulting channel is critical though as it provides the 
> cryptographic hook on which the voucher is attached.

Thats what i referred to in my prior email: We would need to understand how to most easily duplicate the mutual authentication with certificates during TLS connection setup with OPC TCP UA messages.:

| Sure, need to understand how TCP UA works wih the minimum amount of 
| message authentication to allow for BRSKI. Main challenge may be the 
| need for pledges to receive messages from registrar that are 
| authenticated by the registar, but where the pledge has to wait until 
| it can actually perform the authentication later. Depending on how you 
| built TCP UA message layer authentication this may be piece of cake / 
| free or not.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Wed, 7 Aug 2019 19:43:10 +0000

> On Aug 7, 2019, at 4:50 AM, Eliot Lear <[email-masked]> wrote:
> 

More specifically, the voucher enables the device to trust the network, i.e., the entity claiming to be the device's owner.  Without the voucher, there is the TOFU (trust on first use), a.k.a. "resurrecting duckling" problem.

Kent

---

From: Dan Harkins <[email-masked]>
Date: Wed, 07 Aug 2019 22:40:54 -0700

Hi Kent,

On 8/7/19 12:43 PM, Kent Watsen wrote:
>> On Aug 7, 2019, at 4:50 AM, Eliot Lear <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> The purpose, as I see it, of the voucher, is simply to provide 
>> zero-touch network provisioning.  I was asking a slightly different 
>> question: for purposes of network connectivity will operators want to 
>> know that only devices*they* authorized are connecting (e.g., 802.1X 
>> and then like)?  This is a natural assumption in the wireless world, 
>> but less so in wired.
>
> More specifically, the voucher enables the device to trust the 
> network, i.e., the entity claiming to be the device's owner.  Without 
> the voucher, there is the TOFU (trust on first use), a.k.a. 
> "resurrecting duckling" problem.

   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.

   The idea is that degree of gratuitousness of the device's 
bootstrapping directly
determines how much it can trust "the network" that has bootstrapped 
it's public key.
A QR code on the device's backside means that the device will trust 
anyone who has
physical possession of it (and can scan it's backside). This does not 
prevent the
"device fell off the truck" threat. 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.

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

   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.

   regards,

   Dan.

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Thu, 8 Aug 2019 06:04:35 +0000

> I'm not sure how relevant this is to OPC (I have not found the relevant documents
> the OPC website) but I just want to point out that voucher-less provisioning does

What we are looking for from the MASA is a framework that will provide the Operator with a "whitelist" of Device Certificates before any Device is plugged into the Network.
The OPC UA enabled Registrar would know what Devices are allowed when they attempt to register.
(IOW - the registrar does not simply rely on the Manufacturer CA).

From: Iot-onboarding <[email-masked]> On Behalf Of Dan Harkins
Sent: August 7, 2019 10:41 PM
To: [email-masked]
Subject: Re: [Iot-onboarding] OPC and BRSKI

  Hi Kent,
On 8/7/19 12:43 PM, Kent Watsen wrote:
On Aug 7, 2019, at 4:50 AM, Eliot Lear <[email-masked]<mailto:[email-masked]>> 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.

  The idea is that degree of gratuitousness of the device's bootstrapping directly
determines how much it can trust "the network" that has bootstrapped it's public key.
A QR code on the device's backside means that the device will trust anyone who has
physical possession of it (and can scan it's backside). This does not prevent the
"device fell off the truck" threat. 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.

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

  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.

  regards,

  Dan.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 8 Aug 2019 14:43:42 +0000

> only accept a provisioning agent that knows its public key. 

If the public key is public, how secure is that?   Presumably the public-key is not really public, e.g., it is protected by manufacturing and sale-channel processes,  This may be good enough for some use cases.  It would be good to see a Security Considerations write-up whereby acceptable use-cases are enumerated.

> back the device's public key.

Indeed, there are degrees are trustworthiness needed and solutions meeting the criteria.   I mentioned this at the iot-onboarding meetup in Prague.

> relatively higher bar on trust of "the network" that it will join).

Yes, it is a spectrum, but I think that it's important to note that each individual device type can only implement bootstrapping solutions (potentially more than one at a time) that are at the same level of security as, otherwise, there is a possibility for a degradation attack.

> not have to rely solely on blind trust or TOFU.

Fair.   

Back to OPC, my previous comment didn't state it, but I was trying to say that the use case described by Randy is one where the device does NOT need to trust the network at all and, in this sense, bootstrapping protocols relying on RFC 8366 or similar are not needed.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Thu, 8 Aug 2019 14:51:40 +0000

Hi Randy,

> What we are looking for from the MASA is a framework that will provide the Operator with a “whitelist” of Device Certificates before any Device is plugged into the Network.
> The OPC UA enabled Registrar would know what Devices are allowed when they attempt to register..
> (IOW – the registrar does not simply rely on the Manufacturer CA).

Indeed.  Assuming a secure device identity certificate (e.g., IDevID), the network trusting the device is a two-step process:
  1) certificate-path validation to the manufacturer's CA
  2) device-identity (e.g., serial number) is expected.

The backend supporting what you're looking for is hinted at by RFC 8572, item #4 in C.1.   What the NMS does is out-of-scope to SZTP, but not doing both path-validation and identity-verification wouldn't make sense, given that a device-specific response is needed in most cases.

Kent

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Aug 2019 11:47:12 -0400

> OPC UA CP requires mutual authentication with Certificates bound to the
    > application rather than the machine. It provides everything that you
    > get from TLS.

Based upon my reading of the diagram, it is not obvious that it provides
PFS, but I don't think PFS is particularly important for BRSKI.  It seems
to support client certificates and server certificates, and that's enough.
We need an equivalent to tls-unique in order to properly bind the EST channel
to the UA CP SecureChannel, but that's all I think.

    > So when the Pledge Device connects to the Registrar or the Certificate
    > Manager using UA the Device proves it has possession of the Device
    > private key.

    > That said, the KeyPair used for communication does not need to be the
    > same as the KeyPair used to authenticate.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Aug 2019 11:53:22 -0400

Randy Armstrong (OPC) <[email-masked]> wrote:
    dan> I'm not sure how relevant this is to OPC (I have not found the
    dan> relevant documents
    dan> the OPC website) but I just want to point out that voucher-less
    dan> provisioning does
    dan> not have to rely solely on blind trust or TOFU.

    > What we are looking for from the MASA is a framework that will provide
    > the Operator with a "whitelist" of Device Certificates before any
    > Device is plugged into the Network.

We refer to this list as being part of "Sales Channel Integration".

If the manufacturer knows who it sold each device to, then it can provide
vouchers only to those owners; the operator does not need to know.

The alternative is that the manufacturer communicates the identity (serial
number) of each device to the operator as part of an electronic sales
invoice.  How this occurs is not in scope for BRSKI (I hope that OASIS or
some other entity has a protocol), but it means that the operator can know
which device belongs prior talking to the MASA.

    > (IOW - the registrar does not simply rely on the Manufacturer CA).

I'm not sure there is a lot of difference in trust between receiving a list
(upfront) from the manufacturer as part of the sales invoice, and receiving
the list incrementally in the form of vouchers.  They are different
processes, and there are different opportunities for humans to confirm.
Clearly if the list is on paper, then a human has to enter the list, and
this is something I think we should aim to avoid as it is error prone.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 8 Aug 2019 18:25:40 +0200

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 ?

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

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

Cheers
    toerless

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Thu, 8 Aug 2019 16:54:11 +0000

Hi Michael,

OPC UA uses SecurityProfiles to specify the exact algorithms. The based RSA profiles do not have PFS but the ECC profiles do.
We expect the ECC profiles (not released yet) to be most interesting to low end device makers.
https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part7/6.6.164/

It is not clear which tls-unique attribute you are interested in.
Do you need a unique identifier for the negotiated keys?
If so the SecureChannelId + TokenId would provide that.
https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part6/6.7.2/#Table43

Regards,

Randy

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: August 8, 2019 8:47 AM
To: Randy Armstrong (OPC) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Iot-onboarding] OPC and BRSKI

    > application rather than the machine. It provides everything that you

Based upon my reading of the diagram, it is not obvious that it provides PFS, but I don't think PFS is particularly important for BRSKI.  It seems to support client certificates and server certificates, and that's enough.
We need an equivalent to tls-unique in order to properly bind the EST channel to the UA CP SecureChannel, but that's all I think.

---

From: Dan Harkins <[email-masked]>
Date: Fri, 09 Aug 2019 09:55:48 -0700

Hi Toerless,

>> device will only accept a provisioning agent that knows its public key.

   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.

> this approach. But certainly novel to me to use a public key as a shared

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

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

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

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

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Fri, 9 Aug 2019 19:31:57 +0000

>   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 <[email-masked]> On Behalf Of Dan Harkins
Sent: August 9, 2019 9:56 AM
To: Toerless Eckert <[email-masked]>
Cc: [email-masked]
Subject: Re: [Iot-onboarding] OPC and BRSKI

   Hi Toerless,

On 8/8/19 9:25 AM, Toerless Eckert 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!

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

   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.

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

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

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

   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.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 10 Aug 2019 17:15:57 -0400

Jack Visoky <[email-masked]> wrote:
    > I am also involved with OPC-UA and would like to provide my/my
    > company's perspective.  One of the major drivers of this engagement
    > with the ANIMA group was a contentious point around whether or not TLS
    > and EST are required for support of BRSKI.  Some of us had taken the
    > position that these technologies are an integral part of BRSKI and
    > shouldn't be replaced with OPC specific methods, especially given the
    > benefit of using highly adopted security technologies, as well as the
    > tight coupling of BRSKI to these.  So, I think the idea that OPC should
    > just use these technologies is very much a viable answer.

If the device is powered or has enough battery to do 802.11, then it probably
has enough power and code space to do TLS (particularly mbedtls from ARM).
If it's on a very low duty cycle on battery, and/or it does 802.15.4, then
the question is still open.  The IETF may start work on a 802.15.4
specific AKE, (see [email-masked]).  We believe we need these for 6tisch
(TSCH mode of 802.15.4 for deterministic industrial networks)

It appears that the OPC UA methods provide enough security to do BRSKI,
but there are significant benefits to not maintaining your own protocols,
and significant benefits to getting the extensive review that TLS gets.

    > Also, I would strongly push back on any claims that low end OPC devices
    > cannot support TLS.  Other industrial protocols have already added TLS
    > support and are shipping products, including those with TLS client
    > functionality.  TLS is no more heavy-weight than existing, OPC-specific
    > security mechanisms.

The OPC-specific mechanism appears to avoid a DH operation and therefore
lacks PFS.  I understand it uses RSA, which means that it's significantly
more expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have
hardware acceleration for ECDSA's secp256v1, fewer have RSA acceleration.

    > In any event I will be sure to join the call that has been set up for
    > later in August.

Awesome.

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Sat, 10 Aug 2019 23:26:13 +0000

> If the device is powered or has enough battery to do 802.11, then it probably has enough power and code space to do TLS (particularly mbedtls from ARM).

The issue is more the additional libraries needed to support this functionality. For companies like Rockwell, which have heavily invested in CIP over TLS, these libraries are already there. For other big automation vendors this is not the case.  

> It appears that the OPC UA methods provide enough security to do BRSKI, but there are significant benefits to not maintaining your own protocols, and significant benefits to getting the extensive review that TLS gets.

OPC UA security is end to end security and not tied to specific transport which is preferable from an architecture perspective. While the wide use of TLS is an advantage and I can assure you that the OPC WGs have extensively debated the pros and cons of TLS vs an OPC specific mechanism before we got to where we are today. 

> The OPC-specific mechanism appears to avoid a DH operation and therefore lacks PFS.  I understand it uses RSA, which means that it's significantly more expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have hardware > acceleration for ECDSA's secp256v1, fewer have RSA acceleration.

OPC also has ECDH based policies. These will be used by low end devices.

The questions that the OPC WG needs to answer are:

1) Can BRSKI meet our requirements?
2) If the answer to 1) is yes then can it work with OPC UA security?
3) If the answer to 2) is no then do we use TLS or extend our own model with something like BRSKI but not BRSKI?

While I cannot predict how the various participants in the OPC WGs will respond to question 3), I do know it would make collaboration a lot easier if the answer to 2) was yes.

Regards,

Randy

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: August 10, 2019 2:16 PM
To: Jack Visoky <[email-masked]>; Randy Armstrong (OPC) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI

    > just use these technologies is very much a viable answer.

If the device is powered or has enough battery to do 802.11, then it probably has enough power and code space to do TLS (particularly mbedtls from ARM).
If it's on a very low duty cycle on battery, and/or it does 802.15.4, then the question is still open.  The IETF may start work on a 802.15.4 specific AKE, (see [email-masked]).  We believe we need these for 6tisch (TSCH mode of 802.15.4 for deterministic industrial networks)

It appears that the OPC UA methods provide enough security to do BRSKI, but there are significant benefits to not maintaining your own protocols, and significant benefits to getting the extensive review that TLS gets.

    > functionality.  TLS is no more heavy-weight than existing, OPC-specific

The OPC-specific mechanism appears to avoid a DH operation and therefore lacks PFS.  I understand it uses RSA, which means that it's significantly more expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have hardware acceleration for ECDSA's secp256v1, fewer have RSA acceleration.

Awesome.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 10 Aug 2019 21:08:29 -0400

> 1) Can BRSKI meet our requirements?

I think so; there are some details of resale that BRSKI would like to make
out-of-scope for the first document.  Some way, we have to deal with it,
and I would actually like feedback from OPC about the parameters of different
solutions here.

    > 2) If the answer to 1) is yes then can it work with OPC UA security?

yes, I think so.
is there any open source reference code for the OPC UA security?

    > While I cannot predict how the various participants in the OPC WGs will
    > respond to question 3), I do know it would make collaboration a lot
    > easier if the answer to 2) was yes.

I think yes.

---

From: "Randy Armstrong (OPC)" <[email-masked]>
Date: Sun, 11 Aug 2019 02:55:42 +0000

> I think so; there are some details of resale that BRSKI would like to make out-of-scope for the first document.  Some way, we have to deal with it, and I would actually like feedback from OPC about the parameters of different solutions here.

There are two things I would like to clarify:

1) As it stands today BRSKI is pull model only and the push model is out of scope but I don't see why that has to be the case once you allow for different protocols between the Device and the Registrar. With our proposed OPC mapping we would define a Registrar that supports both models. Is this of any interest to the IETF or would it be an OPC only thing?

2) Perhaps the most value from BRSKI comes not from the MASA per se but the voucher format (i.e. a digitally signed document with a standard format). We could meet a lot of our requirements if we had a voucher which has a list of nonce-less or bearer vouchers shipped to a particular location for use by a particular end user. We could create workflows where the manufacturer/distributor has to create this document when devices are delivered. The document could be delivered via the MASA or via some other B2B exchange or even on a USB stick. However it is delivered it can then be read by the Registrar and use it to build a whitelist of Devices allowed on the network. 

I am also thinking that this voucher would be a good application for block chain where instead of a bearer voucher we define a mechanism where the owner the device could append a "block" to the original voucher which authorizes the transfer to new owner. 

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: August 10, 2019 6:08 PM
To: Randy Armstrong (OPC) <[email-masked]>
Cc: Jack Visoky <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI

    > 1) Can BRSKI meet our requirements?

I think so; there are some details of resale that BRSKI would like to make out-of-scope for the first document.  Some way, we have to deal with it, and I would actually like feedback from OPC about the parameters of different solutions here.

yes, I think so.

I think yes.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 11 Aug 2019 12:49:19 -0400

Randy Armstrong (OPC) <[email-masked]> wrote:
    > 1) As it stands today BRSKI is pull model only and the push model is
    > out of scope but I don't see why that has to be the case once you allow
    > for different protocols between the Device and the Registrar. With our
    > proposed OPC mapping we would define a Registrar that supports both
    > models. Is this of any interest to the IETF or would it be an OPC only
    > thing?

There are a number of reasons to think a push model is also workable.
I'm unclear if OPC needs to onboard devices into a wireless network or if
everything is wired.  This matters because the new device has to announce
its presence to the Registrar for push to work.

For instance, you could take a look at:
  https://tools.ietf.org/html/draft-richardson-6tisch-dtsecurity-secure-join-01

which is an old version of the constrained-BRSKI mechanism.
Section 3, (3.2) explains how the Registrar would reach out to the
Pledge using the 6tisch 6p protocol (when it ran over IPv6).

    > 2) Perhaps the most value from BRSKI comes not from the MASA per se but
    > the voucher format (i.e. a digitally signed document with a standard
    > format). We could meet a lot of our requirements if we had a voucher
    > which has a list of nonce-less or bearer vouchers shipped to a
    > particular location for use by a particular end user. We could create
    > workflows where the manufacturer/distributor has to create this
    > document when devices are delivered. The document could be delivered
    > via the MASA or via some other B2B exchange or even on a USB
    > stick. However it is delivered it can then be read by the Registrar and
    > use it to build a whitelist of Devices allowed on the network.

RFC 8572 -- Secure Zero Touch Provisioning (SZTP)
may suit you better. It also uses RFC8366 vouchers.

    > I am also thinking that this voucher would be a good application for
    > block chain where instead of a bearer voucher we define a mechanism
    > where the owner the device could append a "block" to the original
    > voucher which authorizes the transfer to new owner.

We considered distributed ledgers for the audit log.
In all distributed ledgers, you have to ask:
  1) are there mutually distrusting parties?
  2) what do they need to agree upon?
  3) what is the incentive for a third party to validate the chain?

What you have described above, however, is just a certificate chain.
No Block Required.
  https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00

Describes an early notion of how vouchers work, and notice how it delegates
at each step.  Subsequent sales just extend the chain.  We didn't go this
way because:
  1) it mandates sales channel integration, and we think that this will be
     rare at the beginning.
  2) any party in the chain can issue a new sale certificate, effectively
     stealing the device from the current owner.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 12 Aug 2019 20:50:20 +0200

Agreeing to what Michael and you said, but also wanted to point out
that TLS as defined by IETF is on a trajectory which may or may not be desirable
for e.g.: industrial automation (where OPC is used) or other regulated/
critical environments.

For example the total elimination of any non-encryption option in the
TLS1.3 profile and the removal of the ability for passive observers to see
the certificates exchanged impeeds severely on the ability to do passive
diagnostics.

I at least think there are good reasons to also have a strong
and independent reviewed authentication scheme without encryption
that can well be diagnosed by passive observers.

Aspects like these are easily fixed IMHO by creating different profiles
of TLS. Whether or not one could get such profiles through the TLS
WG in the IETF is of course a different question given what seems to
be a highly contentuous nature of the topic.

There also seems to be a desire of areas of industrial automation to
avoid the overhead of a perceived to be redundant network layer. This
was a thing back in the days of OSI where TP4 was often run in
factories without CLNS, and given how IP hasn't really improved on
simplified, automated address management vs. L2 switched ethernet,
this still seems to be a thing. Aka: Someone would need to define
TLS on top of just ethernet instead of IP/IPv6. And there may be
other similar L2 "transport" technologies where its not clear if
simple ethernet mappings would suffice (bluetooth, wifi,...).

Last but not least, QUIC is on a path to replace TLS and that
too puts a dent into the belief that TLS as it stands would be
a long term stable most-widely used protocol.

Finally: There is something said to not simply trust a design like
TLS which you do not really understand just because  its widely used,
and thus hopefully well reviewed, but rather make sure you have a
design based on solid understanding of the cryptographic principles employed
and a well defined review/control process of implementations.  Incidents
like with OpenSSL show how badly reviewed even the most widely deployed
crypto mechanisms can be.

Cheers
    Toerless

On Sun, Aug 11, 2019 at 09:31:22PM +0000, Jack Visoky wrote:
> > but there are significant benefits to not maintaining your own protocols, and significant benefits to getting the extensive review that TLS gets.
> 
> I could not agree more with this statement.
> 
> Thanks,
> 
> --Jack
> 
> 
> Sent: Saturday, August 10, 2019 5:16 PM
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Aug 2019 17:29:11 -0400

Jack Visoky <[email-masked]> wrote:
    >> I think so; there are some details of resale that BRSKI would like to
    >> make out-of-scope for the first document.  Some way, we have to deal
    >> with it, and I would actually like feedback from OPC about the
    >> parameters of different solutions here. 

    > So in this case would the MASA need to be OPC specific, that is, use
    > OPC Security and OPC methods?  Apologies if I'm getting ahead of myself
    > on this conversation.

I don't think that the MASA would be OPC specific.

The Registrar would have to speak the OPC security rather than HTTPS on the
plant side.  The Registrar would still speak HTTPS to the MASA.

This is what we have done in draft-ietf-anima-constrained-voucher:
  it speaks CoAPS (CoAP over DTLS) or OSCORE-EDHOC (CoAP with OSCORE, keyed
  by EDHOC) on the plant side, and HTTPS to the Registrar.

There are (at least) two major ways to build a Registrar.
1) a single monolithic application framework, it receives
   the voucher-request, and then does a synchronous HTTPS request to the MASA.
   (Perhaps doing 100-Continue).

2) The other way is for the pledge-facing part of the Registrar to put it all
   into a database, return 202, and wait for another query.  Asynchronously some
   other part sends requests to the MASA and stores the answers back in the
   database.  Perhaps the only thing connecting the two parts is some
   multi-master database replication...

Case 1 is appropriate up to a certain level of load and complexity.
It's certainly way easier to test!

Case 2 has scaling advantages, some security advantages, and also makes it
way easier to build different plant facing interfaces.

I believe that all implementations are case 1 so far.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 13 Aug 2019 13:19:14 +0000

-----Original Message-----
From: Iot-onboarding <[email-masked]> On Behalf Of Toerless Eckert
Sent: 12 August 2019 19:50
To: Jack Visoky <jmvisoky=[email-masked]>
Cc: Michael Richardson <[email-masked]>; Randy Armstrong (OPC) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Iot-onboarding] [Anima] EXTERNAL: Re: OPC and BRSKI

Agreeing to what Michael and you said, but also wanted to point out that TLS as defined by IETF is on a trajectory which may or may not be desirable for e.g.: industrial automation (where OPC is used) or other regulated/ critical environments.

For example the total elimination of any non-encryption option in the
TLS1.3 profile and the removal of the ability for passive observers to see the certificates exchanged impeeds severely on the ability to do passive diagnostics.

I at least think there are good reasons to also have a strong and independent reviewed authentication scheme without encryption that can well be diagnosed by passive observers.

Aspects like these are easily fixed IMHO by creating different profiles of TLS. Whether or not one could get such profiles through the TLS WG in the IETF is of course a different question given what seems to be a highly contentuous nature of the topic.

There also seems to be a desire of areas of industrial automation to avoid the overhead of a perceived to be redundant network layer. This was a thing back in the days of OSI where TP4 was often run in factories without CLNS, and given how IP hasn't really improved on simplified, automated address management vs. L2 switched ethernet, this still seems to be a thing. Aka: Someone would need to define TLS on top of just ethernet instead of IP/IPv6. And there may be other similar L2 "transport" technologies where its not clear if simple ethernet mappings would suffice (bluetooth, wifi,...).

Last but not least, QUIC is on a path to replace TLS and that too puts a dent into the belief that TLS as it stands would be a long term stable most-widely used protocol.

[ofriel] Its more accurate to say that QUIC is going to replace TCP. QUIC will be secured using TLS: https://tools.ietf.org/html/draft-ietf-quic-tls-22

Finally: There is something said to not simply trust a design like TLS which you do not really understand just because  its widely used, and thus hopefully well reviewed, but rather make sure you have a design based on solid understanding of the cryptographic principles employed and a well defined review/control process of implementations.  Incidents like with OpenSSL show how badly reviewed even the most widely deployed crypto mechanisms can be.

Cheers
    Toerless

On Sun, Aug 11, 2019 at 09:31:22PM +0000, Jack Visoky wrote:
> To: Jack Visoky <[email-masked]>; Randy Armstrong (OPC) 
> <[email-masked]>; [email-masked]; 
> [email-masked]
> If it's on a very low duty cycle on battery, and/or it does 802.15.4, 
> then the question is still open.  The IETF may start work on a 
> 802.15.4 specific AKE, (see [email-masked]).  We believe we need these 
> for 6tisch (TSCH mode of 802.15.4 for deterministic industrial 
> networks)
> 

--
---
[email-masked]

---

From: Jack Visoky <[email-masked]>
Date: Fri, 9 Aug 2019 19:55:24 +0000

Hi Everyone,

I am also involved with OPC-UA and would like to provide my/my company's perspective.  One of the major drivers of this engagement with the ANIMA group was a contentious point around whether or not TLS and EST are required for support of BRSKI.  Some of us had taken the position that these technologies are an integral part of BRSKI and shouldn't be replaced with OPC specific methods, especially given the benefit of using highly adopted security technologies, as well as the tight coupling of BRSKI to these.  So, I think the idea that OPC should just use these technologies is very much a viable answer.

Also, I would strongly push back on any claims that low end OPC devices cannot support TLS.  Other industrial protocols have already added TLS support and are shipping products, including those with TLS client functionality.  TLS is no more heavy-weight than existing, OPC-specific security mechanisms.

In any event I will be sure to join the call that has been set up for later in August.

Thanks and Best Regards,

--Jack Visoky

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Randy Armstrong (OPC)
Sent: Thursday, August 8, 2019 12:54 PM
To: Michael Richardson <[email-masked]>; [email-masked]; [email-masked]
Subject: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI

[Use caution with links & attachments]

Hi Michael,

Regards,

Randy

---

From: Jack Visoky <[email-masked]>
Date: Sun, 11 Aug 2019 21:31:22 +0000

Thanks,

--Jack

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Saturday, August 10, 2019 5:16 PM
To: Jack Visoky <[email-masked]>; Randy Armstrong (OPC) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI

Awesome.

---

From: Jack Visoky <[email-masked]>
Date: Sun, 11 Aug 2019 21:52:30 +0000

> I think so; there are some details of resale that BRSKI would like to make out-of-scope for the first document.  Some way, we have to deal with it, and I would actually like feedback from OPC about…

So in this case would the MASA need to be OPC specific, that is, use OPC Security and OPC methods?  Apologies if I'm getting ahead of myself on this conversation.

Thanks,

--Jack

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Saturday, August 10, 2019 9:08 PM
To: Randy Armstrong (OPC) <[email-masked]>
Cc: Jack Visoky <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI

yes, I think so.

I think yes.

---

From: Jack Visoky <[email-masked]>
Date: Tue, 13 Aug 2019 01:22:30 +0000

Hi Toerless,

Just responding to one of your points, a colleague of mine from Cisco (Nancy Cam-Winget) and I have created a draft for authentication-only data protection for TLS 1.3.  We've registered the cipher suites and will be going through the Independent Review for this RFC soon.  If you, Michael, or even others would like to serve as reviewers we'd be grateful.

Link to RFC: https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-04 

Thanks,

--Jack

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Toerless Eckert
Sent: Monday, August 12, 2019 2:50 PM
To: Jack Visoky <jmvisoky=[email-masked]>
Cc: Michael Richardson <[email-masked]>; Randy Armstrong (OPC) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI

Cheers
    Toerless

--
---
[email-masked]