Re: [core] Resource Directory Authorization Problems

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:

> 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?
> <pvds>
> Correct; the (ep-name, sector-name) pair MUST be unique within the set of endpoints specified within the RD.
> (will rephrase)
> </pvds>
> 
> "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, ..?
> <pvds>
> thanks, it is RD server. will clarify.
> (FYI: endpoint definition has taken some time to agree upon)
> </pvds>
> 
> "Then, it puts the endpoint name of device B." Where does it put that?
> <pvds>
> Yes, this is really opaque, probably something got lost over the versions.
> </pvds>
> 
> 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.
> <pvds>
> Authorization to specify endpoint names
> </pvds>
> 
> 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?
> <pvds>
> This is ACE terminology; I am just guessing: authorizes?
> </pvds>
> 
> 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>
> 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 purpose is to authorize 
> 
> It might be a good idea to only point out the
> security problems concerning authorization in the security
> considerations and define the solution elsewhere.
> 
> <pvds>
> I thougt, I did.
> </pvds>
> 
> Viele Gruesse,
> Steffi
> 
> Many thanks. looking forward to your reaction.
> 
> Peter
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core