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

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

On Tue, Aug 06, 2019 at 09:32:45PM +0000, Randy Armstrong (OPC) wrote:
> 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.

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.

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

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

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.

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

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

> Regards,
> 
> Randy
> 
> From: Eliot Lear <[email-masked]>
> Sent: August 6, 2019 1:47 PM
> To: Randy Armstrong (OPC) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> 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]<mailto:[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);
> 
> 
> 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 DeviceID?
> 
> 
> 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 out of business).
> 
> 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.
> 
> 
> 
> 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
> 
> 
> 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
> 

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

-- 
---
[email-masked]

---

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:

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

> 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

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

--

---

[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]>
> > https://www.ietf.org/mailman/listinfo/iot-onboarding <https://www.ietf.org/mailman/listinfo/iot-onboarding>
> 
> 
> --
> ---
> [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: 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:
>     > 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.

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

>     >> 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).
> 
> +1
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 

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

-----Original Message-----
From: Iot-onboarding <[email-masked]> On Behalf Of Michael Richardson
Sent: August 7, 2019 2:15 PM
To: [email-masked]; [email-masked]
Subject: Re: [Iot-onboarding] OPC and BRSKI

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

---

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

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

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

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

Awesome.

--
]               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: "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: Jack Visoky <[email-masked]>
Date: Sun, 11 Aug 2019 21:31:22 +0000

> 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

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

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

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

[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

Cheers
    Toerless

--
---
[email-masked]