[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
- [core] application group and security group mappi… Christian Amsüss
- Re: [core] application group and security group m… Jim Schaad
- Re: [core] application group and security group m… Thomas Fossati
- Re: [core] application group and security group m… Jim Schaad
- Re: [core] application group and security group m… Thomas Fossati
- Re: [core] application group and security group m… Jim Schaad