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

Ludwig Seitz <ludwig.seitz@ri.se> Fri, 15 June 2018 13:07 UTC

Return-Path: <ludwig.seitz@ri.se>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED8F1292F1 for <ace@ietfa.amsl.com>; Fri, 15 Jun 2018 06:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03fX6mhZ7cfK for <ace@ietfa.amsl.com>; Fri, 15 Jun 2018 06:07:44 -0700 (PDT)
Received: from smtp-out10.electric.net (smtp-out10.electric.net [185.38.180.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866F7130E3F for <ace@ietf.org>; Fri, 15 Jun 2018 06:07:44 -0700 (PDT)
Received: from 1fToS5-000Yuv-VW by out10d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1fToS6-000Ywr-U2; Fri, 15 Jun 2018 06:07:42 -0700
Received: by emcmailer; Fri, 15 Jun 2018 06:07:42 -0700
Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out10d.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1fToS5-000Yuv-VW; Fri, 15 Jun 2018 06:07:41 -0700
Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 15 Jun 2018 15:07:41 +0200
To: Cigdem Sengul <cigdem.sengul@gmail.com>
CC: "ace@ietf.org" <ace@ietf.org>, Anthony Kirby <Anthony.Kirby@nominet.uk>, Paul Fremantle <paul.fremantle@port.ac.uk>
References: <99638740-7df6-c646-29bf-a3b295213396@ri.se> <CAA7SwCOhh2pEpjz9kJwe4Hwc9aAiDVJzqJS78DrGvRSV0vdNBQ@mail.gmail.com>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <5b1f40ed-4df1-29ef-f911-05b8fc0168dc@ri.se>
Date: Fri, 15 Jun 2018 15:07:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CAA7SwCOhh2pEpjz9kJwe4Hwc9aAiDVJzqJS78DrGvRSV0vdNBQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-2.sp.se (10.100.0.162)
X-Outbound-IP: 194.218.146.197
X-Env-From: ludwig.seitz@ri.se
X-Proto: esmtps
X-Revdns:
X-HELO: sp-mail-2.sp.se
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-Authenticated_ID:
X-PolicySMART: 14510320
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/JUhOlVK9O3ryEokuripkheOPAuY>
Subject: Re: [Ace] Review of draft-sengul-ace-mqtt-tls-profile-02
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2018 13:07:48 -0000

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 +46(0)70-349 92 51