Subject: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03

From: Jim Schaad <[email-masked]>
Date: Wed, 1 Jan 2020 14:33:01 -0800

2.2.2 - para 1, the last sentence seems to imply that the first connection
to publish to authz-info is not being done over a TLS connection.  But the
sentence before that states that a TLS connection MUST be used for this.
Perhaps s/and is expected to try reconnecting over TLS./and reconnects,
potentially using client authentication with TLS./

2.2.2 - I am unclear under what circumstances you could end put with a token
which does not parse when processing a PUBLISH message.  If the token cannot
be parsed at connection time, that I can understand.  However having parsed
the token then it does not make sense that the token becomes not parsable at
the time of publishing.  Am I missing something?

2.2.2 - The last paragraph is causing me confusion.  Is this supposed to be
referencing the RS or the AS?  If it is the AS, then I don't see how there
could be any confusion.  Please expand this so it is clearer.

2.2.4 - I am having a problem with trying to parse the content of the AUTH
property.  I have no problems with 2.2.4.3 because this is a zero length
sequence of bytes.  However for 2.2.4.1 and 2.2.4.2 there is a token
(possibly binary with no length prefix) followed by an optional binary
cryptographic value.  For introspection, I would need to figure out the
length of the token before I could make a guess at the length of the
cryptographic value.  However given that there is no divider this does not
seem possible.  This may also become a problem for the response from the
client in the event that there is a change from an 8-byte nonce to a
variable length one.

2.2.4.1 - In my view it is not the secret, but the content that is being
obtained from the TLS exporter.  That is one is signing (or MACing) the
exporter value not using that value to compute a MAC on something else.
While it is true that only the two parties know that value, exposure to a
third party does not lead to a compromise.

2.2.4.3 - I am not sure if the text is supposed to require an empty
authentication data field or to allow for the authentication data field to
be absent as well.

3 - It might be worth while to put a pointer to section 4.7 of the MQTT V5
spec here so that there is an indication of what the different wild card
characters do.  I had to pop over there to make sure that I could figure it
out.

3.1 - Should you state that for a QoS of 0, the client should close the
connection w/ an '0x87' in the event of an authorization failure?  I think
that this is supposed to happen but you have left it open.

6 - It is not clear to me if the authentication method described in this
section is permitted with MQTT v5 or not.  It does not say, but it appears
to be a true statement.  This should probably be explicit.

2.2.4.3 - What is the name of the user property that is being returned here?

I am going to play with something else.  I am sure I will find other issues
at a different time.

Jim

Nits:
Section 2 Para 1 s/Broker.Figure 1/Broker.  Figure 1/
Section 2 Para 1  s/setup.The/setup.  The/
Section 2.2.2 Last Para s/when the AS/when the RS/

---

From: Cigdem Sengul <[email-masked]>
Date: Tue, 14 Jan 2020 16:25:08 +0000

Thank you for this review, Jim.
Responses inline.

> potentially using client authentication with TLS./

[CS] Yes, that part reads confusing.
The aim was to say client authentication is not done over TLS, but
connection can be over TLS.
What it should be saying:
Client can use either mqtt or mqtts to connect to the broker, but does only
server validation, to push the token.
After pushing the token, it is expected to do TLS:Known(RPK/PSK)-MQTT:none.
(Although for PSK the token can be in psk_identity).
Issue created:  https://github.com/ace-wg/mqtt-tls-profile/issues/37

> the time of publishing.  Am I missing something?

[CS] There is a misunderstanding. The PUBLISH message refers to the actual
PUBLISH message to the "authz-info" topic which contains the token i.e.,
this may not parse to a token. (The PUBLISH message is not for other
messages that are permissioned in the token.)
The client connects (without much security), publishes the token to the
public "authz-info" topic, which only the broker can read.
Then, disconnects, and tries to connect with ace security.

Since MQTT v5 can return error messages in response to PUBLISH messages,
here, this is used to signal to the publisher that there is something wrong
with its token.

Added: https://github.com/ace-wg/mqtt-tls-profile/issues/38

> could be any confusion.  Please expand this so it is clearer.

[CS] This is a typo - it should be RS.
 https://github.com/ace-wg/mqtt-tls-profile/issues/39

> client in the event that there is a change from an 8-byte nonce to a

[CS] Not specified a  format, because I  thought we discarded the idea of
using the variable-length nonce based on the meeting in Singapore.
What would you suggest - introduce a specific format to accommodate
variable length?
length_of_token+binary data for token+(the rest is cryptographic value)?
 https://github.com/ace-wg/mqtt-tls-profile/issues/40

> third party does not lead to a compromise.

[CS] I see - so reword "secret" to "content".
Or do you have a suggestion for wording?
https://github.com/ace-wg/mqtt-tls-profile/issues/41

> authentication data field or to allow for the authentication data field to

[CS] I checked whether it would be a protocol error to have only
Authentication Method in MQTT, and it is not.
Then it is best to omit authentication data field.
Will correct the text that the document allows the CONNECT message to have
an Authentication Method set to 'ace' and allows to omit the Authentication
Data field.
https://github.com/ace-wg/mqtt-tls-profile/issues/42

