Re: [Ace] Review of draft-sengul-ace-mqtt-tls-profile-02
Cigdem Sengul <cigdem.sengul@gmail.com> Thu, 14 June 2018 12:09 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 3EB821292F1 for <ace@ietfa.amsl.com>; Thu, 14 Jun 2018 05:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 BV1rBkZy60gZ for <ace@ietfa.amsl.com>; Thu, 14 Jun 2018 05:09:03 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 0E8D4126F72 for <ace@ietf.org>; Thu, 14 Jun 2018 05:09:03 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id i18-v6so5451909qtp.12 for <ace@ietf.org>; Thu, 14 Jun 2018 05:09:03 -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=ZPa7ZkOIhesX7ZywlahztJbqW5inDdcHYJcyvHlAaZU=; b=dhPJ3k/xd58CTcQNZks+HUJWCP+2aBHb45XFEYhKx3rhvQpWakx/IxREeoPAafkFK0 68In6ldXDBVmVOlt2iKJekUUbm7Q3jSLHCU0HM93zsfjsch/sOBnUzdY6STZS+O1HGjm 0bivodmjQiObvKGL3aTlkvQNHoYACqTnMJY5MLELCTG9iZrAB1mtuA7flhjdyxkcmKqj x9rRESqr1gThFWVT7tnynpp/qg1yPASSAZSQTo1X2jQOAhljm9+kYY4id9eZz/ILhxjA kAp2QgzZz7PMU0kCnhEeHUKnbsVBOJqhm96rA8MOjcE6334naLLJmIwVHHOtFhVAE0Zr 6WnA==
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=ZPa7ZkOIhesX7ZywlahztJbqW5inDdcHYJcyvHlAaZU=; b=WftMBzuAE0+8QFi3F4Mf3YVz2PMep0Qj9V7h+yoex8BpZ2GGN1R8agKiZ7cqqpqSJe jUi0XbCVkbX6IjR3A4zdpEXonQa/6ioVJgXP9nlwvA8U73YriS9YZ89m5AR+mkURG2mN G7fI1gElaUaAE79sZ64MRIyPIclep6xs61ymUqcl2RQ/T390xIAPCia6zFxHvNN5EMXo XiariaOifXmNAO8tT1Ot5g8zvtSCFCWkfyItAe7x5DzwQ+DRqxnsB9vbt6SMnVvZ+zoF kiliecuOsIFEsjJvjivtmptGcXu+F+KgAzezLyYlYqeUf75OtdXmzFdqY68UcNdBOvyt AQgA==
X-Gm-Message-State: APt69E0fXFIDq1YhuHiOS56OdGb1bhqTItwaWmIFGbzJzSS1Oty3JiFg gJTSuGRHHkatvNjBpLvkZuT+OkxdFj/lPo0upUA=
X-Google-Smtp-Source: ADUXVKLPAR2k4TlPChsPS/vIC3Hb/4Ny5K8dg5OZ6vOaG3G4lW22QQruLGPlKYA60Nv6kGuq102plVCWHlGL1gTecxo=
X-Received: by 2002:a0c:98d1:: with SMTP id g17-v6mr1951334qvd.27.1528978142023; Thu, 14 Jun 2018 05:09:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a37:d199:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 05:09:01 -0700 (PDT)
In-Reply-To: <99638740-7df6-c646-29bf-a3b295213396@ri.se>
References: <99638740-7df6-c646-29bf-a3b295213396@ri.se>
From: Cigdem Sengul <cigdem.sengul@gmail.com>
Date: Thu, 14 Jun 2018 13:09:01 +0100
Message-ID: <CAA7SwCOhh2pEpjz9kJwe4Hwc9aAiDVJzqJS78DrGvRSV0vdNBQ@mail.gmail.com>
To: Ludwig Seitz <ludwig.seitz@ri.se>
Cc: "ace@ietf.org" <ace@ietf.org>, Anthony Kirby <Anthony.Kirby@nominet.uk>, Paul Fremantle <paul.fremantle@port.ac.uk>
Content-Type: multipart/alternative; boundary="0000000000000654ef056e98f731"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/XmL1YVzqx1i9H1_PtIAIA0g64TE>
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: Thu, 14 Jun 2018 12:09:07 -0000
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
- Re: [Ace] Review of draft-sengul-ace-mqtt-tls-pro… Cigdem Sengul
- Re: [Ace] Review of draft-sengul-ace-mqtt-tls-pro… Ludwig Seitz
- Re: [Ace] Review of draft-sengul-ace-mqtt-tls-pro… Cigdem Sengul
- [Ace] Review of draft-sengul-ace-mqtt-tls-profile… Ludwig Seitz
- Re: [Ace] Review of draft-sengul-ace-mqtt-tls-pro… Cigdem Sengul