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

[Cigdem Sengul <[e-mail]>]

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 <[e-mail]>
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