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

From: Jim Schaad <[email-masked]>
Date: Tue, 15 Oct 2019 14:09:26 -0700

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

---

From: Cigdem Sengul <[email-masked]>
Date: Thu, 17 Oct 2019 12:12:36 +0100

Hello Jim,
Thanks for this review. I have responded inline.

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

>> OK. this was described in the Appendix. I will bring this forward in the
document, as an optional flow.

>>  Will fix.

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

>> Sure. That would increase readability. It became rather long with the
new additions.

>> OK. Will add that.

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

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

>>I think I should clarify this piece as well as it is MQTT terminology. I
will add these to the terminology in the beginning.

AUTH (Authentication Exchange): AUTH packet sent from Client to Server or
Server to Client as part of an extended authentication exchange.
Authentication method: String containing the name of the authentication
method
Authentication data: Binary Data containing authentication data.

This is how these terms are defined in MQTT. Will check where the
terminology is mixed up and will try to assure consistency. Could you flag
particular instances where this was particularly confusing?

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

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

 >> As explained in 10. Will clarify in text.

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

>> Will do.

>> Will do.

>> Will do and remove the repetitious text.

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

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

>>That's a mistake indeed. I should remove DISCONNECT from that list.
DISCONNECT is the last message of the session indeed.

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

>> Will change.

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

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

Best,

>
> Jim
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Jim Schaad <[email-masked]>
Date: Thu, 17 Oct 2019 11:46:27 -0700

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

Hello Jim,

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

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

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

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. 

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

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.

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) 

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

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

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.  

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

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.

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

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

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

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.

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

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

[JLS] Ok

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

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
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ace

---

From: Daniel Migault <[email-masked]>
Date: Wed, 23 Oct 2019 21:50:05 -0400

HI,

Thanks for sending an update. Please find my comments of the draft.

Regards,

Daniel

1.  Introduction

   In this document, message topics are treated as resources.  Clients
   use an access token, bound to a key (the proof-of-possession key) to
   authorize with the MQTT Broker their connection and publish/subscribe
   permissions to topics.  In the context of this ACE profile, the MQTT
   Broker acts as the Resource Server (RS).  In the rest of the document
   RS and Broker are used interchangeably.  To provide communication
   confidentiality and Resource Server authentication, TLS is used.
   This document makes the same assumptions as the Section 4 of the ACE
   framework [I-D.ietf-ace-oauth-authz] regarding Client and RS
   registration with the AS and establishing of keying material.

<mglt> The document seems mostly focuses on the latest version of MQTT,
I am wondering if we could encourage similarly the use of the latest
version of TLS that is 1.3 at the time of writing.

It seems AS as not been defined previously, so maybe it should be
expanded there.
</mglt>

   MQTTS
           Secured transport profile of MQTT.  MQTTS runs over TLS.
           The Server in MQTT and acts as an intermediary between
           Clients that publish Application Messages, and the Clients
           that made Subscriptions.  The Broker acts as the Resource
           Server for the Clients.

<mglt>publishes</mglt>

   Subscription
           A subscription comprises a Topic Filter and a maximum Quality
           of Service (QoS).

<mglt>Maybe that would be clearer to specify QoS level as well.</mglt>

   PINGREQ
           A ping request sent from a Client to the Broker.  It signals
           to the Broker that the Client is alive, and is used to
           confirm that the Broker is still alive.

<mglt>It may look a bit strange to have PINGREQ without PINGRESP. You
might also indicate the keep alive period is provided in the CONNECT</mglt>

   Will
           An application message published by the Server after the
           network connection is closed in cases where the network
           connection is not closed normally.  If the Will Flag is set,
           then the payload of the CONNECT message has information about
           the Will.  The Will consists of the Will Properties, Will
           Topic, and Will Payload fields in the CONNECT message.

<mglt>
The first sentence seems to be related to the Will message while the
intent, I suppose of teh definition was to define the generic conpet of
Will. It might be clearer to expose the principle of the wil, that is a
server sends a given message in case a client is disconnected
improperly.   It might be clearer to mention explicitly there is a Will
"concept" that is implemented a WillFlag WillQoS, WillRetain in the
CONNECT header as well as other Will Properties and Will Messages. This
mostly consists in the last sentence being moved up.
</mglt>

2.  Protocol Interactions

   This section describes the following exchanges between Clients, the
   Broker, and the Authorization Server according to the MQTT v5.0.

