Subject: [core] Resource Directory Authorization Problems

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 6 Jul 2018 11:52:02 +0200

Hi all,

I just read through the security considerations of
draft-ietf-core-resource-directory-14 and have some comments.

I have some difficulties to understand the security considerations, in
particular sections 8.1 and 9.

Section 8.1:

"An Endpoint is determined to be unique.." -> is supposed to be unique?
should/must be unique?

"Consider the following threat: two devices A and B are managed by a
single server" I don't really understand the scenario, are A and B
endpoints (btw, the definition of the term endpoint in the document is
not really intuitive)? What kind of server do you refer to? The RD
server? Do you describe registration, lookup, ..?

"Then, it puts the endpoint name of device B." Where does it put that?

If certain processes, e.g., the registration or the lookup, require
authorization, it may be useful to mention clearly in the security
considerations where authorization is or may be required and why.

Section 9.:

"An authorized registry request to the Resource Directory (RD) is
accompanied by an Access Token that validates the access of the client
to the RD." validates -> allows?

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.
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.

It might be a good idea to only point out the
security problems concerning authorization in the security
considerations and define the solution elsewhere.

Viele Gruesse,
Steffi

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 09 Jul 2018 09:53:33 +0200

Hi Steffi,

Many thanks for reading and sharing your impressions from another
background.
I react below.
Stefanie Gerdes schreef op 2018-07-06 11:52:

> <pvds>
> Correct; the (ep-name, sector-name) pair MUST be unique within the set of endpoints specified within the RD.
> (will rephrase)
> </pvds>
> 
> <pvds>
> thanks, it is RD server. will clarify.
> (FYI: endpoint definition has taken some time to agree upon)
> </pvds>
> 
> <pvds>
> Yes, this is really opaque, probably something got lost over the versions.
> </pvds>
> 
> <pvds>
> Authorization to specify endpoint names
> </pvds>
> 
> Section 9.:
> 
> <pvds>
> This is ACE terminology; I am just guessing: authorizes?
> </pvds>
> 
> <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>
> <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 purpose is to authorize 
> 
> <pvds>
> I thougt, I did.
> </pvds>
> Many thanks. looking forward to your reaction.
> 
> Peter
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 11 Jul 2018 14:00:19 +0200

Hi Peter,

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

>> May be I misunderstand your concern here.

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

>> Do you have an alternative to solve the problem. Can you modify the example?

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

---

From: Peter van der Stok <[email-masked]>
Date: Thu, 12 Jul 2018 10:03:19 +0200

Hi Steffi,

thanks for a continued conversation.
The cted text has helped me to understand better the the reach and
purpose of scope parameter.
Stefanie Gerdes schreef op 2018-07-11 14:00:

> Hi Peter,
> 
> <pvds>
> Concerning section 9 "example"
> I will put it above the "security considerations"
> The Example text is meant as a warning shot to RD users, not as a normative text.
> Introducing the scope, as you suggest, validates that approach.
> </pvds>
> accessed, and how (see [1 [1]], [2 [2]]). If I understand section 9.2 correctly,
> requested resources (see [2 [2]]), i.e., that the CT is allowed to register
> defined by the application (see [3 [3]]), and therefore could be used for
> this purpose.
> 
> <pvds>
> Many thanks for the concrete text portions; that helps enormously.
> next step for me is to modify the example using scope.
> </pvds>
> 
> I fully agree with your open questions.
> another one: How does the AS server know which endpoint is authorized to specify what in the RD.
> Personally, I still think that an RD security draft (in ACE?) is needed in addition to example text in RD draft.
> </pvds>
> 
> Viele Gruesse
> Steffi
> 

Links:
------
[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