IETF Logo Mail Archive

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

Ludwig Seitz <ludwig.seitz@ri.se> Tue, 08 May 2018 06:54 UTC

Return-Path: <ludwig.seitz@ri.se>
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 B9E1E12704A for <core@ietfa.amsl.com>; Mon, 7 May 2018 23:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 BA7oNK-ACSnM for <core@ietfa.amsl.com>; Mon, 7 May 2018 23:54:36 -0700 (PDT)
Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.39]) (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 1734F126CC7 for <core@ietf.org>; Mon, 7 May 2018 23:54:35 -0700 (PDT)
Received: from 1fFwW9-0004BE-Tm by out11a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1fFwW9-0004D8-Ul; Mon, 07 May 2018 23:54:33 -0700
Received: by emcmailer; Mon, 07 May 2018 23:54:33 -0700
Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1fFwW9-0004BE-Tm; Mon, 07 May 2018 23:54:33 -0700
Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Tue, 8 May 2018 08:54:32 +0200
To: core@ietf.org
References: <VI1PR0801MB2112B9A4410DA3EDE39183BEFA9B0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <bd85e420-c6ce-3e87-406a-4cd5a4fafaa6@ericsson.com> <VI1PR0801MB21121FAE34CE76841CF6DBE1FA9B0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <4EBB3DDD0FBF694CA2A87838DF129B3C01F36340@DEFTHW99EL4MSX.ww902.siemens.net> <aee2b1d8-79fa-f88d-3e66-d5bb09805713@ericsson.com>
CC: 'Samuel Erdtman' <samuel@erdtman.se>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <28fbfdb2-9880-11b7-1e26-47fc7889a12c@ri.se>
Date: Tue, 08 May 2018 08:54:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <aee2b1d8-79fa-f88d-3e66-d5bb09805713@ericsson.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162)
X-Outbound-IP: 194.218.146.197
X-Env-From: ludwig.seitz@ri.se
X-Proto: esmtps
X-Revdns:
X-HELO: sp-mail-2.sp.se
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-Authenticated_ID:
X-PolicySMART: 14510320
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/nR6n4k7mTRI8L1m-2D7FFv3wjp0>
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: Tue, 08 May 2018 06:54:39 -0000

On 2018-05-07 19:59, Mohit Sethi wrote:
> Hi Matthias,
> 
> Thanks for bringing forward the use-case.
> 
> I have implemented an earlier version of the RD. I agree, the current 
> text on "mostly mandatory" leaves much to be desired. And +1 on request 
> for more clear text about different possibilities (cf. certificate vs 
> Raw Public Key vs PSK).
> 
> --Mohit

Samuel and I have thought about a similar issue in the ACE context (i.e. 
mapping PSK and RPK to endpoint identifiers, see 
https://tools.ietf.org/html/draft-erdtman-ace-rpcc-02).

For RPK I like the method implemented in Californium quite much (thanks 
Matthias I guess), based on RFC 6920 section 3 (ni URI format).

Here's the relevant text form our draft:

"Note to implementers: Authorization servers can use the following
    method to map a Raw Public Key to a client identifier: The client
    identifier is generated from the Raw Public Key using the procedure
    specified in section 3 of [RFC6920].  The digest is calculated on the
    Raw Public Key only (not on the SubjectPublicKeyInfo used in the
    handshake).  An example is shown in Figure 1."


/Ludwig


-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

v2.23.0 | Report a Bug | By Email