Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

From: Cigdem Sengul <cigdem.sengul@gmail.com> 
Sent: Sunday, August 16, 2020 12:14 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg <ace@ietf.org>
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

Hello Jim, 

Responses inside. 

On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> > wrote:

Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous
session number/  - I think it should be stated that the session number is
provided, which is what the state is associated with.

To the best of my knowledge, and from what I read from the MQTT v5 spec:

The ClientID MUST be used by Clients and by Servers to identify state that they hold relating to this MQTT Session between the Client and the Server. 

I do not think the server uses anything other than the Client ID to look up the state.  

[JLS] I got the name wrong, the need for the identifier remains.

Section 2.2.4 - Last sentence.  There is a difference between the connect
and re-auth flows in that the first and last messages are going to be AUTH
'25', AUTH '0' not CONNECT/CONNACK.  Everything else does stay the same. -
Might just want to say a similar flow and point forward.

Will clarify that this is only for CONNECT as it is under section 2- Authorizing Connection Requests. 

Will direct to section 4 for re-authentication.

Section 2.2.6.1 - I am not sure where you got this from: "Note that this is
different in MQTT v5.0, the Broker is allowed to process AUTH packets even
if the Broker rejects the CONNECT)."  I think that if the broker rejects the
connect it must CONNACK and disconnect.  

I've got that from MQTT v5 spec:

If a Client sets an Authentication Method in the CONNECT, the Client MUST NOT send any packets other than AUTH or DISCONNECT packets until it has received a CONNACK packet [MQTT-3.1.2-30].

 and:

If the Server rejects the CONNECT, it MUST NOT process any data sent by the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6]. 

[JLS] I read this as the following would not do the publish

CONNECT -->

PUBLISH -->

                <-- AUTH

AUTH -->

                <-- CONNACK fail

The PUBLISH can be received but is not processed unless the CONNACK is going to be a success.

[/JLS]

So, the spec allows clients to send AUTH after CONNECT before CONNACK, and servers to process AUTH after CONNECT (before CONNACK I suppose). 

I agree the wording may  be confusing:

What I want to say is that: the servers in our profile do not process anything after CONNECT before CONNACK. 

So, the AUTH flow is strictly initiated by the server during the connection handshake.

After that, the client may do AUTH first, for re-authentication. 

[JLS] Given that a client may only send an AUTH in response to an AUTH, I don’t know how much this is needed.

[JLS]  I think if you just delete the aside (in parens) then it says what needs to be said and is not confusing.

Section 3.1 - Missed a case of "publish_+/topic3"

Yes, in previous version, example was for publish only for topic3.

I thought I should give a pub/sub, pub only, and sub only examples. 

Is that OK?

Yes, I was just pointing out that this was using the old syntax.  Nothing more.

Jim

Thanks,

--Cigdem 

Jim

_______________________________________________
Ace mailing list
Ace@ietf.org <mailto:Ace@ietf.org> 
https://www.ietf.org/mailman/listinfo/ace