[core] Security Model and other issues for group messaging

Jim Schaad <ietf@augustcellars.com> Tue, 09 April 2019 00:02 UTC

From: Jim Schaad <ietf@augustcellars.com>
To: core@ietf.org
Date: Mon, 08 Apr 2019 17:02:28 -0700
Message-ID: <007f01d4ee67$86dcda90$94968fb0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AdTuTrtyLsvZFxlwS3u5xL0Gj0pgRg==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/2CUnrWu_wodbZJTUSofqJPtx0EA>
Subject: [core] Security Model and other issues for group messaging
Precedence: list

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] Security Model and other issues for group … Jim Schaad