Re: [core] application group and security group mapping

[Thomas Fossati <[e-mail]>]

On 02/07/2020, 17:01, "Jim Schaad" <[e-mail]> wrote:
> > -----Original Message-----
> > From: Christian Amsüss <[e-mail]>
> > Sent: Thursday, July 2, 2020 5:35 AM
> > To: Core WG mailing list <[e-mail]>; Jim Schaad
> > <[e-mail]>; [e-mail]
> > Cc: Marco Tiloca <[e-mail]>
> > Subject: application group and security group mapping
> >
> > Hello CoRE,
> > hello Jim (whose review on group discovery [1] trigered this), hello
> > groupcomm-bis authors (whose terminology this will be about),
> >
> > groupcomm-bis describes that application-groups can be n:m mapped to
> > security groups.
> >
> > In one direction, this is rather straight-forward: Different
> > applications can share a security group provided they use different
> > paths, as a way to keep management and overhead low.
> >
> > In the other direction (one application group using multiple
> > security groups), there's two scenarios this can possibly be used
> > for:
> >
> > A. Security groups are used equivalently. The servers need to join
> >    each of the groups, but for a client it is sufficient to join
> >    any.  (Especially, for clients it is sufficient to support any of
> >    the group's signature algorithm rather than all).
> >
> > B. Security grroups have different properties within the application
> >    group. Particular operations may require the client to pick a
> >    special group.
>
> I think that what has been done here is to conflate the ideas of a
> security group and a setup of access control decisions.

I agree we are conflating access control to the communication channel
with access control to the resource space, which are two logically
separate layers.

> It might be worthwhile to try and separate these two concepts and see
> what happens.
>
> A security group is the set of all people who can read each other's
> messages.  There is nothing that might say that I care about somebody
> in the security group reading the command/response that I am making.
>
> A ACL group on the other hand is the set of all people who can perform
> a set of operations.  With group comm this is currently based on the
> security group, but it could just as easily be based on the signature
> key of the sender of the message.
>
> This means that there may be a one-to-one mapping between a security group
> and an ACL group, on the other hand it could just as easily be that an ACL
> group encompasses multiple security groups and maps one-to-one with the
> application group.  (Even worse depending on how things are done, there
> could be multiple application groups associated with an ACL group.)

What is the advantage of treating ACLs as a separate group?  ISTM that,
for the purpose of groupcomm-bis, they can be expressed simply as
properties of the resources defined by the application group.  Or do we
need to go in details of how ACLs are expressed?

cheers!

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.