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 <nore...@ietf.org> 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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
