Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03

Daniel Migault <daniel.migault@ericsson.com> Wed, 29 January 2020 14:54 UTC

Return-Path: <mglt.ietf@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 B5AF3120128; Wed, 29 Jan 2020 06:54:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZBqgXY9yJvxl; Wed, 29 Jan 2020 06:54:12 -0800 (PST)
Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (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 949CA120118; Wed, 29 Jan 2020 06:54:12 -0800 (PST)
Received: by mail-vs1-f54.google.com with SMTP id g15so10604014vsf.1; Wed, 29 Jan 2020 06:54:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4rLjBAf/U5NzaVKZ+vOuZu3/esY0xcdv+uQfDq5Ixpk=; b=QUZVdmXpMu85mdGrOiFXNd9H9Pkrs0PU6Pw0/9KLdXs5R0qq8nuZn6r6rygZApS/sL MTrgnCg8sOUUInuaTsd5CXxZM95pJ4qdqJELgQecrVAerjO82SY4Dm+thUO+HzjFc0rf J9R9e1EBsa0K8tPmfjr8UaarrHQ+eq1nV8oybbq+5q2drJWxrN6d/mUeQKa+6GZ42Thz XUtwMF/sql2ZEHdzmkDautGpskPI8Ol/jNptZMu9nI5oOlyiHaxtBztP8X2fvrTLUuzI ddfsgO0FoLiKnrq171nY30LnlrhsLtAK1FoARvMix7Dj6+7hoYiMgbz/4NG9VsuvN54V j2iw==
X-Gm-Message-State: APjAAAVI3bFQsnYU8o7TFOzNZXTTVCyK7TbbuzPEZmBGuge5AbyzN0LK Tk3n9vFOSzYAw4qNDlvBn9sixMZoqKAFm5E67KhR4Mac
X-Google-Smtp-Source: APXvYqzbiIDWiBJUHPakhfBKiLKWf/OMUKQXZhS1ZrERvlGXNL/P0B/MKjpzM3ntSBj5qSEhOknCNNVQpZqjamnAxls=
X-Received: by 2002:a67:b309:: with SMTP id a9mr16802759vsm.97.1580309651136; Wed, 29 Jan 2020 06:54:11 -0800 (PST)
MIME-Version: 1.0
References: <007401d5c0f3$6e80d320$4b827960$@augustcellars.com> <CAA7SwCNfzur2=VJ9O+76vWBeECn62EdREXRbOgK8=O-LgYUa_Q@mail.gmail.com> <012301d5cda8$a5c74f00$f155ed00$@augustcellars.com> <CADZyTk=FsD=shb7ciaXW8hUJu9DpDPn29dqFhZJu+yvZPXRKGw@mail.gmail.com> <CAA7SwCN7M8P88p=U1-dtb5FJ-0M8Vms2hiLfTdeLKhx-ZRhESw@mail.gmail.com>
In-Reply-To: <CAA7SwCN7M8P88p=U1-dtb5FJ-0M8Vms2hiLfTdeLKhx-ZRhESw@mail.gmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 29 Jan 2020 09:53:59 -0500
Message-ID: <CADZyTk=fvqDZrJ9cGweB7r6WSgD5_tO+5ny8AfDwEph-uwnJKQ@mail.gmail.com>
To: Cigdem Sengul <cigdem.sengul@gmail.com>
Cc: Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>, draft-ietf-ace-mqtt-tls-profile@ietf.org, Jim Schaad <ietf@augustcellars.com>, Ace Wg <ace@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000064253a059d48834f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/bC-ErQG5hC_ta66cEGnaflxBC28>
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 29 Jan 2020 14:54:18 -0000

Thanks for the comments, please see my responses. I have not answered
comments I had nothing to add in order to ease the readability of the
thread. That said, I thank you for addressing them.

In my opinion, there are a few comments, that needs the WG to state how to
address those, and I hope the interim meeting will help. My expectation is
that the next version will need to reviewed by a wider audience in the WG
so the draft can be moved forward.

Yours,
Daniel

On Wed, Jan 29, 2020 at 7:10 AM Cigdem Sengul <cigdem.sengul@gmail.com>
wrote:

> Thank you for your review Daniel.
> Comments inside.
>
> On Tue, Jan 21, 2020 at 6:23 PM Daniel Migault <daniel.migault=
> 40ericsson.com@dmarc.ietf.org> wrote:
>
>>
>>    In this document, topics, more specifically, Topic Names, are treated
>>    as resources.  The Clients are assumed to have identified the
>>    publish/subscribe topics of interest out-of-band (topic discovery is
>>    not a feature of the MQTT protocol).  A resource owner can pre-
>>    configure policies at the AS that give Clients publish or subscribe
>>    permissions to different topics.
>>
>> <mglt> AS should be expanded. As we introduce the ACE terminology, it
>> might be
>> good to specify if "resource" terminology is used related to RS. I am not
>> entirely sure... but if that is the case, it might be good to specify that
>> these resources are hosted on a Resource Server.
>>
>> Though this is a very minor issue, there are multiple double
>> spaces.</mglt>
>>
>
> [CS] AS - Fixed.
> For RS related comment, added to the previous paragraph: "The MQTT Broker,
> which acts as the Resource Server (RS), is responsible
> distributing the messages published by the publishers to their
> subscribers.
> Blank spaces: Noted, will take care of them in the next version.
>
>
>>    Clients use an access token, bound to a proof-of-possession (PoP) key
>> to
>> authorize with the MQTT Broker their connection and publish/ subscribe
>> permissions to topics.
>>
>> <mglt>Though I am an not english native, I have difficulties to parse "to
>> authorize with the MQTT Broker..." This is what I understand from the
>> draft:
>> The permission to publish/suscbribe topics on a given MQTT Broker are
>> defined
>> by an  access token, bound to a proof-of-possession (PoP) key. The token
>> is
>> provided by the AS and used by the Client's to access the RS. </mglt>
>>
>
> [CS] OK. Changed to "Clients prove their permission to publish/subscribe
> to topics hosted on an MQTT broker using an access token, bound to a
> proof-of-possession (PoP) key."
> Is this more clear.
>
>>
>>  In the context of this ACE profile, the Broker acts as
>> the Resource Server (RS).  In the rest of the document the terms "RS" and
>> "Broker" are used interchangeably.  This document describes how to
>> authorise
>> the following exchanges between the Clients and the Broker.
>>
>> <mglt>How to authorize... The wording sounds to me a bit strange though I
>> would
>> not pretend to have a better wording either, wouldn't associated
>> permission
>> more in line with the ACE framework ?</mglt>
>>
>
> [CS] Fixed authorize. Kept the rest the same....
>
>
>
>>
>>    o  Connection requests from the Clients to the Broker
>>
>>    o  Publish requests from the Clients to the Broker, and from the
>>       Broker to the Clients
>>
>>    o  Subscribe requests from Clients to the Broker
>>
>>    This document does not protect the contents of the PUBLISH message
>>    from the Broker, and hence, the content of the the PUBLISH message is
>>
>> <mglt>the the</mglt>
>>
>
> [CS] Fixed.
>
>>
>>
>> Sengul, et al.            Expires June 22, 2020                 [Page 3]
>>
>> Internet-Draft           MQTT-TLS profile of ACE           December 2019
>>
>>
>>    not signed or encrypted separately for the subscribers.  This
>>
>> <mglt>
>> It is the first time the document mentions PUBLISH. It would worth maybe
>> to
>> specify it is an MQTT message.
>>
>> I am wondering if encrypted stands for the opposite of not signed. If so,
>> a
>> document may be signed but not encrypted.  I also understand that the
>> security
>> is performed by TLS or similar mechanism. If that is correct, it might be
>> clarifying to mention this is what we have in mind.  It is also unclear
>> why we
>> introduce subscribers and not Clients. Are we excluding intentionally the
>> publishers?
>>
>> Maybe wording around: the PUBLISH message is unprotected or protected
>> via TLS (or equivalent mechanisms) for each Client's session. .
>>
>> What is unclear to me is what the "content" of the PUBLISH message
>> represents.
>> If that is the data associated to the topic. I would have expected
>> authentication being performed by a signature mechanism and the signature
>> being
>> generated by the content owner, that is (I expect) the publisher. I think
>> that
>> data protection is out-of scope as well as MQTT based mechanisms as MQTT
>> recommends TLS.
>>
>> </mglt>
>>
>> [CS] Preceded the sentence with "Clients use MQTT PUBLISH message to
> publish to a topic."
>
> What I meant was protecting the payload from the Broker. At the moment,
> the broker is the end of TLS sessions for clients.
> So, the Broker does see all the payloads -> if we would like to introduce
> "confidential topics", which is the pub-sub document Francesca is working
> on,
> then the payload needs to be encrypted.  Publishers do not sign the
> payload either.
>
> Not excluding publishers really, it is just that the subscribers are the
> recipients who would need to check the signature, decrypt if things were
> protected.
> Reworded as: "The document does not protect the payload of the PUBLISH
> message from the Broker, and hence, the payload is not signed or encrypted
> specifically for subscribers."
>
>
>
>>
>>    functionality may be implemented using the proposal outlined in the
>>    CoAP Pub-Sub Profile [I-D.palombini-ace-coap-pubsub-profile].
>>
>>
>>    To provide communication confidentiality and RS authentication, TLS
>>    is used and TLS 1.3 is RECOMMENDED.  This document makes the same
>>    assumptions as the Section 4 of the ACE framework
>>    [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with
>>    the AS and setting up keying material.
>>
>> <mglt> Is registration appropriated for the RS to the AS? </mglt>
>>
>
> [CS] I am not sure I understand the question.
> This was referring to " It is also assumed that the RS has been registered
> with the AS,
>    potentially in a similar way as the client has been registered with
>    the AS." in Section 4 of draft-ietf-ace-oauth-authz.
>>
>>
>> <mglt2>
I think. I was wondering whether it is common to consider registration for
RS, as I probably read subscription rather then registration. I think that
is fine. Registration is performed to the Broker to receive topics (Client)
or to publish topics (RS).
<mglt2>

>    While the Client-Broker
>>    exchanges are only over MQTT, the required Client-AS and RS-AS
>>    interactions are described for HTTPS-based communication, using
>>    'application/ace+json' content type, and unless otherwise specified,
>>    using JSON encoding.  The token may be a reference, or JSON Web Token
>>    (JWT).  For JWT tokens, this document follows RFC 7800 [RFC7800] for
>>    PoP semantics for JWTs.
>>
>> <mglt>For my own understanding I would like to check if reference stands
>> for
>> reference to an access token or something else.   </mglt>
>>
>>
> [CS] This is what the  draft-ietf-ace-oauth-authz  says in Section 3.1,
> page 9: "The token is either a simple reference, or a structured
>       information object."
>
>   <mglt2>
I agree this is in draft-ietf-ace-oauth-authz, but it is still unclear to
me what the reference can be. It is an ID privately agreed between the
parties, an URL,...
</mglt2>

>  The Client-AS and RS-AS may also be other
>>    than HTTPS e.g., CoAP or MQTT.
>>
>> <mglt>I suspect some words are missing. Maybe "may also use other
>> transport
>> protocol to carry the JWT.<.mglt>
>>
>
> [CS] Corrected to: "The Client-AS and RS-AS  MAY also use protocols other
> than HTTP e.g., CoAP or MQTT."
>
>>
>> 1.2.  ACE-Related Terminology
>>
>>    The terminology for entities in the architecture is defined in OAuth
>>    2.0 RFC 6749 [RFC6749] such as "Client" (C), "Resource Server" (RS)
>>    and "Authorization Server" (AS).
>>
>>    The term "Resource" is used to refer to an MQTT Topic Name, which is
>>    defined in Section 1.3..  Hence, the "Resource Owner" is any entity
>>    that can authoritatively speak for the topic.
>>
>> <mglt>The introduction is using "resource", I propose the introduction
>> text is
>> coherent with the Terminology used latter in the document. </mglt>
>>
>
> [CS] Changed to "resource".
>
>
>>
>> 1.3.  MQTT-Related Terminology
>>
>>    The document describes message exchanges as MQTT protocol
>>    interactions.  The Clients are MQTT Clients, which connect to the
>>    Broker to publish and subscribe to Application Messages, labeled with
>>    their topics.  For additional information, please refer to the MQTT
>>    v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1
>>    - the OASIS Standard [MQTT-OASIS-Standard].
>>
>>    MQTTS
>>            Secured transport profile of MQTT.  MQTTS runs over TLS.
>>
>> <mglt> I am wondering how appropriated it is to have sentence without
>> verb. I
>> probably think it is safer to use verb.</mglt>
>>
>
> [CS] In other IETF drafts, I typically see a definition without a verb.
>

<mglt2> correct, I cannot figure out what bothered me while reading the
definitions. Just go through them to check they are fine, while updating
the draft and I will be ok, with what you have.
<mglt2>

>
> e..g,
>  QUIC:  The transport protocol described by this document.
>
>
>>
>>    Broker
>>            The Server in MQTT.  It acts as an intermediary between the
>>            Clients that publishes Application Messages, and the Clients
>>            that made Subscriptions.  The Broker acts as the Resource
>>            Server for the Clients.
>>
>> <mglt>Similar comment as before, there seems to have a missing verb.
>> While
>> Broker is defined, Client is not defined as a special term but instead in
>> the
>> introduction of the section. I am wondering if that would not be cleaner
>> to
>> have Client also be defined. I am also wondering if Clients cannot be
>> designated as subscriber/publisher. Note this is a question I am
>> wondering, and
>> I do not think a specific terminology would be needed. Instead, I would
>> simply
>> suggest, that Clients includes subscribers and publishers as these terms
>> are
>> used later.  </mglt>
>>
>
> [CS] Checking some RFCs, I see it is very common to use sentences like
> below.
> Have the rules of how to write terminology changed?
>
> <mglt>sentence or not does not seem relevant. you are correct.</mglt>


> Added:
> Client: A device or program that uses MQTT. (similar to MQTT
> descriptions).
>
> It's actually important not to designate clients as publisher/subscriber.
> A client should be able to get permissions to subscribe to x, and publish
> to y.
> Assume a client has the role of sending out a summary of all published
> messages.
> It should be able to both publish and subscribe.
>
>
>
<mglt>Thanks for the clarification. That is useful to me. If you think that
coudl be usefull to be added to the definition, feel free to add it. </mglt>


>
>>    Subscription
>>            A subscription comprises a Topic Filter and a maximum Quality
>>            of Service (QoS).
>>
>> <mglt>It might be relevant to specify that subscriptions are associated
>> to one
>> session.  </mglt>
>>
>> [CS} Sure. Added "A subscription is associated with a single session" at
> the end.
>
>
>
>>    Topic Filter
>>            An expression that indicates interest in one or more Topic
>>            Names.  Topic Filters may include wildcards.
>>
>>    MQTT sends various control messages across a network connection.  The
>>    following is not an exhaustive list and the control packets that are
>>    not relevant for authorization are not explained.  These include, for
>>    instance, the PUBREL and PUBCOMP packets used in the 4-step handshake
>>    required for the QoS level 2.
>>
>> <mglt>As a general comment, I would recommend to have the same definition
>> as
>> those provided by MQTTv5. We could clearly mention these are from MQTTv5
>> and
>> are repeated here for the document to self contained. There is probably a
>> balance to find to introduce terms that are not used in this document, so
>> some
>> definitions may be partial using [....]. This is mostly a suggestion.
>> </mglt>
>>
>
> [CS] We actually mostly do that anyway. They are just more concise.
>

<mglt2>I agree there are not major differences, though it might be safer to
be as close as possible.</mglt2>


>
>
>>    CONNECT
>>
>>
>>
>>
>> Sengul, et al.            Expires June 22, 2020                 [Page 5]
>>
>> Internet-Draft           MQTT-TLS profile of ACE           December 2019
>>
>>
>>            Client request to connect to the Broker.  After a network
>>            connection is established, this is the first packet sent by a
>>            Client.
>>
>> <mglt>I understand that network connection means the layers below MQTT. I
>> thing
>> this is confusing and would suggest to maybe remove "After a network
>> connection
>> is established,"</mglt>
>>
>
> [CS] OK. But, if we are following the advice of sticking with MQTT spec
> for definitions, here is what the original says:
> "After a Network Connection is established by a Client to a Server, the
> first packet sent from the Client to the Server MUST be a CONNECT packet".
>
>>
>> <mglt2> My personal comparison - and I do not mean I am representative -
is that the later is clearer. Possible reasons are that the definition in
the draft defines CONNECT as a MQTT connect request which seems to me at
least some how circular as connection at MQTT layer is not defined. The
following sentence introduces network connection, and raised - at least to
me - some questions whether the connection was related to MQTT or underlay
network settings. It is also confusing to discuss MQTT, network layers and
MQTT.
I agree differences are in the details, but I would be inclined to take
advantage of this work already done.
</mglt2>


>>    SUBSCRIBE
>>            The Client subscribe request.
>>
>> <mglt>I would suggest to have similar wording for PUBLISH as for
>> SUBSCRIBE.</mglt>
>>
>
> [CS] Changed to: "Subscribe request sent from a Client".
>
>
>>
>> 2.  Authorizing Connection Requests
>>
>>    This section specifies how Client connections are authorized by the
>>    MQTT Broker.Figure 1 shows the basic protocol flow during connection
>>    set-up.The token request and response use the /token endpoint at the
>>
>> <mglt> I suspect "/" should not be here and that url path is not
>> intended.</mglt>
>>
>>
> [CS] Fixed.
>
>
>> [...]
>>
>> 2.2.1..  Client-Server Authentication over TLS and MQTT
>>
>>    The Client and the Broker MUST perform mutual authentication.
>>
>> <mglt>If I am correct this is also correct for the C-AS.</mglt>
>>
> [CS] Yes, added to the previous section.
> Actually: According to  draft-ietf-ace-oauth-authz: It is also REQUIRED
> that the
>    communicating endpoints perform mutual authentication.
> Should it be repeated in the profile as well?
>
> <mglt>I would suggest yes, otherwise we wonder while the profile only
provide one part of it. </mglt2>

>
>
>>  The
>>    Client MAY authenticate to the Broker over MQTT or TLS.
>>
>> <mglt>My understanding of the sentence above is that the Client MAY
>> authenticate. Unless I am missing something, I would rather see MUST
>> instead.</mglt>
>>
>
> [CS]OK. The previous sentence say the Client MUST authenticate.
> It may use either MQTT  or TLS to authenticate.
> Still, I changed the sentence to:
> "Client MUST authenticate to the Broker either over MQTT or TLS".
>
>
<mglt2>The difference is that we do limit the mechanisms used to
authenticate.</mglt2>

>
>
>>    For MQTT,
>>    the options are "None" and "ace".  For TLS, the options are "Anon"
>>    for anonynous client, and "Known(RPK/PSK)" for Raw Public Keys (RPK)
>>    and Pre-Shared Keys (PSK), respectively.  Combined, the Client
>>    authentication takes the following options:
>>
>>    o  "TLS:Anon-MQTT:None": This option is used only for the topics that
>>       do not require authorization, including the "authz-info" topic.
>>       Publishing to the "authz-info" topic is described in
>>       Section 2.2.2.
>>
>> <mglt>It is a bit unseal to describe unauthenticated channel as mutually
>> authenticated.</mglt>
>>
>
> [CS] Himmm, not sure how to deal with this. This is the first step to the
> Mutual authentication.
> I can take this out describe separately. And then have only 3 options for
> mutual authentication.
> Any thoughts?
>
>
<mglt>I have no strong opinion. The simplest way seems maybe to point out
this is mentioned as a first step to perform the mutual authentication. I
am open to any other ways to solve this. </mglt>

>
>>    o  "TLS:Anon-MQTT:ace": The token is transported inside the CONNECT
>> message,
>> and MUST be validated using one of the methods described in Section 2.2.2.
>> This option also supports a tokenless connection request for AS discovery.
>>
>>    o  "TLS:Known(RPK/PSK)-MQTT:none": For the RPK, the token MUST have
>>       been published to the "authz-info" topic.  For the PSK, the token
>>       MAY be, alternatively, provided in the "psk_identity".  The TLS
>>       session set-up is as described in DTLS profile for ACE
>>       [I-D.ietf-ace-dtls-authorize].
>>
>> <mglt> Just to me sure I understand it properly. In this case the RPK or
>> PSK is
>> the one contained into the token. DTLS authenticate the TLS client via a
>> CertificateRequest. Other information related to the topic are performed
>> by the
>> MQTT. In order to perform perform the TLS authentication, the token with
>> the
>> existing key needs to be found. The Broker upon receiving a CONNECT needs
>> to
>> keep track of the used token.  </mglt>
>>
>
> [CS] We use TLS - give the DTLS profile as an example of the set-up for
> ACE.
> Yes: The token is validated, the client is authenticated, a secure TLS
> channel with them using the info in the token.
> The topic authorisation happens when the client tries to publish or
> subscribe.
>
>
>>
>>    o  "TLS:Known(RPK/PSK)-MQTT:ace": This option SHOULD NOT be chosen.
>>       In any case, the token transported in the CONNECT overwrites any
>>       permissions passed during the TLS authentication.
>>
>> <mglt>My understanding is that the same access token would be used.
>> Collision
>> would occurs when different access token would be used. However, when
>> authentication is performed using DTLS, the Broker, as I would understand
>> it,
>> keeps track of the used token, which should avoid the overwriting
>> rules.</mglt>
>>
>
> [CS] This statement was in case two different tokens were used, the last
> valid token overwrites the former.
> i.e., u can not add to your permissions - there is no union.
>
>
<mglt2> I have the impression that the requirements is to ensure one token
is being used when more token are available. The document provides one way
to do, but does not leave room to other mechanisms or implementation. I am
wondering if that is something we want or if I am missing
something.</mglt2>

>
>>    It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace.
>>
>>    The Broker MUST be authenticated during the TLS handshake.  If the
>>    Client authentication uses TLS:Known(RPK/PSK), then the Broker is
>>    authenticated using the respective method.
>>
>> <mglt>I understand that when the server is authenticated using RPK, the
>> server
>> needs to be authenticated using RPK, but it is unclear why standard WPKI
>> would
>> not work. I understand that for PSK the same method can be used, though.
>> </mglt>
>>
>> [CS] The language around TLS may have gotten more constrained because I
> wanted to follow roughly
> what DTLS profile for ACE says...
> Though I do not have specific experience with WPKI.
>
> <mglt>needs to be clarified by the WG.</mglt>
>


> 2.2.2.  authz-info: The Authorization Information Topic
>>
>>
>>    The Broker stores and indexes all tokens received to this topic in
>>    its key store similar to DTLS profile for ACE
>>    [I-D.ietf-ace-dtls-authorize].  This profile follows the
>>    recommendation of Section 5.8.1 of ACE framework
>>    [I-D.ietf-ace-oauth-authz], and expects that RS stores only one token
>>    per proof-of-possession key, and any other token linked to the same
>>    key overwrites existing token at the RS.
>>
>> <mglt>I think the intend is to avoid having multiple access token that
>> could
>> have the same PoP with different permissions. Keeping only the latest
>> does not
>> guarantee the client and the broker are considering the same ticket, and
>> MAY
>> force client to perform a two step authentication at any time. In case of
>> rekey
>> or synchronization issues, this might generate more traffic than needed. I
>> would think that keeping track of the access token used by DTLS is safer,
>> the
>> way described here is only one way of doing it. </mglt>
>>
>
> [CS] This is coming from draft-ietf-ace-oauth-authz, Page 37:
>
> This specification RECOMMENDS that an RS stores only one token per
>    proof-of-possession key, meaning that an additional token linked to
>    the same key will overwrite any existing token at the RS.
>
> I would like to follow this recommendation in this profile as it greatly
> simplifies the implementation.
> And, during a long MQTT session, the client may  push new tokens. The
> behaviour should be the new token overwrites the old one.
>
>
<mglt>I understand,  the motivation, maybe we should keep the mechanisms
described as RECOMMENDED only rather than having this normative. That said,
I am fine with what the WG thinks.</mglt>


>
>> 2.2.4.1.  Proof-of-Possession Using a Challenge from the TLS session
>>
>>    For this option, the Authentication Data MUST contain the token and
>>    the keyed message digest (MAC) or the Client signature.  The secret
>>    that is used for the proof-of-possession calculation, i.e., to
>>    calculate the keyed message digest (MAC) or the Client signature, is
>>    obtained using a TLS exporter ([RFC5705] for TLS 1.2 and for TLS 1.3,
>>    Section 7.5 of [RFC8446]).
>>
>> <mglt>Just to make sure I follow, the secret is signed or MACed without
>> being
>> sent. The secret is not used to derive the key used to the signature or
>> MAC.
>> Instead this key is in the access token.  If I am correct, the use of MAC
>> or
>> signature is defined by the PoP symmetric or asymmetric. Correct ? I
>> believe
>> the text could be clearer.  </mglt>
>>
>
> Yes, correct. Added to the github issue to make this text clearer:
> https://github.com/ace-wg/mqtt-tls-profile/issues/41
>
>
>>
>> 2.2.4.2.  Proof-of-Possession via Broker-generated Challenge/Response
>>
>>    For this option, the RS follows a Broker-generated challenge/response
>>    protocol.  The success case is illustrated in Figure 4.  If the
>>    Authentication Data only includes the token, the RS MUST respond with
>>    an AUTH packet, with the Authenticate Reason Code set to '0x18
>>    (Continue Authentication)'.  This packet includes the Authentication
>>    Method, which MUST be set to 'ace' and Authentication Data.  The
>>    Authentication Data MUST NOT be empty and contains an 8-byte nonce as
>>    a challenge for the Client.  The Client responds to this with an AUTH
>>    packet with a reason code '0x18 (Continue Authentication)'.
>>    Similarly, the Client packet sets the Authentication Method to 'ace'.
>>    The Authentication Data in the Client's response contains a client-
>>    generated 8-byte nonce, and the signature or MAC computed over the RS
>>    nonce concatenated with the client nonce.  Next, the token is
>>    validated as described in Section 2.2.5.
>>
>>
>> <mglt>I do not see exporters being involved, and if that is correct there
>> is no
>> channel binding. As DTLS is mandatory, wouldn't it be possible to add the
>> exporter to the nonces. This may also be used to increases the randomness
>> of
>> the nonces</mglt>
>>
>>
> [CS] I have to admit, I have gone back and forth about this.
> Some implementers have commented not to have  TLS exporter support...
>
> <mglt> Unless there is a clear decision from the WG, I believe this should
> discussed by the WG, and maybe documented in the document or the security
> considerations. </mglt>
>
>
>> [...]
>>
>> 3.1.  PUBLISH Messages from the Publisher Client to the Broker
>>
>>    On receiving the PUBLISH message, the Broker MUST use the type of
>>    message (i.e., PUBLISH) and the Topic name in the message header to
>>    match against the scope string in the cached token or its
>>    introspection result.  Following the example above, a client sending
>>    a PUBLISH message to 'a/topic3' would be allowed to publish, as the
>>    scope includes the string 'publish_+/topic3'.
>>
>>    If the Client is allowed to publish to the topic, the RS must publish
>>
>> <mglt>While "must" may not be necessary, if used, it could be
>> normative.</mglt>
>>
>
> [CS] I tried to keep MQTT musts as "must" and  this profile's musts as
> MUST.
> Wouldn't that be acceptable?
>
>
<mglt> I am fine with this alternative, so maybe you should clearly
indicate in the section that this document is not normative to MQTT, you
only use the normative language for the profile. If that is the only
section, please add this to the section otherwise in the terminology
section. It is good you keep must then, and implementer will interpret them
a MUST without the authority for them.</mglt>



>
>> 3.2.  PUBLISH Messages from the Broker to the Subscriber Clients
>>
>>    To forward PUBLISH messages to the subscribing Clients, the Broker
>>    identifies all the subscribers that have valid matching topic
>>    subscriptions (i.e., the tokens are valid, and token scopes allow a
>>    subscription to the particular topic).  The Broker sends a PUBLISH
>>    message with the Topic name to all the valid subscribers.
>>
>>    RS MUST stop forwarding messages to the unauthorized subscribers.
>>
>> <mgtl>I do not think they should have started. I am wondering if
>> s/stop/NOT/
>> would not be better.</mglt>
>>
>
> [CS] Fixed.
>
>
>>
>> 4.  Token Expiration and Reauthentication
>>
>>
>>    To re-authenticate, the Client sends an AUTH packet with reason code
>>    '0x19 (Re-authentication)'.  The Client MUST set the Authentication
>>    Method as 'ace' and transport the new token in the Authentication
>>    Data.  The Client and the RS go through the same steps for proof of
>>    possession validation as described in Section 2.2.  The Client SHOULD
>>    use the same method used for the first connection request.
>>
>> <mglt>I am wondering if there are good reasons for SHOULD. I would say
>> that
>> using multiple authentication method with different level of trust SHOULD
>> be
>> avoided. </mglt>
>>
>
> [CS] I am not sure any more if that sentence is necessary....
>
> Thanks for your review again,
> --Cigdem
>
>
>
>>
>> On Fri, Jan 17, 2020 at 9:40 PM Jim Schaad <ietf@augustcellars.com>
>> wrote:
>>
>>>
>>>
>>>
>>>
>>> *From:* Cigdem Sengul <cigdem.sengul@gmail.com>
>>> *Sent:* Tuesday, January 14, 2020 8:25 AM
>>> *To:* Jim Schaad <ietf@augustcellars.com>
>>> *Cc:* draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg <ace@ietf.org>
>>> *Subject:* Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03
>>>
>>>
>>>
>>> Thank you for this review, Jim.
>>>
>>> Responses inline.
>>>
>>>
>>>
>>> On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad <ietf@augustcellars.com>
>>> wrote:
>>>
>>>
>>>
>>>
>>> 2.2.2 - I am unclear under what circumstances you could end put with a
>>> token
>>> which does not parse when processing a PUBLISH message.  If the token
>>> cannot
>>> be parsed at connection time, that I can understand.  However having
>>> parsed
>>> the token then it does not make sense that the token becomes not
>>> parsable at
>>> the time of publishing.  Am I missing something?
>>>
>>>
>>>
>>> [CS] There is a misunderstanding. The PUBLISH message refers to the
>>> actual PUBLISH message to the "authz-info" topic which contains the token
>>> i.e., this may not parse to a token. (The PUBLISH message is not for other
>>> messages that are permissioned in the token.)
>>>
>>> The client connects (without much security), publishes the token to the
>>> public "authz-info" topic, which only the broker can read.
>>>
>>> Then, disconnects, and tries to connect with ace security.
>>>
>>>
>>>
>>> Since MQTT v5 can return error messages in response to PUBLISH messages,
>>> here, this is used to signal to the publisher that there is something wrong
>>> with its token.
>>>
>>>
>>>
>>> Added: https://github.com/ace-wg/mqtt-tls-profile/issues/38
>>>
>>>
>>>
>>> [JLS] Ok – I see where I got mixed in in reading this.  I think this may
>>> just be a problem on my end and you might not be able to do this better.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2.2.4 - I am having a problem with trying to parse the content of the
>>> AUTH
>>> property.  I have no problems with 2.2.4.3 because this is a zero length
>>> sequence of bytes.  However for 2.2.4.1 and 2.2.4.2 there is a token
>>> (possibly binary with no length prefix) followed by an optional binary
>>> cryptographic value.  For introspection, I would need to figure out the
>>> length of the token before I could make a guess at the length of the
>>> cryptographic value.  However given that there is no divider this does
>>> not
>>> seem possible.  This may also become a problem for the response from the
>>> client in the event that there is a change from an 8-byte nonce to a
>>> variable length one.
>>>
>>>
>>>
>>> [CS] Not specified a  format, because I  thought we discarded the idea
>>> of using the variable-length nonce based on the meeting in Singapore.
>>>
>>> What would you suggest - introduce a specific format to accommodate
>>> variable length?
>>>
>>> length_of_token+binary data for token+(the rest is cryptographic value)?
>>>
>>>  https://github.com/ace-wg/mqtt-tls-profile/issues/40
>>>
>>>
>>>
>>> [JLS] I put in a comment on the github issue about what I was looking
>>> for.  Additionally,  my only possible problem with the fixed size nonce is
>>> that the IESG or Security Directorate down the line may decide that it is
>>> too small for some reason (16 bytes signed by a 521-bit (65+ byte key)).
>>> Some might consider it to be small for a SHA-256 MAC operation.  Not the
>>> exact same situation here for TLS as it is not really a compact protocol.
>>> But it may considered to be for the IoT variants being used.  I don’t know.
>>>
>>>
>>>
>>>
>>>
>>> Jim
>>>
>>>
>>>
>>>
>>> I am going to play with something else.  I am sure I will find other
>>> issues
>>> at a different time.
>>>
>>>
>>>
>>> Thank you for your review. Much appreciated.
>>>
>>> --Cigdem
>>>
>>>
>>>
>>>
>>> Jim
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Nits:
>>> Section 2 Para 1 s/Broker.Figure 1/Broker.  Figure 1/
>>> Section 2 Para 1  s/setup.The/setup.  The/
>>> Section 2.2.2 Last Para s/when the AS/when the RS/
>>>
>>>
>>> _______________________________________________
>>> Ace mailing list
>>> Ace@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ace
>>>
>>> _______________________________________________
>>> Ace mailing list
>>> Ace@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ace
>>>
>> _______________________________________________
>> Ace mailing list
>> Ace@ietf.org
>> https://www.ietf.org/mailman/listinfo/ace
>>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>