Re: [Iot-onboarding] OPC and BRSKI

Toerless Eckert <tte@cs.fau.de> Wed, 07 August 2019 17:23 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: iot-onboarding@ietfa.amsl.com
Delivered-To: iot-onboarding@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A154312070E; Wed, 7 Aug 2019 10:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.998
X-Spam-Level:
X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6mhUtjde9nj; Wed, 7 Aug 2019 10:22:58 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E614D12068E; Wed, 7 Aug 2019 10:22:57 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E7455548014; Wed, 7 Aug 2019 19:22:52 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D7438440041; Wed, 7 Aug 2019 19:22:52 +0200 (CEST)
Date: Wed, 07 Aug 2019 19:22:52 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Eliot Lear <lear@cisco.com>, "Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, anima@ietf.org
Message-ID: <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de>
References: <BYAPR08MB4903F02A37ED9AE092A59B8EFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <BYAPR08MB4903129ECDEADF61E681DE0BFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <11781.1565189957@localhost>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/TykYIH8AljMvBLhOhXkyJnYQwSs>
Subject: Re: [Iot-onboarding] OPC and BRSKI
X-BeenThere: iot-onboarding@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <iot-onboarding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-onboarding/>
List-Post: <mailto:iot-onboarding@ietf.org>
List-Help: <mailto:iot-onboarding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-onboarding>, <mailto:iot-onboarding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Aug 2019 17:23:01 -0000

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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



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


-- 
---
tte@cs.fau.de