Subject: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-mqtt-tls-profile-15: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 08 Mar 2022 15:02:38 -0800

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/

---

From: Cigdem Sengul <[email-masked]>
Date: Thu, 10 Mar 2022 12:32:35 +0000

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-masked]>
wrote:

> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/

[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

   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.

]

> “/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?
]

> ** Section 1. Editorial. s/The Client-AS and RS-AS/The Client-AS and RS-AS
[CS: This was changed to "The client-AS and RS-AS exchanges" based on
artart review.]

> (comma or no comma).  “UTF-8 string” uses the former and “binary data”
[CS: Fixed to 65535]

> Subscribe acknowledgement from the Broker to the Client.
[CS: Fixed]

> 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.]

> “… 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

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 10 Mar 2022 13:30:04 +0000

Hi Cigdem!

Thanks for the quick response.  The clarifications and proposed edits listed below address my feedback.

Roman

From: Cigdem Sengul <[email-masked]>
Sent: Thursday, March 10, 2022 7:33 AM
To: Roman Danyliw <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; Ace Wg <[email-masked]>; Daniel Migault <[email-masked]>
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-masked]<mailto:[email-masked]>> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-ace-mqtt-tls-profile-15: No Objection

** Section 2.

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

           to the AS.

In the figure, we tried to capture the two separately: (1) Client Authorization 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.

   token. "

   on behalf of the Client (Figure 1 (A) and (B)), and later, onboard the Client with the

   token.
]

** Section 3.3.

[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.]

OLD

NEW

** Section 2.  Editorial.
   The token request and

[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.]

[CS: That crept in because the MQTT standard uses both Publish Message, Publish Packet.
But in this context, "message" is more meaningful. So, fixed.]