IETF Logo Mail Archive

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

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Tue, 24 April 2018 10:48 UTC

Return-Path: <Hannes.Tschofenig@arm.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 C4F921243F6 for <core@ietfa.amsl.com>; Tue, 24 Apr 2018 03:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 eUAJcy8I1ttY for <core@ietfa.amsl.com>; Tue, 24 Apr 2018 03:48:39 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30040.outbound.protection.outlook.com [40.107.3.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D351241F8 for <core@ietf.org>; Tue, 24 Apr 2018 03:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mfArEIgZl4M2HGAH9K79Z1LM2IgPxTB1LqB2LmjeFAI=; b=Ttw61hwTsyONat2ljdwggTY0pkHQmJdSeUXLGI/lf+TWMcGYb+X1cBu6otsfya9zupAIxafrskCopR2lnKlQjdiPB0F8nsUBd6vh+CkM0v/g9m2r4SwfH5+nLh82buGxW8zoD4Tn1dFh15F5KhjPUrONoyhR6vOIyQl2NTl7lKM=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1600.eurprd08.prod.outlook.com (10.167.211.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.696.13; Tue, 24 Apr 2018 10:48:36 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::35fb:6e2c:e118:5644%17]) with mapi id 15.20.0696.017; Tue, 24 Apr 2018 10:48:36 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: "Kovatsch, Matthias" <matthias.kovatsch@siemens.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: AQHT0zm23rcsFhLKykKKsIPwEtlWPKQCOhQAgAec7ACAA+NkwIAAmP0AgAF5RCA=
Date: Tue, 24 Apr 2018 10:48:36 +0000
Message-ID: <VI1PR0801MB211293D5B26328AFFC450A3AFA880@VI1PR0801MB2112.eurprd08.prod.outlook.com>
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>
In-Reply-To: <4EBB3DDD0FBF694CA2A87838DF129B3C01F07CF0@DEFTHW99EL4MSX.ww902.siemens.net>
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=Hannes.Tschofenig@arm.com;
x-originating-ip: [103.40.135.60]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1600; 7:oz5Lh95zlSY2L7mYSPAF93zV34TwUpttgJJ2mQJDVucaq6EKFp4TQ4VYI2/DMka0Y8qpAf6zXXIVnf6/yJF+5rg7+47jUMe1cfG/wkLRI3Qhih8qCRn0YKtXRlX4rRupeXvBpYiRzTCMalcRkQyLL6E1yLGc5GuNKKPX3VvgjyokoqJKiNzmDu36AXYzUVDe7rBxO1fzSaMSiRadtmH671rlTqK1TxVuJ4tPJ6pQow7nTOsoC0Z3wgE9AHU23nmX
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1600;
x-ms-traffictypediagnostic: VI1PR0801MB1600:
x-microsoft-antispam-prvs: <VI1PR0801MB1600A6B224A87322E020D349FA880@VI1PR0801MB1600.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(180628864354917)(278428928389397)(192374486261705)(126837547833334);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231232)(944501410)(52105095)(93006095)(93001095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR0801MB1600; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1600;
x-forefront-prvs: 0652EA5565
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39380400002)(376002)(39860400002)(396003)(366004)(189003)(199004)(40434004)(13464003)(305945005)(74316002)(72206003)(8936002)(53936002)(478600001)(9686003)(86362001)(3280700002)(97736004)(2906002)(476003)(3660700001)(25786009)(55016002)(486006)(446003)(11346002)(68736007)(106356001)(3846002)(105586002)(6116002)(5660300001)(5890100001)(5250100002)(2900100001)(186003)(4326008)(229853002)(93886005)(316002)(26005)(99286004)(59450400001)(76176011)(33656002)(53546011)(6506007)(6436002)(2501003)(7696005)(102836004)(81166006)(81156014)(66066001)(8676002)(14454004)(7736002)(110136005)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1600; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: RRydpNYkWskruN+7UhXaKpeW00A7kcNGl2zOBmoPodR7BvJZu6YUC8Ghyze1AwzY5mD58TDhgnmN9pb0H3BgjxIpUNI2Ui5hFJZhJgmJKuRltUNkv7vEsiHl/4DzUFu0ZHWCQx5UJKMbQ5scsd1/c/GMxfTUPGq4UJAyqsdiTyOiWugOMR0IV5HSR5r2LgyU
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: a25de167-5d4e-472a-f3f1-08d5a9d0ee7f
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a25de167-5d4e-472a-f3f1-08d5a9d0ee7f
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2018 10:48:36.1354 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1600
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/8s_qryZg-HlnXRD5LEJYoKQiy3c>
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: Tue, 24 Apr 2018 10:48:41 -0000

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.

v2.23.0 | Report a Bug | By Email