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


Randy Armstrong (OPC) <randy.armstr...@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+i...@sandelman.ca>, Sandelman Software Works  -= IPv6 
IoT consulting =-



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

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

Reply via email to