Re: [Ace] Review for draft-palombini-ace-coap-pubsub-profile

[Benjamin Kaduk <[e-mail]>]

On Fri, Dec 20, 2019 at 12:03:04PM +0000, Cigdem Sengul wrote:
> Hello Ben,
> Response below.
> 
> >  >
> > >
> >
> > > CS: I see that I wasn't clear in my thinking before and mixed up things.
> > I
> > > was trying to understand how groups map to topics and the topic
> > hierarchy;
> > > and how group maintenance scales with the increasing number of topics,
> > > publisher and subscribers. Said another way, who creates groups, and
> > > creates/updates keys for these groups to be maintained in the KDC?
> > >
> > > I agree topic hierarchies require more thought. Here is my second attempt
> > > at explaining my thinking, which is by no means complete:
> > > In MQTT, it is possible to publish to all levels in a topic hierarchy
> > e.g.,
> > > if you have sport/tennis/player1/rankings, it is possible to publish to
> > the
> > > sport, sport/tennis, sport/player1, sport/player1/rankings...
> > > One option is to have as many keys as the nodes on the hierarchy
> > > independent of actual publishers and subscribers to them.  (Assuming this
> > > hierarchy is pre-built, and AS2 maintains a complete topic-key database).
> > > So, if publisher P1 comes with rights to publish to sport/tennis - he
> > gets
> > > the keys for that. But, if he comes with the right to publish to
> > > sport/tennis/#, he gets multiple keys, one each for every node under
> > > tennis.
> >
> > Having to always send all the keys would get frustrating (and/or expensive
> > in terms of bytes!), but the "other option" below feels quite messy with
> > respect to having to push out updates when membership/number of groups
> > changes.  I suppose the right balance depends on actual usage patterns, but
> > I would mostly expect a flow where permissions on a hierarchy grant the
> > ability to get any (per-topic) key from the hierarchy, but you still have
> > to explicitly request the individual key for the individual topics you are
> > going to post to, to be of most generic applicability.  Am I forgetting a
> > reason why that's not possible?
> >
> > Thanks,
> >
> >
> Yes, both have problems - mainly used them to talk about the differences
> between (semi-)static grouping (topics define groups) and dynamic grouping
> (active publisher/subscribers and their topic permissions determine groups).
> 
> Yes, a token with scopes that use the wildcard will give you the right to
> get any key from the hierarchy. In the "first approach," you would need the
> get the specific one for the individual topic because any number of
> publisher/subscribers may be on that topic (but not on others).
> If I understand correctly, you suggest that the client asks for the right
> key just-in-time before a publish/subscribe message?
> This is a good solution if the client can connect to AS2 at all times, but
> in ACE, I thought, we did not assume ASes are always reachable by clients.
> Therefore, I was always thinking of a scenario where the client is
> provisioned with the right keys beforehand (determined by their
> permissions).

Yes, I was thinking of having the client ask for the key "just in time",
but you are also right that we do consider cases where such connectivity is
not always available.  So perhaps there is not a single clear answer for
all cases...

> But the "second option", where the same encryption key may be used across
> different topics,  has the same connectivity requirements due to rekeying
> expected as groups change.
> 
> I hinted this in my previous e-mail by having to consider rekeying
> policies, as I haven't seen it mentioned in coap-pub-sub.
> 
> Need to also consider rekeying as a separate problem that needs to be
> addressed regardless of what approach is taken: ace-key-groupcomm refers
> to  [RFC2093], [RFC2094] and [RFC2627] for rekeying mechanisms and I am not
> exactly sure how to use them for client-broker communication.
> 
>  ace-key-groupcomm also states: If the application requires forward
> security, the KDC MUST generate new group keying material and securely
> distribute it to all the current group members but the leaving node, using
> the message format of the Key Distribution Response"
> If it is the AS2 (KDC) that needs to rekey groups, then AS2 should be able
> to connect to the clients and push this information? Am I missing something
> here?

I think we need to hear from other members of the WG to make progress here;
I don't have a clear picture, myself.

-Ben

> (In MQTT, things were easier when tokens expire. The Broker knows a token
> expired and disconnects the client, which forces the client to get a new
> token. But, the Broker here has no idea of rekeying.  So, the trigger for
> that needs to come from AS2. )
> 
> Regards,
> --Cigdem
> 
> 
> > Ben
> >
> 
> 
> 
> 
> 
> 
> 
> >
> > > The other option is creating groups dynamically and subtopics inherit
> > > authorisations (as captured by the wildcards), i.e., publisher and
> > > subscribers that have an exact match in their topic filters form a group.
> > > Going back to the previous example, assuming AS2 is generating the keys
> > > (need to read the groupcomm in detail to understand how the KDC and its
> > > endpoints work in general), I imagine something like this may work:
> > > Publisher P1 - publish_sport/tennis/#  -> AS2 checks if a matching group
> > > exists, doesn't find one, generates the key, and hands it out to P1,
> > stores
> > > the mapping.
> > > Publisher P2 - publish_sport/tennis/# -> AS2 checks if a matching group
> > > exists, find one, gives out the key to P2.
> > > Subscriber S1 - publish_sport/tennis/# -> AS2 checks if a matching group
> > > exists, find one, gives out the key to S1. Until now, assumed no rekeying
> > > when the new members join an existing group, as this would work well with
> > > MQTT RETAIN option, which enables the publisher to indicate
> > > to the Broker that it should store the most
> > >  recent message for the associated topic.  Hence, the new subscribers
> > > can receive
> > > the last sent message from the publisher of that particular topic
> > > without waiting
> > > for the next PUBLISH message.
> > > Subscriber S2 - publish_sport/tennis/+/rankings - AS2 checks if a
> > matching
> > > group exists, does not find an exact match -> generates new key, but then
> > > needs to update P1, P2, S1 as well as publish_sport/tennis/+/rankings
> > will
> > > be sent encrypted with the new key, and the rest will be with the old
> > key.
> > > When they are rekeyed, the publishers may send RETAINED messages again
> > with
> > > the new key.
> > >
> > > i.e.,
> > > P1-P2-S1 are one group
> > > P1-P2-S1-S2 would be another group
> > > Two groups - two keys.
> > >
> > > Do not know what is best, or there is a third option.
> > >
> > > Another thing to consider would be rekeying policies of course.
> > >
> > >
> > > >
> > > > Another approach could be each publisher creating its group. This way
> > the
> > > > number of groups scales with the number of publishers (and the COSE
> > keys is
> > > > per publisher).
> > > >
> > > >
> > > >
> > > > FP: I don't think this scales well, but yes, an application could also
> > do
> > > > this.
> > > >
> > >
> > > CS: Yes, scratch that - that actually wouldn't work.
> > >
> > > Thanks,
> > > --Cigdem
> > >
> > >
> > >
> > > >
> > > >
> > > > Kind regards,
> > > >
> > > > --Cigdem
> > > >
> >
> > > _______________________________________________
> > > Ace mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/ace
> >
> >