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

Cigdem Sengul <cigdem.sengul@gmail.com> Fri, 15 June 2018 13:38 UTC

Return-Path: <cigdem.sengul@gmail.com>
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 89E90130ED6 for <ace@ietfa.amsl.com>; Fri, 15 Jun 2018 06:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 470zt1odV1tb for <ace@ietfa.amsl.com>; Fri, 15 Jun 2018 06:38:41 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23D2130ED2 for <ace@ietf.org>; Fri, 15 Jun 2018 06:38:40 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id j80-v6so5581050qke.9 for <ace@ietf.org>; Fri, 15 Jun 2018 06:38:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JYLKfzjdkfXNKfyutZrwG6jatDfSvTvEpqLHTGWyaos=; b=VYDDflrulkn4JzwTVn1vOtYGVGxUFMyZL6dyAbbLgN+Rs5/yKdolVqL/BslHVJGDn/ pVQK5Ue/S9D7zjymDVJiAJFp39gorsbnotVHpqLK6bQAEy6gmEnCoaM1sJkRSZHEFVC+ z6LBp+kZ1G4owdAGt/oCqKfeJQMGEE9uDArCqlU2f0Q4XuWC2iENS0XSJ5yXC7Usp3J8 1JmhVttSP0WHjDK6KbGTI62RW+JrrzCJEtjlAIC3ixvmCu/hvWWUcOYYnDtICZYWe8lV D+NpTXiMRRWm+1h6f5rhalIsfiSe9YK3x64jKzsaWXYtxn0AAS5xykwmmqr3tn8KsKVv B8WQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JYLKfzjdkfXNKfyutZrwG6jatDfSvTvEpqLHTGWyaos=; b=pD79pmyGDGNWmjmLshCTQLjaXzXj5ngTqzrxtrZZa0Baun0woZFAyZsixR1chot0YF 8Fj/7ajXsTYe71G0cABToR8ts6NuQDXcZFjcpTtYM+o2WAlUpD/7nfXqlCphRaQ993Kz nArxIZ6LD5wB/hWzF4mgR/WwH1oKRY4rNdCkAkjWGrZ+A0ijdiMmO5ercHAIDIgqkuSc CK1LIdVj9ezFo7jEugOXfB42WQu7b1QqMnwZWzkstj+8lxCcqh1SxKVBhFvcNj8cdHdG xfSdpGlp+ZoK7kB9kssX9tKvsr+4H99t8KEpOjURRZhIaxpw0qtgbi1vCbReP/wG/Lzm uvPw==
X-Gm-Message-State: APt69E1FEAG97EGbd/1OnZ6WjSA8bpprNgwwaebE9k2RXxBHC4BjDqRH CaIVdN6vNTlLNwCb1NqvyJySoT0cQLSZLdW6uqM=
X-Google-Smtp-Source: ADUXVKK7wvwKgCBIfqkmIeqYngC+2oAOW0K2Oos1wpg2F3CQubJyrc5wHBnyzZnGaKAIEEmyAEgfnk/+NkXvKyjHJ98=
X-Received: by 2002:a37:5607:: with SMTP id k7-v6mr1315238qkb.342.1529069920165; Fri, 15 Jun 2018 06:38:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a37:d199:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 06:38:39 -0700 (PDT)
In-Reply-To: <5b1f40ed-4df1-29ef-f911-05b8fc0168dc@ri.se>
References: <99638740-7df6-c646-29bf-a3b295213396@ri.se> <CAA7SwCOhh2pEpjz9kJwe4Hwc9aAiDVJzqJS78DrGvRSV0vdNBQ@mail.gmail.com> <5b1f40ed-4df1-29ef-f911-05b8fc0168dc@ri.se>
From: Cigdem Sengul <cigdem.sengul@gmail.com>
Date: Fri, 15 Jun 2018 14:38:39 +0100
Message-ID: <CAA7SwCM3tUntuivAsDPFcm1YG19NJtUXEMZN=mRG5SVQeLBPkA@mail.gmail.com>
To: Ludwig Seitz <ludwig.seitz@ri.se>, ace@ietf.org
Cc: Anthony Kirby <Anthony.Kirby@nominet.uk>, Paul Fremantle <paul.fremantle@port.ac.uk>
Content-Type: multipart/alternative; boundary="0000000000006da3e3056eae5582"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/0pc3xQRnSQx6YOYycnLm0H8GOvk>
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:38:44 -0000

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 <ludwig.seitz@ri.se> 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 +46(0)70-349 92 51
>