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

"Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org> Tue, 06 August 2019 23:17 UTC

Return-Path: <randy.armstrong@opcfoundation.org>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23B812006E; Tue, 6 Aug 2019 16:17:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opcfoundation.onmicrosoft.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 21rAHo7plIMb; Tue, 6 Aug 2019 16:17:11 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770089.outbound.protection.outlook.com [40.107.77.89]) (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 86E8A12008B; Tue, 6 Aug 2019 16:17:11 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b5xNway+iV3ps/0+4bp3PhXjM+mZzqUmByxuS86hbjqKhw6F8/lbWg+iZhmSFY0gy0do7X4B8OaAeE+mzMaimRhUsi6jiquyz8LY+6noohU8yqUiJfxOlh7j76/bp58P7TwOZiJu8nqoV0Qu3fgmtFB2X2Tq5zxWD+Ym3d6whNLDUv7l4tg2Wj5KR60NyFWSaMuXUQV0HjJwVAi3MVo7F07FJ03TKZjt9d8aeAo1m6AagCwgL5iuP+oBqnkzAlLRY6Tr5P0JubRJb7Ye7Zn5bJuevVBg1itgtkKijjs1xqUmDPIaHTRUkbAU0IM4pAcdZ5DOUmU/aG/W3Nm3c5ycQw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mw/7yIgwLIb9jcAilWiA1a+8/5nK5q5b1B/8wdxwxAk=; b=mHOMqhsRwYmzdyqAxxZxpN1F8+aTiNkJ87VU6cr0W3CYknuEVTiQUgJx8i5yYwyU0fLjwB0XhsCPUDOBVigDJAotQt7j3iQv419yMgMmnLZKkyZ7WNbZrC6F8JrqHdCuDx5OeBClcggusl2HC+x9fiYCvGm3KW2HZwZsel1mPpjmia+95tYkebXFoewQv/NtiohTqdfNmjavDE2nNmZaRnqXayNLttRYLQAvqT1698WfwIkK9eRsbxB3Hpncp6AoFoc09dUN2k0LUQ/XiRBja11vPO+v43WzUxNrDixr2NWEIpQcsSQOOCblaQvQhqkktdPjcjRxRnrGe+0vLqWAsg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=opcfoundation.org;dmarc=pass action=none header.from=opcfoundation.org;dkim=pass header.d=opcfoundation.org;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opcfoundation.onmicrosoft.com; s=selector1-opcfoundation-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mw/7yIgwLIb9jcAilWiA1a+8/5nK5q5b1B/8wdxwxAk=; b=f8ohHuSjl+kG5t/8K7P24pZIc0ZPEopIzHcUhACWJvdtfAUrA/5RbM9DFhUL9f13MdzlsGEBj0NBk2rqwIaNQOqtY7CjqpwfMShcGE9LLQEe7EijgZQHEtYY6Wz3AF9X/Pn5vxHrr0WEBoFFxPe/vjINykwPk67CBd7waDvbDPk=
Received: from BYAPR08MB4903.namprd08.prod.outlook.com (20.176.255.96) by BYAPR08MB5975.namprd08.prod.outlook.com (20.179.89.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Tue, 6 Aug 2019 23:17:08 +0000
Received: from BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53]) by BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53%4]) with mapi id 15.20.2094.017; Tue, 6 Aug 2019 23:17:08 +0000
From: "Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org>
To: Toerless Eckert <tte@cs.fau.de>
CC: Eliot Lear <lear@cisco.com>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, "anima@ietf.org" <anima@ietf.org>
Thread-Topic: [Iot-onboarding] OPC and BRSKI
Thread-Index: AdVMZzs5EDHMP+c/QWCVcWuK34MU/QAGrJ8AAADfarAABKcngAAAO+sQAANovwAAARHHUA==
Date: Tue, 06 Aug 2019 23:17:08 +0000
Message-ID: <BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50@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> <BYAPR08MB49037C509717B409DE7B570BFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=randy.armstrong@opcfoundation.org;
x-originating-ip: [24.80.80.10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 705e3eef-1cb7-4d63-de5c-08d71ac433ee
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:BYAPR08MB5975;
x-ms-traffictypediagnostic: BYAPR08MB5975:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR08MB5975EAAAE15226950D6F28EBFAD50@BYAPR08MB5975.namprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-forefront-prvs: 0121F24F22
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400004)(366004)(376002)(346002)(396003)(136003)(13464003)(199004)(189003)(76116006)(54906003)(7696005)(4326008)(6916009)(68736007)(8936002)(76176011)(25786009)(6506007)(86362001)(966005)(508600001)(53546011)(102836004)(606006)(14444005)(71190400001)(71200400001)(81156014)(9326002)(14454004)(8676002)(256004)(3846002)(99286004)(2906002)(81166006)(6116002)(790700001)(55016002)(99936001)(476003)(6246003)(229853002)(74316002)(446003)(486006)(11346002)(66066001)(66574012)(6436002)(66446008)(53936002)(316002)(64756008)(26005)(6306002)(733005)(66556008)(52536014)(186003)(7736002)(66476007)(54896002)(54556002)(66576008)(33656002)(66946007)(9686003)(5660300002)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR08MB5975; H:BYAPR08MB4903.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: opcfoundation.org does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: hEuPzG30XnmmSzupwVenRRkAAw4ZEQoSg6a3BF/7/7YnUdbD3Gyj/mNiiuVQl9f+Ha9DhrXgODXmMmOhibv/C2YNA8sLD3H3I3kFJ4LBvupWP31eVHcl+fdUZrFt88MZOgZhHCXPXUZHWR6LlSLoTzy98N0hsgfsouiCoDjNWf2OEHFKFIdhrNe8+qAmOAEoDh+jpF6SXwIyo4dNbBWzHhwQqxoohtr9qX9IifHvibMlbv7GtuVHHW6Nm3/Vbog3aND7B/JMw2phQskZOK880TDp46vXnQEGlEGufnYhZYfId/wN55Sil6fHLZvqrrqqeEbpQHeURmhBhe1WbqmRAXhfeLoapG/Q8nu8VFAdPg0PhLpmZiHp7r48TqBiGqo/UJgF3KKnsFKZmd46eOlWVZP8Lg9clYGjnikp7wSNhUE=
Content-Type: multipart/related; boundary="_008_BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50BYAPR08MB4903namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: opcfoundation.org
X-MS-Exchange-CrossTenant-Network-Message-Id: 705e3eef-1cb7-4d63-de5c-08d71ac433ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2019 23:17:08.1270 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2d8ef4e4-d41c-489c-8004-bb99304b60fe
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: randy.armstrong@opcfoundation.org
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB5975
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/5nL0LtYZTyJ6zItlinW_zsUb8ew>
Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Aug 2019 23:17:16 -0000

