[Ace] Review for draft-ietf-ace-mqtt-tls-profile-01

[Jim Schaad <[e-mail]>]

Some of what is going here is going to duplicate information from my last
message.  Some of this are not necessarily things that need to be in this
document but should be discussed at some point.

1.  Are there any specifics about using ACE over HTTP that need to be
explicitly stated some place.  Some of these things might include:
	a) Must be HTTPS even if encrypted requests/responses are provided. 
	b) What types of validation are permitted/required: anon-anon,
server validation, server & client validation. The latter corresponds to
current DTLS statements.  
	c) Are we looking for using the normal HTTP/HTTPS ports or should we
be using different ports?  

2.  Section 2.1.2: Somehow I missed on the first reading that you were
suggesting the use of a topic /authz-info inside of the MQTT server for
posting.   I think that this needs to have a more detailed set of
instructions.  I assume but don't know that initially this would mean an
anonymous connect, publish, disconnect, validated connect.  This however is
not clear from the text.  It is also not clear that this should be over a
TLS wrapped session for the publish.

3.  Section 2.1.2: The correct reference is I-D.ietf-ace-dtls-authorize and
not I-D.gerdes-ace-dtls-authorize.

4.  Section 2.1.2: It is not clear from the document is a Broker is going to
also have the possibility of doing a post of the token via HTTPS.  Currently
I would think not, but given that this is documented in OAuth 2.0 as an
option I am not clear.

5.  It might make sense to break up section 2.1.2 more and cover the
different methods either in continuous paragraphs or in subsections.

6.  As noted before, you need to have a section on TLS requirements.  This
should cover what levels/types of authentication are permitted.  Some type
of statement on TLS 1.3 vs prior versions.  Part of what needs to be placed
here is the fact that while there is client authentication in MQTT, there is
no method of doing server authentication other than the surrounding TLS
protocol.  Also should cover how the certificate(?) or RPK would be
validated.  Use the existing rs_cnf?

7.   In Figure 2, I think the use of Client Identifier is somewhat
confusing.  I think this is supposed to be the token as the Client
Identifier is a different thing in MQTT.  Either that or you need to do a
better job of describing the property block.

8.  If the value of Clean Start or Expiry Interval are not set correct is
the server to fail the connect?

9.  Should do a pass through the document and make sure that terms like
"AUTH (Authentication Exchange) method" are not used.  I think you meant to
use 'packet' rather than method in this location.  You need to be clear on
the difference between methods and packets in the document.

10. Section 2.1.2.1 - I am having a problem computing the MAC over the
payload of the CONNECT message.  The password where the value is placed is
included in the payload and I am not clear if it should be computed up to
that value or if a fixed value should be used for the computation.

11. I am worried about the text on the Client Identifier in this section.
It is not clear to me that having the client generate a random value for
this field is good just in terms of the possibility of collisions occurring
on the server.  The text in the MQTT 5.0 document appears to say that this
is more interesting for the situation of getting back state that was left on
the server after a disconnect and not so much for a clean session.

12.  I don't know where the nonce in this section is coming from.
Discussion on where it comes from and where it is passed in the protocol is
needed.

13. Is there someplace that authentication methods need to be registered?  I
was unable to see any such registry setup with OASIS from the v5
specification.  Should we suggest to the MQTT group that this is something
that should be done?

14.  It would be useful to re-iterate that the authentication method for
2.1.2.3 is still set to 'ace'.

15. Section 2.1.3 - Please include a sentence that the signature algorithm
of "none" is explicitly not permitted for tokens.

16. You might want to point to the updated text in the ACE Framework
document for token validation procedures as they were rewritten and contain
more or less the same content?

17.  It is not clear to me, how in the scope string is the ability to have a
"will" indicated? 

18.  Section 2.1.4 - I am unsure what the implications of discarding tokens
on the end of a connection are going to be.  How do you publish the token
before doing the connection or is that only for an updated token?

19. Section 2.4  In the second paragraph, it appears you are saying that a
client could send an AUTH packet after receiving a DISCONNECT message.  I
don't believe that is true.

20.  I am not sure what the benefits of doing the check on a PINGREQUEST is
going to be.  Like the relay of a PUBLISH message this is just going to
produce a DISCONNECT and a closed channel.  If this is really allowed, then
you should potentially also say that the Broker could do a check based on
clock time elapsing.  (I.e. do the check every hour.)

21.  Section 2.5 - The last sentence in the first paragraph could be state
more clearly.  Specifically there would appear to be some ambiguity on who
the associated tokens are attached to.  "messages as long as the publisher
token for that message remains valid." Might be better.

22. Not sure if this goes here or in the connect documentation.  There needs
to be a check that the will topic is a topic that the client is going to be
permitted to publish on.   Corner case, if the ability to publish a will in
the event that this permission is lost.  Does this kill the session or the
will message?  I.e. should the permission for the will message be rechecked
before sending it allowing for the time based expiration of the token.

Jim