> characters do.  I had to pop over there to make sure that I could figure it

[CS] Will do.
https://github.com/ace-wg/mqtt-tls-profile/issues/43

> that this is supposed to happen but you have left it open.

[CS]
Yes, I must have cut some text out. QoS of 0, the client is disconnected.
Will add.
https://github.com/ace-wg/mqtt-tls-profile/issues/44

> to be a true statement.  This should probably be explicit.

[CS] Yes,
MQTT v5 broker can support this method as well - we say at the beginning
something around backward compatibility to MQTT v3.1.1.
Will make it more explicit.
https://github.com/ace-wg/mqtt-tls-profile/issues/45

> [CS]
This is under-defined. It should say, the name pairs follow the same
optional (name, value) parameters for AS request creation hints as defined
in the core document. There could be multiple user properties in a CONNACK,
one needs to make sure the size of the message does not grow beyond the
Maximum Packet Size specified by the client.
 https://github.com/ace-wg/mqtt-tls-profile/issues/46

> I am going to play with something else.  I am sure I will find other issues

Thank you for your review. Much appreciated.
--Cigdem

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

---

From: Jim Schaad <[email-masked]>
Date: Fri, 17 Jan 2020 18:40:26 -0800

From: Cigdem Sengul <[email-masked]> 
Sent: Tuesday, January 14, 2020 8:25 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; Ace Wg <[email-masked]>
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03

Responses inline. 

On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

[CS] There is a misunderstanding. The PUBLISH message refers to the actual PUBLISH message to the "authz-info" topic which contains the token i.e., this may not parse to a token. (The PUBLISH message is not for other messages that are permissioned in the token.)

The client connects (without much security), publishes the token to the public "authz-info" topic, which only the broker can read. 

Since MQTT v5 can return error messages in response to PUBLISH messages, here, this is used to signal to the publisher that there is something wrong with its token. 

[JLS] Ok – I see where I got mixed in in reading this.  I think this may just be a problem on my end and you might not be able to do this better.

[CS] Not specified a  format, because I  thought we discarded the idea of using the variable-length nonce based on the meeting in Singapore. 

What would you suggest - introduce a specific format to accommodate variable length?

[JLS] I put in a comment on the github issue about what I was looking for.  Additionally,  my only possible problem with the fixed size nonce is that the IESG or Security Directorate down the line may decide that it is too small for some reason (16 bytes signed by a 521-bit (65+ byte key)).  Some might consider it to be small for a SHA-256 MAC operation.  Not the exact same situation here for TLS as it is not really a compact protocol.  But it may considered to be for the IoT variants being used.  I don’t know.

Jim

--Cigdem 

Jim

Nits:

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

---

From: Daniel Migault <[email-masked]>
Date: Tue, 21 Jan 2020 13:23:04 -0500

Hi,

I reviewed the current version of the draft and please see my comments
below. The quality of the document has improved a lot in my opinion. There
are also some parts I need to review more in depth (including the
security consideration).

Yours,
Daniel

[...]

1.  Introduction

[...]

   In this document, topics, more specifically, Topic Names, are treated
   as resources.  The Clients are assumed to have identified the
   publish/subscribe topics of interest out-of-band (topic discovery is
   not a feature of the MQTT protocol).  A resource owner can pre-
   configure policies at the AS that give Clients publish or subscribe
   permissions to different topics.

<mglt> AS should be expanded. As we introduce the ACE terminology, it might
be
good to specify if "resource" terminology is used related to RS. I am not
entirely sure... but if that is the case, it might be good to specify that
these resources are hosted on a Resource Server.

Though this is a very minor issue, there are multiple double spaces.</mglt>

   Clients use an access token, bound to a proof-of-possession (PoP) key to
authorize with the MQTT Broker their connection and publish/ subscribe
permissions to topics.

<mglt>Though I am an not english native, I have difficulties to parse "to
authorize with the MQTT Broker..." This is what I understand from the draft:
The permission to publish/suscbribe topics on a given MQTT Broker are
defined
by an  access token, bound to a proof-of-possession (PoP) key. The token is
provided by the AS and used by the Client's to access the RS. </mglt>

 In the context of this ACE profile, the Broker acts as
the Resource Server (RS).  In the rest of the document the terms "RS" and
"Broker" are used interchangeably.  This document describes how to authorise
the following exchanges between the Clients and the Broker.

<mglt>How to authorize... The wording sounds to me a bit strange though I
would
not pretend to have a better wording either, wouldn't associated permission
more in line with the ACE framework ?</mglt>

   o  Connection requests from the Clients to the Broker

   o  Publish requests from the Clients to the Broker, and from the
      Broker to the Clients

   o  Subscribe requests from Clients to the Broker

   This document does not protect the contents of the PUBLISH message
   from the Broker, and hence, the content of the the PUBLISH message is

<mglt>the the</mglt>

Sengul, et al.            Expires June 22, 2020                 [Page 3]

Internet-Draft           MQTT-TLS profile of ACE           December 2019

   not signed or encrypted separately for the subscribers.  This

<mglt>
It is the first time the document mentions PUBLISH. It would worth maybe to
specify it is an MQTT message.

