[Ace] Review of draft-sengul-ace-mqtt-tls-profile-02
Ludwig Seitz <ludwig.seitz@ri.se> Tue, 15 May 2018 09:04 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 212B612D7E6 for <ace@ietfa.amsl.com>; Tue, 15 May 2018 02:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 QQ9S8oOReBx9 for <ace@ietfa.amsl.com>; Tue, 15 May 2018 02:04:55 -0700 (PDT)
Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.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 082FA12D77A for <ace@ietf.org>; Tue, 15 May 2018 02:04:55 -0700 (PDT)
Received: from 1fIVt6-0004w5-Tn by out11a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1fIVt6-0004yN-Ve; Tue, 15 May 2018 02:04:52 -0700
Received: by emcmailer; Tue, 15 May 2018 02:04:52 -0700
Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1fIVt6-0004w5-Tn; Tue, 15 May 2018 02:04:52 -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.1261.35; Tue, 15 May 2018 11:04:52 +0200
To: "ace@ietf.org" <ace@ietf.org>
CC: Cigdem Sengul <cigdem.sengul@nominet.uk>, Anthony Kirby <Anthony.Kirby@nominet.uk>, paul.fremantle@port.ac.uk
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <99638740-7df6-c646-29bf-a3b295213396@ri.se>
Date: Tue, 15 May 2018 11:04:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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/s-MiUAHaEI21H_jgW8AcCgst4wE>
Subject: [Ace] Review of draft-sengul-ace-mqtt-tls-profile-02
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 15 May 2018 09:04:58 -0000
Hello ACE, I've reviewed draft-sengul-ace-mqtt-tls-profile-02. I think this is a very relevant draft, due to the amount of IoT devices that use MQTT. I would encourage the WG to pick this up as the third profile of draft-ietf-ace-oauth-authz Detailed comments below. /Ludwig 1. Introduction " Section 4 of the ACE framework [I-D.ietf-ace-oauth-authz]" If you make that "Section 4 of [I-D.ietf-ace-oauth-authz]" the IETF html-izer will not turn this into a link to section 4 of your draft (I think). See: https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor18 1.1. Requirements Language There is a new recommendation how this section should be worded: "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here." 1.2. ACE-Related Terminology "The term "Resource" is used to refer to an MQTT "topic", which is defined in Section 1.2." This references back to the same section, perhaps this was meant to reference to some other part of the draft? 2.1. Authorizing Connection Establishment Figure 1 could clarify that steps E and F are optional. 2.1.1. Client Authorization Server (CAS) and Authorization Server (AS) Interaction "and the client is authorized to obtain a token for the indicated audience (e.g., topics) and scopes (e.g., publish/subscribe permissions)" 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 "This includes a token, which is assumed to be PoP by default." The abbreviation PoP is not defined at this point, I would write it out as in "... assumed to be a Proof-of-Possession (PoP) token ..." 2.1.2. Client connection request to the broker " For the basic operation described in this section, the Username field MUST be set to the token." I think this refers to the access token right? I'd suggest to be more specific, since there is room for confusion (CoAP has also the concept of a token, and then OAuth has different types of tokens, the access token being one of them). "The Password field MUST be set to the keyed message digest (MAC) or signature." Please make it explicit already here that this is the Proof-of-possession mechanism for the key associated to the token. "(The Username field is a UTF-8 encoded string," You need to specify how the (possibly binary) access token is supposed to be converted into an UTF-8 string. Base64 encoding would be obvious, but it needs to be explicitly stated. General comment: An example of how the CONNECT message could look like would be good. 2.1.3. Token validation "The broker MAY cache the introspection result because it will need to decide whether to accept subsequent PUBLISH and SUBSCRIBE messages" This could warrant a section in the security considerations about the trade-off of caching introspection results (freshness vs. connectivity requirements). "If the introspection result is not cached, then the RS needs to introspect the saved token for each request." This is only true if the token is not self-contained. I would rephrase this statement "Note: Scope strings MAY follow ..." Note that a scope is a "space-delimited list strings" (OAuth 2.0 3.3.) so you could include several topics in one scope as in e.g. "connect publish_topic1 publish_topic2 subsrcibe_topic3" The use of 'aud' as described in this paragraph is definitely not the intended use, and I would not recommend this type of use. See https://tools.ietf.org/html/rfc7519#section-4.1.3 for the definition of aud. 2.4. Token expiration "The token validation is done either by checking the 'exp' claim of a CWT/JWT or via performing an introspection request with the Authorization server as described in Section 8.2 of the ACE framework [I-D.ietf-ace-oauth-authz]." The word "token validation" here could be misconstrued to ignoring crypto wrappers, token issuers ect. While it is clear from the context (to me) that you only refer to checking the expiration of a token, the full validation of a token would include the following steps: 1. Check that the issuer of the token (= AS) is acceptable 2. Check the cryptographic wrapper of the token (may be MAC or signature or AEAD encryption) 3. Check that the token contains all expected claims 4. Check that the "exp" and "nbf" claims are fulfilled if present 5. Check that the "aud" claim applies to the recipient if present 3.1. Token Transport via Authentication Exchange (AUTH) "The first option is that Authentication data contains both the token and the keyed message digest (MAC) or signature as described in Section 2.1.2." You need to specify how these two items are encoded. I would suggest a CBOR array since this property expects binary data. An example would also be very helpful here. "... RS responds with a CONNACK reason code '0x87 (Not Authorized)' and includes a User Property set to the address of the AS." You need to specify the format of this user property, in order to mirror the framework's section 5.1.2. I guess you could use either a JSON map or binary data containing a CBOR map for this. 4. IANA Considerations " This memo includes no request to IANA." This should instead register the new profile identifier "mqtt_tls" in the soon-to-be-created IANA registry for ACE profile identifiers. See the DTLS profile for example: https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-03#section-7 5. Security Considerations You should add some text here about the security implications of the limitations of MQTT v3.1 (client disconnect only). I could imagine that you could perform some attacks on a client that hasn't realized it was disconnected for example. -- Ludwig Seitz, PhD Security Lab, RISE SICS Phone +46(0)70-349 92 51
- 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