Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope

[Cigdem Sengul <[e-mail]>]

Hello,


It gets interesting when the scope is more restricted than the subscription
request.

For instance, the scope is sport/+

But subscription is sport/#


Should this be refused? Obviously the subscriber is attempting to subscribe
to more than it has permission for. But does the broker still allow the
subscription but reduce it to "sport/+"?

>
>
> [JLS] Given that this is not defined in the base MQTT specification, most
> clients would not expect this if the ACE is grafted on the side of the
> program.  I would therefore say this is a “not authorized” and go on.
>
>
>

[CS] Agreed. Another issue that we should say something about is the case
when multiple permission strings aggregated together gives enough
permission to the subscription request, based on the _current_ topic
hierarchy.
Example:
Scope strings in the token were: publish_sport/tennis
publish_sport/basketball
and then the client asks for publish_sport/+

If tennis and basketball are the only topics under sport, then this is a
valid request.
But, if the topic hierarchy is changes during the connection time (adds
sport/baseball) then subscriber gets PUBLISH messages for something they
should not.
When topic subscriptions are not protected, the broker would send anything
at the single level for sport/+ and would not worry about the new additions
after the subscription.

When topic subscriptions are protected, the Broker can choose to do two
things:
1) Allow the subscription but internally subscribe the clients to
sport/basketball and sport/tennis only.
or
2) Reject the subscription and the client needs to ask for subscriptions
that are a subset or equal to their permission strings. So the client
specifically needs to ask for publish_sport/tennis and
publish_sport/basketball matching its scope strings. But then scope
parameter cannot be optional and must be included in the AS response.
or
3) Allow the subscription, when a new level is added, check the permissions
of all active subscribers, send DISCONNECT if the current permissions do
not apply to the new hierarchy.

1 would need to be again signalled to the client, 2 might be too
restrictive, and 3 may introduce a processing load if things are changing
all the time (which I do not expect).
Leaning towards 3...  Any thoughts?

--Cigdem






> Jim
>
>
>
>
>
> --Cigdem
>
>
> Jim
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>
>