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

[Cigdem Sengul]

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  wrote:

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


[CS] Yes.


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

[CS] Yes.


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

[CS] Yes.

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

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
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03

[Cigdem Sengul]

Thank you for this review, Jim.
Responses inline.

On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad  wrote:

>
> 2.2.2 - para 1, the last sentence seems to imply that the first connection
> to publish to authz-info is not being done over a TLS connection.  But the
> sentence before that states that a TLS connection MUST be used for this.
> Perhaps s/and is expected to try reconnecting over TLS./and reconnects,
> potentially using client authentication with TLS./
>

[CS] Yes, that part reads confusing.
The aim was to say client authentication is not done over TLS, but
connection can be over TLS.
What it should be saying:
Client can use either mqtt or mqtts to connect to the broker, but does only
server validation, to push the token.
After pushing the token, it is expected to do TLS:Known(RPK/PSK)-MQTT:none.
(Although for PSK the token can be in psk_identity).
Issue created:  https://github.com/ace-wg/mqtt-tls-profile/issues/37


> 2.2.2 - I am unclear under what circumstances you could end put with a
> token
> which does not parse when processing a PUBLISH message.  If the token
> cannot
> be parsed at connection time, that I can understand.  However having parsed
> the token then it does not make sense that the token becomes not parsable
> at
> the time of publishing.  Am I missing something?
>

[CS] There is a misunderstanding. The PUBLISH message refers to the actual
PUBLISH message to the "authz-info" topic which contains the token i.e.,
this may not parse to a token. (The PUBLISH message is not for other
messages that are permissioned in the token.)
The client connects (without much security), publishes the token to the
public "authz-info" topic, which only the broker can read.
Then, disconnects, and tries to connect with ace security.

Since MQTT v5 can return error messages in response to PUBLISH messages,
here, this is used to signal to the publisher that there is something wrong
with its token.

Added: https://github.com/ace-wg/mqtt-tls-profile/issues/38


>
> 2.2.2 - The last paragraph is causing me confusion.  Is this supposed to be
> referencing the RS or the AS?  If it is the AS, then I don't see how there
> could be any confusion.  Please expand this so it is clearer.
>

[CS] This is a typo - it should be RS.
 https://github.com/ace-wg/mqtt-tls-profile/issues/39


> 2.2.4 - I am having a problem with trying to parse the content of the AUTH
> property.  I have no problems with 2.2.4.3 because this is a zero length
> sequence of bytes.  However for 2.2.4.1 and 2.2.4.2 there is a token
> (possibly binary with no length prefix) followed by an optional binary
> cryptographic value.  For introspection, I would need to figure out the
> length of the token before I could make a guess at the length of the
> cryptographic value.  However given that there is no divider this does not
> seem possible.  This may also become a problem for the response from the
> client in the event that there is a change from an 8-byte nonce to a
> variable length one.
>

[CS] Not specified a  format, because I  thought we discarded the idea of
using the variable-length nonce based on the meeting in Singapore.
What would you suggest - introduce a specific format to accommodate
variable length?
length_of_token+binary data for token+(the rest is cryptographic value)?
 https://github.com/ace-wg/mqtt-tls-profile/issues/40


> 2.2.4.1 - In my view it is not the secret, but the content that is being
> obtained from the TLS exporter.  That is one is signing (or MACing) the
> exporter value not using that value to compute a MAC on something else.
> While it is true that only the two parties know that value, exposure to a
> third party does not lead to a compromise.
>

[CS] I see - so reword "secret" to "content".
Or do you have a suggestion for wording?
https://github.com/ace-wg/mqtt-tls-profile/issues/41

>
> 2.2.4.3 - I am not sure if the text is supposed to require an empty
> authentication data field or to allow for the authentication data field to
> be absent as well.
>

[CS] I checked whether it would be a protocol error to have only
Authentication Method in MQTT, and it is not.
Then it is best to omit authentication data field.
Will correct the text that the document allows the CONNECT message to have
an Authentication Method set to 'ace' and allows to omit the Authentication
Data field.
https://github.com/ace-wg/mqtt-tls-profile/issues/42


>
> 3 - It might be worth while to put a pointer to section 4.7 of the MQTT V5
> spec here so that there is an indication of what the different wild card
> characters do.  I had to pop over there to make sure that I could figure it
> out.
>

[CS] Will do.
https://github.com/ace-wg/mqtt-tls-profile/issues/43


> 3.1 - Should you state that for a QoS of 0, the client should close the
> connection w/ an '0x87' in the event of an authorization failure?  I think
> that this is supposed to happen but you have left it open.
>

[CS]
Yes, I must have cut some text out. QoS of 0, the client is 

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

[Jim Schaad]

 

 

From: Cigdem Sengul  
Sent: Tuesday, January 14, 2020 6:24 AM
To: Jim Schaad 
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 
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 mailto:i...@augustcellars.com> > wrote:

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.

 

[CS] Yes. 

 


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.

 

[CS] Yes. 

 

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

 

[CS] Yes. 

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.

 

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

 

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

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.

 

[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
Ace@ietf.org  
https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace