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