Re: [Iot-onboarding] OPC and BRSKI

Eliot Lear <lear@cisco.com> Tue, 06 August 2019 20:46 UTC

Return-Path: <lear@cisco.com>
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 71250120033 for <iot-onboarding@ietfa.amsl.com>; Tue, 6 Aug 2019 13:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 eR5A6JvPprUe for <iot-onboarding@ietfa.amsl.com>; Tue, 6 Aug 2019 13:46:37 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E45612006A for <iot-onboarding@ietf.org>; Tue, 6 Aug 2019 13:46:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10889; q=dns/txt; s=iport; t=1565124397; x=1566333997; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=EJR9j8IFntiWjfKGLOcW/6jXUgtmD9RqS+jPkjlw6yg=; b=DqYQhOsINC1lVKvjCVB2bJroBxg/CPoqILto7VXblXFUzkc+nIdJqREH +En9cs54fKpFMmx+/U+WpBkS2oc84VDu4vWJQ2gAyjKL7qTBiEmb+rd6B P0nfApQlFyX0K2JnvZTDCiVTitVH59O60u1wJokX+QTzCGwYeQt2I0WPm Y=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AQAAAN5kld/xbLJq1dCRoBAQEBAQIBAQEBBwIBAQEBgVUDAQEBAQsBgRWCQAEgEiqEHoh8iDYlhzeLTYYFFIFnAgcBAQEJAwEBLwEBhD8CgmE2Bw4BBAEBBAEBAgEGbYUzhUoBAQEBAgEjVgULCxgqAgJXBgoJgyIBgXsPqwyBMoVJhHAQgTQBgVCKKYF/gREnDBOCTD6ECBITAYMhMoImBIwsGohGlh0Jgh6CH4EOkHQbgi+HLINrhlCEFp58gzKDDgIEBgUCFYFXAi+BWDMaCBsVZQGCQT6BDY89PQMwjBYrgiUBAQ
X-IronPort-AV: E=Sophos;i="5.64,353,1559520000"; d="asc'?scan'208,217";a="15101051"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Aug 2019 20:46:35 +0000
Received: from [10.61.221.4] ([10.61.221.4]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x76KkYQC026199 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Aug 2019 20:46:35 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_01B73CB9-8666-427F-AFD2-139AED11FBB8"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 06 Aug 2019 22:46:33 +0200
In-Reply-To: <BYAPR08MB4903129ECDEADF61E681DE0BFAD50@BYAPR08MB4903.namprd08.prod.outlook.com>
Cc: "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>
To: "Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org>
References: <BYAPR08MB4903F02A37ED9AE092A59B8EFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <BYAPR08MB4903129ECDEADF61E681DE0BFAD50@BYAPR08MB4903.namprd08.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client: 10.61.221.4, [10.61.221.4]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/kVGhYHmHazgUqJo432A8wq-Xoo8>
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: Tue, 06 Aug 2019 20:46:39 -0000

Hi Randy,

Thanks for this.  It’s a great starting point.  I would propose that we do a call so we can get some high bandwidth discussion going.  Please now see below.

> On 6 Aug 2019, at 20:58, Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org> wrote:
> 
> I will start with the main trouble spots. Some of these may be already covered by BRKSI but I missed the implications of some of the text:
> 
> 1) Low end devices that only support OPC; this means no TLS client capabilities and no ability to initiate network communication (i.e. server only mode);
> 

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.


> 2) Machine builders that combine devices into a machine that is sold as a unit. These device still have a unique network identity but the effective manufacturer has changed; How to deal with the DeviceID?


At some point, the thing decides which part gets an IP address or at least is responsible for the phy.  Can that process be leveraged to establish identity?


> 
> 3) Devices may be reset to factory defaults and sold/transferred to another organization. This needs to be possible even if the MASA is no longer available (i.e. the original manufacturer has gone out of business).

One possible view here is that the MASA may be offline, and may have provided a voucher via offline means to the join registrar.  This of course would be nonceless with a lengthy expiry time.  In addition, I posited during BRSKI’s review that perhaps the device should be able to generate its own certificate via a higher level interface.

> 
> 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?

Eliot