I am wondering if encrypted stands for the opposite of not signed. If so, a
document may be signed but not encrypted.  I also understand that the
security
is performed by TLS or similar mechanism. If that is correct, it might be
clarifying to mention this is what we have in mind.  It is also unclear why
we
introduce subscribers and not Clients. Are we excluding intentionally the
publishers?

Maybe wording around: the PUBLISH message is unprotected or protected
via TLS (or equivalent mechanisms) for each Client's session. .

What is unclear to me is what the "content" of the PUBLISH message
represents.
If that is the data associated to the topic. I would have expected
authentication being performed by a signature mechanism and the signature
being
generated by the content owner, that is (I expect) the publisher. I think
that
data protection is out-of scope as well as MQTT based mechanisms as MQTT
recommends TLS.

</mglt>

   functionality may be implemented using the proposal outlined in the
   CoAP Pub-Sub Profile [I-D.palombini-ace-coap-pubsub-profile].

   To provide communication confidentiality and RS authentication, TLS
   is used and TLS 1.3 is RECOMMENDED.  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 setting up keying material.

<mglt> Is registration appropriated for the RS to the AS? </mglt>

   While the Client-Broker
   exchanges are only over MQTT, the required Client-AS and RS-AS
   interactions are described for HTTPS-based communication, using
   'application/ace+json' content type, and unless otherwise specified,
   using JSON encoding.  The token may be a reference, or JSON Web Token
   (JWT).  For JWT tokens, this document follows RFC 7800 [RFC7800] for
   PoP semantics for JWTs.

<mglt>For my own understanding I would like to check if reference stands for
reference to an access token or something else.   </mglt>

 The Client-AS and RS-AS may also be other
   than HTTPS e.g., CoAP or MQTT.

<mglt>I suspect some words are missing. Maybe "may also use other transport
protocol to carry the JWT.<.mglt>

Implementations MAY also use
   'application/ace+cbor' content type, and CBOR encoding, and CBOR Web
   Token (CWT) and associated PoP semantics to reduce the protocol
   memory and bandwidth requirements.  For more information on Proof of
   Possession semantics for CWTs, see Proof-of-Possession Key Semantics
   for CBOR Web Tokens (CWTs) [I-D.ietf-ace-cwt-proof-of-possession].

[...]

1.2.  ACE-Related Terminology

   The terminology for entities in the architecture is defined in OAuth
   2.0 RFC 6749 [RFC6749] such as "Client" (C), "Resource Server" (RS)
   and "Authorization Server" (AS).

   The term "Resource" is used to refer to an MQTT Topic Name, which is
   defined in Section 1.3.  Hence, the "Resource Owner" is any entity
   that can authoritatively speak for the topic.

<mglt>The introduction is using "resource", I propose the introduction text
is
coherent with the Terminology used latter in the document. </mglt>

   Certain security-related terms such as "authentication",
   "authorization", "confidentiality", "(data) integrity", "message
   authentication code", and "verify" are taken from RFC 4949 [RFC4949].

Sengul, et al.            Expires June 22, 2020                 [Page 4]

Internet-Draft           MQTT-TLS profile of ACE           December 2019

1.3.  MQTT-Related Terminology

   The document describes message exchanges as MQTT protocol
   interactions.  The Clients are MQTT Clients, which connect to the
   Broker to publish and subscribe to Application Messages, labeled with
   their topics.  For additional information, please refer to the MQTT
   v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1
   - the OASIS Standard [MQTT-OASIS-Standard].

   MQTTS
           Secured transport profile of MQTT.  MQTTS runs over TLS.

<mglt> I am wondering how appropriated it is to have sentence without verb.
I
probably think it is safer to use verb.</mglt>

   Broker
           The Server in MQTT.  It acts as an intermediary between the
           Clients that publishes Application Messages, and the Clients
           that made Subscriptions.  The Broker acts as the Resource
           Server for the Clients.

<mglt>Similar comment as before, there seems to have a missing verb.  While
Broker is defined, Client is not defined as a special term but instead in
the
introduction of the section. I am wondering if that would not be cleaner to
have Client also be defined. I am also wondering if Clients cannot be
designated as subscriber/publisher. Note this is a question I am wondering,
and
I do not think a specific terminology would be needed. Instead, I would
simply
suggest, that Clients includes subscribers and publishers as these terms are
used later.  </mglt>

   Application Message
           The data carried by the MQTT protocol.  The data has an
           associated QoS level and a Topic Name.

   QoS level
           The level of assurance for the delivery of an Application
           Message.  The QoS level can be 0-2, where "0" indicates "At
           most once delivery", "1" "At least once delivery", and "2"
           "Exactly once delivery".

   Topic Name
           The label attached to an Application Message, which is
           matched to a Subscription.

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

<mglt>It might be relevant to specify that subscriptions are associated to
one
session.  </mglt>

   Topic Filter
           An expression that indicates interest in one or more Topic
           Names.  Topic Filters may include wildcards.

   MQTT sends various control messages across a network connection.  The
   following is not an exhaustive list and the control packets that are
   not relevant for authorization are not explained.  These include, for
   instance, the PUBREL and PUBCOMP packets used in the 4-step handshake
   required for the QoS level 2.

