Hi Randy, Thanks again for your comments. Please see below.
> On 7 Aug 2019, at 10:32, Randy Armstrong (OPC) > <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 <l...@cisco.com> > Sent: August 7, 2019 12:33 AM > To: Randy Armstrong (OPC) <randy.armstr...@opcfoundation.org> > Cc: Toerless Eckert <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) > <randy.armstr...@opcfoundation.org > <mailto:randy.armstr...@opcfoundation.org>> wrote: > > Push should be “Certificate Manager initiated” > > From: Iot-onboarding <iot-onboarding-boun...@ietf.org > <mailto:iot-onboarding-boun...@ietf.org>> On Behalf Of Randy Armstrong (OPC) > Sent: August 6, 2019 4:17 PM > To: Toerless Eckert <t...@cs.fau.de <mailto:t...@cs.fau.de>> > Cc: iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org>; anima@ietf.org > <mailto:anima@ietf.org>; Eliot Lear <l...@cisco.com <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) > > <image005.png> > > Push (Registrar initiated) > > <image006.png> > > Regards, > > Randy > > -----Original Message----- > From: Toerless Eckert <t...@cs.fau.de <mailto:t...@cs.fau.de>> > Sent: August 6, 2019 3:31 PM > To: Randy Armstrong (OPC) <randy.armstr...@opcfoundation.org > <mailto:randy.armstr...@opcfoundation.org>> > Cc: Eliot Lear <l...@cisco.com <mailto:l...@cisco.com>>; > iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org>; anima@ietf.org > <mailto:anima@ietf.org> > Subject: Re: [Iot-onboarding] OPC and BRSKI > > 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 <l...@cisco..com <mailto:l...@cisco.com>> > > Sent: August 6, 2019 1:47 PM > > To: Randy Armstrong (OPC) <randy.armstr...@opcfoundation.org > > <mailto:randy.armstr...@opcfoundation.org>> > > Cc: iot-onboard...@ietf.org <mailto: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) > > <randy.armstr...@opcfoundation.org<mailto:randy.armstr...@opcfoundation.org > > <mailto:randy.armstr...@opcfoundation.org%3cmailto: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 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 > > iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org> > > https://www.ietf.org/mailman/listinfo/iot-onboarding > > <https://www.ietf.org/mailman/listinfo/iot-onboarding> > > > -- > --- > t...@cs.fau.de <mailto:t...@cs.fau.de>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
