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
>