<mglt>As a general comment, I would recommend to have the same definition as
those provided by MQTTv5. We could clearly mention these are from MQTTv5 and
are repeated here for the document to self contained. There is probably a
balance to find to introduce terms that are not used in this document, so
some
definitions may be partial using [...]. This is mostly a suggestion. </mglt>

   CONNECT

Sengul, et al.            Expires June 22, 2020                 [Page 5]

Internet-Draft           MQTT-TLS profile of ACE           December 2019

           Client request to connect to the Broker.  After a network
           connection is established, this is the first packet sent by a
           Client.

<mglt>I understand that network connection means the layers below MQTT. I
thing
this is confusing and would suggest to maybe remove "After a network
connection
is established,"</mglt>

   CONNACK
           The Broker connection acknowledgment.  The first packet sent
           from the Broker to a Client is a CONNACK packet.  CONNACK
           packets contain return codes indicating either a success or
           an error state to a Client.

   AUTH
           Authentication Exchange.  An AUTH packet is sent from the
           Client to the Broker or to the Broker to the Client as part
           of an extended authentication exchange.  AUTH Properties
           include Authentication Method and Authentication Data.  The
           Authentication Method is set in the CONNECT packet, and
           consequent AUTH packets follow the same Authentication
           Method.  The contents of the Authentication Data are defined
           by the Authentication Method.

   PUBLISH
           Publish request sent from a publishing Client to the Broker,
           or from the Broker to a subscribing Client.

   PUBACK
           Response to PUBLISH request with QoS level 1.  PUBACK can be
           sent from the Broker to a Client or a Client to the Broker.

   PUBREC
           Response to PUBLISH request with QoS level 2.  PUBREC can be
           sent from the Broker to a Client or a Client to the Broker.

   SUBSCRIBE
           The Client subscribe request.

<mglt>I would suggest to have similar wording for PUBLISH as for
SUBSCRIBE.</mglt>

   SUBACK
           Subscribe acknowledgment.

   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 also alive.  The "Keep Alive"
           period is set in the CONNECT message.

   PINGRESP
           Response sent by the Broker to the Client in response to
           PINGREQ.  It indicates the Broker is alive.

Sengul, et al.            Expires June 22, 2020                 [Page 6]

Internet-Draft           MQTT-TLS profile of ACE           December 2019

   Will
           If the network connection is not closed normally, the Server
           sends a last Will message for the Client, if the Client
           provided one in its CONNECT message.  If the Will Flag is
           set, then the payload of the CONNECT message includes
           information about the Will.  The information consists of the
           Will Properties, Will Topic, and Will Payload fields.

2.  Authorizing Connection Requests

   This section specifies how Client connections are authorized by the
   MQTT Broker.Figure 1 shows the basic protocol flow during connection
   set-up.The token request and response use the /token endpoint at the

<mglt> I suspect "/" should not be here and that url path is not
intended.</mglt>

[...]

2.2.1.  Client-Server Authentication over TLS and MQTT

   The Client and the Broker MUST perform mutual authentication.

<mglt>If I am correct this is also correct for the C-AS.</mglt>

 The
   Client MAY authenticate to the Broker over MQTT or TLS.

<mglt>My understanding of the sentence above is that the Client MAY
authenticate. Unless I am missing something, I would rather see MUST
instead.</mglt>

   For MQTT,
   the options are "None" and "ace".  For TLS, the options are "Anon"
   for anonynous client, and "Known(RPK/PSK)" for Raw Public Keys (RPK)
   and Pre-Shared Keys (PSK), respectively.  Combined, the Client
   authentication takes the following options:

   o  "TLS:Anon-MQTT:None": This option is used only for the topics that
      do not require authorization, including the "authz-info" topic.
      Publishing to the "authz-info" topic is described in
      Section 2.2.2.

<mglt>It is a bit unseal to describe unauthenticated channel as mutually
authenticated.</mglt>

   o  "TLS:Anon-MQTT:ace": The token is transported inside the CONNECT
message,
and MUST be validated using one of the methods described in Section 2.2.2.
This option also supports a tokenless connection request for AS discovery.

   o  "TLS:Known(RPK/PSK)-MQTT:none": For the RPK, the token MUST have
      been published to the "authz-info" topic.  For the PSK, the token
      MAY be, alternatively, provided in the "psk_identity".  The TLS
      session set-up is as described in DTLS profile for ACE
      [I-D.ietf-ace-dtls-authorize].

<mglt> Just to me sure I understand it properly. In this case the RPK or
PSK is
the one contained into the token. DTLS authenticate the TLS client via a
CertificateRequest. Other information related to the topic are performed by
the
MQTT. In order to perform perform the TLS authentication, the token with the
existing key needs to be found. The Broker upon receiving a CONNECT needs to
keep track of the used token.  </mglt>

   o  "TLS:Known(RPK/PSK)-MQTT:ace": This option SHOULD NOT be chosen.
      In any case, the token transported in the CONNECT overwrites any
      permissions passed during the TLS authentication.

