Hi,
Answering the one issue left from Ludwig's review, including Jim's reaction
inline.
Thanks,
Francesca
On 23/07/2019, 14:56, "Ace on behalf of Jim Schaad" <ace-boun...@ietf.org on
behalf of i...@augustcellars.com> wrote:
-----Original Message-----
From: Ace <ace-boun...@ietf.org> On Behalf Of Ludwig Seitz
Sent: Friday, July 19, 2019 7:22 AM
To: draft-ietf-ace-key-groupc...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] Review of draft-ietf-ace-key-groupcomm
Hello Francesca, Marco,
I have finally managed to read the whole of draft-ietf-ace-key-groupcomm
and have a few comments for you:
==
5.2
"If the leaving node wants to be part of a group with fewer roles, it
does not need to communicate that to the KDC, and can simply stop acting
according to such roles."
There are legitimate cases where a node might want to explicitly
deactivate roles it is currently using (principle of least priviledge)
and not just stop using them.
[JLS] I trimmed because I only wanted to address this one topic. I totally
agree that there are cases where a node might want to deactivate roles, however
in the case of group communication I don't see how this could be done in a
reasonable manner.
FP: I agree with Jim that I am not sure this can be done "in a reasonable
manner" (where reasonable means "worth the effort").
If a node says - please stop advertising my public key because I am no
longer a publisher, that is reasonable for a KDC to start doing. However,
there are currently no provisions in the protocol for a KDC to advertise that
fact to all of the subscribers. Even if a key roll over were to occur, as the
node still is part of the group, it can produce the correct key material and
sign a message. A subscriber with the signature key would successfully
validate the signature and accept it the message, only those subscribers which
had not yet pulled down a public key would fail to validate the message.
This would require a new mechanism for the purpose of asking if a public
key is still associated with a specific key identifier (which is a good reason
for the note about keeping the same key ids when rolling keys). I am not sure
that the traffic would be worth the effort for this small gain.
FP: The KDC keeps track of nodes being in the group now, and for each node it
has an associated token with authorization information, so the KDC knows what
roles each node has within the group. A possible new mechanism to solve this
would be: we could add
* an (observable) resource at the KDC that allows any member of the group to
get information about nodes’ roles, say POSTing an array of node identifiers to
the KDC and getting back the roles, or observing it and getting any changes it
might happen, and
* another resource where a node can POST updates to its own role
But I am not sure that is very useful/worth the effort vs the amount of traffic
generated. The node requesting to “leave a role” could still request to “get
the role” again, if it is still authorized to do so (for example, a publisher
could decide to suddenly only be a subscriber, but could still get back its
publisher role if it wanted to). I am interested in hearing more opinions about
this (“no we don’t need this” “yes we need this and why”).
Note that for a gated transmission system such as a pub-sub server, the
node can get lesser privilege for the gate system without getting less
privilege for the KDC.
Jim
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
