Re: [Iot-onboarding] OPC and BRSKI

Dan Harkins <dharkins@lounge.org> Thu, 08 August 2019 05:41 UTC

Return-Path: <dharkins@lounge.org>
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 6C3A012001E for <iot-onboarding@ietfa.amsl.com>; Wed, 7 Aug 2019 22:41:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Oxlg5z3iJJWa for <iot-onboarding@ietfa.amsl.com>; Wed, 7 Aug 2019 22:41:00 -0700 (PDT)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673A012000E for <iot-onboarding@ietf.org>; Wed, 7 Aug 2019 22:41:00 -0700 (PDT)
Received: from trixy.bergandi.net (cpe-76-93-158-174.san.res.rr.com [76.93.158.174]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0PVW0074AL4CNO@wwwlocal.goatley.com> for iot-onboarding@ietf.org; Thu, 08 Aug 2019 00:41:00 -0500 (CDT)
Received: from thinny.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PVW000JDL3YGX@trixy.bergandi.net> for iot-onboarding@ietf.org; Wed, 07 Aug 2019 22:40:47 -0700 (PDT)
Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO thinny.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Wed, 07 Aug 2019 22:40:47 -0700
Date: Wed, 07 Aug 2019 22:40:54 -0700
From: Dan Harkins <dharkins@lounge.org>
In-reply-to: <0100016c6d9b4c92-77a6c841-c195-4323-b467-169c4bfabdee-000000@email.amazonses.com>
To: iot-onboarding@ietf.org
Message-id: <70a91551-dc40-966b-0f3d-f12fc41d58b7@lounge.org>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_axDmQ6kJUvPzlrx/Y6zOcw)"
Content-language: en-US
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8)
X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO thinny.local)
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> <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>
X-PMAS-Software: PreciseMail V3.3 [190807] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/xXU7EmaO-_lX31wRItf4nODZ2aI>
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 05:41:03 -0000

   Hi Kent,

On 8/7/19 12:43 PM, Kent Watsen wrote:
>> On Aug 7, 2019, at 4:50 AM, Eliot Lear <lear@cisco.com 
>> <mailto:lear@cisco.com>> wrote:
>>
>> The purpose, as I see it, of the voucher, is simply to provide 
>> zero-touch network provisioning.  I was asking a slightly different 
>> question: for purposes of network connectivity will operators want to 
>> know that only devices*they* authorized are connecting (e.g., 802.1X 
>> and then like)?  This is a natural assumption in the wireless world, 
>> but less so in wired.
>
> More specifically, the voucher enables the device to trust the 
> network, i.e., the entity claiming to be the device's owner.  Without 
> the voucher, there is the TOFU (trust on first use), a.k.a. 
> "resurrecting duckling" problem.

   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.

   The idea is that degree of gratuitousness of the device's 
bootstrapping directly
determines how much it can trust "the network" that has bootstrapped 
it's public key.
A QR code on the device's backside means that the device will trust 
anyone who has
physical possession of it (and can scan it's backside). This does not 
prevent the
"device fell off the truck" threat. 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.

   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).

   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.

   regards,

   Dan.