Re: [core] Resource Directory Authorization Problems

Stefanie Gerdes <gerdes@tzi.de> Wed, 11 July 2018 12:00 UTC

Return-Path: <gerdes@tzi.de>
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 383A2130E60 for <core@ietfa.amsl.com>; Wed, 11 Jul 2018 05:00:31 -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] 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 1s0TXeStrLTu for <core@ietfa.amsl.com>; Wed, 11 Jul 2018 05:00:27 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6793D130E3A for <core@ietf.org>; Wed, 11 Jul 2018 05:00:27 -0700 (PDT)
Received: from [192.168.1.109] (p54BDE38A.dip0.t-ipconnect.de [84.189.227.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 93CDD203A4; Wed, 11 Jul 2018 14:00:25 +0200 (CEST)
To: consultancy@vanderstok.org
References: <3d39562b-5a57-6fd6-03f7-9d13d2c58ffd@tzi.de> <6a6095b3681e9d3da32eb98c14ec2239@bbhmail.nl>
Cc: core@ietf.org
From: Stefanie Gerdes <gerdes@tzi.de>
Message-ID: <8c297b25-b38d-abc7-88c7-fabda3935482@tzi.de>
Date: Wed, 11 Jul 2018 14:00:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <6a6095b3681e9d3da32eb98c14ec2239@bbhmail.nl>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/nBIhvYCo5FYHbmZa2G3Y_ABtHRA>
Subject: Re: [core] Resource Directory Authorization Problems
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.27
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, 11 Jul 2018 12:00:32 -0000

Hi Peter,

Thank you for your explanation. Please find some more thoughts below.

>>
>> In section 9.2 you define the new CWT fields rd_epn and rd_sct. I don't
>> think new fields should be defined in the security considerations.
>> <pvds>
>> We agree; that is not done; Section 9 is stand alone; Section 8 refers to it; that's all.
>> May be I misunderstand your concern here.
>> </pvds>

Sorry, I misread the document structure. But defining new fields for an
example may also be difficult.

>> Also, lookup and registration of RD entries do not seem to differ that
>> much from the access to other resources. We may not want to define new
>> CWT fields for every use case. That the subject of the access token is
>> only allowed to register for the registree-ep given in rd_epn, sounds
>> more like an access token scope to me.
>> <pvds>
>> scope is from client to AS?
>> I did not discuss that part, but indeed the client first asks the AS permission to register an endpoint name into the RD.
>> The AS, when happy, creates an endpoint name, and authorizes the client to register the endpoint name by specifying its value with rd_epn.
>> Do you have an alternative to solve the problem. Can you modify the example?
>> </pvds>

The scope defines the authorization, e.g., which resource may be
accessed, and how (see [1], [2]). If I understand section 9.2 correctly,
the CWT with the new fields authorizes the CT to register the endpoint
with a certain certificate identifier and sector name. Since these
fields scope the authorization (define which endpoint the CT is allowed
to register), I wonder why you cannot use an access token scope for this
purpose. The RD would then need to validate that the scope covers the
requested resources (see [2]), i.e., that the CT is allowed to register
resources for the endpoint, which is what we aim at, right? Scopes are
defined by the application (see [3]), and therefore could be used for
this purpose.

There are some more open question concerning the authorization that may
need to be considered here, e.g.: How does the RD server know the
Authorization Server (they must have a security association)? How does
the RD server know that a certain AS is authorized to issue access
tokens for a certain endpoint registration or lookup? Does the RD server
protect every lookup? If it doesn't, how does the RD server know which
resources it must protect?

Viele Gruesse
Steffi

[1] https://tools.ietf.org/html/rfc6749#section-3.3
[2] https://tools.ietf.org/html/rfc6749#section-7
[3] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13#section-5.8