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

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 <anima-bounces@ietf.org> On Behalf Of Randy Armstrong (OPC)
Sent: Thursday, August 8, 2019 12:54 PM
To: Michael Richardson <mcr+ietf@sandelman.ca>; iot-onboarding@ietf.org; anima@ietf.org
Subject: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI

[Use caution with links & attachments]

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 <mcr+ietf@sandelman.ca>
Sent: August 8, 2019 8:47 AM
To: Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>; iot-onboarding@ietf.org; anima@ietf.org
Subject: Re: [Iot-onboarding] OPC and BRSKI

Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works  -= IPv6 IoT consulting =-

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