<mglt> Though english is not my first language, I have the impression the
text can be interpreted as MQTT enables clients to establish session
which does not seems correct to me. The text that follows clarifies this
as well.
</mglt>

2.1.  Authorizing Connection Establishment

If the
   Client is resource-constrained, a Client Authorisation Server may

<mglt>I have the impression an AS would be sufficient.</mglt>

   carry out the token request on behalf of the Client, and later,
   onboard the Client with the token.  Also, these interfaces may be
   implemented using other protocols, e.g., CoAP or MQTT.
<mglt>While the introduction and the figure mentions that HTTPS is used
as a transport, it might be worth mentioning that HTTPS is being used. I
propose to add "...other protocols than HTTPS, e.g ...
</mglt>

2.1.1.  Client Token Request to the Authorization Server (AS)

   The first step in the protocol flow (Figure 1 (A)) is the token
   acquisition by the Client from the AS.  When requesting an access
   token from the AS, the Client MAY include parameters in its request
   as defined in Section 5.6.1 of the ACE framework
   [I-D.ietf-ace-oauth-authz].  The media format is 'application/
   ace+json'.  The profile parameter MUST be set to 'mqtt_tls'.  The
   OAuth 2.0 AS uses a JSON structure in the payload of its responses
   both to client and RS.

<mglt> I understand that some parameters are mandatory while other are
not. I believe it might be clearer to start with the mandatory
parameters (MUST) and then mention that other parameters are optional
(MAY). That said, it might be simpler, if that is correct to mention
that the token request is as described in Section 5.6.1 of the ACE framework
   [I-D.ietf-ace-oauth-authz] with the profile set to "mqtt".
</mglt>

   In the case of an error, the AS returns error responses for HTTP-
   based interactions as ASCII codes in JSON content, as defined in
   Section 5.2 of RFC 6749 [RFC6749].

<mglt>Error messages are handled by OAuth2.0 instead of the ACE
framework in order to keep JSON format. I am wondering why do we have
the requirement to use ace+cbor only for error message ? It seems to me
a bit strange to have error handling defined in another document.
</mglt>

2.1.2.  Client Connection Request to the Broker (C)

   This section describes how the Client transports the token to the
   Broker (RS) via the CONNECT control message after the TLS handshake.

<mglt>If the TLS handshake has already been performed, it would be good
to mention which credentials have been used. Obviously, if the token is
provided by the CONNECT message, I expect other credentials to be
involved. </mglt>

   This is similar to an earlier proposal by Fremantle et al.
   [fremantle14].  Alternatively, the token may be used for the TLS
   session establishment as described in the DTLS profile for ACE
   [I-D.gerdes-ace-dtls-authorize].  In this case, both the TLS PSK and
   RPK handshakes MAY be supported.
<mglt>
It would be good to expand Raw Public Keys (RPK). My reading is that
this section does not provide a single mechanism for the Client to be
authenticated by the Broker, but instead two different ways. I would
thus recommend to state it clearly in the introduction of the section.
Currently, the section mentions:
"""
This section describes how the Client transports the token to the
   Broker (RS) via the CONNECT control message after the TLS handshake.
"""

An then we have a relatively detailed description on how this is
performed using TLS. It might be better to say something around the
following lines:
"""
This section describes how the Client transports the token to the
   Broker (RS). This can be achieved during the TLS KEX or during the
MQTT session establishment via the CONNECT control message after the TLS
handshake.
"""

I am not sure that MAY is appropriated here. I suspect that if none are
supported, this method will not work. As a result, if seems to me that
it woudl be more accurate to say that TLS Client and TLS server MUST
support the PSK authentication as well as the raw public key.

One issue I have with I-D.gerdes-ace-dtls-authorize that is now
draft-ietf-ace-dtls-authorize is that it seems to only consider TLS 1.2.
With TLS 1.3 PSK and RPK are supported.

My interpretation is that PSK provides mutual authentication, but in our
case RPK will only authenticate the client. If that is correct, there
might be a new to specify how the RS is authenticated by the Client.

</mglt>

 This option is described in more
   detail in Appendix B.

<mglt>see my comment in annex B.</mglt>

   After the token acquisition, the Client connects to the RS (Broker)
   using the CONNECT message of MQTT over TLS.  For server
   authentication, the client MAY either have the ability to receive and
   validate a certificate or a raw public key from the Broker.

