Re: [Iot-onboarding] OPC and BRSKI

Toerless Eckert <tte@cs.fau.de> Thu, 08 August 2019 16:25 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 1C6441201D4 for <iot-onboarding@ietfa.amsl.com>; Thu, 8 Aug 2019 09:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 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] 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 ep9xHzDKbtcT for <iot-onboarding@ietfa.amsl.com>; Thu, 8 Aug 2019 09:25:45 -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 17F4C1201B7 for <iot-onboarding@ietf.org>; Thu, 8 Aug 2019 09:25:44 -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 5ECFD54802C; Thu, 8 Aug 2019 18:25:40 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4DE4A440041; Thu, 8 Aug 2019 18:25:40 +0200 (CEST)
Date: Thu, 08 Aug 2019 18:25:40 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Dan Harkins <dharkins@lounge.org>
Cc: iot-onboarding@ietf.org
Message-ID: <20190808162540.5jwwwxcubl6wp6u2@faui48f.informatik.uni-erlangen.de>
References: <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <BYAPR08MB49037C509717B409DE7B570BFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> <BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <BYAPR08MB4903E91A2E9FC117755443C1FAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <F5504CAE-85B7-43AF-B743-1E234A4B320E@cisco.com> <BYAPR08MB4903C95973435BA06FC3C080FAD40@BYAPR08MB4903.namprd08.prod.outlook.com> <B5B28896-C211-41BF-AB51-0C6FDC72E44F@cisco.com> <0100016c6d9b4c92-77a6c841-c195-4323-b467-169c4bfabdee-000000@email.amazonses.com> <70a91551-dc40-966b-0f3d-f12fc41d58b7@lounge.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <70a91551-dc40-966b-0f3d-f12fc41d58b7@lounge.org>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/K99y2KslAS5JfR0Q7eQVHCtgzxg>
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: Thu, 08 Aug 2019 16:25:47 -0000

On Wed, Aug 07, 2019 at 10:40:54PM -0700, Dan Harkins wrote:
>   The problematic nature of voucher-less trust can be offset somewhat by
> limiting knowledge of the device's credential. DPP attempts to do this. The DPP
> device will only accept a provisioning agent that knows its public key.

What is DPP ?

Interesting scheme. I wonder how problematic security experts would find
this approach. But certainly novel to me to use a public key as a shared
secret with one "owner".  

> But that is not the only way of  bootstrapping a
> device's public key. The device's public key could be bootstrapped from a
> cloud service-- give the serial number of the device (and/or proof-of-ownership)
> and get back the device's public key.

How about resale of such a device. The second owner knows that the first
owner always has a key left (because it can always remember the public key).
Or else it should be possible to erase/recreate this key-pair.

>   This allows the device to have a modicum of trust in "the network" based
> on the steps the network had to go through in order to bootstrap the device's
> public key.

> This way printers (with a relatively low bar on trust of "the network") can
> get provisioned for a network that also includes something like a centrifuge
> (with a relatively higher bar on trust of "the network" that it will join).

Not sure i understand that point.

>   I'm not sure how relevant this is to OPC (I have not found the relevant
> documents on the OPC website) but I just want to point out that voucher-less
> provisioning does  not have to rely solely on blind trust or TOFU.

A voucher is just a secure digital artefact to pass on authorization of
ownership. If you want to give that authorization to some enterprises
server/registrar in the shared-secret public-key scheme, you would also
need to have some way to pass on that public key to that enterprise
server. Just a different type of voucher.

Aka: there is always a voucher, even if you haven't called it that way ;-))

Cheers
    toerless

>   regards,
> 
>   Dan.