Re: [Iot-onboarding] EXTERNAL: Re: [Anima] OPC and BRSKI

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 12 August 2019 06:10 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 3C811120975; Sun, 11 Aug 2019 23:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Avlp6hzzxapk; Sun, 11 Aug 2019 23:09:21 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A361208D4; Sun, 11 Aug 2019 09:49:21 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id CCF56380BE; Sun, 11 Aug 2019 12:48:36 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A5491A51; Sun, 11 Aug 2019 12:49:19 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Randy Armstrong \(OPC\)" <randy.armstrong@opcfoundation.org>
cc: "iot-onboarding\@ietf.org" <iot-onboarding@ietf.org>, "anima\@ietf.org" <anima@ietf.org>
In-Reply-To: <BYAPR08MB4903EDF247B68E31BC2C580BFAD00@BYAPR08MB4903.namprd08.prod.outlook.com>
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> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <BYAPR08MB490385B1BED4C665C79B1937FAD70@BYAPR08MB4903.namprd08.prod.outlook.com> <4671.1565279232@localhost> <BYAPR08MB49034F3B36F6979D59561FC3FAD70@BYAPR08MB4903.namprd08.prod.outlook.com> <DM5PR2201MB1340BD83D6CF3F95E82518C299D60@DM5PR2201MB1340.namprd22.prod.outlook.com> <19592.1565471757@localhost> <BYAPR08MB49035E6C8A4C9CD1A596B7F2FAD10@BYAPR08MB4903.namprd08.prod.outlook.com> <15583.1565485709@localhost> <BYAPR08MB4903EDF247B68E31BC2C580BFAD00@BYAPR08MB4903.namprd08.prod.outlook.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Sun, 11 Aug 2019 12:49:19 -0400
Message-ID: <7075.1565542159@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/QPOrdvun_YU3m4ZLkp2e3Cs-Au0>
Subject: Re: [Iot-onboarding] EXTERNAL: Re: [Anima] 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: Mon, 12 Aug 2019 06:10:19 -0000

Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>; wrote:
    > 1) As it stands today BRSKI is pull model only and the push model is
    > out of scope but I don't see why that has to be the case once you allow
    > for different protocols between the Device and the Registrar. With our
    > proposed OPC mapping we would define a Registrar that supports both
    > models. Is this of any interest to the IETF or would it be an OPC only
    > thing?

There are a number of reasons to think a push model is also workable.
I'm unclear if OPC needs to onboard devices into a wireless network or if
everything is wired.  This matters because the new device has to announce
its presence to the Registrar for push to work.

For instance, you could take a look at:
  https://tools.ietf.org/html/draft-richardson-6tisch-dtsecurity-secure-join-01

which is an old version of the constrained-BRSKI mechanism.
Section 3, (3.2) explains how the Registrar would reach out to the
Pledge using the 6tisch 6p protocol (when it ran over IPv6).

    > 2) Perhaps the most value from BRSKI comes not from the MASA per se but
    > the voucher format (i.e. a digitally signed document with a standard
    > format). We could meet a lot of our requirements if we had a voucher
    > which has a list of nonce-less or bearer vouchers shipped to a
    > particular location for use by a particular end user. We could create
    > workflows where the manufacturer/distributor has to create this
    > document when devices are delivered. The document could be delivered
    > via the MASA or via some other B2B exchange or even on a USB
    > stick. However it is delivered it can then be read by the Registrar and
    > use it to build a whitelist of Devices allowed on the network.

RFC 8572 -- Secure Zero Touch Provisioning (SZTP)
may suit you better. It also uses RFC8366 vouchers.

    > I am also thinking that this voucher would be a good application for
    > block chain where instead of a bearer voucher we define a mechanism
    > where the owner the device could append a "block" to the original
    > voucher which authorizes the transfer to new owner.

We considered distributed ledgers for the audit log.
In all distributed ledgers, you have to ask:
  1) are there mutually distrusting parties?
  2) what do they need to agree upon?
  3) what is the incentive for a third party to validate the chain?

What you have described above, however, is just a certificate chain.
No Block Required.
  https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00

Describes an early notion of how vouchers work, and notice how it delegates
at each step.  Subsequent sales just extend the chain.  We didn't go this
way because:
  1) it mandates sales channel integration, and we think that this will be
     rare at the beginning.
  2) any party in the chain can issue a new sale certificate, effectively
     stealing the device from the current owner.

--
Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works
 -= IPv6 IoT consulting =-