Hi



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



It would be easy to drop in a OPC UA aware registrar and implement all of the BRKSI flows back to the MASA. The only nuisance factor is the 'prior-signed-voucher-request'. If MASA's are willing allow this field to be omitted and to trust the Registrar then nothing more needs to done. If MASA's need this field then we could get it from the Device via OPC UA but producing the CMS message adds an additional burden on low end devices (i.e. the need to pull in libraries that provide the same functionality as OPC UA but do it in different format).



The 2 modes of operation with a OPC UA aware registrar (the Certificate Manager is an OPC UA defined entity).



Pull (device initiated)



[cid:image002.png@01D54C72.640B69F0]



Push (Registrar initiated)



[cid:image004.png@01D54C72.640B69F0]



Regards,



Randy



-----Original Message-----
From: Toerless Eckert <tte@cs.fau.de>
Sent: August 6, 2019 3:31 PM
To: Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>
Cc: Eliot Lear <lear@cisco.com>; iot-onboarding@ietf.org; anima@ietf.org
Subject: Re: [Iot-onboarding] OPC and BRSKI



On Tue, Aug 06, 2019 at 09:32:45PM +0000, Randy Armstrong (OPC) wrote:

> OPC is layered to separate the application from the choice of network protocol. TLS/WebSockets is an option but the primary protocol that will be used by low end devices is UA TCP which provides complete message based security framework.  These devices do not need TLS to have security and requiring it would require duplication of code.



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.



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

>

> Machines may have a separate network for internal Devices which IPs assigned by the machine???s DHCP service. Some of these devices may interact with external equipment via a NAT router which assigns a unique port to each device. This means the individual Devices need to be granted access to the operators network when the machine is installed even though the operator cannot provide them with IPs.

>

> I need to consult with our machine experts to better explain this use case.



Primary questions seem to be whether this is just about authentication at the TCP UA layer or further below at some implied NAC mechanism.



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

>

> OPC already has APIs needed to manage Certificates on a Device. The link to something like the MASA is what we are missing. Nonceless vouchers that do not expire should allow local registrar to emulate a MASA when the MASA is no longer available. I wanted to make sure that this mode of operation is allowed BRSKI.



Yes it is, it may just not be fully specified in the current targeted BRSKI RFC that we feel everybody who wants to implement it has everything to do so, but thats would just be subjet to future small RFC to close any possible gaps.



> 4) Can you say more about what mechanisms OPC is interested in pursuing?

>

> With OPC we assume that network selection and IP assignment are out of scope. Wired devices are the primary market at this time but 5G could change that.



BRSKI also does not care about Addressing. Only ACP does, so you can ignore that part if you're not interested in. We have tried to separate out ACP specific aspects in the BRSKI document as good as possible with the somewhat convoluted process we had in the IETF how to drive those documents.



Cheers

    Toerless



> Regards,

>

> Randy

>

> From: Eliot Lear <lear@cisco.com<mailto:lear@cisco.com>>

> Sent: August 6, 2019 1:47 PM

> To: Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org<mailto:randy.armstrong@opcfoundation.org>>

> Cc: iot-onboarding@ietf.org<mailto:iot-onboarding@ietf.org>

> Subject: Re: [Iot-onboarding] OPC and BRSKI

>

> 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<mailto:randy.armstrong@opcfoundation.org<mailto:randy.armstrong@opcfoundation.org%3cmailto: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

>



> --

> Iot-onboarding mailing list

> Iot-onboarding@ietf.org<mailto:Iot-onboarding@ietf.org>

> https://www.ietf.org/mailman/listinfo/iot-onboarding





--

---

tte@cs.fau.de<mailto:tte@cs.fau.de>