Hi! Jim, I think now I understand your idea and it makes sense to me.
Some comments in line below. Best, /Marco On 2020-02-26 14:17, Michael Richardson wrote: > clarifying question. > > Jim Schaad <[email protected]> wrote: > > I do not seem to have been doing a good job of explaining the issue > > that I am raising here, so I am going to go scenario based for a > > description. > > > (1) I get an access token from an AS with a scope of [ > > "coap://multicast-01", ["responder"]] > > (2) I join the group associated > > with that address > > (3) I then decide to send the message below out > > encrypted with the group symmetric key and signed with the public key I > > registered during the join > > > GET coap://multicast-01/resource1 > > .... (I numbered the steps) > I believe that (1) was intended to allow you to become a responder for this > resource. ==>MT Step (1) is intended to allow access to the group-membership resource at the Group Manager (GM), to get the keying material for communicating in the group. Practically, the roles are currently used only at the GM to determine which public keys is relevant to return to a node upon its joining. <== > > > It then processes the get request > > because it does not know that this is a violation of the scope assigned > > to me by the AS. > > ! ==>MT As above, the original idea for that scope was to have it applied to the group joining itself and the resource at the GM to access for joining. But I agree that we should inform the other group members of that role, i.e. "allowed to send requests" and/or "allowed to send responses". <== > > > The only way that I know for the server TimeX to enforce the allowable > > operations is for that information to be propagated along with the > > signature public key from the KDC to the server. ==>MT This can be one more parameter in the Joining Response or in the Public Key Response, when request public keys of group members are included. Together with the array of public keys, we can have a same-ordered array of roles echoing the roles from the scope of the Access Token above. Each element of the array can possibly be an array of roles. How does it sound? <== > One can create a > > similar scenario on the other side where a client sends a response when > > it is only authorized as a "requester". ==>MT Right, if it's "requester"-only. <== > It seems to me that if the access control to the group is a group-shared > symmetric key + asymmetric signature, that each responder requires the list > of valid signers. > Or, we need LAKE to turn the group key into 1:1. ==>MT What I understand from Jim's proposal is essentially enabling at each group member a list of valid request signers and valid response signers. <== ==>MT Just to complement, this is all fine for this level of "filtering", i.e. "this group member can send requests/responses or not". We have a separate draft at [1], defining a new Group OSCORE profile of ACE, to enforce access control within the group, i.e. to access group members' resources after having joined, i.e. as a group member towards another group member. That is, that profile considers a granularity of exact REST methods and resources, i.e. as fine-grained as ACE can be. Also, it enables having together ACE-based access control and Group OSCORE, which is so far not possible with other profiles. The current version -01 in the datatracker defines a "full mode" where both OSCORE and Group OSCORE are considered as security protocols between Client and RS. We plan to submit soon an updated version, focusing more on a lighter, intended-to-be main mode, that focuses on using only Group OSCORE as security protocol between Client and RS. [1] https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01 <== Best, /Marco > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
