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 >
- [Ace] Review for draft-ietf-ace-mqtt-tls-profile-… Jim Schaad
- Re: [Ace] Review for draft-ietf-ace-mqtt-tls-prof… Cigdem Sengul
- Re: [Ace] Review for draft-ietf-ace-mqtt-tls-prof… Jim Schaad
- Re: [Ace] Review for draft-ietf-ace-mqtt-tls-prof… Daniel Migault
- Re: [Ace] Review for draft-ietf-ace-mqtt-tls-prof… Cigdem Sengul
- Re: [Ace] Review for draft-ietf-ace-mqtt-tls-prof… Jim Schaad
- Re: [Ace] Review for draft-ietf-ace-mqtt-tls-prof… Cigdem Sengul
- Re: [Ace] Review for draft-ietf-ace-mqtt-tls-prof… Daniel Migault