[Ace] Roman Danyliw's No Objection on draft-ietf-ace-mqtt-tls-profile-15: (with COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Tue, 08 March 2022 23:02 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ace@ietf.org
Delivered-To: ace@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3F73A1B2D; Tue, 8 Mar 2022 15:02:38 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, ace-chairs@ietf.org, ace@ietf.org, Daniel Migault <daniel.migault@ericsson.com>, daniel.migault@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <164678055841.27251.8215934547015351301@ietfa.amsl.com>
Date: Tue, 08 Mar 2022 15:02:38 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/PfWbxbuKTVijSKmOCWDn7Tk3zL4>
Subject: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-mqtt-tls-profile-15: (with COMMENT)
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
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, 08 Mar 2022 23:02:39 -0000
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. ** 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. Editorial Nits ** Section 1. Editorial. s/The Client-AS and RS-AS/The Client-AS and RS-AS communication/ ** 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 ** 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. ** 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). ** Section 2.3. Should it be MQTT messages vs. MQTT packets? For example, in “… to allow a Client’s future PUBLISH and SUBSCRIBE packets”. ** Section 3.3. Editorial. s/token token/token scope which/
- [Ace] Roman Danyliw's No Objection on draft-ietf-… Roman Danyliw via Datatracker
- Re: [Ace] Roman Danyliw's No Objection on draft-i… Cigdem Sengul
- Re: [Ace] Roman Danyliw's No Objection on draft-i… Roman Danyliw