Re: [core] application group and security group mapping

Jim Schaad <ietf@augustcellars.com> Fri, 03 July 2020 14:55 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC343A0891; Fri, 3 Jul 2020 07:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z52RdNtKFmf1; Fri, 3 Jul 2020 07:55:57 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B103A088F; Fri, 3 Jul 2020 07:55:56 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 3 Jul 2020 07:55:48 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Thomas Fossati' <Thomas.Fossati@arm.com>, 'Core WG mailing list' <core@ietf.org>, draft-ietf-core-groupcomm-bis@ietf.org
References: <20200702123449.GA196068@hephaistos.amsuess.com> <04aa01d65089$e56261e0$b02725a0$@augustcellars.com> <7CDAD642-9DCC-4AFB-84A4-4975A5674BDA@arm.com>
In-Reply-To: <7CDAD642-9DCC-4AFB-84A4-4975A5674BDA@arm.com>
Date: Fri, 03 Jul 2020 07:55:47 -0700
Message-ID: <04e901d6514a$0ac23da0$2046b8e0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
thread-index: AQJfgAQHx0Lo/iXKPRhuzGfX0Si9gwFe4jUzAO/iuKWn0ROwoA==
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/l5SbIyvdI_Wsxjiw-EyFnz2V9FA>
Subject: Re: [core] application group and security group mapping
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2020 14:55:59 -0000


> -----Original Message-----
> From: Thomas Fossati <Thomas.Fossati@arm.com>
> Sent: Friday, July 3, 2020 4:50 AM
> To: Jim Schaad <ietf@augustcellars.com>; 'Christian Amsüss'
> <christian@amsuess.com>; 'Core WG mailing list' <core@ietf.org>; draft-ietf-
> core-groupcomm-bis@ietf.org
> Cc: Thomas Fossati <Thomas.Fossati@arm.com>
> Subject: Re: [core] application group and security group mapping
> 
> 
> 
> On 02/07/2020, 17:01, "Jim Schaad" <ietf@augustcellars.com> wrote:
> > > -----Original Message-----
> > > From: Christian Amsüss <christian@amsuess.com>
> > > Sent: Thursday, July 2, 2020 5:35 AM
> > > To: Core WG mailing list <core@ietf.org>; Jim Schaad
> > > <ietf@augustcellars.com>; draft-ietf-core-groupcomm-bis@ietf.org
> > > Cc: Marco Tiloca <marco.tiloca@ri.se>
> > > 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?

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.