Re: [Iot-onboarding] OPC and BRSKI

["Randy Armstrong (OPC)" <[e-mail]>]

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 <[e-mail]> 
Sent: August 7, 2019 10:23 AM
To: Michael Richardson <[e-mail]>
Cc: Eliot Lear <[e-mail]>; Randy Armstrong (OPC) <[e-mail]>; [e-mail]; [e-mail]
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 <[e-mail]>, Sandelman Software Works  
> -= IPv6 IoT consulting =-
> 
> 
> 



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


-- 
---
[e-mail]