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

[Jim Schaad <[e-mail]>]

 

 

From: Cigdem Sengul <[e-mail]> 
Sent: Thursday, October 17, 2019 4:13 AM
To: Jim Schaad <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01

 

Hello Jim,

Thanks for this review. I have responded inline. 



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?  

 

>> Agreed. Need to specify that it is HTTPS.

Mutual authentication and server validation Required. 

Was thinking it would be normal HTTPS ports. Should we consider different?

What scenarios should permit anon-anon; anon clients? 

 

[JLS] If you look at my last email I went through this.  Anon-anon is going to be a bad idea because the server is never validated, however client anon is fine since you are going to validate the client in the MQTT protocol. 

 

 


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.

>> Do you mean for introspection? Yes, this is a MAY as in the core document, and so in this one too. 

And if there is an RS-AS interaction, we expect that to be on HTTPS. 

I will try to see where I should clarify in the text. 

 

[JLS] No, I was originally looking at doing an HTTPS post of the token from the client to the RS.  This was before I figured out that you have an alternative method of doing this in the MQTT protocol and so it should not be needed.   Being clear on the fact that this would not be expected is probably a good idea.

 


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.

 

OK. I think I should explain MQTT packets better. 

A connect packet has three parts: 1) Fixed header 2) Variable Header and 3) Payload.

The variable header may have several properties, and Authentication Method and Authentication Data are two of these properties. 

According to MQTT Specification:

The ClientID MUST be present and is the first field in the CONNECT packet Payload. 

The ClientID MUST be a UTF-8 Encoded String

A Server MAY allow a Client to supply a ClientID that has a length of zero bytes, however, if it does so the Server MUST treat this as a special case.

 

And this is what is done in the case of a collision:

If the ClientID represents a Client already connected to the Server, the Server sends a DISCONNECT packet to the existing Client with Reason Code of 0x8E (Session taken over) 

 

Is this more clear? If yes, I will try to clarify in text. 

 

[JLS] That is not where I was having a problem.  I was getting confused by the figure itself.  Labeling the figure better might help.  “MQTT V5.0 CONNECT control message with ‘ace’ authentication method”.  I would rather not have all of the abbreviations in the title, but I can live with it.

 


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

 

>> Agreed. This should be specified. 

Two options: 1) Do not accept connection or 2) accept the connection but then never create sessions, and then server  MUST set Session Present to 0 in the CONNACK packet, indicating 

no session is present. 

 

This basically makes Clean Start flag meaningless. 

If this is better than client MUST be setting those parameters correctly, then we can go this way. 

Any thoughts?

 

[JLS] I don’t really care one way or the other.  Given that there is the return value in the CONNACK, I think that a simple statement that the flag is set to 0 regardless of the value coming in.  

 


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.

 

>>OK. I think it got muddled because I was trying to find a solution for a scenario where the ClientId is used across sessions, and hence, not random. 

 

Two cases.

1) Client ID uniquely random across each Client connection attempt to Broker: MAC over Payload - Payload begins with ClientID and MAY include Will Properties if Client indicated that it will have a will. 

2) Client ID NOT uniquely random: MAC over Authentication Data. 

 

It may be best to choose one method and just say MUST always have a nonce in Authentication Data, and MAC is computed over that?

 

[JLS] Lets step back and look at the problem I think you are trying to solve.    

*	If you are trying to make sure that there is not a replay of the signature, then this would require that the server keep track of the list of nonce values that the client has provided. 
*	 If you are trying to make sure that the signature is “fresh” then the server would need to be able to provide some type of data as part of the value being signed.  As I think I have said before the latter can be satisfied by getting your nonce value from the TLS session using a tls-exporter.

 

If neither of these problems is trying to be solved, then there is no need for the nonce at all.

 

 

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.

 

>> Yes, but as I explained for comment 7, in MQTT, the typical case is the client provides its id. 

However, to cater to all requirements and all implementation possibilities, maybe it is best to just use a nonce as explained for comment 10 and not tie anything to client id.

 

Previously, when we were writing the draft for MQTT v3.1.1 we wanted to provide a solution that uses the available fields in the CONNECT packet as much as possible; without

introducing any new fields. This was because of the constraints of the MQTT v3.1.1. MQTT v5 gives us more options to implement this better.

 

For backward compatibility, we would need to think if we create a special data structure to be used in the password so that it holds both the MAC/signature and the nonce.   

 

As the use of ClientId seems to create confusion, I am leaning towards this solution. Any thoughts?

 

[JLS] Look at the previous answer and the re-ask the question.

 

 

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?

 

>> This is an interesting thought. The draft was indeed discussed in the OASIS MQTT WG. 

 

But, the WG may consider this out of scope, as they have on their charter page:

 Transport level security is assumed and no mandatory security features will be added.

The MQTT v5 draft says:

The Authentication Method is commonly a SASL mechanism, and using such a registered name aids interchange. However, the Authentication Method is not constrained to using registered SASL mechanisms.

 

[JLS] I think that the lack of a registry should be identified someplace in the document.  This is probably a security consideration that there might be a different authentication method which re-uses the same authentication method name.

 

 

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

>> If the Will Flag is set to 1, the Will Topic follows the Client ID and Will Properties in the Payload.

This is where the broker learns the Will Topic. 

Then the scope would be publish_<will topic>. 

And subscribes would need to subscribe_<will topic> to receive this message. 

Will clarify in text.

 

[JLS] publish makes sense to me.  I was just being overly complicated.

 

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?

 

>> Tokens are discarded at the end of disconnection because no previous session state is kept.

And a token is expected in the new CONNECT request (otherwise, it is AS discovery)

 

Before the connection, a token may be transported via  "authz-info" topic described in Appendix B. 

During the connection, a new token may be transported via the AUTH packet - which enables reauthentication. 

 

[JLS] This is still not clear to me.  Is the transport of the token via “auth-info” topic not considered to be part of the session?  If you say that you look at just the last value published, then is there not going to be a race condition between two different clients trying to publish and connect?  

 


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

 

>> This was suggested by one of the reviewers that provide MQTT services (his e-mail regarding this was sent to the ace list). 

It was suggested as an optimization for detecting token expirations and disconnecting early. 

(i.e., if you are already receiving PINGREQUESTs, use these as a trigger to check the token). 

I think time-based checks may also help and be added as an option.

 

[JLS] Ok

 


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.

 

>> We have been thinking about this. 

If the disconnect is due to a token expiration, and hence, also includes the will topic as well, you have to decide between:

1) publish the will

2) do not publish the will. 

At the moment, it's written like we publish the will - but on second consideration, 

it seems safer to say "Publish the Will on Server Disconnect or unusual disconnect if the token (the will permission) has not expired". 

 

[JLS] I would be fine with either position, after all at the time the “publish” event occurred the token was valid, this is just deferring relaying it to subscribers.  

 

Jim

 

 

Thanks again for these comments, will create the necessary github issues and start revising the text. 

 

Best, 

 


Jim









_______________________________________________
Ace mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/ace