<mglt>My understanding is that the same access token would be used.
Collision
would occurs when different access token would be used. However, when
authentication is performed using DTLS, the Broker, as I would understand
it,
keeps track of the used token, which should avoid the overwriting
rules.</mglt>

   It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace.

   The Broker MUST be authenticated during the TLS handshake.  If the
   Client authentication uses TLS:Known(RPK/PSK), then the Broker is
   authenticated using the respective method.

<mglt>I understand that when the server is authenticated using RPK, the
server
needs to be authenticated using RPK, but it is unclear why standard WPKI
would
not work. I understand that for PSK the same method can be used, though.
</mglt>

  Otherwise, to
   authenticate the Broker, the client MUST validate a public key from a
   X.509 certificate or an RPK from the Broker against the 'rs_cnf'
   parameter in the token response.  The AS MAY include the thumbprint

Sengul, et al.            Expires June 22, 2020                 [Page 9]

Internet-Draft           MQTT-TLS profile of ACE           December 2019

   of the RS's X.509 certificate in the 'rs_cnf' (thumbrint as defined
   in [I-D.ietf-cose-x509]), then the client MUST validate the RS
   certificate against this thumbprint.

2.2.2.  authz-info: The Authorization Information Topic

   In the cases when the Client MUST transport the token to the Broker
   before the TLS handshake, the Client connects to the Broker and
   publishes its token to the "authz-info" topic.  The "authz-info"
   topic MUST be publish-only (i.e., the Clients are not allowed to
   subscribe to it).  "authz-info" is not protected, and hence, the
   Client authenticates with the RS using the "TLS:Anon-MQTT:None"
   option.  After publishing the token, the Client disconnects from the
   Broker and is expected to try reconnecting over TLS.

   The Broker stores and indexes all tokens received to this topic in
   its key store similar to DTLS profile for ACE
   [I-D.ietf-ace-dtls-authorize].  This profile follows the
   recommendation of Section 5.8.1 of ACE framework
   [I-D.ietf-ace-oauth-authz], and expects that RS stores only one token
   per proof-of-possession key, and any other token linked to the same
   key overwrites existing token at the RS.

<mglt>I think the intend is to avoid having multiple access token that could
have the same PoP with different permissions. Keeping only the latest does
not
guarantee the client and the broker are considering the same ticket, and MAY
force client to perform a two step authentication at any time. In case of
rekey
or synchronization issues, this might generate more traffic than needed. I
would think that keeping track of the access token used by DTLS is safer,
the
way described here is only one way of doing it. </mglt>

[...]

2.2.4.1.  Proof-of-Possession Using a Challenge from the TLS session

   For this option, the Authentication Data MUST contain the token and
   the keyed message digest (MAC) or the Client signature.  The secret
   that is used for the proof-of-possession calculation, i.e., to
   calculate the keyed message digest (MAC) or the Client signature, is
   obtained using a TLS exporter ([RFC5705] for TLS 1.2 and for TLS 1.3,
   Section 7.5 of [RFC8446]).

<mglt>Just to make sure I follow, the secret is signed or MACed without
being
sent. The secret is not used to derive the key used to the signature or MAC.
Instead this key is in the access token.  If I am correct, the use of MAC or
signature is defined by the PoP symmetric or asymmetric. Correct ? I believe
the text could be clearer.  </mglt>

  The secret is exported from TLS using the
   exporter label 'EXPORTER-ACE-Sign-Challenge', an empty context, and
   length of 32 bytes.  The token is also validated as described in
   Section 2.2.5 and the server responds with a CONNACK with the
   appropriate response code.

2.2.4.2.  Proof-of-Possession via Broker-generated Challenge/Response

   For this option, the RS follows a Broker-generated challenge/response
   protocol.  The success case is illustrated in Figure 4.  If the
   Authentication Data only includes the token, the RS MUST respond with
   an AUTH packet, with the Authenticate Reason Code set to '0x18
   (Continue Authentication)'.  This packet includes the Authentication
   Method, which MUST be set to 'ace' and Authentication Data.  The
   Authentication Data MUST NOT be empty and contains an 8-byte nonce as
   a challenge for the Client.  The Client responds to this with an AUTH
   packet with a reason code '0x18 (Continue Authentication)'.
   Similarly, the Client packet sets the Authentication Method to 'ace'.
   The Authentication Data in the Client's response contains a client-
   generated 8-byte nonce, and the signature or MAC computed over the RS
   nonce concatenated with the client nonce.  Next, the token is
   validated as described in Section 2.2.5.

<mglt>I do not see exporters being involved, and if that is correct there
is no
channel binding. As DTLS is mandatory, wouldn't it be possible to add the
exporter to the nonces. This may also be used to increases the randomness of
the nonces</mglt>

[...]

3.1.  PUBLISH Messages from the Publisher Client to the Broker

   On receiving the PUBLISH message, the Broker MUST use the type of
   message (i.e., PUBLISH) and the Topic name in the message header to
   match against the scope string in the cached token or its
   introspection result.  Following the example above, a client sending
   a PUBLISH message to 'a/topic3' would be allowed to publish, as the
   scope includes the string 'publish_+/topic3'.

   If the Client is allowed to publish to the topic, the RS must publish

