Subject: [core] application group and security group mapping

From: Christian Amsüss <[email-masked]>
Date: Thu, 2 Jul 2020 14:34:49 +0200

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 B is calling for trouble implementation-wise and would be
better addressed by using different application groups. The application
should interact with application group memberships and possibly roles in
that application group, but never handle (or express policy for)
security group identifiers.

Follow-up discusson on the last item of [1] which Marco mentioned
indicates that there is a use case for those -- please tell me about
those!

If there is a case for B, I'd like to hear it (and especiallly
understand why it can't be better solved by administrative grouping of
application groups). The upcoming version of oscore-discovery currently
contains a line on the "client joins any, server joins all" that assumes
A, so if B is supposed to be viable, let's talk about it.

Otherwise (ie. if only A is the intended and the cases for B were
misrepresented), some clarification might help in groupcomm-bis.

Kind regards
Christian

[1]: https://mailarchive.ietf.org/arch/msg/core/h62d2c2mYmG43ykz52KvbbEpgDc/

-- 
Es ist nicht deine Schuld, dass die Welt ist, wie sie ist -- es wär' nur
deine Schuld, wenn sie so bleibt.
(You are not to blame for the state of the world, but you would be if
that state persisted.)
  -- Die Ärzte

---

From: Jim Schaad <[email-masked]>
Date: Thu, 2 Jul 2020 09:00:21 -0700

> -----Original Message-----
> From: Christian Amsüss <[email-masked]>
> Sent: Thursday, July 2, 2020 5:35 AM
> To: Core WG mailing list <[email-masked]>; Jim Schaad
> <[email-masked]>; [email-masked]
> Cc: Marco Tiloca <[email-masked]>
> 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),
> 
> 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.
> 
groups),
> there's two scenarios this can possibly be used for:
> 

I think that what has been done here is to conflate the ideas of a security
group and a setup of access control decisions.  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.)

Jim

> I think that B is calling for trouble implementation-wise and would be
better
> addressed by using different application groups. The application should
interact
> with application group memberships and possibly roles in that application
> group, but never handle (or express policy for) security group
identifiers.
> Follow-up discusson on the last item of [1] which Marco mentioned
indicates
> that there is a use case for those -- please tell me about those!
> 
> 
> If there is a case for B, I'd like to hear it (and especiallly understand
why it can't
> be better solved by administrative grouping of application groups). The
> upcoming version of oscore-discovery currently contains a line on the
"client
> joins any, server joins all" that assumes A, so if B is supposed to be
viable, let's
> talk about it.
> [1]:
> https://mailarchive.ietf.org/arch/msg/core/h62d2c2mYmG43ykz52KvbbEpgDc/
> 
> --
deine
> Schuld, wenn sie so bleibt.
> (You are not to blame for the state of the world, but you would be if that
state
> persisted.)

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 3 Jul 2020 11:50:07 +0000

On 02/07/2020, 17:01, "Jim Schaad" <[email-masked]> wrote:
> > 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).
> >
> >    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.
>
> 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.
>

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.

---

From: Jim Schaad <[email-masked]>
Date: Fri, 3 Jul 2020 07:55:47 -0700

> From: Thomas Fossati <[email-masked]>
> Sent: Friday, July 3, 2020 4:50 AM
> To: Jim Schaad <[email-masked]>; 'Christian Amsüss'
> <[email-masked]>; 'Core WG mailing list' <[email-masked]>; draft-ietf-
> [email-masked]
> Cc: Thomas Fossati <[email-masked]>
> Subject: Re: [core] application group and security group mapping
> 
> 
> 
> I agree we are conflating access control to the communication channel with
> access control to the resource space, which are two logically separate layers.
> 
> > 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?

The biggest benefit of treating ACLs as a different thing is that there is a big potential to reduce the number of security groups that need to be maintained by the endpoints.  Consider an application which has five different resources and there are three operations on each of those resources (POST, PUT, GET)[1].   Everybody gets GET access and it does not really matter if people see what is done for POST and PUT as they can get the results via a GET anyway.  At this point you have the potential of needing 11 different security groups if access to PUT and POST is separate on each of the different resources.  On the other hand, if the access control is done by using ACLs then you only need to use a single security group.

In the even of using 11 security groups, each of the application clients would need to understand which security group is going to be used for any of the different resource/method pairs.  This means that clients and servers do not need to understand what group name is associated with which action.

Jim

[1] This could end up not being this, but being the ability to use different query parameters and/or content types for a single CoAP method.
> 
> 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.

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 3 Jul 2020 15:20:25 +0000

Hi Jim,

On 03/07/2020, 15:56, "Jim Schaad" <[email-masked]> wrote:
> > 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?
>
> The biggest benefit of treating ACLs as a different thing is that
> there is a big potential to reduce the number of security groups that
> need to be maintained by the endpoints.  Consider an application which
> has five different resources and there are three operations on each of
> those resources (POST, PUT, GET)[1].   Everybody gets GET access and
> it does not really matter if people see what is done for POST and PUT
> as they can get the results via a GET anyway.  At this point you have
> the potential of needing 11 different security groups if access to PUT
> and POST is separate on each of the different resources.  On the other
> hand, if the access control is done by using ACLs then you only need
> to use a single security group.
>
> In the even of using 11 security groups, each of the application
> clients would need to understand which security group is going to be
> used for any of the different resource/method pairs.  This means that
> clients and servers do not need to understand what group name is
> associated with which action.

Sure, I'm not advocating for conflating security groups and ACLs, on the
contrary I think we should actively advise against that practice. My
question was about the value of explicitly adding an ACL construct in
groupcomm-bis framework instead of just pointing out that resources in
an application group are likely to have their own ACLs, which are an
application concern (rather than a groupcomm's).

cheers!

---

From: Jim Schaad <[email-masked]>
Date: Fri, 3 Jul 2020 09:28:13 -0700

> Sent: Friday, July 3, 2020 8:20 AM
> To: Jim Schaad <[email-masked]>; 'Core WG mailing list'
> <[email-masked]>; [email-masked]
> contrary I think we should actively advise against that practice. My question
> was about the value of explicitly adding an ACL construct in groupcomm-bis
> framework instead of just pointing out that resources in an application group
> are likely to have their own ACLs, which are an application concern (rather
> than a groupcomm's).

I don't know that you necessarily need to create a new thing and map it into all of the pictures, but the fact that this is not at all obvious from the current text is something that really need to be changed.