Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft
Mert Ocak <mert.ocak@ericsson.com> Wed, 06 June 2018 14:06 UTC
Return-Path: <mert.ocak@ericsson.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 0E2DE130F2A for <core@ietfa.amsl.com>; Wed, 6 Jun 2018 07:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 gt0fDH3DFBxQ for <core@ietfa.amsl.com>; Wed, 6 Jun 2018 07:06:38 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 544B0130F20 for <core@ietf.org>; Wed, 6 Jun 2018 07:06:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1528293996; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=z0r4IVJjDuOHbM4rUG0gRqK++wAlOA2Fs8cTkELLRHg=; b=aHPPdvb9oGvFvkdBV9+8Ng1SQDfkLtX7+DkuZHfUCvNyYof5SToVaDnk4PtOguOv EPa9Fsec98ilhKzaOxPF424ojbnk7ODkrhLOTfQalenjpgzLDweOYTRSNY1m7esv d4mz9j+o/USfVsYVLh2Q0v93QavqwYBQbOztLbJpuhg=;
X-AuditID: c1b4fb25-31dff70000003465-36-5b17ea6cb527
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FF.9A.13413.C6AE71B5; Wed, 6 Jun 2018 16:06:36 +0200 (CEST)
Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSHC016.ericsson.se (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 6 Jun 2018 16:06:36 +0200
Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Jun 2018 16:06:36 +0200
Received: from ESESBMB505.ericsson.se ([153.88.183.188]) by ESESBMB505.ericsson.se ([153.88.183.188]) with mapi id 15.01.1466.003; Wed, 6 Jun 2018 16:06:35 +0200
From: Mert Ocak <mert.ocak@ericsson.com>
To: "core@ietf.org" <core@ietf.org>
Thread-Topic: [core] Conclusion -- Endpoint Client Name / Endpoint Name in RD draft
Thread-Index: AdPmCfncz1IX5t6GRJaeO0C+mMHM9QAhG46AAWOgH0D//+5SgIAaqQwAgAh+xAA=
Date: Wed, 06 Jun 2018 14:06:35 +0000
Message-ID: <793E8C96-B37F-421C-8712-98BEEF7FC867@ericsson.com>
References: <VI1PR0801MB2112B9A4410DA3EDE39183BEFA9B0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <9970c70fea6ea457c74c8ae3ca303f76@xs4all.nl> <4EBB3DDD0FBF694CA2A87838DF129B3C01F48F8A@DEFTHW99EL4MSX.ww902.siemens.net> <VI1PR0801MB2112CCC0F54274336BFE3EB7FA930@VI1PR0801MB2112.eurprd08.prod.outlook.com> <3b2ad29ec49c83c31646b38e856c0ae7@xs4all.nl>
In-Reply-To: <3b2ad29ec49c83c31646b38e856c0ae7@xs4all.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.d.1.180523
x-originating-ip: [153.88.183.157]
Content-Type: text/plain; charset="utf-8"
Content-ID: <854825EA1CB7BF4AA3CBCD7424546BF7@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUyM2K7k27OK/Fog6lTtCwe7V/FZrHv7Xpm ByaPJUt+MnmcaNjOHsAUxWWTkpqTWZZapG+XwJWx+/w5poIZKhW/ps9naWBcoNzFyMkhIWAi cWrXdJYuRi4OIYEjjBLNp44xQzibGSX+7VjDAlIlJPCVUeL7/gCIxFJGift9rawgCTYBDYld /VeZQGwRAWWJzWdeM4LYzAK2Eju+bGEHsYUFQiTaTkxlhKgJlVj97QwLhO0ncf7kZLA4i4CK xOWJ28Hm8ArYS8xfuIgJYvFjJokPS/xAbE4BS4lPx1azgdiMAmIS30+tYYLYJS5x68l8Joh3 BCSW7DnPDGGLSrx8/A/sTlEBPYmenVfZIOJKElt6twDVcwD1akqs36UPYVpLzD9nBzFRUWJK 90N2iGsEJU7OfAINBmWJp+9XsU5glJqFZPEshEGzEAbNQjJoFpJBCxhZVzGKFqcWJ+WmGxnr pRZlJhcX5+fp5aWWbGIExuzBLb9VdzBefuN4iFGAg1GJh3fSU/FoIdbEsuLK3EOMEhzMSiK8 iZfEooV4UxIrq1KL8uOLSnNSiw8xSnOwKInzPjTfHCUkkJ5YkpqdmlqQWgSTZeLglGpgNDv4 91v0ftE1a/nZdlhPj3IwmPLfdanM7ZQujd0KR/S5Z9qmGAbvnvlbpTQ6q1H1RqzSY6ar99a/ WX6iMELjD8//O/HlETc9Vj20Ur8j8f7RmV3T9d7qdbw7tmbflg/JGS8FD1Uz512VLT7AsUtZ dcFFdoU8PpHaHclstZHihw5cnrn/5OfHO5VYijMSDbWYi4oTAUtZFVvVAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/QvYM0NqoBiW2wDrFCHrpw8PdM6Y>
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: Wed, 06 Jun 2018 14:06:43 -0000
Hi, Confirming the endpoint name with the security context sounds reasonable but introducing a MUST for an authorization server is quite a big change, which I think we should avoid. ACE-Oauth could be one of the ways the RD supports for endpoint authentication but we should not invalidate other options the RD in different use cases can use for authentication, such as PSK, RPK or Certificates as Hannes mentioned. Cheers, Mert On 01/06/2018, 10.23, "core on behalf of peter van der Stok" <core-bounces@ietf.org on behalf of stokcons@xs4all.nl> wrote: 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. _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core
- Re: [core] Conclusion -- Endpoint Client Name / E… Jim Schaad
- Re: [core] Conclusion -- Endpoint Client Name / E… Peter van der Stok
- Re: [core] Conclusion -- Endpoint Client Name / E… Jim Schaad
- Re: [core] Conclusion -- Endpoint Client Name / E… Peter van der Stok
- Re: [core] Conclusion -- Endpoint Client Name / E… Mert Ocak
- [core] Conclusion -- Endpoint Client Name / Endpo… Hannes Tschofenig
- Re: [core] Conclusion -- Endpoint Client Name / E… Mohit Sethi
- Re: [core] Conclusion -- Endpoint Client Name / E… Hannes Tschofenig
- Re: [core] Conclusion -- Endpoint Client Name / E… Kovatsch, Matthias
- Re: [core] Conclusion -- Endpoint Client Name / E… Mohit Sethi
- Re: [core] Conclusion -- Endpoint Client Name / E… Ludwig Seitz
- Re: [core] Conclusion -- Endpoint Client Name / E… peter van der Stok
- Re: [core] Conclusion -- Endpoint Client Name / E… peter van der Stok
- Re: [core] Conclusion -- Endpoint Client Name / E… Hannes Tschofenig
- Re: [core] Conclusion -- Endpoint Client Name / E… peter van der Stok
- Re: [core] Conclusion -- Endpoint Client Name / E… Hannes Tschofenig
- Re: [core] Conclusion -- Endpoint Client Name / E… peter van der Stok
- Re: [core] Conclusion -- Endpoint Client Name / E… Kovatsch, Matthias
- Re: [core] Conclusion -- Endpoint Client Name / E… Hannes Tschofenig
- Re: [core] Conclusion -- Endpoint Client Name / E… peter van der Stok
- Re: [core] Conclusion -- Endpoint Client Name / E… peter van der Stok
- Re: [core] Conclusion -- Endpoint Client Name / E… peter van der Stok