Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01

Daniel Migault <daniel.migault@ericsson.com> Wed, 30 October 2019 17:07 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 62FFE120888; Wed, 30 Oct 2019 10:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, 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 gwdCtgAIpB8g; Wed, 30 Oct 2019 10:06:58 -0700 (PDT)
Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (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 221031208A9; Wed, 30 Oct 2019 10:06:55 -0700 (PDT)
Received: by mail-vs1-f47.google.com with SMTP id w25so2155941vso.4; Wed, 30 Oct 2019 10:06:55 -0700 (PDT)
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=j23HXhvFO4/uhqs7HjCkLsLtpqpNhZbluFDfp2bh0SI=; b=avFXWLWZLlXvkYjSkJ96lhls+xdyCTQ/7FYrXlB4HQ7AWJxnkIq0JsT/n1W0FabmzL QCYuVLZH8taZKSltXK5XtTJdb6UUVRXEDEWXv7Z4vCrY26hkaWEc/dA55iJw0CRUqSTn VkqCbVHp27MLyZDE5sPmND45UmJPp/NpJH/YSJtbT7+L8ua/oWyXSYWvoJ0TCXhAyAq6 pm5Q1b1GLRBt2RzVs+ZtQPOv97anAb+hZ8e5AXW1w5dcUuhkJmELG3V6UVKZZgkMZrL+ 5bQfILBLtaCjCenfn2BCr8MJIqsgd8gX1gb6TTlKYpzYTRzF2iE/dNAbSUdsJBCqR9ie PHIA==
X-Gm-Message-State: APjAAAVYXU7cCfA5H+28WtKkHQrhvsVwBpKpHaM0Daz0DxzLKKnDr8zZ HIzQZyCQ34+TmEPkcgAwHdccMmqyVuIdN6gvvBw=
X-Google-Smtp-Source: APXvYqyQgkr/l8iviNOtwA/jisC+8WzDK5jkHig79InwAuk5+HVqtxBfbnFFXCSflrTe2PJEf50hbzHhfXbF60two14=
X-Received: by 2002:a05:6102:1178:: with SMTP id k24mr270846vsg.97.1572455213779; Wed, 30 Oct 2019 10:06:53 -0700 (PDT)
MIME-Version: 1.0
References: <021c01d5839c$d53206a0$7f9613e0$@augustcellars.com> <CAA7SwCM62Uuk5yOCKAYO+jhZuP2LkOrH+38qJxkzePRV0S8E1g@mail.gmail.com> <033101d5851b$30a41ad0$91ec5070$@augustcellars.com> <CADZyTkndTgn=tXS5+rsSehb_+LEkxEWwMJ9iTeeUu8uhnEsj3g@mail.gmail.com> <CAA7SwCP_Vrqq-thTrmhvKvhL94JMy5Uv1pJZQeEe5QjDcEzmBg@mail.gmail.com>
In-Reply-To: <CAA7SwCP_Vrqq-thTrmhvKvhL94JMy5Uv1pJZQeEe5QjDcEzmBg@mail.gmail.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 30 Oct 2019 13:06:42 -0400
Message-ID: <CADZyTknSdUfa7zstex+Cv=fi3j8+=CsWX-16_HrifyXceMc=TA@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@ietf.org
Content-Type: multipart/alternative; boundary="000000000000714ec0059623c27d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/RVdiqHjiUNNMwgTJ04swu3m5XPU>
Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01
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, 30 Oct 2019 17:07:03 -0000

Thank you for the response. Feel free to publish the updated version.
Please see my comments inline.
Yours,
Daniel

On Wed, Oct 30, 2019 at 12:13 PM Cigdem Sengul <cigdem.sengul@gmail.com>;
wrote:

> Thank you for your comments Daniel (prefixed [CS])
> My comments are inside. I've also created the -v-02-WIP branch for the
> work in progress based on your and Jim's comments.
>
> On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault <daniel.migault=
> 40ericsson.com@dmarc.ietf.org>; wrote:
>
>> HI,
>>
>> Thanks for sending an update. Please find my comments of the draft.
>>
>>    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 establishing of keying material.
>>
>> <mglt> The document seems mostly focuses on the latest version of MQTT,
>> I am wondering if we could encourage similarly the use of the latest
>> version of TLS that is 1.3 at the time of writing.
>>
>> It seems AS as not been defined previously, so maybe it should be
>> expanded there.
>> </mglt>
>>
>
> [CS] Can add a similar recommendation for TLS 1.3.
> AS is expanded.
>
>
>
>>
>>    MQTTS
>>            Secured transport profile of MQTT.  MQTTS runs over TLS.
>>            The Server in MQTT acts as an intermediary between
>>            Clients that publishes Application Messages, and the Clients
>>            that made Subscriptions.  The Broker acts as the Resource
>>            Server for the Clients.
>>
>> <mglt>publishes</mglt>
>>
> [CS] Fixed.
>
>
>
>>
>>    Subscription
>>            A subscription comprises a Topic Filter and a maximum Quality
>>            of Service (QoS).
>>
>> <mglt>Maybe that would be clearer to specify QoS level as well.</mglt>
>>
>
> [CS] Added.
>
>
>
>>    PINGREQ
>>            A ping request sent from a Client to the Broker.  It signals
>>            to the Broker that the Client is alive, and is used to
>>            confirm that the Broker is still alive.
>>
>> <mglt>It may look a bit strange to have PINGREQ without PINGRESP. You
>> might also indicate the keep alive period is provided in the
>> CONNECT</mglt>
>>
>
> [CS] Added PINGRESP, clarified the Keep Alive period is set in the CONNECT
> in the definition of PINGREQ.
>
>
>>
>>    Will
>>            An application message published by the Server after the
>>            network connection is closed in cases where the network
>>            connection is not closed normally.  If the Will Flag is set,
>>            then the payload of the CONNECT message has information about
>>            the Will.  The Will consists of the Will Properties, Will
>>            Topic, and Will Payload fields in the CONNECT message.
>>
>> <mglt>
>> The first sentence seems to be related to the Will message while the
>> intent, I suppose of teh definition was to define the generic conpet of
>> Will. It might be clearer to expose the principle of the wil, that is a
>> server sends a given message in case a client is disconnected
>> improperly.   It might be clearer to mention explicitly there is a Will
>> "concept" that is implemented a WillFlag WillQoS, WillRetain in the
>> CONNECT header as well as other Will Properties and Will Messages. This
>> mostly consists in the last sentence being moved up.
>> </mglt>
>>
>
> [CS] I reworded it - let me know if it is more clear.
>
will have a look.

>
>> 2.  Protocol Interactions
>>
>>    This section describes the following exchanges between Clients, the
>>    Broker, and the Authorization Server according to the MQTT v5.0.
>>
>> <mglt> Though english is not my first language, I have the impression the
>> text can be interpreted as MQTT enables clients to establish session
>> which does not seems correct to me. The text that follows clarifies this
>> as well.
>> </mglt>
>>
>
> [CS] Neither mine, I reworded that as: "Authorizing connection requests
> from the Clients to the Broker"
> Actually, I also went through the text to reword "establishment" to set-up
> which is simpler.
>
ok

>
>
>>
>> 2.1.  Authorizing Connection Establishment
>>
>> If the
>>    Client is resource-constrained, a Client Authorisation Server may
>>
>> <mglt>I have the impression an AS would be sufficient.</mglt>
>>
>
> [CS] Client Authorization Server was the terminology used in the Actors
> draft - I've removed all other references but wanted to distinguish that
> this is separate than the AS granting access tokens.
> Can just say client's AS?
>
Maybe just explicitly saying it is different would be clearer. I will have
to re-read it.

>
>>    carry out the token request on behalf of the Client, and later,
>>    onboard the Client with the token.  Also, these interfaces may be
>>    implemented using other protocols, e.g., CoAP or MQTT.
>> <mglt>While the introduction and the figure mentions that HTTPS is used
>> as a transport, it might be worth mentioning that HTTPS is being used. I
>> propose to add "...other protocols than HTTPS, e.g ...
>> </mglt>
>>
>
> [CS] Added.
>
>
>> 2.1.1.  Client Token Request to the Authorization Server (AS)
>>
>>    The first step in the protocol flow (Figure 1 (A)) is the token
>>    acquisition by the Client from the AS.  When requesting an access
>>    token from the AS, the Client MAY include parameters in its request
>>    as defined in Section 5.6.1 of the ACE framework
>>    [I-D.ietf-ace-oauth-authz].  The media format is 'application/
>>    ace+json'.  The profile parameter MUST be set to 'mqtt_tls'.  The
>>    OAuth 2.0 AS uses a JSON structure in the payload of its responses
>>    both to client and RS.
>>
>> <mglt> I understand that some parameters are mandatory while other are
>> not. I believe it might be clearer to start with the mandatory
>> parameters (MUST) and then mention that other parameters are optional
>> (MAY). That said, it might be simpler, if that is correct to mention
>> that the token request is as described in Section 5.6.1 of the ACE
>> framework
>>    [I-D.ietf-ace-oauth-authz] with the profile set to "mqtt".
>> </mglt>
>>
>
> [CS]
> When requesting an access token from the AS, the Client follows the token
> request as is
> described in Section 5.6.1 of the ACE framework, however, it MUST set the
> profile parameter to 'mqtt_tls'.
>
>
>>
>>
>>    In the case of an error, the AS returns error responses for HTTP-
>>    based interactions as ASCII codes in JSON content, as defined in
>>    Section 5.2 of RFC 6749 [RFC6749].
>>
>> <mglt>Error messages are handled by OAuth2.0 instead of the ACE
>> framework in order to keep JSON format. I am wondering why do we have
>> the requirement to use ace+cbor only for error message ? It seems to me
>> a bit strange to have error handling defined in another document.
>> </mglt>
>>
>> [CS] Should keep as-is for the time being?
>
That was just a comment. I do not believe you could address this. So yes
let's keep it this way.

>
>
>>
>> 2.1.2.  Client Connection Request to the Broker (C)
>>
>>    This section describes how the Client transports the token to the
>>    Broker (RS) via the CONNECT control message after the TLS handshake.
>>
>> <mglt>If the TLS handshake has already been performed, it would be good
>> to mention which credentials have been used. Obviously, if the token is
>> provided by the CONNECT message, I expect other credentials to be
>> involved. </mglt>
>>
>
> [CS] TLS handshake uses only server-side certificate or RPK. I think this
> is in the text..
> That said there is a Github issue #16
> https://github.com/ace-wg/mqtt-tls-profile/issues/16
> around this, and will provide other clarifications as Jim asked.
>

great!

>
>>    This is similar to an earlier proposal by Fremantle et al.
>>    [fremantle14].  Alternatively, the token may be used for the TLS
>>    session establishment as described in the DTLS profile for ACE
>>    [I-D.gerdes-ace-dtls-authorize].  In this case, both the TLS PSK and
>>    RPK handshakes MAY be supported.
>> <mglt>
>> It would be good to expand Raw Public Keys (RPK). My reading is that
>> this section does not provide a single mechanism for the Client to be
>> authenticated by the Broker, but instead two different ways. I would
>> thus recommend to state it clearly in the introduction of the section..
>> Currently, the section mentions:
>> """
>> This section describes how the Client transports the token to the
>>    Broker (RS) via the CONNECT control message after the TLS handshake.
>> """
>>
>> An then we have a relatively detailed description on how this is
>> performed using TLS. It might be better to say something around the
>> following lines:
>> """
>> This section describes how the Client transports the token to the
>>    Broker (RS). This can be achieved during the TLS KEX or during the
>> MQTT session establishment via the CONNECT control message after the TLS
>> handshake.
>> """
>>
>> I am not sure that MAY is appropriated here. I suspect that if none are
>> supported, this method will not work. As a result, if seems to me that
>> it woudl be more accurate to say that TLS Client and TLS server MUST
>> support the PSK authentication as well as the raw public key.
>>
>> One issue I have with I-D.gerdes-ace-dtls-authorize that is now
>> draft-ietf-ace-dtls-authorize is that it seems to only consider TLS 1.2.
>> With TLS 1.3 PSK and RPK are supported.
>>
>> My interpretation is that PSK provides mutual authentication, but in our
>> case RPK will only authenticate the client. If that is correct, there
>> might be a new to specify how the RS is authenticated by the Client.
>>
>> </mglt>
>>
>
> [CS] I will actually reorganize this section, and hence, this will be more
> clear.
> Added your comment to issue #29, acknowledge that it is linked to #16 as
> well.
>
> I was trying to say the following, but I see that the text is not clear on
> that:
> - MUST: TLS with server validation + token in MQTT CONNECT (will clarify
> server-side certificate/RPK)
> - MAY: TLS with server/client validation with RPK -> token pushed to
> "authz-info"
> - MAY: TLS with server/client validation with PSK -> token in
> psk_identity
>

ok, it is also good to clarify which layer performs the authentication.
Will have a look at the text when the new version is published.

>
>
>>  This option is described in more
>>    detail in Appendix B..
>>
>> <mglt>see my comment in annex B.</mglt>
>>
>>
> [CS] OK.
>
>
>>    After the token acquisition, the Client connects to the RS (Broker)
>>    using the CONNECT message of MQTT over TLS.  For server
>>    authentication, the client MAY either have the ability to receive and
>>    validate a certificate or a raw public key from the Broker.
>>
>> <mglt>I might have missed something, but I thought that PSK/RPK were
>> used to authenticate the Client. While in this case the RPK is used to
>> authenticate the RS, is that the same RPK provided by the AS or another
>> one? </mglt>
>>
>
> [CS] No the RPK was suggested for the RS/Broker authentication.
> As in the core ACE document, we assumed that the client learned either
> the RS's public key
> from the AS. However, I haven't seen in the core document an example of
> how AS
> returns this information to the client.
>

Ok, this might need to be clarified even if that seems outside your
document.

>
>
>
>    For token transport, the RS SHOULD support AUTH (Authentication
>>    Exchange) method.  The RS MAY support token transport via username
>>    and password, which is described in Section 3 for MQTT v3.1.1.  The
>>    rest of this section describes the AUTH method, for which the
>>    username and password flags MUST be set to 0.
>>
>> <mglt>
>> Maybe the reference should be for MQTTv5 instead of MQTTv3.
>> I believe it would be good to specify how setting the password flag
>> interacts with the Authentication method.
>> </mglt>
>>
>>
>> [CS] Do you suggest that if AUTH method is used, MQTTv5 ignores
> password/username?
>
I think I was wondering why MQTT v3 was mentioned rather than v5. It seems
to me that there is no difference in our case - the only change being that
v5 permit password only.

>
>
>
>
>> 2.1.2.1.  Proof-of-Possession over Predefined Field
>>
>>    For this option, the Authentication Data MUST contain the token and
>>    the keyed message digest (MAC) or the Client signature.  To calculate
>>    the keyed message digest (MAC) or the Client signature, the Client
>>    SHOULD apply the PoP key to the CONNECT payload.
>>
>>   <mglt> I have the impression the latest sentence indicates that the
>> Authenticated Data is include din the CONNECT payload. I have however
>> the impression that Authenticated Data is part of the properties which
>> are include din the variable header and not the payload. </mglt>
>>
>
>
> [CS]
> No, the CONNECT payload only includes Client Identifier, Will Properties,
> Will Topic, Will Payload, User Name, Password.
> AUTH data is variable header part of the CONNECT message.
> Anyway, based on also Jim's input, using payload to do the PoP will be
> dropped.
> Jim suggested we use a nonce from the tls_exporter, and apply PoP to that.
> We believe that is the better approach as well. These are related to
> issues #15 ( https://github.com/ace-wg/mqtt-tls-profile/issues/15) and
> #19 (https://github.com/ace-wg/mqtt-tls-profile/issues/19).
>
> That is probably better to bind with the TLS. Please also clarify how it
could work with early_exporters, if that works.

>
> The CONNECT payload
>>    has at least a Client Identifier, and if the Will Flag is set to 1,
>>    may contain Will-related information.  The Client Identifier is a
>>    MUST be a UTF-8 Encoded String (i.e., is prefixed with a two-byte
>>    integer length field that gives the number of bytes in a UTF-8
>>    encoded string itself).  The Client Identifier may be 1-23 UTF-8
>>    encoded bytes, and contain only the characters
>>    "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ".
>>
>> <mglt>
>> For my information I would like to understand the mention of UTF8
>> while only ascii characters are permitted. It seems that teh server MUST
>> accept these and MAY accept others as well as a longer client id. Am I
>> correct ?
>>
>> The nonce coded this way has a randomness of 62**23 =2**138 = 17 bytes
>> </mglt>
>>
>
> [CS] This section will be changed anyway... However, need to familiarize
> to specify how to use Exporter Labels.
> (Server can accept other characters.)
>
> 2.1.4.  The Broker's Response to Client Connection Request
>>
>>    If the RS accepts the connection, it MUST store the token until the
>>    end of connection.  On Client or RS disconnection, the token is
>>    discarded, and the Client MUST provide a token inside each CONNECT
>>    message.
>>
>> <mglt> The latest sentence is unclear to me. I think that disconnection
>> can be interpreted in two way: 1) the disconnection of the will or a
>> DISCONNECT. I believe both are considered. </mglt>
>>
>> [CS] Either Client or Server may initiate a disconnection. In either
> case, the token is discarded.
> The will may be sent if the client set up a will in case of unexpected
> disconnection.
>
> Though it needs to be clarified for instance, if there are retained
> messages, these are sent as long as the token is valid.
> Since the introspection results are cached, this can be still done but
> should clarify unless it gets confusing.
>
> To avoid any confusion, and not to have to discuss these things in that
> section, I reworded as:
> On Client or RS disconnection, the Client is expected to provide a token
> again inside the next CONNECT message.
>
> seems fine

