Re: [core] Resource Directory Authorization Problems

Stefanie Gerdes <> Wed, 11 July 2018 12:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 383A2130E60 for <>; Wed, 11 Jul 2018 05:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1s0TXeStrLTu for <>; Wed, 11 Jul 2018 05:00:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6793D130E3A for <>; Wed, 11 Jul 2018 05:00:27 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 93CDD203A4; Wed, 11 Jul 2018 14:00:25 +0200 (CEST)
References: <> <>
From: Stefanie Gerdes <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [core] Resource Directory Authorization Problems
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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