<mglt>I might have missed something, but I thought that PSK/RPK were
used to authenticate the Client. While in this case the RPK is used to
authenticate the RS, is that the same RPK provided by the AS or another
one? </mglt>

   For token transport, the RS SHOULD support AUTH (Authentication
   Exchange) method.  The RS MAY support token transport via username
   and password, which is described in Section 3 for MQTT v3.1.1.  The
   rest of this section describes the AUTH method, for which the
   username and password flags MUST be set to 0.

<mglt>
Maybe the reference should be for MQTTv5 instead of MQTTv3.
I believe it would be good to specify how setting the password flag
interacts with the Authentication method.
</mglt>

2.1.2.1.  Proof-of-Possession over Predefined Field

   For this option, the Authentication Data MUST contain the token and
   the keyed message digest (MAC) or the Client signature.  To calculate
   the keyed message digest (MAC) or the Client signature, the Client
   SHOULD apply the PoP key to the CONNECT payload.

  <mglt> I have the impression the latest sentence indicates that the
Authenticated Data is include din the CONNECT payload. I have however
the impression that Authenticated Data is part of the properties which
are include din the variable header and not the payload. </mglt>

The CONNECT payload
   has at least a Client Identifier, and if the Will Flag is set to 1,
   may contain Will-related information.  The Client Identifier is a
   MUST be a UTF-8 Encoded String (i.e., is prefixed with a two-byte
   integer length field that gives the number of bytes in a UTF-8
   encoded string itself).  The Client Identifier may be 1-23 UTF-8
   encoded bytes, and contain only the characters
   "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ".

<mglt>
For my information I would like to understand the mention of UTF8
while only ascii characters are permitted. It seems that teh server MUST
accept these and MAY accept others as well as a longer client id. Am I
correct ?

The nonce coded this way has a randomness of 62**23 =2**138 = 17 bytes
</mglt>

2.1.4.  The Broker's Response to Client Connection Request

   If the RS accepts the connection, it MUST store the token until the
   end of connection.  On Client or RS disconnection, the token is
   discarded, and the Client MUST provide a token inside each CONNECT
   message.

<mglt> The latest sentence is unclear to me. I think that disconnection
can be interpreted in two way: 1) the disconnection of the will or a
DISCONNECT. I believe both are considered. </mglt>

   If the token is not self-contained and the Broker uses token
   introspection, it MAY cache the validation result to authorize the
   subsequent PUBLISH and SUBSCRIBE messages.  PUBLISH and SUBSCRIBE
   messages, which are sent after a connection set-up, do not contain
   access tokens.  If the introspection result is not cached, then the
   RS needs to introspect the saved token for each request.  The Broker
   SHOULD use a cache time out to introspect tokens regularly.

<mglt>The latest sentence seems to indicate that result provided as
via introspection do not necessarily have a Time to Live which could be
interpreted as a commitment from the AS to authorize during that
period. If that is possible, it would be appropriated this time out is
provided by the AS.
I am also wondering why the token expiration cannot be considered as
well.
</mglt>

Appendix B.  The Authorization Information Endpoint

   The main document described a method for transporting tokens inside
   MQTT CONNECT messages.  In this section, we describe an alternative
   method to transport an access token.
   The method consists of the MQTT Broker accepting PUBLISH messages to
   a public "authz-info" topic.  A Client using this method MUST first
   connect to the Broker, and publish the access token using the "authz-
   info" topic.  The Broker must verify the validity of the token (i.e.,
   through local validation or introspection).  After publishing the
   token, the Client disconnects from the Broker and is expected to try
   reconnecting over TLS.

<mglt>I understand this as an open channel for CONNECT and sending
PUBLISHING message. This potentially open the door for DoSing the RS
either by openning too many MQTT sessions or by sending too many tokens.
I expect this to be mentioned in the security consideration section as
well as potential mechanisms to limit these risks.
</mglt>

