Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03
Daniel Migault <daniel.migault@ericsson.com> Tue, 21 January 2020 18:23 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 6651B12003F; Tue, 21 Jan 2020 10:23:22 -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=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 Vd-ozMKtLGyb; Tue, 21 Jan 2020 10:23:18 -0800 (PST)
Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (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 9805412006F; Tue, 21 Jan 2020 10:23:17 -0800 (PST)
Received: by mail-ua1-f43.google.com with SMTP id y23so1397347ual.2; Tue, 21 Jan 2020 10:23:17 -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=tXmlW+RjvYy7EwXees7Er9xTV4vMxd1oXTwk9HsP/xw=; b=dVbzKDoevxwXaxEp8vF+VTRnd3L4Sz9RkepxX7GSdCsubF0fjFxBC87WdUZ8itpqzK FsyVN69Pt/YJ2FktR74DKKHMTDiEw6VRMz8MUFARl2hi4PAnO3yuFRwTUKF+xc8qht2B JNaubT3FWhqQnGvhvU5hAUsIaCLUYx8bSHbPkzmhn9FRL3q3rR377aYKSSNSWKpDw9CU /Bg3l43DSGvwiF2Q+/+b6r0L4h54mQUBuaTGDHsw6zHR3ZYv1LZGAxJw+MODmK2C/jHV zbyKT/wBqHHqnkvL75fmUw57MfBCTWwqkwFqugBFrL2SsfsOlosuCVKMr/9RKLeMgnZ7 lGDA==
X-Gm-Message-State: APjAAAVc9MPCgQrSb0kNwO5a/j2rFBLJIfNXjmF/2TV7MBmRB6rMzHr3 03h6i231AUJtpcYYZRNOilTgokf2iOJH8I6tYnM=
X-Google-Smtp-Source: APXvYqwew6J5cYR84xxUnU4uPlNPoAiEp9g0AJNvl5YIB7X1H/B+jN8nd/5RSYMnV5VHo5BFDk8aUF8MaYQGJUdzC1s=
X-Received: by 2002:ab0:74c8:: with SMTP id f8mr3566205uaq.114.1579630995895; Tue, 21 Jan 2020 10:23:15 -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>
In-Reply-To: <012301d5cda8$a5c74f00$f155ed00$@augustcellars.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 21 Jan 2020 13:23:04 -0500
Message-ID: <CADZyTk=FsD=shb7ciaXW8hUJu9DpDPn29dqFhZJu+yvZPXRKGw@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: Cigdem Sengul <cigdem.sengul@gmail.com>, draft-ietf-ace-mqtt-tls-profile@ietf.org, Ace Wg <ace@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000062f872059caa80c2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/zYRD_XG-WicS_dswHSMHVvgitRE>
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: Tue, 21 Jan 2020 18:23:22 -0000
Hi, I reviewed the current version of the draft and please see my comments below. The quality of the document has improved a lot in my opinion. There are also some parts I need to review more in depth (including the security consideration). Yours, Daniel [...] 1. Introduction [...] 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> 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> 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> 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> 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> 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> 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> 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> Implementations MAY also use 'application/ace+cbor' content type, and CBOR encoding, and CBOR Web Token (CWT) and associated PoP semantics to reduce the protocol memory and bandwidth requirements. For more information on Proof of Possession semantics for CWTs, see Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) [I-D.ietf-ace-cwt-proof-of-possession]. [...] 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> Certain security-related terms such as "authentication", "authorization", "confidentiality", "(data) integrity", "message authentication code", and "verify" are taken from RFC 4949 [RFC4949]. Sengul, et al. Expires June 22, 2020 [Page 4] Internet-Draft MQTT-TLS profile of ACE December 2019 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> 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> Application Message The data carried by the MQTT protocol. The data has an associated QoS level and a Topic Name. QoS level The level of assurance for the delivery of an Application Message. The QoS level can be 0-2, where "0" indicates "At most once delivery", "1" "At least once delivery", and "2" "Exactly once delivery". Topic Name The label attached to an Application Message, which is matched to a Subscription. 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> 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> 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> CONNACK The Broker connection acknowledgment. The first packet sent from the Broker to a Client is a CONNACK packet. CONNACK packets contain return codes indicating either a success or an error state to a Client. AUTH Authentication Exchange. An AUTH packet is sent from the Client to the Broker or to the Broker to the Client as part of an extended authentication exchange. AUTH Properties include Authentication Method and Authentication Data. The Authentication Method is set in the CONNECT packet, and consequent AUTH packets follow the same Authentication Method. The contents of the Authentication Data are defined by the Authentication Method. PUBLISH Publish request sent from a publishing Client to the Broker, or from the Broker to a subscribing Client. PUBACK Response to PUBLISH request with QoS level 1. PUBACK can be sent from the Broker to a Client or a Client to the Broker. PUBREC Response to PUBLISH request with QoS level 2. PUBREC can be sent from the Broker to a Client or a Client to the Broker. SUBSCRIBE The Client subscribe request. <mglt>I would suggest to have similar wording for PUBLISH as for SUBSCRIBE.</mglt> SUBACK Subscribe acknowledgment. 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 also alive. The "Keep Alive" period is set in the CONNECT message. PINGRESP Response sent by the Broker to the Client in response to PINGREQ. It indicates the Broker is alive. Sengul, et al. Expires June 22, 2020 [Page 6] Internet-Draft MQTT-TLS profile of ACE December 2019 Will If the network connection is not closed normally, the Server sends a last Will message for the Client, if the Client provided one in its CONNECT message. If the Will Flag is set, then the payload of the CONNECT message includes information about the Will. The information consists of the Will Properties, Will Topic, and Will Payload fields. 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> [...] 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> 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> 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> 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> 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> 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> Otherwise, to authenticate the Broker, the client MUST validate a public key from a X.509 certificate or an RPK from the Broker against the 'rs_cnf' parameter in the token response. The AS MAY include the thumbprint Sengul, et al. Expires June 22, 2020 [Page 9] Internet-Draft MQTT-TLS profile of ACE December 2019 of the RS's X.509 certificate in the 'rs_cnf' (thumbrint as defined in [I-D.ietf-cose-x509]), then the client MUST validate the RS certificate against this thumbprint. 2.2.2. authz-info: The Authorization Information Topic In the cases when the Client MUST transport the token to the Broker before the TLS handshake, the Client connects to the Broker and publishes its token to the "authz-info" topic. The "authz-info" topic MUST be publish-only (i.e., the Clients are not allowed to subscribe to it). "authz-info" is not protected, and hence, the Client authenticates with the RS using the "TLS:Anon-MQTT:None" option. After publishing the token, the Client disconnects from the Broker and is expected to try reconnecting over TLS. 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> [...] 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> The secret is exported from TLS using the exporter label 'EXPORTER-ACE-Sign-Challenge', an empty context, and length of 32 bytes. The token is also validated as described in Section 2.2.5 and the server responds with a CONNACK with the appropriate response code. 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> [...] 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> the message to all valid subscribers of the topic. In the case of an authorization failure, an error MAY be returned to the Client. For this the QoS level of the PUBLISH message MUST be set to greater than or equal to 1. This guarantees that RS responds with either a PUBACK or PUBREC packet with reason code '0x87 (Not authorized)'. On receiving a PUBACK with '0x87 (Not authorized)', the Client MAY reauthenticate as described in Section 4, and pass a new token following the same PoP methods as described in Figure 2. 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> There is no way to inform the Clients with invalid tokens that an authorization error has occurred other than sending a DISCONNECT message. The RS SHOULD send a DISCONNECT message with the reason code '0x87 (Not authorized)'. Note that the server-side DISCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1, the server needs to drop the connection). [...] 4. Token Expiration and Reauthentication The Broker MUST check for token expiration whenever a CONNECT, PUBLISH or SUBSCRIBE message is received or sent. The Broker SHOULD check for token expiration on receiving a PINGREQUEST message. The Broker MAY also check for token expiration periodically e.g., every hour. This may allow for early detection of a token expiry. The token expiration is checked by checking the 'exp' claim of a JWT or introspection response, or via performing an introspection request with the AS as described in Section 5.7 of the ACE framework [I-D.ietf-ace-oauth-authz]. Token expirations may trigger the RS to send PUBACK, SUBACK and DISCONNECT messages with return code set to 'Not authorised'. After sending a DISCONNECT message, the network connection is closed, and no more messages can be sent. However, as a response to the PUBACK and SUBACK, the Client MAY re-authenticate by sending an AUTH packet with a Reason Code of '0x19 (Re- authentication)'. 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> Sengul, et al. Expires June 22, 2020 [Page 27] 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] Review of draft-ietf-ace-mqtt-tls-profile-03 Jim Schaad
- Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profi… Cigdem Sengul
- Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profi… Jim Schaad
- Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profi… Daniel Migault
- Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profi… Cigdem Sengul
- Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profi… Daniel Migault