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

"Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org> Sun, 11 August 2019 00:57 UTC

Return-Path: <randy.armstrong@opcfoundation.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 59425120945; Sat, 10 Aug 2019 17:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 kLAx9CtjHyY3; Sat, 10 Aug 2019 17:56:01 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760054.outbound.protection.outlook.com [40.107.76.54]) (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 5420F1208A5; Sat, 10 Aug 2019 16:26:15 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bsuWzhON0P6+P4vyJ7obQt/z36SgNnZaI6RLm+EhokYW2jphcoQwRliDEfgkdggStBsNDvT8WMvZ+7MIcR3OnDpS3DVIkxJ6lEKWEgpseIftSmNeDBafSG2ePEad1hFdxPc7xhs9r2YjzZ+eVObWuJ1/OciZ1u+rXoFz+S1pSu0tMsuOBa7yErpQHC+LYxL6vm2iZYVnBhMFNSCxM52Y2ulHfX9F6EUgzmgU7RCsyH/yusmvtGIJosFeHGVqMA+PxIEIssY7edBX0gGrgzvBnN7JgRgd89ZwqbJYt5vDcDTUh3HuK9EGvksR0r4/MbrBT0sBfVBudrEPEgZbVbSHVw==
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=B8j+JKEyw+RbTFCKo6fmfkx43RK4++Z9AGqtoZJICI0=; b=dWIJETxZL1/zIi/pm1TkZ6UjqQGdP9OMmbfsqJJVVB2CX9jhFH9IzD0zcbeQwIH/nYoLFiV973HOwocFv1yju9ywTEudwTjujJS9/YakalockZKJ83g3tMgha3HCnr++n6GazCNYxfbIfG1/oRC2Lz+Gv+WNu1V3DG8n4fWrklqk9puId/08VHekYOElE3kBEk5zfHrGyVoHOzueTzNZBwTfEtmu9uPSd8O/TfJ2JAZZ3aHvxwEC1GQN3FGi6314j9nKrkrQCo/RfJ9wLcMeOutIAgZZw/c/rYnyRCvOhqGtONpF+04GcM2lpTbTwtRir4UOCV/08BrWgQsxveKeWw==
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=B8j+JKEyw+RbTFCKo6fmfkx43RK4++Z9AGqtoZJICI0=; b=QmJtWmXv7o4bDvAJ+ssGVCQVaEuZsfv14b27ETLwhHUNpByWbYb8rZcgdphXqchD5BeyvbkGbvef8mSjvc+7Kw699k3EniXN8r9sX+IQOF3bLmFATumHmLwLpxSnWcoYx7wSOjhqaiqhTQuT6GkzSjPc5X4uPtuvxNwOW8d0abI=
Received: from BYAPR08MB4903.namprd08.prod.outlook.com (20.176.255.96) by BYAPR08MB5141.namprd08.prod.outlook.com (20.177.125.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.13; Sat, 10 Aug 2019 23:26:13 +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.2157.020; Sat, 10 Aug 2019 23:26:13 +0000
From: "Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Jack Visoky <jmvisoky@ra.rockwell.com>, "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, "anima@ietf.org" <anima@ietf.org>
Thread-Topic: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI
Thread-Index: AdVMZzs5EDHMP+c/QWCVcWuK34MU/QAGrJ8AAADfarAABKcngAAmKcyAAAUDvQAADyfMUAAfy3oAAAGXgVAAOV4vAAA1GsaAAAH8CsA=
Date: Sat, 10 Aug 2019 23:26:13 +0000
Message-ID: <BYAPR08MB49035E6C8A4C9CD1A596B7F2FAD10@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>
In-Reply-To: <19592.1565471757@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
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: 51202618-5fc9-4ad6-39c0-08d71dea22a7
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)(7193020); SRVR:BYAPR08MB5141;
x-ms-traffictypediagnostic: BYAPR08MB5141:
x-ms-exchange-purlcount: 1
x-ld-processed: 2d8ef4e4-d41c-489c-8004-bb99304b60fe,ExtAddr
x-microsoft-antispam-prvs: <BYAPR08MB5141293A3CF31FC5053E9727FAD10@BYAPR08MB5141.namprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 012570D5A0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39830400003)(136003)(346002)(396003)(199004)(189003)(13464003)(6246003)(229853002)(74316002)(7696005)(53936002)(55016002)(9686003)(8936002)(8676002)(186003)(2906002)(6436002)(26005)(110136005)(2201001)(76176011)(6306002)(99286004)(2501003)(86362001)(14444005)(966005)(316002)(6506007)(6116002)(102836004)(66476007)(508600001)(5660300002)(3846002)(53546011)(66556008)(64756008)(66946007)(66446008)(66066001)(76116006)(7736002)(256004)(33656002)(52536014)(446003)(476003)(71200400001)(14454004)(25786009)(81166006)(81156014)(71190400001)(11346002)(486006)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR08MB5141; 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: g6Us98gZVVBC+PTwW515g9VFVHu1sLtyS2VAgBCGh3y25wYMlJkm34+qskJttyaHq5qqbunt49qcRVWWoFAdv+D46w9boVOGxX4L7zUA/974iqXaIdqpUyoaWXHSap9qfoyv07bx04lXTDsoyy/R77LJAqw9QMd93IeOpEUS+c1EjVWRtJDP/4CGE3/MacFPWFQon6grI+lp/N6PGyD6Yf/jnwDgTHueJ0MSwh9XqW+wORvHDiT3gVvkjmqb7pQ1upquXNO+001StEsgO8af9pc+4dzcYywtsSeHvJD6nFCrqQJBWgE+uTK+ffE0GUe26S5iX6HJBi3bnhsd3XbjnCzwEbs6zc9x85g3zxsceo3QeCN+P8kDnP4UZmmAjXyNz8wSYVuL8GUD8yPl5Y4x94kuZK419ZmKnVjr9Hv3JXg=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: opcfoundation.org
X-MS-Exchange-CrossTenant-Network-Message-Id: 51202618-5fc9-4ad6-39c0-08d71dea22a7
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2019 23:26:13.3833 (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: HpJUrTVFuoyXE0X9T4jQHSaiwCt0MzPWq8JKq4q+URiFVJXB8Ig3IWKJ8p16DY6OtCChQaC4L44/geVYvWHbJ7YZygosNbE3O+UPa16k4K/ocYHDTtOunQ33+7Id3W1a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB5141
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-onboarding/tiBDL5bHdAXuiEFyRkPhsDGDZyo>
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: Sun, 11 Aug 2019 00:57:31 -0000

> If the device is powered or has enough battery to do 802.11, then it probably has enough power and code space to do TLS (particularly mbedtls from ARM).

The issue is more the additional libraries needed to support this functionality. For companies like Rockwell, which have heavily invested in CIP over TLS, these libraries are already there. For other big automation vendors this is not the case.  

> It appears that the OPC UA methods provide enough security to do BRSKI, but there are significant benefits to not maintaining your own protocols, and significant benefits to getting the extensive review that TLS gets.

OPC UA security is end to end security and not tied to specific transport which is preferable from an architecture perspective. While the wide use of TLS is an advantage and I can assure you that the OPC WGs have extensively debated the pros and cons of TLS vs an OPC specific mechanism before we got to where we are today. 

> The OPC-specific mechanism appears to avoid a DH operation and therefore lacks PFS.  I understand it uses RSA, which means that it's significantly more expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have hardware > acceleration for ECDSA's secp256v1, fewer have RSA acceleration.

OPC also has ECDH based policies. These will be used by low end devices.

The questions that the OPC WG needs to answer are:

1) Can BRSKI meet our requirements?
2) If the answer to 1) is yes then can it work with OPC UA security?
3) If the answer to 2) is no then do we use TLS or extend our own model with something like BRSKI but not BRSKI?

