[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/