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

2019-08-08 Thread Randy Armstrong (OPC) 
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  
Sent: August 8, 2019 8:47 AM
To: Randy Armstrong (OPC) ; 
iot-onboard...@ietf.org; anima@ietf.org
Subject: Re: [Iot-onboarding] OPC and BRSKI


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

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.

--
Michael Richardson , Sandelman Software Works  -= IPv6 
IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

2019-08-08 Thread Michael Richardson 

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

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.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

2019-08-07 Thread Randy Armstrong (OPC) 
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  
Sent: August 7, 2019 10:23 AM
To: Michael Richardson 
Cc: Eliot Lear ; Randy Armstrong (OPC) 
; iot-onboard...@ietf.org; anima@ietf.org
Subject: Re: [Iot-onboarding] OPC and BRSKI

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



> --
> Iot-onboarding mailing list
> iot-onboard...@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-onboarding


-- 
---
t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

2019-08-07 Thread Randy Armstrong (OPC) 
> If the MASA goes away or is compromised, then all the devices
>  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.

 > 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 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  On Behalf Of Michael 
Richardson
Sent: August 7, 2019 2:15 PM
To: iot-onboard...@ietf.org; anima@ietf.org
Subject: Re: [Iot-onboarding] OPC and BRSKI


Randy Armstrong (OPC)  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.

--
Michael Richardson , Sandelman Software Works  -= IPv6 
IoT consulting =-



___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

2019-08-07 Thread Michael Richardson 

Randy Armstrong (OPC)  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.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

2019-08-07 Thread Michael Richardson 

Randy Armstrong (OPC)  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.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-


signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

2019-08-07 Thread Kent Watsen 


> On Aug 7, 2019, at 4:50 AM, Eliot Lear  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.

Kent

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

2019-08-07 Thread Toerless Eckert 
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).
> >>
> >> 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?
> 
> +1
> 
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



> -- 
> Iot-onboarding mailing list
> iot-onboard...@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-onboarding


-- 
---
t...@cs.fau.de

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

2019-08-07 Thread Eliot Lear 
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) 
>  wrote:
> 
> 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
> 
> From: Eliot Lear 
> Sent: August 7, 2019 1:50 AM
> To: Randy Armstrong (OPC) 
> Cc: Toerless Eckert ; iot-onboard...@ietf.org; anima@ietf.org
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> Hi Randy,
> 
> Thanks again for your comments.  Please see below.
> 
> 
> On 7 Aug 2019, at 10:32, Randy Armstrong (OPC) 
>  > wrote:
> 
> 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).
> 
> 
> 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 mailto:l...@cisco.com>>
> Sent: August 7, 2019 12:33 AM
> To: Randy Armstrong (OPC)  >
> Cc: Toerless Eckert mailto:t...@cs.fau.de>>; 
> iot-onboard...@ietf.org ; anima@ietf.org 
> 
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> 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) 
>  > wrote:
> 
> Push should be “Certificate Manager initiated”
> 
> From: Iot-onboarding  > On Behalf Of Randy Armstrong (OPC)
> Sent: August 6, 2019 4:17 PM
> To: Toerless Eckert mailto:t...@cs.fau.de>>
> Cc: iot-onboard...@ietf.org ; anima@ietf.org 
> ; Eliot Lear mailto:l...@cisco.com>>
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> 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
> 
>

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

2019-08-07 Thread Randy Armstrong (OPC) 
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

From: Eliot Lear 
Sent: August 7, 2019 1:50 AM
To: Randy Armstrong (OPC) 
Cc: Toerless Eckert ; iot-onboard...@ietf.org; anima@ietf.org
Subject: Re: [Iot-onboarding] OPC and BRSKI

Hi Randy,

Thanks again for your comments.  Please see below.


On 7 Aug 2019, at 10:32, Randy Armstrong (OPC) 
mailto:randy.armstr...@opcfoundation.org>> 
wrote:

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


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



Regards,

Randy


From: Eliot Lear mailto:l...@cisco.com>>
Sent: August 7, 2019 12:33 AM
To: Randy Armstrong (OPC) 
mailto:randy.armstr...@opcfoundation.org>>
Cc: Toerless Eckert mailto:t...@cs.fau.de>>; 
iot-onboard...@ietf.org; 
anima@ietf.org
Subject: Re: [Iot-onboarding] OPC and BRSKI

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) 
mailto:randy.armstr...@opcfoundation.org>> 
wrote:

Push should be “Certificate Manager initiated”

From: Iot-onboarding 
mailto:iot-onboarding-boun...@ietf.org>> On 
Behalf Of Randy Armstrong (OPC)
Sent: August 6, 2019 4:17 PM
To: Toerless Eckert mailto:t...@cs.fau.de>>
Cc: iot-onboard...@ietf.org; 
anima@ietf.org; Eliot Lear 
mailto:l...@cisco.com>>
Subject: Re: [Iot-onboarding] OPC and BRSKI

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 mailto:t...@cs.fau.de>>
Sent: August 6, 2019 3:31 PM
To: Randy Armstrong (OPC) 
mailto:randy.armstr...@opcfoundation.org>>
Cc: Eliot Lear mailto:l...@cisco.com>>; 
iot-onboard...@ietf.org; 
anima@ietf.org
Subject: Re: [Iot-onboarding] OPC and BRSKI

