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

[Ludwig Seitz <[e-mail]>]

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]