[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) (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 ( by mail2.augustcellars.com ( 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, 8 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: []
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.


core mailing list