<mglt>While "must" may not be necessary, if used, it could be
normative.</mglt>

   the message to all valid subscribers of the topic.  In the case of an
   authorization failure, an error MAY be returned to the Client.  For
   this the QoS level of the PUBLISH message MUST be set to greater than
   or equal to 1.  This guarantees that RS responds with either a PUBACK
   or PUBREC packet with reason code '0x87 (Not authorized)'.

   On receiving a PUBACK with '0x87 (Not authorized)', the Client MAY
   reauthenticate as described in Section 4, and pass a new token
   following the same PoP methods as described in Figure 2.

3.2.  PUBLISH Messages from the Broker to the Subscriber Clients

   To forward PUBLISH messages to the subscribing Clients, the Broker
   identifies all the subscribers that have valid matching topic
   subscriptions (i.e., the tokens are valid, and token scopes allow a
   subscription to the particular topic).  The Broker sends a PUBLISH
   message with the Topic name to all the valid subscribers.

   RS MUST stop forwarding messages to the unauthorized subscribers.

<mgtl>I do not think they should have started. I am wondering if s/stop/NOT/
would not be better.</mglt>

   There is no way to inform the Clients with invalid tokens that an
   authorization error has occurred other than sending a DISCONNECT
   message.  The RS SHOULD send a DISCONNECT message with the reason
   code '0x87 (Not authorized)'.  Note that the server-side DISCONNECT
   is a new feature of MQTT v5.0 (in MQTT v3.1.1, the server needs to
   drop the connection).

[...]

4.  Token Expiration and Reauthentication

   The Broker MUST check for token expiration whenever a CONNECT,
   PUBLISH or SUBSCRIBE message is received or sent.  The Broker SHOULD
   check for token expiration on receiving a PINGREQUEST message.  The
   Broker MAY also check for token expiration periodically e.g., every
   hour.  This may allow for early detection of a token expiry.

   The token expiration is checked by checking the 'exp' claim of a JWT
   or introspection response, or via performing an introspection request
   with the AS as described in Section 5.7 of the ACE framework
   [I-D.ietf-ace-oauth-authz].  Token expirations may trigger the RS to
   send PUBACK, SUBACK and DISCONNECT messages with return code set to
   'Not authorised'.  After sending a DISCONNECT message, the network
   connection is closed, and no more messages can be sent.  However, as
   a response to the PUBACK and SUBACK, the Client MAY re-authenticate
   by sending an AUTH packet with a Reason Code of '0x19 (Re-
   authentication)'.

   To re-authenticate, the Client sends an AUTH packet with reason code
   '0x19 (Re-authentication)'.  The Client MUST set the Authentication
   Method as 'ace' and transport the new token in the Authentication
   Data.  The Client and the RS go through the same steps for proof of
   possession validation as described in Section 2.2.  The Client SHOULD
   use the same method used for the first connection request.

<mglt>I am wondering if there are good reasons for SHOULD. I would say that
using multiple authentication method with different level of trust SHOULD be
avoided. </mglt>

Sengul, et al.            Expires June 22, 2020                [Page 27]

On Fri, Jan 17, 2020 at 9:40 PM Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* Cigdem Sengul <[email-masked]>
> *Sent:* Tuesday, January 14, 2020 8:25 AM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* [email-masked]; Ace Wg <[email-masked]>
> *Subject:* Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03
>
>
>
> [JLS] Ok – I see where I got mixed in in reading this.  I think this may
> just be a problem on my end and you might not be able to do this better.
>
>
>
>
>
>
>
>
> [JLS] I put in a comment on the github issue about what I was looking
> for.  Additionally,  my only possible problem with the fixed size nonce is
> that the IESG or Security Directorate down the line may decide that it is
> too small for some reason (16 bytes signed by a 521-bit (65+ byte key)).
> Some might consider it to be small for a SHA-256 MAC operation.  Not the
> exact same situation here for TLS as it is not really a compact protocol.
> But it may considered to be for the IoT variants being used.  I don’t know.
>
>
>
>
>
> Jim
>
>
>
>

---

From: Cigdem Sengul <[email-masked]>
Date: Wed, 29 Jan 2020 12:09:54 +0000

Thank you for your review Daniel.
Comments inside.

On Tue, Jan 21, 2020 at 6:23 PM Daniel Migault <daniel.migault=
[email-masked]> wrote:

> <mglt> AS should be expanded. As we introduce the ACE terminology, it
> might be

[CS] AS - Fixed.
For RS related comment, added to the previous paragraph: "The MQTT Broker,
which acts as the Resource Server (RS), is responsible
distributing the messages published by the publishers to their subscribers.
Blank spaces: Noted, will take care of them in the next version.

> provided by the AS and used by the Client's to access the RS. </mglt>

[CS] OK. Changed to "Clients prove their permission to publish/subscribe to
topics hosted on an MQTT broker using an access token, bound to a
proof-of-possession (PoP) key."
Is this more clear.

> more in line with the ACE framework ?</mglt>

[CS] Fixed authorize. Kept the rest the same....

>    from the Broker, and hence, the content of the the PUBLISH message is

[CS] Fixed.