On Thu, Oct 17, 2019 at 2:47 PM Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* Cigdem Sengul <[email-masked]>
> *Sent:* Thursday, October 17, 2019 4:13 AM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01
>
>
>
> Hello Jim,
>
> [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.
>
>
>
>
>
>
> [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.
>
>
>
>
> [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.
>
>
>
>
> then never create sessions, and then server  MUST set Session Present to
> 0 in the CONNACK packet, indicating
>
> no session is present.
>
>
>
> [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.
>
>
>
>
>    - 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> [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.
>
>
>
>
>
> [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?
>
>
>
>
> [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
>
>
>
>
>

---

From: Cigdem Sengul <[email-masked]>
Date: Wed, 30 Oct 2019 16:12:59 +0000

Thank you for your comments Daniel (prefixed [CS])
My comments are inside. I've also created the -v-02-WIP branch for the work
in progress based on your and Jim's comments.

> It seems AS as not been defined previously, so maybe it should be

[CS] Can add a similar recommendation for TLS 1.3.
AS is expanded.

>            The Server in MQTT acts as an intermediary between
>            Clients that publishes Application Messages, and the Clients
[CS] Fixed.

> <mglt>Maybe that would be clearer to specify QoS level as well.</mglt>

[CS] Added.

> might also indicate the keep alive period is provided in the CONNECT</mglt>

[CS] Added PINGRESP, clarified the Keep Alive period is set in the CONNECT
in the definition of PINGREQ.

> mostly consists in the last sentence being moved up.

[CS] I reworded it - let me know if it is more clear.

> which does not seems correct to me. The text that follows clarifies this

[CS] Neither mine, I reworded that as: "Authorizing connection requests
from the Clients to the Broker"
Actually, I also went through the text to reword "establishment" to set-up
which is simpler.

> <mglt>I have the impression an AS would be sufficient.</mglt>

[CS] Client Authorization Server was the terminology used in the Actors
draft - I've removed all other references but wanted to distinguish that
this is separate than the AS granting access tokens.
Can just say client's AS?

> propose to add "...other protocols than HTTPS, e.g ...

[CS] Added.

>    [I-D.ietf-ace-oauth-authz] with the profile set to "mqtt".

[CS]
When requesting an access token from the AS, the Client follows the token
request as is
described in Section 5.6.1 of the ACE framework, however, it MUST set the
profile parameter to 'mqtt_tls'.

> [CS] Should keep as-is for the time being?

> provided by the CONNECT message, I expect other credentials to be

[CS] TLS handshake uses only server-side certificate or RPK. I think this
is in the text.
That said there is a Github issue #16
https://github.com/ace-wg/mqtt-tls-profile/issues/16
around this, and will provide other clarifications as Jim asked.

> thus recommend to state it clearly in the introduction of the section..

[CS] I will actually reorganize this section, and hence, this will be more
clear.
Added your comment to issue #29, acknowledge that it is linked to #16 as
well.

I was trying to say the following, but I see that the text is not clear on
that:
- MUST: TLS with server validation + token in MQTT CONNECT (will clarify
server-side certificate/RPK)
- MAY: TLS with server/client validation with RPK -> token pushed to
"authz-info"
- MAY: TLS with server/client validation with PSK -> token in  psk_identity

> <mglt>see my comment in annex B.</mglt>
[CS] OK.

> authenticate the RS, is that the same RPK provided by the AS or another

[CS] No the RPK was suggested for the RS/Broker authentication.
As in the core ACE document, we assumed that the client learned either the
RS's public key
from the AS. However, I haven't seen in the core document an example of how
AS
returns this information to the client.

> [CS] Do you suggest that if AUTH method is used, MQTTv5 ignores
password/username?

> are include din the variable header and not the payload. </mglt>

[CS]
No, the CONNECT payload only includes Client Identifier, Will Properties,
Will Topic, Will Payload, User Name, Password.
AUTH data is variable header part of the CONNECT message.
Anyway, based on also Jim's input, using payload to do the PoP will be
dropped.
Jim suggested we use a nonce from the tls_exporter, and apply PoP to that.
We believe that is the better approach as well. These are related to issues
#15 ( https://github.com/ace-wg/mqtt-tls-profile/issues/15) and #19 (
https://github.com/ace-wg/mqtt-tls-profile/issues/19).

The CONNECT payload
> The nonce coded this way has a randomness of 62**23 =2**138 = 17 bytes

[CS] This section will be changed anyway... However, need to familiarize to
specify how to use Exporter Labels.
(Server can accept other characters.)

> [CS] Either Client or Server may initiate a disconnection. In either case,
the token is discarded.
The will may be sent if the client set up a will in case of unexpected
disconnection.

Though it needs to be clarified for instance, if there are retained
messages, these are sent as long as the token is valid.
Since the introspection results are cached, this can be still done but
should clarify unless it gets confusing.

To avoid any confusion, and not to have to discuss these things in that
section, I reworded as:
On Client or RS disconnection, the Client is expected to provide a token
again inside the next CONNECT message.

> I am also wondering why the token expiration cannot be considered as

[CS] This is to handle the situation where the resource owner changes the
permissions of the Client, which would revoke the token.
And hence the token exp field would not help.
 If the RS does not check the token introspection results, it
will use the token until its expiration time.
I've considered this more appropriate to be set by the RS as its RS risk
management.

> well as potential mechanisms to limit these risks.

[CS] It is indeed mentioned in this paragraph in the security consideration
section.
"The RS may monitor Client behaviour to detect potential security problems,
especially those affecting availability.
 These include repeated token transfer attempts to the public "authz-info"
topic, repeated connection attempts,
 abnormal terminations, and Clients that connect but do not send any data.
 If the RS supports the public "authz-info" topic, described in Appendix B,
 then this may be vulnerable to a DDoS attack, where many Clients use the
"authz-info" public topic
       to transport fictitious tokens, which RS may need to store
indefinitely."

Thank you for your comments. And will try to address Jim's shortly to be
able to push another version before the deadline.

Kind regards,
--Cigdem

>> The variable header may have several properties, and Authentication
>> Method and Authentication Data are two of these properties.
>>
>> 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.
>>
>>
>>
>> [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
>> >>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.
>>

---

From: Jim Schaad <[email-masked]>
Date: Wed, 30 Oct 2019 09:21:34 -0700

Just one quick comment below

From: Cigdem Sengul <[email-masked]> 
Sent: Wednesday, October 30, 2019 9:13 AM
To: Daniel Migault <daniel.migault=[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01

My comments are inside. I've also created the -v-02-WIP branch for the work in progress based on your and Jim's comments. 

On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault <daniel.migault=[email-masked] <mailto:[email-masked]> > wrote:

HI, 

AS is expanded. 

   MQTTS

<mglt>publishes</mglt>

[CS] Fixed.

   Subscription

[CS] Added. 

   PINGREQ

[CS] Added PINGRESP, clarified the Keep Alive period is set in the CONNECT in the definition of PINGREQ. 

   Will

<mglt>

2.  Protocol Interactions

[CS] Neither mine, I reworded that as: "Authorizing connection requests from the Clients to the Broker"

Actually, I also went through the text to reword "establishment" to set-up which is simpler. 

If the

[CS] Client Authorization Server was the terminology used in the Actors draft - I've removed all other references but wanted to distinguish that this is separate than the AS granting access tokens. 

[CS] Added. 

[CS] 

When requesting an access token from the AS, the Client follows the token request as is
described in Section 5.6.1 of the ACE framework, however, it MUST set the profile parameter to 'mqtt_tls'. 

[CS] TLS handshake uses only server-side certificate or RPK. I think this is in the text. 

That said there is a Github issue #16 https://github.com/ace-wg/mqtt-tls-profile/issues/16

MQTT session establishment via the CONNECT control message after the TLS handshake.
"""

</mglt>

[CS] I will actually reorganize this section, and hence, this will be more clear. 

Added your comment to issue #29, acknowledge that it is linked to #16 as well. 

I was trying to say the following, but I see that the text is not clear on that:

- MUST: TLS with server validation + token in MQTT CONNECT (will clarify server-side certificate/RPK)

- MAY: TLS with server/client validation with RPK -> token pushed to "authz-info"

 

[CS] OK. 

As in the core ACE document, we assumed that the client learned either the RS's public key

from the AS. However, I haven't seen in the core document an example of how AS 

[JLS] This is done using the ‘rs_cnf’ field

<mglt>

[CS] Do you suggest that if AUTH method is used, MQTTv5 ignores password/username?

 

[CS] 

No, the CONNECT payload only includes Client Identifier, Will Properties, Will Topic, Will Payload, User Name, Password.

Anyway, based on also Jim's input, using payload to do the PoP will be dropped. 

We believe that is the better approach as well. These are related to issues #15 ( https://github.com/ace-wg/mqtt-tls-profile/issues/15) and #19 (https://github.com/ace-wg/mqtt-tls-profile/issues/19). 

The CONNECT payload

<mglt>

[CS] This section will be changed anyway... However, need to familiarize to specify how to use Exporter Labels.  

[CS] Either Client or Server may initiate a disconnection. In either case, the token is discarded.

The will may be sent if the client set up a will in case of unexpected disconnection.

Though it needs to be clarified for instance, if there are retained messages, these are sent as long as the token is valid. 

Since the introspection results are cached, this can be still done but should clarify unless it gets confusing. 

To avoid any confusion, and not to have to discuss these things in that section, I reworded as: 

On Client or RS disconnection, the Client is expected to provide a token again inside the next CONNECT message.

 

[CS] This is to handle the situation where the resource owner changes the permissions of the Client, which would revoke the token.

I've considered this more appropriate to be set by the RS as its RS risk management. 

[CS] It is indeed mentioned in this paragraph in the security consideration section. 

"The RS may monitor Client behaviour to detect potential security problems, especially those affecting availability.

 These include repeated token transfer attempts to the public "authz-info" topic, repeated connection attempts,
 abnormal terminations, and Clients that connect but do not send any data.
 If the RS supports the public "authz-info" topic, described in Appendix B,
 then this may be vulnerable to a DDoS attack, where many Clients use the "authz-info" public topic
       to transport fictitious tokens, which RS may need to store indefinitely."

Thank you for your comments. And will try to address Jim's shortly to be able to push another version before the deadline. 

Kind regards, 

--Cigdem 

On Thu, Oct 17, 2019 at 2:47 PM Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

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

Hello Jim,

 

no session is present. 

Any thoughts?

Two cases.

 

 

The MQTT v5 draft says:

 

Will clarify in text.

[JLS] Ok

1) publish the will

Jim

Best, 

Jim

---

From: Cigdem Sengul <[email-masked]>
Date: Wed, 30 Oct 2019 16:34:07 +0000

Just saw it in the core document as well. Thanks, Jim.

--Cigdem

On Wed, Oct 30, 2019 at 4:21 PM Jim Schaad <[email-masked]> wrote:

> *Sent:* Wednesday, October 30, 2019 9:13 AM
> *To:* Daniel Migault <daniel.migault=[email-masked]>
> *Cc:* Jim Schaad <[email-masked]>; [email-masked];
> [email-masked]
> My comments are inside. I've also created the -v-02-WIP branch for the
> work in progress based on your and Jim's comments.
>
>
>
> We believe that is the better approach as well. These are related to
> issues #15 ( https://github.com/ace-wg/mqtt-tls-profile/issues/15) and
> #19 (https://github.com/ace-wg/mqtt-tls-profile/issues/19).
>
>
>
>
>
> The CONNECT payload
> "The RS may monitor Client behaviour to detect potential security
> problems, especially those affecting availability.
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 30 Oct 2019 13:06:42 -0400

Thank you for the response. Feel free to publish the updated version.
Please see my comments inline.
Yours,
Daniel

> [CS] I reworded it - let me know if it is more clear.
will have a look.

> Actually, I also went through the text to reword "establishment" to set-up
ok

> Can just say client's AS?
Maybe just explicitly saying it is different would be clearer. I will have
to re-read it.

>> [CS] Should keep as-is for the time being?
That was just a comment. I do not believe you could address this. So yes
let's keep it this way.

> is in the text..

great!

> - MAY: TLS with server/client validation with PSK -> token in

ok, it is also good to clarify which layer performs the authentication.
Will have a look at the text when the new version is published.

>>    detail in Appendix B..

Ok, this might need to be clarified even if that seems outside your
document.

>> [CS] Do you suggest that if AUTH method is used, MQTTv5 ignores
I think I was wondering why MQTT v3 was mentioned rather than v5. It seems
to me that there is no difference in our case - the only change being that
v5 permit password only.

> That is probably better to bind with the TLS. Please also clarify how it
could work with early_exporters, if that works.

> seems fine

> I've considered this more appropriate to be set by the RS as its RS risk

I do understand but I am questioning whether this is necessary or useful.

>  abnormal terminations, and Clients that connect but do not send any data..

perfect, the dead line is monday I think.

>>> be needed..   Being clear on the fact that this would not be expected is
>>> probably a good idea.
>>>
>>>
>>>
>>>
>>> Is this more clear? If yes, I will try to clarify in text..
>>>
>>>
>>>
>>> then never create sessions, and then server  MUST set Session Present
>>> to 0 in the CONNACK packet, indicating
>>>
>>> no session is present.
>>>
>>>
>>>
>>> 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?
>>>
>>>
>>>
>>> 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