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

From: Jim Schaad <[email-masked]>
Date: Sun, 12 Jan 2020 17:38:12 -0800

I have run across an interesting question for doing validation of
subscriptions that I would like to get an opinion on.

When doing a publish, there is not an issue.  One simply takes the set of
values in the scope field as topic filters and checks the publication topic
against the set of permissible publication topic filters in the scope.

When doing a subscribe, there are four distinct cases that can arise:
1.  The subscription is for a single topic and either is or is not
successfully matched against the scope topic filter.
2.  The subscription is for a topic filter and it is identical to the scope
topic filter.
3.  Both are topic filters and are not the same.  Is one supposed to do some
type of subset matching on the two filters or does one always say that this
is not a match.  This is not addressed in the MQTT document and I am not
sure where it would be addressed.   As an example:

Scope value is subscribe_sport/#
Subscription topic is sport/tennis/#

The second is clearly a subset of the first and thus it would seem logical
to include it, but it gets more complicated if one instead asks for

Subscription topic is sport/+

In this case the two wild cards are not the same value.

Jim

---

From: Cigdem Sengul <[email-masked]>
Date: Tue, 14 Jan 2020 14:23:35 +0000

Hello Jim,

Topic filter and permission filter matching is something that I would like
to have a better resolution as well.
Responses inline.

> against the set of permissible publication topic filters in the scope.

[CS] Yes.

> successfully matched against the scope topic filter.

[CS] Yes.

> 2.  The subscription is for a topic filter and it is identical to the scope

[CS] Yes.

> In this case the two wild cards are not the same value.

We were thinking using a subset matching to check whether the token would
permit the subscription request.
For your example, a subscription request
"sport/+" would cover all the single-levels under "sport" - including
"sport/" but not "sport" .
So if the scope is "subscribe_sport/#" which covers all multi-levels under
"sport" (including "sport", the subscription request should still succeed.
(i.e., the subscriber has a larger set of permissions than the request)

Now when the broker receives a publication with "sport/tennis" then it
should pass this message on to the subscriber.
When it receives a publication "sport/tennis/player1" then it should not.
This would be normal broker behaviour as well (without using ace).

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/+"?
Currently would opt for the former, because the second option may be hard
to signal to the subscriber - the SUBACK reason string together with the
user property field may be used for such feedback to the subscriber but
would need to be defined properly.

--Cigdem

>
> Jim
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Jim Schaad <[email-masked]>
Date: Tue, 14 Jan 2020 08:50:05 -0800

From: Cigdem Sengul <[email-masked]> 
Sent: Tuesday, January 14, 2020 6:24 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; Ace Wg <[email-masked]>
Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope

Hello Jim,

Topic filter and permission filter matching is something that I would like to have a better resolution as well. 

Responses inline. 

On Mon, Jan 13, 2020 at 1:38 AM Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

[CS] Yes. 

[CS] Yes. 

[CS] Yes. 

We were thinking using a subset matching to check whether the token would permit the subscription request. 

"sport/+" would cover all the single-levels under "sport" - including "sport/" but not "sport" . 

So if the scope is "subscribe_sport/#" which covers all multi-levels under "sport" (including "sport", the subscription request should still succeed. (i.e., the subscriber has a larger set of permissions than the request)

Now when the broker receives a publication with "sport/tennis" then it should pass this message on to the subscriber. 

When it receives a publication "sport/tennis/player1" then it should not. This would be normal broker behaviour as well (without using ace). 

[JLS] This is what I expected the answer to be, I will need to figure out what this algorithm looks like now for all of the corner cases.

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

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/+"?

Currently would opt for the former, because the second option may be hard to signal to the subscriber - the SUBACK reason string together with the user property field may be used for such feedback to the subscriber but would need to be defined properly.

[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.

Jim

--Cigdem 

Jim

_______________________________________________
Ace mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ace

---

From: Cigdem Sengul <[email-masked]>
Date: Wed, 15 Jan 2020 12:44:25 +0000

Hello,

>
>
> [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

---

From: Jim Schaad <[email-masked]>
Date: Fri, 17 Jan 2020 19:28:27 -0800

Sent: Wednesday, January 15, 2020 4:44 AM

Hello,

 

[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

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). 

[JLS]  My first thought was to run and hide.  I think you have the scope strings setup wrong, they all should be “subscribe_” not “publish_” as a client is never going to ask to publish with a wildcard (MQTT-3.3.2-2).     I would far prefer that the answer be 2 rather than 1 and I think that 3 is right out.

For 3 you are saying we are going to subscribe you, and then potentially disconnect you at a later time for something you never heard about.  I don’t really care about 1, only because there is no way to communicate this information back to the client that one is changing the set of subscriptions that was requested.  

I am not sure what you are requesting in terms of returning the scope parameter.  The current OAuth specification states that if the Authorization server returns a token that contains a different scope that the one requested by the client, then it is required to return the modified scope to the client.  Is that what you are looking for.

Jim

--Cigdem

 

Jim

--Cigdem 

Jim

---

From: Cigdem Sengul <[email-masked]>
Date: Mon, 20 Jan 2020 22:23:16 +0000

Hello Jim,

> 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.
>
>
>
> [JLS]  My first thought was to run and hide.  I think you have the scope
> strings setup wrong, they all should be “subscribe_” not “publish_” as a
> client is never going to ask to publish with a wildcard (MQTT-3.3.2-2).
>   I would far prefer that the answer be 2 rather than 1 and I think that 3
> is right out.
>

Gosh... Don't know why I switched to publish... Sorry for any pain caused!

>
>
> For 3 you are saying we are going to subscribe you, and then potentially
> disconnect you at a later time for something you never heard about.  I
> don’t really care about 1, only because there is no way to communicate this
> information back to the client that one is changing the set of
> subscriptions that was requested.
>

Ah, I see your interpretation- I saw the subscription request for
subscribe_topic/+  and subscribe_topic/# as a request from the subscriber
saying "send me anything under x" (depending on +/# restrictions). So, they
may not know all the matching subtopics anyway.

If the permissions are including the wildcards and cover the request, no
problem.  But, if they don't but the combination of a subset of permissions
do at the current state (i.e., subscribe_sport/basketball +
subscribe_sport/tennis = subscribe_sport/+), I wondered whether the RS may
want to accept this request. However, if it registers this subscription as
subscribe_sport/+, it is not future proof for any changes to that level and
client would be lacking the appropriate permissions - which should lead to
a disconnect.

>
>
> I am not sure what you are requesting in terms of returning the scope
> parameter.  The current OAuth specification states that if the
> Authorization server returns a token that contains a different scope that
> the one requested by the client, then it is required to return the modified
> scope to the client.  Is that what you are looking for.
>

Thanks, I was not sure that was a MUST, and I should have read the RFC more
carefully. (Possibly I got confused with another spec out of IETF, where
the client may not have the final info on the scope.)

Then 2 would definitely work and is much simpler. I was thinking it may be
restricting. But, it's best to avoid the complexity of additional checks on
combinations of permissions to see if the request can be satisfied.

Thanks for your feedback.
--Cigdem