Re: [Ace] Review of draft-sengul-ace-mqtt-tls-profile-02
Cigdem Sengul <cigdem.sengul@gmail.com> Tue, 15 May 2018 20:31 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 3826112E8A1 for <ace@ietfa.amsl.com>; Tue, 15 May 2018 13:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, 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 xZSVYgssO994 for <ace@ietfa.amsl.com>; Tue, 15 May 2018 13:31:26 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 AA6B912D95D for <ace@ietf.org>; Tue, 15 May 2018 13:31:25 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id c11-v6so1340747qkm.0 for <ace@ietf.org>; Tue, 15 May 2018 13:31:25 -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=j/giFpEE3FEOwPuerAh1Fw7OBDVvGsa9EMB2buu3NtU=; b=jZHGSF2bs9PK3OvDHbNIK9rg5T0rJIuq8+BKxDNY7BYogubghwO4HNIyc9m+rTxums oguFcPwMWu6DLoqLTlrFz7XmaJTbBNFY0fJX66C3hZTXxFc2sOQxRBI7WLaz2S7WbRVr 8hl6lParzy06m3kuBARkjL1IFXdWwDAJro5yKegLVo8C8SR/P7/VjwvIiJW6PlpF3DZS YFzvc7GndQOEQ0KpDP5imMI9hMCnosOi6s6epr58Zyc+6hFwHazVfaexg2V/29vp8zrY ubXirpAkT3KimIb82hE2/qmw2ndkA3ir7Mpo7dl0Ku4ei6Iy0qgdffuHKYHOG8BvvIFC OshA==
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=j/giFpEE3FEOwPuerAh1Fw7OBDVvGsa9EMB2buu3NtU=; b=LDKLe0ez23BHMy8VHBT4MHkaLC50cJU1l5Di8hmVcnO1kI2w5plz+OVZI4dUn/ebrp 5TJaWid8EDdLN7owMHm0T0ixMuaGbVk2+FptWtG8DJWzMLH+wBLiNcifawZOYXhNM7/S syiWQBO6JiRqa6CVRI8sXPRNxVy/MAME89pLEayapgveVpBIZ9i006GubAAB/2xkzHo6 a215srItYcuKrE0O+Axz+Hlf/XyMeHTF+dymovW35xt9KTFWfOo5GXQne2tPJRiFH2UD OpRfS6wsWW1gJWc+7zq+SMyKYXpbEVqJPVhjldIK8a4VPnv+lnVHLeJECg5mDI8y7UNK mZwQ==
X-Gm-Message-State: ALKqPwcc5CbMPJ/cKvJ/yQ6FRCdCS+eIPQ/cXpc3aZp1PuwKNPY8jftD GR1WPz0gqpv+bRvHITLuUV3p1uFEnbXq8XHN7iY=
X-Google-Smtp-Source: AB8JxZp0TXLzIzJiF3m1AJ44dNpNTDRKubUC8FPb6yt1+h1jvE8Fs+8jzgPtmfyEITdmkqC/9XGRoCUa6pgWmqfcxzo=
X-Received: by 2002:a37:ac12:: with SMTP id e18-v6mr22549qkm.342.1526416284777; Tue, 15 May 2018 13:31:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.57.195 with HTTP; Tue, 15 May 2018 13:31:24 -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: Tue, 15 May 2018 21:31:24 +0100
Message-ID: <CAA7SwCOp-jytmM0wNNSvEQidcDKv0NUY+tWf_yrJp_6P7miHHA@mail.gmail.com>
To: Ludwig Seitz <ludwig.seitz@ri.se>
Cc: "ace@ietf.org" <ace@ietf.org>, Cigdem Sengul <cigdem.sengul@nominet.uk>, Anthony Kirby <Anthony.Kirby@nominet.uk>, Paul Fremantle <paul.fremantle@port.ac.uk>
Content-Type: multipart/alternative; boundary="0000000000006eff5c056c447c5f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/VRBZbJPhheDaBC_U5MsZXy613UI>
Subject: Re: [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 20:31:29 -0000
Hello Ludwig, Thank you for reviewing our draft. We will start working on addressing your comments asap. Thanks, --Cigdem On Tue, May 15, 2018 at 10:04 AM, Ludwig Seitz <ludwig.seitz@ri.se> wrote: > 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 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >
- 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