Subject: Re: [Ace] Review of draft-sengul-ace-mqtt-tls-profile-02

From: Cigdem Sengul <[email-masked]>
Date: Thu, 14 Jun 2018 13:09:01 +0100

Hello Ludwig,

Again thank you for your comments.
We are going through them and making several revisions to our draft.

We want to discuss two of your comments further:

(1) Our text: ”and the client is authorized to obtain a token for the
indicated
   audience (e.g., topics) and scopes (e.g., publish/subscribe
   permissions)"

Your comment: Note that the audience claim is typically used to identify
the RS (so in this case the MQTT broker), while the scope is intended to
identify both the resource (=topic) and the actions (=publish, subscribe).
See this for how OAuth scopes are typically used:
https://www.brandur.org/oauth-scope

Our response:
According to the draft-IETF-ace-oauth-authz-12, the audience of an access
token can be a specific resource or one or many resource servers.

So, we considered three ways to structure our tokens, given that a token
can hold multiple scopes but only a single audience :
(1) aud: RS

     scopes: underscore separated keywords representing <permission>_<topic>,
e.g., "publish_valve2012/temperature", "subscribe_/foo/+/bar",
"subscribe_$SYS/#"
(2) aud: resource, i.e., a topic in MQTT context

      scopes: permissions, i.e., publish and/or subscribe keywords

(3) aud: permission, i.e., publish or subscribe
scope: topics (i.e., resources), e.g., topic1 topic2 topic3

We think Options (1) and (2)  fit the current text in the ace-oauth draft,
especially, when we consider this example:
{
     "grant_type" : "client_credentials",
     "client_id" : "myclient",
     "client_secret" : "mysecret234",
     "aud" : "valve424",
     "scope" : "read",
     "cnf" : {
       "kid" : b64'6kg0dXJM13U'
     }

If using option (1), we can choose to leave this as an "application
specific convention".  On the other hand, it could be useful to have
this defined, because MQTT only allows publish & subscribe, and there are
rules for the MQTT topic string.  This would make ACE-savvy MQTT clients &
servers generally more compatible/interoperable.

Based on our option (2), these would be in MQTT - “aud”: “valve424”,
“scope”: “subscribe” Note that, the multiple tokens trade-off we mention in
our draft still exists for the core’s valve example too. This token does
not help with reading “valve425”.

Option (3) is more left-field proposition and does not align with the rest
of the core draft. Though, it does have an efficiency advantage that a
single token can permit access to multiple topics.

Based on the ace-oauth draft, the first two options for token structure
should be acceptable. We want to list both to avoid being too prescriptive
about scope structures (as the option (1) dictates).

(2)

Your comment: An example of how the CONNECT message could look like would
be good.

We think we need a bit of clarification about what kind of an example you
have in mind. Our draft has a figure 2 that explains the different field an
MQTT Connect packet will have. We could add an example in hex (MQTT being
binary)  but it wouldn't be as easy to read as the HTTP example.

Thanks,
—Cigdem & Anthony

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 15 Jun 2018 15:07:41 +0200

On 2018-06-14 14:09, Cigdem Sengul wrote:
> According to the draft-IETF-ace-oauth-authz-12, the audience of an 
> access token can be a specific resource or one or many resource servers.
> 
> So, we considered three ways to structure our tokens,given that a token 
>       scopes: underscoreseparated keywords 
> representing<permission>_<topic>, e.g.,"publish_valve2012/temperature", 
> "subscribe_/foo/+/bar", "subscribe_$SYS/#"
> 
> We think Options (1) and (2)  fit the current text in 
> the ace-oauthdraft, especially, when we consider this example:
> {
> this defined, because MQTT only allows publish & subscribe, and there 
> are rules for the MQTT topic string.  This would make ACE-savvy MQTT 
> clients & servers generally more compatible/interoperable.
> 
> “scope”: “subscribe” Note that, the multiple tokens trade-off we mention 
> in our draft still exists for the core’s valve example too. This token 
> does not help with reading “valve425”.
> 
> 
> Option (3)is more left-field proposition and does not align with the 
> rest of the core draft. Though, it doeshavean efficiency advantage that 
> a single token can permit access to multiple topics.
> 
> should be acceptable. We want to list both to avoid being too 
> prescriptive about scope structures (as the option (1) dictates).
> 

Note that 'the "aud" value is an array of case-
    sensitive strings' (RFC7519 section 4.1.3), while scope is a "... 
list of space-delimited, case-sensitive strings." (RFC6749 section 3.3), 
so you could authorize access to several topics with different 
permissions in a single token with all of the approaches you define above.

Option 3 is clearly far off from the intended use of aud
(' the "aud" (audience) claim identifies the recipients that the JWT is
    intended for.' )

In option 2 how do you avoid the use of an access token at a different 
resource broker?
(For clarification: Say you have resource broker A and B who both serve 
similarly named topics, but in entirely different locations, and who 
happen to use the same AS.)

> (2)
> 
> Your comment: An example of how the CONNECT message could look like 
> would be good.
> 
> We think we need a bit of clarification about what kind of an example 
> you have in mind. Our draft has a figure 2 that explains the different 
> field an MQTT Connect packet will have. We could add an example in hex 
> (MQTT being binary)  but it wouldn't be as easy to read as the HTTP example.
> 

Perhaps hex-code with explanations under the different parts of it as in:

45FC    481A        F56B        1234  A527
Header  Parameter1  Parameter2  Payload

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Cigdem Sengul <[email-masked]>
Date: Fri, 15 Jun 2018 14:38:39 +0100

Thanks for clarifications Ludwig,

True,  aud can be an array. We typically avoided this, hence, the omission.

For the case (2) to be used, there would be a single RS assumption indeed.
This should be clearly said when we are proposing the option 2.

Thanks for your response,
--Cigdem

On Fri, Jun 15, 2018 at 2:07 PM, Ludwig Seitz <[email-masked]> wrote:

>>       scopes: underscoreseparated keywords representing<permission>_<topic>,
>> e.g.,"publish_valve2012/temperature", "subscribe_/foo/+/bar",
>> "subscribe_$SYS/#"
>>
>> We think Options (1) and (2)  fit the current text in the ace-oauthdraft,
>> Option (3)is more left-field proposition and does not align with the rest
>> of the core draft. Though, it doeshavean efficiency advantage that a single
>> token can permit access to multiple topics.
>>
>    sensitive strings' (RFC7519 section 4.1.3), while scope is a "... list
> of space-delimited, case-sensitive strings." (RFC6749 section 3.3), so you
> could authorize access to several topics with different permissions in a
> single token with all of the approaches you define above.
>
> similarly named topics, but in entirely different locations, and who happen
> to use the same AS.)
>
>
> (2)
>>