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

[Cigdem Sengul <[e-mail]>]

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 <[e-mail]> wrote:

> On 2018-06-14 14:09, Cigdem Sengul wrote:
>
>> 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: underscoreseparated 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-oauthdraft,
>> 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 doeshavean 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).
>>
>>
> 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 [phone]
>