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

peter van der Stok <stokcons@xs4all.nl> Fri, 01 June 2018 07:23 UTC

Return-Path: <stokcons@xs4all.nl>
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 1AF66129515 for <core@ietfa.amsl.com>; Fri, 1 Jun 2018 00:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 zbafVoOFmnDe for <core@ietfa.amsl.com>; Fri, 1 Jun 2018 00:22:57 -0700 (PDT)
Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (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 432C712D7ED for <core@ietf.org>; Fri, 1 Jun 2018 00:22:57 -0700 (PDT)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:195]) by smtp-cloud7.xs4all.net with ESMTPA id OeOkfvWRVxiYrOeOkftZQb; Fri, 01 Jun 2018 09:22:54 +0200
Received: from AMontpellier-654-1-77-167.w90-0.abo.wanadoo.fr ([90.0.172.167]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 01 Jun 2018 09:22:54 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Fri, 01 Jun 2018 09:22:54 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: "Kovatsch, Matthias" <matthias.kovatsch@siemens.com>, consultancy@vanderstok.org, core@ietf.org
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <VI1PR0801MB2112CCC0F54274336BFE3EB7FA930@VI1PR0801MB2112.eurprd08.prod.outlook.com>
References: <VI1PR0801MB2112B9A4410DA3EDE39183BEFA9B0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> <VI1PR0801MB2112CCC0F54274336BFE3EB7FA930@VI1PR0801MB2112.eurprd08.prod.outlook.com>
Message-ID: <3b2ad29ec49c83c31646b38e856c0ae7@xs4all.nl>
X-Sender: stokcons@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfFYLOsGEnO4BFhv/ZdaD3G7P2/Vd/uKWMtUTPsZItKsdbhVxX99rUrzGjpCl/TkxzUom9T2aOXBm+/hNheWFeKoy9lQ2oH3qOTrwOJshN92IPZQgWK9A OAPdBFHenjBH+y+TrjLkikvp0yODTprOdhN+CyMkQohZogq6aXdLML6yYW4LhaEaE2qx5slNW3WrBYSAY0BN/FT8uXK4Jyp3JirTx1N4qh3cJXrbQQ5ubRKp aSd17IEov/ZozpayS7Msbi9mXMSVm8AgdtSnTo2Fr+k=
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/nscptZh0w_YbpH8r1cw06r0P1eY>
Subject: Re: [core] Conclusion -- 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: Fri, 01 Jun 2018 07:23:05 -0000

Hi Hannes, Matthias,

Below a proposal for the security considerations section in the RD draft

the last paragraph:
"Therefore, Endpoints MUST include the
Endpoint identifier in the message, and this identifier
MUST be checked by a resource directory to match the Endpoint identifier
included in the Registration message."

to be replaced with:
"A client MUST obtain an access token from an authorization server 
[draft-ietf-ace-oauth-authz]. For most installations the name of the 
endpoint does not need to be semantically meaningful. For those 
installations the endpoint name MUST be equated to the security 
identifier transported in the access token. For installations where the 
endpoint name must reflect the names of components of the installation, 
the access token MUST contain the values of the endpoint name and the 
optional domain name. A companion document SHOULD describe the format of 
the access tokens, the negotiation between client and Authorization 
server, and the treatment of the token by the RD server."

Will that be sufficient for you; or do you want more detailed text like 
yours below?
Looking forward to your improvements,

thanks,

peter

Hannes Tschofenig schreef op 2018-05-15 10:15:
> @Hannes: Could you provide some more detail, how exactly the Endpoint
> Client Name is extracted from "security context"? Overall, I like
> this, but we should provide concrete text on how people should do it.
> 
> You want to store the security context on the server side and the
> Endpoint Client Name points to the identifier part of it.
> (Other parts of the security context will be relevant for other 
> purposes.)
> 
>  * For PSK-based credential the Endpoint Client Name becomes the PSK 
> Identity
>  * For raw-public keys the Endpoint Client Name becomes the
> SubjectPublicKeyInfo structure (or a hash of it).
>  * For certificates the Endpoint Client Name becomes the leftmost CN
> component of subject name or the SubjectAltName of the certificate,
> depending on what you use.
> 
> Ciao
> Hannes
> 
> 
> 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.