While I cannot predict how the various participants in the OPC WGs will respond to question 3), I do know it would make collaboration a lot easier if the answer to 2) was yes.

Regards,

Randy

-----Original Message-----
From: Michael Richardson <mcr+ietf@sandelman.ca> 
Sent: August 10, 2019 2:16 PM
To: Jack Visoky <jmvisoky@ra.rockwell.com>om>; Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>rg>; iot-onboarding@ietf.org; anima@ietf.org
Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI


Jack Visoky <jmvisoky@ra.rockwell.com> wrote:
    > I am also involved with OPC-UA and would like to provide my/my
    > company's perspective.  One of the major drivers of this engagement
    > with the ANIMA group was a contentious point around whether or not TLS
    > and EST are required for support of BRSKI.  Some of us had taken the
    > position that these technologies are an integral part of BRSKI and
    > shouldn't be replaced with OPC specific methods, especially given the
    > benefit of using highly adopted security technologies, as well as the
    > tight coupling of BRSKI to these.  So, I think the idea that OPC should
    > just use these technologies is very much a viable answer.

If the device is powered or has enough battery to do 802.11, then it probably has enough power and code space to do TLS (particularly mbedtls from ARM).
If it's on a very low duty cycle on battery, and/or it does 802.15.4, then the question is still open.  The IETF may start work on a 802.15.4 specific AKE, (see lake@ietf.org).  We believe we need these for 6tisch (TSCH mode of 802.15.4 for deterministic industrial networks)

It appears that the OPC UA methods provide enough security to do BRSKI, but there are significant benefits to not maintaining your own protocols, and significant benefits to getting the extensive review that TLS gets.

    > Also, I would strongly push back on any claims that low end OPC devices
    > cannot support TLS.  Other industrial protocols have already added TLS
    > support and are shipping products, including those with TLS client
    > functionality.  TLS is no more heavy-weight than existing, OPC-specific
    > security mechanisms.

The OPC-specific mechanism appears to avoid a DH operation and therefore lacks PFS.  I understand it uses RSA, which means that it's significantly more expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have hardware acceleration for ECDSA's secp256v1, fewer have RSA acceleration.

    > In any event I will be sure to join the call that has been set up for
    > later in August.

Awesome.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


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