[core] application group and security group mapping

Christian Amsüss <christian@amsuess.com> Thu, 02 July 2020 12:34 UTC

Return-Path: <christian@amsuess.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 8720D3A0B35; Thu, 2 Jul 2020 05:34:57 -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 XQTonMuWlVGn; Thu, 2 Jul 2020 05:34:55 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3EE3A0B0C; Thu, 2 Jul 2020 05:34:53 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id A0429406A1; Thu, 2 Jul 2020 14:34:51 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 072C0AB; Thu, 2 Jul 2020 14:34:50 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:9c70:b4b3:7a70:7d6a]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C631064; Thu, 2 Jul 2020 14:34:49 +0200 (CEST)
Received: (nullmailer pid 588859 invoked by uid 1000); Thu, 02 Jul 2020 12:34:49 -0000
Date: Thu, 02 Jul 2020 14:34:49 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Core WG mailing list <core@ietf.org>, Jim Schaad <ietf@augustcellars.com>, draft-ietf-core-groupcomm-bis@ietf.org
Message-ID: <20200702123449.GA196068@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/4JtUVaB-XG_g0i_8v8CEMGyNdO8>
Subject: [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: Thu, 02 Jul 2020 12:34:58 -0000

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