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

"Randy Armstrong (OPC)" <> Thu, 08 August 2019 00:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 895DB120099; Wed, 7 Aug 2019 17:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7MrFHCTV0GIM; Wed, 7 Aug 2019 17:46:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0AC0120033; Wed, 7 Aug 2019 17:46:59 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=BqCvybJoA/bAJ1ychCE3uQ+b/et3ahm8kHWgmLzqTG9oE8BRYcwnxc35fHHFxpEI1YFMLBqcFJ4PqNKfkGb3MFmWQLzexGJADx7oDd/uAjCUoQnCDpz2A2pGug7/DiSPxV2ACBDMhuhqqzHxKyoDPbyMqrWuGv/pi95xYKCviGy5Emn7Gzsu1x0PWR1y8boe7Db0gKKFj4bY7GBsZW6R20SMd4ygmYOpB5B/F8kjdSGusOrki0hFuNQgBECKl9C5HhMp9D9yof7SWvMfZql1r+zOCf48ZzkNaSClID9as5MWMrCo+Ipx9G0DLxySJ8ZC6q+IBalu6js7ubjAM2kxZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EvhfTd6G8J6Ene2jOfV4HWiE2Cimiir0JW4xDDvnMn8=; b=aEAAz9in5G7eWoq3ZDQtNEdVFr6TzHHiWeOzApbFyRKPjYsBjZQyHuoyJxwGGspsuZ4GO9pi9aF2b5AiN2WVQq9wzcqVxi0ySzKc8RGNZ2FFA2WYw9xuHB0z+LU74nXMtsGfgrRDnmUyzF6SgRMq3NIBT+qgsA9U6uvN0mB4W5Fwkqej3gp9GcoEaSJta+2M9RiW4jngUO/vyyKHVIBFgSMDjKRgj8LanJ/Wr3TDyCvcAzDUfHQKZ1DZlDwYsUpI2N8a4ajW5JiKmoE02wpulrEqc3WXh2Eo4FLVpEVFkNt4Pa6iVocfrNkVX7QULtw82+uh4zqS99RpXhWG6BtcPA==
ARC-Authentication-Results: i=1; 1;spf=pass;dmarc=pass action=none;dkim=pass;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-opcfoundation-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EvhfTd6G8J6Ene2jOfV4HWiE2Cimiir0JW4xDDvnMn8=; b=dBVbp9Efwa7K413LlPe6zuNYjp0Bo1XiITomVkEsN1RzILnfM1ZWKW5CBMlJwsaGfErEtODQ8aWC3SZg76t4spNbEYr9fI9KxPqNKKANpLNpKezP89kY6AWbxj/1l+qXgAOOtIJe7bvJaP/cJodXlcKVIxQ5qAMzSfO1MQpKpQA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.12; Thu, 8 Aug 2019 00:46:56 +0000
Received: from ([fe80::149d:d834:7df3:fc53]) by ([fe80::149d:d834:7df3:fc53%4]) with mapi id 15.20.2157.015; Thu, 8 Aug 2019 00:46:56 +0000
From: "Randy Armstrong (OPC)" <>
To: Toerless Eckert <>, Michael Richardson <>
CC: Eliot Lear <>, "" <>, "" <>
Thread-Topic: [Iot-onboarding] OPC and BRSKI
Date: Thu, 08 Aug 2019 00:46:56 +0000
Message-ID: <>
References: <> <> <> <> <11781.1565189957@localhost> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a4f81e50-8ca6-4cda-c3e6-08d71b99e9f9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7193020); SRVR:BYAPR08MB4550;
x-ms-traffictypediagnostic: BYAPR08MB4550:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 012349AD1C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39840400004)(346002)(136003)(396003)(366004)(13464003)(189003)(199004)(6116002)(71190400001)(256004)(26005)(33656002)(81166006)(4326008)(81156014)(8936002)(8676002)(6506007)(66946007)(508600001)(64756008)(55016002)(186003)(446003)(71200400001)(76176011)(102836004)(66556008)(6306002)(476003)(5660300002)(53546011)(6436002)(74316002)(76116006)(99286004)(11346002)(316002)(66476007)(14454004)(66446008)(14444005)(66066001)(6246003)(9686003)(305945005)(5024004)(52536014)(229853002)(53936002)(54906003)(2906002)(86362001)(966005)(25786009)(486006)(110136005)(7696005)(3846002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR08MB4550;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: pfqtvRelpwsgBkB4u6v6WezvtNl5TtuYtkAmLEtdXWO+pS1NSBFlCqUzSwQNIeGUEhqOskvMl6FWn4Ko310UxokzhzyQip3xwftzk1i/QWfhmFkU5a+qBhopibkhF8sLUgtwN0ytQLNRgYip26YivbkOwhm2g5PLT/X35iQX7ZJTwcLtZ90ua5BWVDdH5crsLrfdzAB4418XsQgdm9sHOq7eeKUe4ApUeNL426x4+qSpYQxS+yZqnGtXtOLmsuBTIUsOkn8rpnyPSNvi0JfljlhQzFig1e8ZpK75YV0L1K/W+pN55VdfmRVzawIySwzuxqPRB7JlUvQA+MHwx1ftWnAssT8qDW8JGDFPfSC/ZamOkyLosnzTgS7kbRG/tMNwKy6J6+KeKJiZDi/dUZeGG44NwXFcymiEW88aVU70Ph0=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a4f81e50-8ca6-4cda-c3e6-08d71b99e9f9
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 00:46:56.3401 (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: WEFkvRR0GXl91xAe2/oiN1NG15bUkChjviUg99iJnjJfhl2NIJ/TpxheH19gl/+zyCrVvOIHQF6KpFZiI+Zil0TgnkGD7Bo+aGjdrDvkoAEajYA9FtkhPQidHXU4PLdv
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4550
Archived-At: <>
Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Aug 2019 00:47:02 -0000


> Thats what i referred to in my prior email: We would need to understand how to most easily duplicate the mutual authentication with certificates during TLS connection setup with OPC TCP UA messages.:

OPC UA CP requires mutual authentication with Certificates bound to the application rather than the machine. It provides everything that you get from TLS.

So when the Pledge Device connects to the Registrar or the Certificate Manager using UA the Device proves it has possession of the Device private key. 

That said, the KeyPair used for communication does not need to be the same as the KeyPair used to authenticate. 



-----Original Message-----
From: Toerless Eckert <> 
Sent: August 7, 2019 10:23 AM
To: Michael Richardson <>
Cc: Eliot Lear <>; Randy Armstrong (OPC) <>;;
Subject: Re: [Iot-onboarding] OPC and BRSKI

On Wed, Aug 07, 2019 at 10:59:17AM -0400, Michael Richardson wrote:
>     > 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.
> The TLS encryption provides confidentiality, yes, and I agree that it 
> is not critical to onboarding.  The TLS Client and ServerCertificate 
> and resulting channel is critical though as it provides the 
> cryptographic hook on which the voucher is attached.

Thats what i referred to in my prior email: We would need to understand how to most easily duplicate the mutual authentication with certificates during TLS connection setup with OPC TCP UA messages.:

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


>     >> 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?
> +1
> --
> Michael Richardson <>, Sandelman Software Works  
> -= IPv6 IoT consulting =-

> --
> Iot-onboarding mailing list