[Ace] FW: [core] Security Model and other issues for group messaging
Jim Schaad <ietf@augustcellars.com> Tue, 09 April 2019 00:18 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1381200E5 for <ace@ietfa.amsl.com>; Mon, 8 Apr 2019 17:18:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Fyhk08ULiFGh for <ace@ietfa.amsl.com>; Mon, 8 Apr 2019 17:18:05 -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 5100412000F for <ace@ietf.org>; Mon, 8 Apr 2019 17:18:05 -0700 (PDT)
Received: from Jude (50.248.212.131) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Apr 2019 17:17:59 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: ace@ietf.org
References: <007e01d4ee52$34d796a0$9e86c3e0$@augustcellars.com>
In-Reply-To: <007e01d4ee52$34d796a0$9e86c3e0$@augustcellars.com>
Date: Mon, 08 Apr 2019 17:17:56 -0700
Message-ID: <009901d4ee69$aff2f8e0$0fd8eaa0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFx6YjvQYg2xhqyBm0BZ7FTdtBC1qb5ADLw
Content-Language: en-us
X-Originating-IP: [50.248.212.131]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/aJEv5TMAo4iSBWyfAewnK4KZQ0E>
Subject: [Ace] FW: [core] Security Model and other issues for group messaging
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2019 00:18:07 -0000
Discussion is for both lists, but only post to one please. -----Original Message----- From: core <core-bounces@ietf.org> On Behalf Of Jim Schaad Sent: Monday, April 8, 2019 2:30 PM To: core@ietf.org Subject: [core] Security Model and other issues for group messaging I have been going through the design process for getting software running for Montreal and I have come across the following issues that I think need some discussion. Some of these may just need clarification in documents but other are more substantive. It took me a while to determine that one of the strange issues I was having is that when looking just at the multicast case my mental model of who was making the decisions on if access was allowed did not seem to make a good match to what was being documented. I rather expected that all of the ACL decisions were going to be made on the AS and none on the KDC. This meant that the inclusion of scope in all of the messages was redundant if sending messages to a per group resource. Part of the questions involved here are who does the configuration for what key groups are associated with what application groups. I was always thinking of a single key group which was identified by the AS and sent to the KDC without the KDC needing to know the details of multiple resources for that key group. This of course does not match the model in the document. Some text on what model is being laid out is probably worthwhile. There was discussions for the ACE OAuth document about how to handle multiple access tokens for a single entity that need to be looked at in the context of a KDC. The current rule is that a resource server needs only to keep one token for any single supplicant. This was mostly discussed in the context of adding and subtracting privileges for the supplicant. It may be that this also needs to be viewed in the context of having completely disjoint resources on a single RS which are going to have different AS tokens issued. Thus for example, if there is a KDC which is servicing two different key groups. The supplicant gets a token for group1, gets the keys from the KDC. It then asks for a token for group2. Given that the lifetimes of these different tokens could be radically different does it really make sense to require that the two AS tokens be merged together (assuming they are from the same source) or would it make more sense to relax the RS only needs to keep one token rule. An easy way out of this might be to say one token per resource, but for constrained devices it could be one token per RS. Jim _______________________________________________ core mailing list core@ietf.org https://www.ietf.org/mailman/listinfo/core