Re: [core] Endpoint Client Name / Endpoint Name in RD draft

"Kovatsch, Matthias" <matthias.kovatsch@siemens.com> Wed, 25 April 2018 20:56 UTC

Return-Path: <matthias.kovatsch@siemens.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C72B12D7F4 for <core@ietfa.amsl.com>; Wed, 25 Apr 2018 13:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 gv1bjQB_jTlv for <core@ietfa.amsl.com>; Wed, 25 Apr 2018 13:56:02 -0700 (PDT)
Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (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 A0AF812D7ED for <core@ietf.org>; Wed, 25 Apr 2018 13:56:01 -0700 (PDT)
Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id w3PKtKXv003928 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Apr 2018 22:55:20 +0200
Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id w3PKtJjJ011531 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Apr 2018 22:55:19 +0200
Received: from DEFTHW99ER8MSX.ww902.siemens.net (139.22.70.73) by DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) with Microsoft SMTP Server (TLS) id 14.3.389.1; Wed, 25 Apr 2018 22:55:19 +0200
Received: from DEFTHW99EL4MSX.ww902.siemens.net ([169.254.5.4]) by DEFTHW99ER8MSX.ww902.siemens.net ([139.22.70.73]) with mapi id 14.03.0389.001; Wed, 25 Apr 2018 22:55:18 +0200
From: "Kovatsch, Matthias" <matthias.kovatsch@siemens.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Jim Schaad <ietf@augustcellars.com>, 'Christian Amsüss' <christian@amsuess.com>, "consultancy@vanderstok.org" <consultancy@vanderstok.org>, 'Carsten Bormann' <cabo@tzi.org>
CC: "core@ietf.org" <core@ietf.org>
Thread-Topic: [core] Endpoint Client Name / Endpoint Name in RD draft
Thread-Index: AQHT0znBtoTmC857b0Co5UImt06WfqQCGI0AgAe4tOCAA8hngIAAuLvggAFZOgCAAlp+4A==
Date: Wed, 25 Apr 2018 20:55:17 +0000
Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C01F17724@DEFTHW99EL4MSX.ww902.siemens.net>
References: <CB28DFEA-5F9E-4C35-BD86-A37AC5C122C9@tzi.org> <ca2b6038e911d93e15e57763836a1d09@xs4all.nl> <20180413151121.GC20765@hephaistos.amsuess.com> <011701d3d4f0$46255e50$d2701af0$@augustcellars.com> <4EBB3DDD0FBF694CA2A87838DF129B3C01EF5D0D@DEFTHW99EL4MSX.ww902.siemens.net> <VI1PR0801MB2112D28860DD3E048518C10AFA890@VI1PR0801MB2112.eurprd08.prod.outlook.com> <4EBB3DDD0FBF694CA2A87838DF129B3C01F07CF0@DEFTHW99EL4MSX.ww902.siemens.net> <VI1PR0801MB211293D5B26328AFFC450A3AFA880@VI1PR0801MB2112.eurprd08.prod.outlook.com>
In-Reply-To: <VI1PR0801MB211293D5B26328AFFC450A3AFA880@VI1PR0801MB2112.eurprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [139.22.70.49]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/V5vFpaa8ejrfbqC7w3aPK93jKTg>
Subject: Re: [core] Endpoint Client Name / Endpoint Name in RD draft
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2018 20:56:04 -0000

Dear Hannes

My comment is that your solution to link the Endpoint Client Name to the registration authentication does not work for at least two of the desired use cases:
- A commissioning tool registering a device on its behalf, as the commissioning tool should not have the private keys or similar of the device.
- Applications using Endpoint Client Names that are different from the names in the device certificates/authentication credentials for registration

I fully agree with you, however, that the RD must clearly state that the registering entity must proof that it is authorized to use the Endpoint Client Name it registers. This might have been too implicit so far and there definitely was not enough work to figure this out fully. There are several ways how to do this; I think we should not limit it to just one simple way that breaks at least two use cases. But we can give it, for instance, as minimum MUST when there is no other way to proof authorization to use the Endpoint Client Name for registration.

One more generic way could be to require device and registering entity to be within the same domain, so that "d" can be authenticated. A commissioning tool would need to authenticate its domain, but then can use any Endpoint Client Name within this domain.

Ciao,
Matthias


> -----Ursprüngliche Nachricht-----
> Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@arm.com]
> Gesendet: Dienstag, 24. April 2018 12:49
> An: Kovatsch, Matthias (CT RDA IOT EWT-DE); Jim Schaad; 'Christian Amsüss'; consultancy@vanderstok.org; 'Carsten Bormann'
> Cc: core@ietf.org
> Betreff: RE: [core] Endpoint Client Name / Endpoint Name in RD draft
> 
> Hi Matthias
> 
> I fear that you are creating security holes that will be very difficult to fix afterwards.
> It just feels that these are "nice ideas" with limited practical experience. Very much like the idea of doing the third party registration with
> the commissioning tool as defined in the RD specification.
> 
> Ciao
> Hannes
> 
> 
> -----Original Message-----
> From: Kovatsch, Matthias [mailto:matthias.kovatsch@siemens.com]
> Sent: 23 April 2018 19:17
> To: Hannes Tschofenig; Jim Schaad; 'Christian Amsüss'; consultancy@vanderstok.org; 'Carsten Bormann'
> Cc: core@ietf.org
> Subject: AW: [core] Endpoint Client Name / Endpoint Name in RD draft
> 
> > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@arm.com]
> > > Applications will use the application-defined identifier, not a handle generated by the RD, not the security context.
> >
> > Who says that? If applications make security decisions based on unauthenticated parameters then they will be toast.
> 
> I am not saying they should not authenticate.
> I am saying that the identifier might be different for authorizating the registration and lookup by applications. They must be correlatable
> of course; them being the same is a special case, that could be desirable. Yet someone who is authenticated and authorized should be
> allowed to introduce additional identifiers.
> 
> Ciao,
> Matthias
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the
> intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or
> store or copy the information in any medium. Thank you.