> clarifying to mention this is what we have in mind.  It is also unclear
> why we
> [CS] Preceded the sentence with "Clients use MQTT PUBLISH message to
publish to a topic."

What I meant was protecting the payload from the Broker. At the moment, the
broker is the end of TLS sessions for clients.
So, the Broker does see all the payloads -> if we would like to introduce
"confidential topics", which is the pub-sub document Francesca is working
on,
then the payload needs to be encrypted.  Publishers do not sign the payload
either.

Not excluding publishers really, it is just that the subscribers are the
recipients who would need to check the signature, decrypt if things were
protected.
Reworded as: "The document does not protect the payload of the PUBLISH
message from the Broker, and hence, the payload is not signed or encrypted
specifically for subscribers."

> <mglt> Is registration appropriated for the RS to the AS? </mglt>

[CS] I am not sure I understand the question.
This was referring to " It is also assumed that the RS has been registered
with the AS,
   potentially in a similar way as the client has been registered with
   the AS." in Section 4 of draft-ietf-ace-oauth-authz.
> reference to an access token or something else.   </mglt>
[CS] This is what the  draft-ietf-ace-oauth-authz  says in Section 3.1,
page 9: "The token is either a simple reference, or a structured
      information object."

> protocol to carry the JWT.<.mglt>

[CS] Corrected to: "The Client-AS and RS-AS  MAY also use protocols other
than HTTP e.g., CoAP or MQTT."

> <mglt>The introduction is using "resource", I propose the introduction
> text is

[CS] Changed to "resource".

> <mglt> I am wondering how appropriated it is to have sentence without
> verb. I

[CS] In other IETF drafts, I typically see a definition without a verb.

e..g,
 QUIC:  The transport protocol described by this document.

> designated as subscriber/publisher. Note this is a question I am
> wondering, and

[CS] Checking some RFCs, I see it is very common to use sentences like
below.
Have the rules of how to write terminology changed?

Added:
Client: A device or program that uses MQTT. (similar to MQTT descriptions).

It's actually important not to designate clients as publisher/subscriber.
A client should be able to get permissions to subscribe to x, and publish
to y.
Assume a client has the role of sending out a summary of all published
messages.
It should be able to both publish and subscribe.

> [CS} Sure. Added "A subscription is associated with a single session" at
the end.

> definitions may be partial using [....]. This is mostly a suggestion.
> </mglt>
>

[CS] We actually mostly do that anyway. They are just more concise.

> this is confusing and would suggest to maybe remove "After a network

[CS] OK. But, if we are following the advice of sticking with MQTT spec for
definitions, here is what the original says:
"After a Network Connection is established by a Client to a Server, the
first packet sent from the Client to the Server MUST be a CONNECT packet".

> <mglt>I would suggest to have similar wording for PUBLISH as for

[CS] Changed to: "Subscribe request sent from a Client".

> <mglt> I suspect "/" should not be here and that url path is not
[CS] Fixed.

> <mglt>If I am correct this is also correct for the C-AS.</mglt>
[CS] Yes, added to the previous section.
Actually: According to  draft-ietf-ace-oauth-authz: It is also REQUIRED
that the
   communicating endpoints perform mutual authentication.
Should it be repeated in the profile as well?

> authenticate. Unless I am missing something, I would rather see MUST

[CS]OK. The previous sentence say the Client MUST authenticate.
It may use either MQTT  or TLS to authenticate.
Still, I changed the sentence to:
"Client MUST authenticate to the Broker either over MQTT or TLS".

> <mglt>It is a bit unseal to describe unauthenticated channel as mutually

[CS] Himmm, not sure how to deal with this. This is the first step to the
Mutual authentication.
I can take this out describe separately. And then have only 3 options for
mutual authentication.
Any thoughts?

> CertificateRequest. Other information related to the topic are performed
> by the

[CS] We use TLS - give the DTLS profile as an example of the set-up for
ACE.
Yes: The token is validated, the client is authenticated, a secure TLS
channel with them using the info in the token.
The topic authorisation happens when the client tries to publish or
subscribe.

> keeps track of the used token, which should avoid the overwriting

[CS] This statement was in case two different tokens were used, the last
valid token overwrites the former.
i.e., u can not add to your permissions - there is no union.

> [CS] The language around TLS may have gotten more constrained because I
wanted to follow roughly
what DTLS profile for ACE says...
Though I do not have specific experience with WPKI.

> way described here is only one way of doing it. </mglt>

[CS] This is coming from draft-ietf-ace-oauth-authz, Page 37:

This specification RECOMMENDS that an RS stores only one token per
   proof-of-possession key, meaning that an additional token linked to
   the same key will overwrite any existing token at the RS.

I would like to follow this recommendation in this profile as it greatly
simplifies the implementation.
And, during a long MQTT session, the client may  push new tokens. The
behaviour should be the new token overwrites the old one.

> the text could be clearer.  </mglt>

Yes, correct. Added to the github issue to make this text clearer:
https://github.com/ace-wg/mqtt-tls-profile/issues/41

> exporter to the nonces. This may also be used to increases the randomness
[CS] I have to admit, I have gone back and forth about this.
Some implementers have commented not to have  TLS exporter support...