On Tue, Aug 06, 2019 at 09:32:45PM +, 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

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

2019-08-07 Thread Eliot Lear 
Hi Randy,

Thanks again for your comments.  Please see below.

> On 7 Aug 2019, at 10:32, Randy Armstrong (OPC) 
>  wrote:
> 
> 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).


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

> 
> Regards,
> 
> Randy
> 
> 
> From: Eliot Lear 
> Sent: August 7, 2019 12:33 AM
> To: Randy Armstrong (OPC) 
> Cc: Toerless Eckert ; iot-onboard...@ietf.org; anima@ietf.org
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> 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) 
>  > wrote:
> 
> Push should be “Certificate Manager initiated”
> 
> From: Iot-onboarding  > On Behalf Of Randy Armstrong (OPC)
> Sent: August 6, 2019 4:17 PM
> To: Toerless Eckert mailto:t...@cs.fau.de>>
> Cc: iot-onboard...@ietf.org ; anima@ietf.org 
> ; Eliot Lear mailto:l...@cisco.com>>
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> 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 mailto:t...@cs.fau.de>>
> Sent: August 6, 2019 3:31 PM
> To: Randy Armstrong (OPC)  >
> Cc: Eliot Lear mailto:l...@cisco.com>>; 
> iot-onboard...@ietf.org ; anima@ietf.org 
> 
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> On Tue, Aug 06, 2019 at 09:32:45PM +, 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

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

2019-08-07 Thread Randy Armstrong (OPC) 
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 
Sent: August 7, 2019 12:33 AM
To: Randy Armstrong (OPC) 
Cc: Toerless Eckert ; iot-onboard...@ietf.org; anima@ietf.org
Subject: Re: [Iot-onboarding] OPC and BRSKI

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) 
mailto:randy.armstr...@opcfoundation.org>> 
wrote:

Push should be “Certificate Manager initiated”

From: Iot-onboarding 
mailto:iot-onboarding-boun...@ietf.org>> On 
Behalf Of Randy Armstrong (OPC)
Sent: August 6, 2019 4:17 PM
To: Toerless Eckert mailto:t...@cs.fau.de>>
Cc: iot-onboard...@ietf.org; 
anima@ietf.org; Eliot Lear 
mailto:l...@cisco.com>>
Subject: Re: [Iot-onboarding] OPC and BRSKI

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 mailto:t...@cs.fau.de>>
Sent: August 6, 2019 3:31 PM
To: Randy Armstrong (OPC) 
mailto:randy.armstr...@opcfoundation.org>>
Cc: Eliot Lear mailto:l...@cisco.com>>; 
iot-onboard...@ietf.org; 
anima@ietf.org
Subject: Re: [Iot-onboarding] OPC and BRSKI

On Tue, Aug 06, 2019 at 09:32:45PM +, 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

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

2019-08-07 Thread Eliot Lear 
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) 
>  wrote:
> 
> Push should be “Certificate Manager initiated”
> 
> From: Iot-onboarding  > On Behalf Of Randy Armstrong (OPC)
> Sent: August 6, 2019 4:17 PM
> To: Toerless Eckert mailto:t...@cs.fau.de>>
> Cc: iot-onboard...@ietf.org ; anima@ietf.org 
> ; Eliot Lear mailto:l...@cisco.com>>
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> 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 mailto:t...@cs.fau.de>>
> Sent: August 6, 2019 3:31 PM
> To: Randy Armstrong (OPC)  >
> Cc: Eliot Lear mailto:l...@cisco.com>>; 
> iot-onboard...@ietf.org ; anima@ietf.org 
> 
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> On Tue, Aug 06, 2019 at 09:32:45PM +, 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

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

2019-08-06 Thread Randy Armstrong (OPC) 
Push should be "Certificate Manager initiated"

From: Iot-onboarding  On Behalf Of Randy 
Armstrong (OPC)
Sent: August 6, 2019 4:17 PM
To: Toerless Eckert 
Cc: iot-onboard...@ietf.org; anima@ietf.org; Eliot Lear 
Subject: Re: [Iot-onboarding] OPC and BRSKI


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)



[cid:image005.png@01D54C72.CA661C90]



Push (Registrar initiated)



[cid:image006.png@01D54C72.CA661C90]



Regards,



Randy



-Original Message-
From: Toerless Eckert mailto:t...@cs.fau.de>>
Sent: August 6, 2019 3:31 PM
To: Randy Armstrong (OPC) 
mailto:randy.armstr...@opcfoundation.org>>
Cc: Eliot Lear mailto:l...@cisco.com>>; 
iot-onboard...@ietf..org; 
anima@ietf.org
Subject: Re: [Iot-onboarding] OPC and BRSKI



On Tue, Aug 06, 2019 at 09:32:45PM +, 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

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

2019-08-06 Thread Toerless Eckert 
On Tue, Aug 06, 2019 at 09:32:45PM +, 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 
> Sent: August 6, 2019 1:47 PM
> To: Randy Armstrong (OPC) 
> Cc: iot-onboard...@ietf.org
> 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) 
> mailto:randy.armstr...@opcfoundation.org>> 
> 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