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

Jim Schaad <ietf@augustcellars.com> Fri, 22 June 2018 14:56 UTC

Return-Path: <ietf@augustcellars.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 A654E130E8E for <core@ietfa.amsl.com>; Fri, 22 Jun 2018 07:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8fqtEdDsI_Rl for <core@ietfa.amsl.com>; Fri, 22 Jun 2018 07:56:50 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D7C130E8B for <core@ietf.org>; Fri, 22 Jun 2018 07:56:49 -0700 (PDT)
Received: from Jude (104.129.192.86) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 22 Jun 2018 07:53:45 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: consultancy@vanderstok.org
CC: 'Hannes Tschofenig' <Hannes.Tschofenig@arm.com>, core@ietf.org
References: <VI1PR0801MB2112B9A4410DA3EDE39183BEFA9B0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> <VI1PR0801MB2112CCC0F54274336BFE3EB7FA930@VI1PR0801MB2112.eurprd08.prod.outlook.com> <3b2ad29ec49c83c31646b38e856c0ae7@xs4all.nl> <29a9636a3703e43947fce2f4cb900825@bbhmail.nl> <00d001d406ff$d1392f80$73ab8e80$@augustcellars.com> <c33454ea90c9219419410990ae624c65@bbhmail.nl>
In-Reply-To: <c33454ea90c9219419410990ae624c65@bbhmail.nl>
Date: Fri, 22 Jun 2018 07:56:42 -0700
Message-ID: <01c001d40a39$3cf415f0$b6dc41d0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C1_01D409FE.9098E770"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLSQRyK31kKN7geubfCKDOvczH9iQKw5U1yAihxEq4C310y0gFDLGVkAV7n08IBtcHyTgJwqdY3ofvmYyA=
Content-Language: en-us
X-Originating-IP: [104.129.192.86]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/0CklHr98GHDQaQ41nfY0DGF-wz4>
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.26
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, 22 Jun 2018 14:56:53 -0000

Given that the ‘sub’ claim is a binary value (for CWT), if you don’t need to make a distinction on what the subject name was derived from then you could just use that rather than defining a new ‘epn’ claim.

 

 

 

From: Peter van der Stok <stokcons@bbhmail.nl> 
Sent: Friday, June 22, 2018 3:07 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: consultancy@vanderstok.org; 'Hannes Tschofenig' <Hannes.Tschofenig@arm.com>; core@ietf.org
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

 

H JIm,

thanks, see below for fast questions

Peter

Jim Schaad schreef op 2018-06-18 14:28:

A couple of fast comments below

 

Jim

 

 

to assign a value to the endpoint name of the endpoint to be registered. Three possibilities are supported:

From: core <core-bounces@ietf.org <mailto:core-bounces@ietf.org> > On Behalf Of Peter van der Stok
Sent: Monday, June 18, 2018 2:53 AM
To: consultancy@vanderstok.org <mailto:consultancy@vanderstok.org> 
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com> >; core@ietf.org <mailto:core@ietf.org> 
Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft

 

 

1.	For PSK-based credential, the Endpoint Name becomes the PSK Identity

[JLS] PSK identities are binary and not text strings so a mapping is going to be needed here as with RPKs.

<pvds> I understand, Is there a standard way to do so? otherwise, a BSD64 representation of the RPK or PSK key is all-right? </pvds>



1.	For raw-public keys, the Endpoint Name becomes the SubjectPublicKeyInfo structure (or a hash of it).
2.	For certificates, the Endpoint Name becomes the leftmost CN component of subject name or the SubjectAltName of the certificate, depending on what is used.

An access token MAY include one of the two following new claims:

"epn" endpoint name with value the identifier part of one of the 3 possible identifier parts of the security ccontext.

[JLS] Why not use the 'normal' subject name? Would you think that they are the same or different?

<pvds> I seem to miss this. the intention is to provide the same  three epn identifiers (RPK, PSK, certificate) for the three cases:
- ep registers itself,
- 3rd party registers ep,
- multiple registries , links are changed.
</pvds>