Hi Cigdem! Thanks for the quick response. The clarifications and proposed edits listed below address my feedback.
Roman From: Cigdem Sengul <[email protected]> Sent: Thursday, March 10, 2022 7:33 AM To: Roman Danyliw <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; Ace Wg <[email protected]>; Daniel Migault <[email protected]> Subject: Re: Roman Danyliw's No Objection on draft-ietf-ace-mqtt-tls-profile-15: (with COMMENT) Dear Roman, Thank you for your comments. I tried to respond to them inline below. (I have made fixes here: https://github.com/ace-wg/mqtt-tls-profile/pull/104) On Tue, 8 Mar 2022 at 23:02, Roman Danyliw via Datatracker <[email protected]<mailto:[email protected]>> wrote: Roman Danyliw has entered the following ballot position for draft-ietf-ace-mqtt-tls-profile-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** Section 2. If the Client is resource-constrained or does not support HTTPS, a separate Client Authorization Server may carry out the token request on behalf of the Client, and later, onboard the Client with the token. Appreciating that the CAS is out of scope, I’m trying to understand which of the (A) – (F) interactions are handled by the Client and which would be handled by the CAS. Figure 1 is a ambiguous. (A) and (B) seem like they would be covered by the CAS, but I’m assuming (C) and (D) are the Client after being provisioned with the access token (from A and B). Is that correct? If so, it would be helpful to clarify that in the text and/or diagram. [That is correct. CAS was expected to be helpful for clients that are not able to do the HTTPS. We have a CAS definiton in 1.2 - Client Authorization Server (CAS) An entity that prepares and endorses authentication and authorization data for a Client, and communicates using HTTPS to the AS. In the figure, we tried to capture the two separately: (1) Client Authorization interface, and (2) MQTT Pub/Sub Interface. Client may be able to do both (1) and (2), or rely on CAS for (1), and is expected to be provisioned with a otken for Pub/Sub Interface if aiming to publish/subscribe to proteced topics. We had the following text in the document: " If the Client is resource-constrained or does not support HTTPS, a separate Client Authorization Server may carry out the token request on behalf of the Client, and later, onboard the Client with the token. " Is revising it so that we point to the figure sufficient clarification? " If the Client is resource-constrained or does not support HTTPS, a separate Client Authorization Server may carry out the token request on behalf of the Client (Figure 1 (A) and (B)), and later, onboard the Client with the token. ] ** Section 3.3. As a response to the SUBSCRIBE packet, the Broker issues a SUBACK. For each Topic Filter, the SUBACK packet includes a return code matching the QoS level for the corresponding Topic Filter. In the case of failure, the return code is 0x87, indicating that the Client is 'Not authorized'. A reason code is returned for each Topic Filter. This may be a detail of MQTT. Does the explicit use of “not authorized” vs. “not authorized/not found” leak the existence of a topic name to an off-path attacker? It seems that with “not authorized” semantics, one could try to guess topic name with enumeration, say, try 1: “/topic/is-the-sensitive-project-called-A”, try 2: “/topic/is-the-sensitive-project-called-B”, etc. [CS : I see your point. MQTT has also the following error code: 0x80 Unspecified error The subscription is not accepted and the Server either does not wish to reveal the reason or none of the other Reason Codes apply. We can add: "The Broker MAY return 0x80 Unspecified error if they do not want to leak the topic names to unauthorised clients." Would that be OK? ] Editorial Nits ** Section 1. Editorial. s/The Client-AS and RS-AS/The Client-AS and RS-AS communication/ [CS: This was changed to "The client-AS and RS-AS exchanges" based on artart review.] ** Section 1.3. Editorial. Chose either the “65535” or “65,535” convention (comma or no comma). “UTF-8 string” uses the former and “binary data” uses the latter [CS: Fixed to 65535] ** Section 1.2. Editorial. SUBACK. Describe the who is the sender and receiver like in the other message types. OLD Subscribe acknowledgement. NEW Subscribe acknowledgement from the Broker to the Client. [CS: Fixed] ** Section 2. Editorial. The token request and response use the token endpoint at the AS, specified for HTTP-based interactions in Section 5.8 of the ACE framework [I-D.ietf-ace-oauth-authz]. This reference should likely read Section 4 of [I-D.ietf-ace-oauth-authz] as this section included the bullet protocol flow from (A) – (E). [CS: Actually, I was referring to section 5.8 to highlight the HTTP-specific interactions, and in the rest of that paragraph I refer to the specific section for introspection as well. I will keep this as-is if it is not affecting clarity.] ** Section 2.3. Should it be MQTT messages vs. MQTT packets? For example, in “… to allow a Client’s future PUBLISH and SUBSCRIBE packets”. [CS: That crept in because the MQTT standard uses both Publish Message, Publish Packet. But in this context, "message" is more meaningful. So, fixed.] ** Section 3.3. Editorial. s/token token/token scope which/ [CS: This has been fixed in an earlier revision. ] Thanks again for your review. Kind regards, --Cigdem
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