>
>
>>    If the token is not self-contained and the Broker uses token
>>    introspection, it MAY cache the validation result to authorize the
>>    subsequent PUBLISH and SUBSCRIBE messages.  PUBLISH and SUBSCRIBE
>>    messages, which are sent after a connection set-up, do not contain
>>    access tokens.  If the introspection result is not cached, then the
>>    RS needs to introspect the saved token for each request.  The Broker
>>    SHOULD use a cache time out to introspect tokens regularly.
>>
>> <mglt>The latest sentence seems to indicate that result provided as
>> via introspection do not necessarily have a Time to Live which could be
>> interpreted as a commitment from the AS to authorize during that
>> period. If that is possible, it would be appropriated this time out is
>> provided by the AS.
>> I am also wondering why the token expiration cannot be considered as
>> well.
>> </mglt>
>>
>
>
> [CS] This is to handle the situation where the resource owner changes the
> permissions of the Client, which would revoke the token.
> And hence the token exp field would not help.
>  If the RS does not check the token introspection results, it
> will use the token until its expiration time.
> I've considered this more appropriate to be set by the RS as its RS risk
> management.
>

I do understand but I am questioning whether this is necessary or useful.

>
>
>>
>> Appendix B.  The Authorization Information Endpoint
>>
>>    The main document described a method for transporting tokens inside
>>    MQTT CONNECT messages.  In this section, we describe an alternative
>>    method to transport an access token.
>>    The method consists of the MQTT Broker accepting PUBLISH messages to
>>    a public "authz-info" topic.  A Client using this method MUST first
>>    connect to the Broker, and publish the access token using the "authz-
>>    info" topic.  The Broker must verify the validity of the token (i.e.,
>>    through local validation or introspection).  After publishing the
>>    token, the Client disconnects from the Broker and is expected to try
>>    reconnecting over TLS.
>>
>> <mglt>I understand this as an open channel for CONNECT and sending
>> PUBLISHING message. This potentially open the door for DoSing the RS
>> either by openning too many MQTT sessions or by sending too many tokens.
>> I expect this to be mentioned in the security consideration section as
>> well as potential mechanisms to limit these risks.
>> </mglt>
>>
>
> [CS] It is indeed mentioned in this paragraph in the security
> consideration section.
> "The RS may monitor Client behaviour to detect potential security
> problems, especially those affecting availability.
>  These include repeated token transfer attempts to the public "authz-info"
> topic, repeated connection attempts,
>  abnormal terminations, and Clients that connect but do not send any data..
>  If the RS supports the public "authz-info" topic, described in Appendix B,
>  then this may be vulnerable to a DDoS attack, where many Clients use the
> "authz-info" public topic
>        to transport fictitious tokens, which RS may need to store
> indefinitely."
>
>
> Thank you for your comments. And will try to address Jim's shortly to be
> able to push another version before the deadline.
>