> <mglt>While "must" may not be necessary, if used, it could be

[CS] I tried to keep MQTT musts as "must" and  this profile's musts as
MUST.
Wouldn't that be acceptable?

> would not be better.</mglt>

[CS] Fixed.

> using multiple authentication method with different level of trust SHOULD

[CS] I am not sure any more if that sentence is necessary....

Thanks for your review again,
--Cigdem

>> [CS] There is a misunderstanding. The PUBLISH message refers to the
>> actual PUBLISH message to the "authz-info" topic which contains the token
>> i.e., this may not parse to a token. (The PUBLISH message is not for other

---

From: Daniel Migault <[email-masked]>
Date: Wed, 29 Jan 2020 09:53:59 -0500

Thanks for the comments, please see my responses. I have not answered
comments I had nothing to add in order to ease the readability of the
thread. That said, I thank you for addressing them.

In my opinion, there are a few comments, that needs the WG to state how to
address those, and I hope the interim meeting will help. My expectation is
that the next version will need to reviewed by a wider audience in the WG
so the draft can be moved forward.

Yours,
Daniel

On Wed, Jan 29, 2020 at 7:10 AM Cigdem Sengul <[email-masked]>
wrote:

> [CS] OK. Changed to "Clients prove their permission to publish/subscribe
> to topics hosted on an MQTT broker using an access token, bound to a
> What I meant was protecting the payload from the Broker. At the moment,
> the broker is the end of TLS sessions for clients.
> then the payload needs to be encrypted.  Publishers do not sign the
> payload either.
>
>> <mglt2>
I think. I was wondering whether it is common to consider registration for
RS, as I probably read subscription rather then registration. I think that
is fine. Registration is performed to the Broker to receive topics (Client)
or to publish topics (RS).
<mglt2>

>   <mglt2>
I agree this is in draft-ietf-ace-oauth-authz, but it is still unclear to
me what the reference can be. It is an ID privately agreed between the
parties, an URL,...
</mglt2>

>>    defined in Section 1.3..  Hence, the "Resource Owner" is any entity

<mglt2> correct, I cannot figure out what bothered me while reading the
definitions. Just go through them to check they are fine, while updating
the draft and I will be ok, with what you have.
<mglt2>

> <mglt>sentence or not does not seem relevant. you are correct.</mglt>

> It should be able to both publish and subscribe.
<mglt>Thanks for the clarification. That is useful to me. If you think that
coudl be usefull to be added to the definition, feel free to add it. </mglt>

>> <mglt>It might be relevant to specify that subscriptions are associated
>> to one
>> session.  </mglt>
>>

<mglt2>I agree there are not major differences, though it might be safer to
be as close as possible.</mglt2>

> [CS] OK. But, if we are following the advice of sticking with MQTT spec
> for definitions, here is what the original says:
>> <mglt2> My personal comparison - and I do not mean I am representative -
is that the later is clearer. Possible reasons are that the definition in
the draft defines CONNECT as a MQTT connect request which seems to me at
least some how circular as connection at MQTT layer is not defined. The
following sentence introduces network connection, and raised - at least to
me - some questions whether the connection was related to MQTT or underlay
network settings. It is also confusing to discuss MQTT, network layers and
MQTT.
I agree differences are in the details, but I would be inclined to take
advantage of this work already done.
</mglt2>

>> 2.2.1..  Client-Server Authentication over TLS and MQTT
>>
> <mglt>I would suggest yes, otherwise we wonder while the profile only
provide one part of it. </mglt2>

> "Client MUST authenticate to the Broker either over MQTT or TLS".
<mglt2>The difference is that we do limit the mechanisms used to
authenticate.</mglt2>

> I can take this out describe separately. And then have only 3 options for
<mglt>I have no strong opinion. The simplest way seems maybe to point out
this is mentioned as a first step to perform the mutual authentication. I
am open to any other ways to solve this. </mglt>

> i.e., u can not add to your permissions - there is no union.
<mglt2> I have the impression that the requirements is to ensure one token
is being used when more token are available. The document provides one way
to do, but does not leave room to other mechanisms or implementation. I am
wondering if that is something we want or if I am missing
something.</mglt2>

> <mglt>needs to be clarified by the WG.</mglt>
>

>> have the same PoP with different permissions. Keeping only the latest
>> does not
<mglt>I understand,  the motivation, maybe we should keep the mechanisms
described as RECOMMENDED only rather than having this normative. That said,
I am fine with what the WG thinks.</mglt>

> <mglt> Unless there is a clear decision from the WG, I believe this should
> discussed by the WG, and maybe documented in the document or the security
> considerations. </mglt>
>
>
>> [...]
>>
<mglt> I am fine with this alternative, so maybe you should clearly
indicate in the section that this document is not normative to MQTT, you
only use the normative language for the profile. If that is the only
section, please add this to the section otherwise in the terminology
section. It is good you keep must then, and implementer will interpret them
a MUST without the authority for them.</mglt>

>>> [CS] Not specified a  format, because I  thought we discarded the idea
>>> of using the variable-length nonce based on the meeting in Singapore.
>>>