perfect, the dead line is monday I think.

>
> Kind regards,
> --Cigdem
>
>
>>
>>
>> On Thu, Oct 17, 2019 at 2:47 PM Jim Schaad <ietf@augustcellars.com>;
>> wrote:
>>
>>>
>>>
>>>
>>>
>>> *From:* Cigdem Sengul <cigdem.sengul@gmail.com>;
>>> *Sent:* Thursday, October 17, 2019 4:13 AM
>>> *To:* Jim Schaad <ietf@augustcellars.com>;
>>> *Cc:* draft-ietf-ace-mqtt-tls-profile@ietf.org; ace@ietf.org
>>> *Subject:* Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01
>>>
>>>
>>>
>>> Hello Jim,
>>>
>>> Thanks for this review. I have responded inline.
>>>
>>>
>>>
>>> 1.  Are there any specifics about using ACE over HTTP that need to be
>>> explicitly stated some place.  Some of these things might include:
>>>         a) Must be HTTPS even if encrypted requests/responses are
>>> provided.
>>>         b) What types of validation are permitted/required: anon-anon,
>>> server validation, server & client validation. The latter corresponds to
>>> current DTLS statements.
>>>         c) Are we looking for using the normal HTTP/HTTPS ports or
>>> should we
>>> be using different ports?
>>>
>>>
>>>
>>> >> Agreed. Need to specify that it is HTTPS.
>>>
>>> Mutual authentication and server validation Required.
>>>
>>> Was thinking it would be normal HTTPS ports. Should we consider
>>> different?
>>>
>>> What scenarios should permit anon-anon; anon clients?
>>>
>>>
>>>
>>> [JLS] If you look at my last email I went through this.  Anon-anon is
>>> going to be a bad idea because the server is never validated, however
>>> client anon is fine since you are going to validate the client in the MQTT
>>> protocol.
>>>
>>>
>>>
>>>
>>>
>>>
>>> 4.  Section 2.1.2: It is not clear from the document is a Broker is
>>> going to
>>> also have the possibility of doing a post of the token via HTTPS.
>>> Currently
>>> I would think not, but given that this is documented in OAuth 2.0 as an
>>> option I am not clear.
>>>
>>> >> Do you mean for introspection? Yes, this is a MAY as in the core
>>> document, and so in this one too.
>>>
>>> And if there is an RS-AS interaction, we expect that to be on HTTPS.
>>>
>>> I will try to see where I should clarify in the text.
>>>
>>>
>>>
>>> [JLS] No, I was originally looking at doing an HTTPS post of the token
>>> from the client to the RS.  This was before I figured out that you have an
>>> alternative method of doing this in the MQTT protocol and so it should not
>>> be needed..   Being clear on the fact that this would not be expected is
>>> probably a good idea.
>>>
>>>
>>>
>>>
>>> 7.   In Figure 2, I think the use of Client Identifier is somewhat
>>> confusing.  I think this is supposed to be the token as the Client
>>> Identifier is a different thing in MQTT.  Either that or you need to do a
>>> better job of describing the property block.
>>>
>>>
>>>
>>> OK. I think I should explain MQTT packets better.
>>>
>>> A connect packet has three parts: 1) Fixed header 2) Variable Header and
>>> 3) Payload.
>>>
>>> The variable header may have several properties, and Authentication
>>> Method and Authentication Data are two of these properties.
>>>
>>> According to MQTT Specification:
>>>
>>> The ClientID MUST be present and is the first field in the CONNECT
>>> packet Payload.
>>>
>>> The ClientID MUST be a UTF-8 Encoded String
>>>
>>> A Server MAY allow a Client to supply a ClientID that has a length of
>>> zero bytes, however, if it does so the Server MUST treat this as a special
>>> case.
>>>
>>>
>>>
>>> And this is what is done in the case of a collision:
>>>
>>> If the ClientID represents a Client already connected to the Server, the
>>> Server sends a DISCONNECT packet to the existing Client with Reason Code of
>>> 0x8E (Session taken over)
>>>
>>>
>>>
>>> Is this more clear? If yes, I will try to clarify in text..
>>>
>>>
>>>
>>> [JLS] That is not where I was having a problem.  I was getting confused
>>> by the figure itself.  Labeling the figure better might help.  “MQTT V5.0
>>> CONNECT control message with ‘ace’ authentication method”.  I would rather
>>> not have all of the abbreviations in the title, but I can live with it.
>>>
>>>
>>>
>>>
>>> 8.  If the value of Clean Start or Expiry Interval are not set correct is
>>> the server to fail the connect?
>>>
>>>
>>>
>>> >> Agreed. This should be specified.
>>>
>>> Two options: 1) Do not accept connection or 2) accept the connection but
>>> then never create sessions, and then server  MUST set Session Present
>>> to 0 in the CONNACK packet, indicating
>>>
>>> no session is present.
>>>
>>>
>>>
>>> This basically makes Clean Start flag meaningless.
>>>
>>> If this is better than client MUST be setting those parameters
>>> correctly, then we can go this way.
>>>
>>> Any thoughts?
>>>
>>>
>>>
>>> [JLS] I don’t really care one way or the other.  Given that there is the
>>> return value in the CONNACK, I think that a simple statement that the flag
>>> is set to 0 regardless of the value coming in.
>>>
>>>
>>>
>>>
>>> 10. Section 2.1.2.1 - I am having a problem computing the MAC over the
>>> payload of the CONNECT message.  The password where the value is placed
>>> is
>>> included in the payload and I am not clear if it should be computed up to
>>> that value or if a fixed value should be used for the computation.
>>>
>>>
>>>
>>> >>OK. I think it got muddled because I was trying to find a solution for
>>> a scenario where the ClientId is used across sessions, and hence, not
>>> random.
>>>
>>>
>>>
>>> Two cases.
>>>
>>> 1) Client ID uniquely random across each Client connection attempt to
>>> Broker: MAC over Payload - Payload begins with ClientID and MAY include
>>> Will Properties if Client indicated that it will have a will.
>>>
>>> 2) Client ID NOT uniquely random: MAC over Authentication Data.
>>>
>>>
>>>
>>> It may be best to choose one method and just say MUST always have a
>>> nonce in Authentication Data, and MAC is computed over that?
>>>
>>>
>>>
>>> [JLS] Lets step back and look at the problem I think you are trying to
>>> solve.
>>>
>>>    - If you are trying to make sure that there is not a replay of the
>>>    signature, then this would require that the server keep track of the list
>>>    of nonce values that the client has provided.
>>>    -  If you are trying to make sure that the signature is “fresh” then
>>>    the server would need to be able to provide some type of data as part of
>>>    the value being signed.  As I think I have said before the latter can be
>>>    satisfied by getting your nonce value from the TLS session using a
>>>    tls-exporter.
>>>
>>>
>>>
>>> If neither of these problems is trying to be solved, then there is no
>>> need for the nonce at all.
>>>
>>>
>>>
>>>
>>>
>>> 11. I am worried about the text on the Client Identifier in this section.
>>> It is not clear to me that having the client generate a random value for
>>> this field is good just in terms of the possibility of collisions
>>> occurring
>>> on the server.  The text in the MQTT 5.0 document appears to say that
>>> this
>>> is more interesting for the situation of getting back state that was
>>> left on
>>> the server after a disconnect and not so much for a clean session.
>>>
>>>
>>>
>>> >> Yes, but as I explained for comment 7, in MQTT, the typical case is
>>> the client provides its id.
>>>
>>> However, to cater to all requirements and all implementation
>>> possibilities, maybe it is best to just use a nonce as explained for
>>> comment 10 and not tie anything to client id.
>>>
>>>
>>>
>>> Previously, when we were writing the draft for MQTT v3.1.1 we wanted to
>>> provide a solution that uses the available fields in the CONNECT packet as
>>> much as possible; without
>>>
>>> introducing any new fields. This was because of the constraints of the
>>> MQTT v3.1.1. MQTT v5 gives us more options to implement this better.
>>>
>>>
>>>
>>> For backward compatibility, we would need to think if we create a
>>> special data structure to be used in the password so that it holds both the
>>> MAC/signature and the nonce.
>>>
>>>
>>>
>>> As the use of ClientId seems to create confusion, I am leaning towards
>>> this solution. Any thoughts?
>>>
>>>
>>>
>>> [JLS] Look at the previous answer and the re-ask the question.
>>>
>>>
>>>
>>>
>>>
>>> 13. Is there someplace that authentication methods need to be
>>> registered?  I
>>> was unable to see any such registry setup with OASIS from the v5
>>> specification.  Should we suggest to the MQTT group that this is
>>> something
>>> that should be done?
>>>
>>>
>>>
>>> >> This is an interesting thought. The draft was indeed discussed in the
>>> OASIS MQTT WG.
>>>
>>>
>>>
>>> But, the WG may consider this out of scope, as they have on their
>>> charter page:
>>>
>>>  Transport level security is assumed and no mandatory security features
>>> will be added.
>>>
>>> The MQTT v5 draft says:
>>>
>>> The Authentication Method is commonly a SASL mechanism, and using such a
>>> registered name aids interchange. However, the Authentication Method is not
>>> constrained to using registered SASL mechanisms.
>>>
>>>
>>>
>>> [JLS] I think that the lack of a registry should be identified someplace
>>> in the document.  This is probably a security consideration that there
>>> might be a different authentication method which re-uses the same
>>> authentication method name.
>>>
>>>
>>>
>>>
>>>
>>> 17.  It is not clear to me, how in the scope string is the ability to
>>> have a
>>> "will" indicated?
>>>
>>> >> If the Will Flag is set to 1, the Will Topic follows the Client ID
>>> and Will Properties in the Payload.
>>>
>>> This is where the broker learns the Will Topic.
>>>
>>> Then the scope would be publish_<will topic>.
>>>
>>> And subscribes would need to subscribe_<will topic> to receive this
>>> message.
>>>
>>> Will clarify in text.
>>>
>>>
>>>
>>> [JLS] publish makes sense to me.  I was just being overly complicated.
>>>
>>>
>>>
>>> 18.  Section 2.1.4 - I am unsure what the implications of discarding
>>> tokens
>>> on the end of a connection are going to be.  How do you publish the token
>>> before doing the connection or is that only for an updated token?
>>>
>>>
>>>
>>> >> Tokens are discarded at the end of disconnection because no previous
>>> session state is kept.
>>>
>>> And a token is expected in the new CONNECT request (otherwise, it is AS
>>> discovery)
>>>
>>>
>>>
>>> Before the connection, a token may be transported via  "authz-info"
>>> topic described in Appendix B.
>>>
>>> During the connection, a new token may be transported via the AUTH
>>> packet - which enables reauthentication.
>>>
>>>
>>>
>>> [JLS] This is still not clear to me.  Is the transport of the token via
>>> “auth-info” topic not considered to be part of the session?  If you say
>>> that you look at just the last value published, then is there not going to
>>> be a race condition between two different clients trying to publish and
>>> connect?
>>>
>>>
>>>
>>>
>>> 20.  I am not sure what the benefits of doing the check on a PINGREQUEST
>>> is
>>> going to be.  Like the relay of a PUBLISH message this is just going to
>>> produce a DISCONNECT and a closed channel.  If this is really allowed,
>>> then
>>> you should potentially also say that the Broker could do a check based on
>>> clock time elapsing.  (I.e. do the check every hour.)
>>>
>>>
>>>
>>> >> This was suggested by one of the reviewers that provide MQTT services
>>> (his e-mail regarding this was sent to the ace list).
>>>
>>> It was suggested as an optimization for detecting token expirations and
>>> disconnecting early.
>>>
>>> (i.e., if you are already receiving PINGREQUESTs, use these as a trigger
>>> to check the token).
>>>
>>> I think time-based checks may also help and be added as an option.
>>>
>>>
>>>
>>> [JLS] Ok
>>>
>>>
>>>
>>>
>>> 22. Not sure if this goes here or in the connect documentation.  There
>>> needs
>>> to be a check that the will topic is a topic that the client is going to
>>> be
>>> permitted to publish on.   Corner case, if the ability to publish a will
>>> in
>>> the event that this permission is lost.  Does this kill the session or
>>> the
>>> will message?  I.e. should the permission for the will message be
>>> rechecked
>>> before sending it allowing for the time based expiration of the token.
>>>
>>>
>>>
>>> >> We have been thinking about this.
>>>
>>> If the disconnect is due to a token expiration, and hence, also includes
>>> the will topic as well, you have to decide between:
>>>
>>> 1) publish the will
>>>
>>> 2) do not publish the will.
>>>
>>> At the moment, it's written like we publish the will - but on second
>>> consideration,
>>>
>>> it seems safer to say "Publish the Will on Server Disconnect or unusual
>>> disconnect if the token (the will permission) has not expired".
>>>
>>>
>>>
>>> [JLS] I would be fine with either position, after all at the time the
>>> “publish” event occurred the token was valid, this is just deferring
>>> relaying it to subscribers.
>>>
>>>
>>>
>>> Jim
>>>
>>>
>>>
>>>
>>>
>>> Thanks again for these comments, will create the necessary github issues
>>> and start revising the text.
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>>
>>>
>>> Jim
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>