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

[Cigdem Sengul <[e-mail]>]

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

--Cigdem

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

> Just one quick comment below
>
>
>
> *From:* Cigdem Sengul <[e-mail]>
> *Sent:* Wednesday, October 30, 2019 9:13 AM
> *To:* Daniel Migault <daniel.migault=[e-mail]>
> *Cc:* Jim Schaad <[e-mail]>; [e-mail];
> [e-mail]
> *Subject:* Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01
>
>
>
> 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.
>
>
>
> On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault <daniel.migault=
> [e-mail]> wrote:
>
> HI,
>
>
>
> Thanks for sending an update. Please find my comments of the draft.
>
>
>
>    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>
>
>
>
> [CS] Can add a similar recommendation for TLS 1.3.
>
> AS is expanded.
>
>
>
>
>
>
>
>    MQTTS
>            Secured transport profile of MQTT.  MQTTS runs over TLS.
>            The Server in MQTT acts as an intermediary between
>            Clients that publishes Application Messages, and the Clients
>            that made Subscriptions.  The Broker acts as the Resource
>            Server for the Clients.
>
> <mglt>publishes</mglt>
>
> [CS] Fixed.
>
>
>
>
>
>
>
>    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>
>
>
>
> [CS] Added.
>
>
>
>
>
>    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>
>
>
>
> [CS] Added PINGRESP, clarified the Keep Alive period is set in the CONNECT
> in the definition of PINGREQ.
>
>
>
>
>    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>
>
>
>
> [CS] I reworded it - let me know if it is more clear.
>
>
>
> 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>
>
>
>
> [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.
>
>
>
>
>
> 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>
>
>
>
> [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?
>
>
>    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>
>
>
>
> [CS] Added.
>
>
>
>
>
> 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>
>
>
>
> [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'.
>
>
>
>
>
>
>    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>
>
> [CS] Should keep as-is for the time being?
>
>
>
>
> 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>
>
>
>
> [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.
>
>
>    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>
>
>
>
> [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
>
>
>
>  This option is described in more
>    detail in Appendix B.
>
> <mglt>see my comment in annex B.</mglt>
>
>
>
>
>
> [CS] OK.
>
>
>
>
>    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>
>
>
>
> [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.
>
>
>
> [JLS] This is done using the ‘rs_cnf’ field
>
>
>
>
>
>
>
>    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>
>
>
>
>
>
> [CS] Do you suggest that if AUTH method is used, MQTTv5 ignores
> password/username?
>
>
>
>
>
>
>
> 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>
>
>
>
>
>
> [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
>    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>
>
>
>
> [CS] This section will be changed anyway... However, need to familiarize
> to specify how to use Exporter Labels.
>
> (Server can accept other characters.)
>
>
>
> 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>
>
>
>
> [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.
>
>
>
>
>
>    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>
>
>
>
>
>
> [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.
>
>
>
>
>
> 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>
>
>
>
> [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 <[e-mail]> wrote:
>
>
>
>
>
> *From:* Cigdem Sengul <[e-mail]>
> *Sent:* Thursday, October 17, 2019 4:13 AM
> *To:* Jim Schaad <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01
>
>
>
> Hello Jim,
>
> Thanks for this review. I have responded inline.
>
>
>
> 1.  Are there any specifics about using ACE over HTTP that need to be
> explicitly stated some place.  Some of these things might include:
>         a) Must be HTTPS even if encrypted requests/responses are
> provided.
>         b) What types of validation are permitted/required: anon-anon,
> server validation, server & client validation. The latter corresponds to
> current DTLS statements.
>         c) Are we looking for using the normal HTTP/HTTPS ports or should
> we
> be using different ports?
>
>
>
> >> Agreed. Need to specify that it is HTTPS.
>
> Mutual authentication and server validation Required.
>
> Was thinking it would be normal HTTPS ports. Should we consider different?
>
> What scenarios should permit anon-anon; anon clients?
>
>
>
> [JLS] If you look at my last email I went through this.  Anon-anon is
> going to be a bad idea because the server is never validated, however
> client anon is fine since you are going to validate the client in the MQTT
> protocol.
>
>
>
>
>
>
> 4.  Section 2.1.2: It is not clear from the document is a Broker is going
> to
> also have the possibility of doing a post of the token via HTTPS.
> Currently
> I would think not, but given that this is documented in OAuth 2.0 as an
> option I am not clear.
>
> >> Do you mean for introspection? Yes, this is a MAY as in the core
> document, and so in this one too.
>
> And if there is an RS-AS interaction, we expect that to be on HTTPS.
>
> I will try to see where I should clarify in the text.
>
>
>
> [JLS] No, I was originally looking at doing an HTTPS post of the token
> from the client to the RS.  This was before I figured out that you have an
> alternative method of doing this in the MQTT protocol and so it should not
> be needed.   Being clear on the fact that this would not be expected is
> probably a good idea.
>
>
>
>
> 7.   In Figure 2, I think the use of Client Identifier is somewhat
> confusing.  I think this is supposed to be the token as the Client
> Identifier is a different thing in MQTT.  Either that or you need to do a
> better job of describing the property block.
>
>
>
> OK. I think I should explain MQTT packets better.
>
> A connect packet has three parts: 1) Fixed header 2) Variable Header and
> 3) Payload.
>
> The variable header may have several properties, and Authentication Method
> and Authentication Data are two of these properties.
>
> According to MQTT Specification:
>
> The ClientID MUST be present and is the first field in the CONNECT packet
> Payload.
>
> The ClientID MUST be a UTF-8 Encoded String
>
> A Server MAY allow a Client to supply a ClientID that has a length of zero
> bytes, however, if it does so the Server MUST treat this as a special case.
>
>
>
> And this is what is done in the case of a collision:
>
> If the ClientID represents a Client already connected to the Server, the
> Server sends a DISCONNECT packet to the existing Client with Reason Code of
> 0x8E (Session taken over)
>
>
>
> Is this more clear? If yes, I will try to clarify in text.
>
>
>
> [JLS] That is not where I was having a problem.  I was getting confused by
> the figure itself.  Labeling the figure better might help.  “MQTT V5.0
> CONNECT control message with ‘ace’ authentication method”.  I would rather
> not have all of the abbreviations in the title, but I can live with it.
>
>
>
>
> 8.  If the value of Clean Start or Expiry Interval are not set correct is
> the server to fail the connect?
>
>
>
> >> Agreed. This should be specified.
>
> Two options: 1) Do not accept connection or 2) accept the connection but
> then never create sessions, and then server  MUST set Session Present to
> 0 in the CONNACK packet, indicating
>
> no session is present.
>
>
>
> This basically makes Clean Start flag meaningless.
>
> If this is better than client MUST be setting those parameters correctly,
> then we can go this way.
>
> Any thoughts?
>
>
>
> [JLS] I don’t really care one way or the other.  Given that there is the
> return value in the CONNACK, I think that a simple statement that the flag
> is set to 0 regardless of the value coming in.
>
>
>
>
> 10. Section 2.1.2.1 - I am having a problem computing the MAC over the
> payload of the CONNECT message.  The password where the value is placed is
> included in the payload and I am not clear if it should be computed up to
> that value or if a fixed value should be used for the computation.
>
>
>
> >>OK. I think it got muddled because I was trying to find a solution for a
> scenario where the ClientId is used across sessions, and hence, not random.
>
>
>
> Two cases.
>
> 1) Client ID uniquely random across each Client connection attempt to
> Broker: MAC over Payload - Payload begins with ClientID and MAY include
> Will Properties if Client indicated that it will have a will.
>
> 2) Client ID NOT uniquely random: MAC over Authentication Data.
>
>
>
> It may be best to choose one method and just say MUST always have a nonce
> in Authentication Data, and MAC is computed over that?
>
>
>
> [JLS] Lets step back and look at the problem I think you are trying to
> solve.
>
>    - If you are trying to make sure that there is not a replay of the
>    signature, then this would require that the server keep track of the list
>    of nonce values that the client has provided.
>    -  If you are trying to make sure that the signature is “fresh” then
>    the server would need to be able to provide some type of data as part of
>    the value being signed.  As I think I have said before the latter can be
>    satisfied by getting your nonce value from the TLS session using a
>    tls-exporter.
>
>
>
> If neither of these problems is trying to be solved, then there is no need
> for the nonce at all.
>
>
>
>
>
> 11. I am worried about the text on the Client Identifier in this section.
> It is not clear to me that having the client generate a random value for
> this field is good just in terms of the possibility of collisions occurring
> on the server.  The text in the MQTT 5.0 document appears to say that this
> is more interesting for the situation of getting back state that was left
> on
> the server after a disconnect and not so much for a clean session.
>
>
>
> >> Yes, but as I explained for comment 7, in MQTT, the typical case is the
> client provides its id.
>
> However, to cater to all requirements and all implementation
> possibilities, maybe it is best to just use a nonce as explained for
> comment 10 and not tie anything to client id.
>
>
>
> Previously, when we were writing the draft for MQTT v3.1.1 we wanted to
> provide a solution that uses the available fields in the CONNECT packet as
> much as possible; without
>
> introducing any new fields. This was because of the constraints of the
> MQTT v3.1.1. MQTT v5 gives us more options to implement this better.
>
>
>
> For backward compatibility, we would need to think if we create a special
> data structure to be used in the password so that it holds both the
> MAC/signature and the nonce.
>
>
>
> As the use of ClientId seems to create confusion, I am leaning towards
> this solution. Any thoughts?
>
>
>
> [JLS] Look at the previous answer and the re-ask the question.
>
>
>
>
>
> 13. Is there someplace that authentication methods need to be registered?
> I
> was unable to see any such registry setup with OASIS from the v5
> specification.  Should we suggest to the MQTT group that this is something
> that should be done?
>
>
>
> >> This is an interesting thought. The draft was indeed discussed in the
> OASIS MQTT WG.
>
>
>
> But, the WG may consider this out of scope, as they have on their charter
> page:
>
>  Transport level security is assumed and no mandatory security features
> will be added.
>
> The MQTT v5 draft says:
>
> The Authentication Method is commonly a SASL mechanism, and using such a
> registered name aids interchange. However, the Authentication Method is not
> constrained to using registered SASL mechanisms.
>
>
>
> [JLS] I think that the lack of a registry should be identified someplace
> in the document.  This is probably a security consideration that there
> might be a different authentication method which re-uses the same
> authentication method name.
>
>
>
>
>
> 17.  It is not clear to me, how in the scope string is the ability to have
> a
> "will" indicated?
>
> >> If the Will Flag is set to 1, the Will Topic follows the Client ID and
> Will Properties in the Payload.
>
> This is where the broker learns the Will Topic.
>
> Then the scope would be publish_<will topic>.
>
> And subscribes would need to subscribe_<will topic> to receive this
> message.
>
> Will clarify in text.
>
>
>
> [JLS] publish makes sense to me.  I was just being overly complicated.
>
>
>
> 18.  Section 2.1.4 - I am unsure what the implications of discarding tokens
> on the end of a connection are going to be.  How do you publish the token
> before doing the connection or is that only for an updated token?
>
>
>
> >> Tokens are discarded at the end of disconnection because no previous
> session state is kept.
>
> And a token is expected in the new CONNECT request (otherwise, it is AS
> discovery)
>
>
>
> Before the connection, a token may be transported via  "authz-info" topic
> described in Appendix B.
>
> During the connection, a new token may be transported via the AUTH packet
> - which enables reauthentication.
>
>
>
> [JLS] This is still not clear to me.  Is the transport of the token via
> “auth-info” topic not considered to be part of the session?  If you say
> that you look at just the last value published, then is there not going to
> be a race condition between two different clients trying to publish and
> connect?
>
>
>
>
> 20.  I am not sure what the benefits of doing the check on a PINGREQUEST is
> going to be.  Like the relay of a PUBLISH message this is just going to
> produce a DISCONNECT and a closed channel.  If this is really allowed, then
> you should potentially also say that the Broker could do a check based on
> clock time elapsing.  (I.e. do the check every hour.)
>
>
>
> >> This was suggested by one of the reviewers that provide MQTT services
> (his e-mail regarding this was sent to the ace list).
>
> It was suggested as an optimization for detecting token expirations and
> disconnecting early.
>
> (i.e., if you are already receiving PINGREQUESTs, use these as a trigger
> to check the token).
>
> I think time-based checks may also help and be added as an option.
>
>
>
> [JLS] Ok
>
>
>
>
> 22. Not sure if this goes here or in the connect documentation.  There
> needs
> to be a check that the will topic is a topic that the client is going to be
> permitted to publish on.   Corner case, if the ability to publish a will in
> the event that this permission is lost.  Does this kill the session or the
> will message?  I.e. should the permission for the will message be rechecked
> before sending it allowing for the time based expiration of the token.
>
>
>
> >> We have been thinking about this.
>
> If the disconnect is due to a token expiration, and hence, also includes
> the will topic as well, you have to decide between:
>
> 1) publish the will
>
> 2) do not publish the will.
>
> At the moment, it's written like we publish the will - but on second
> consideration,
>
> it seems safer to say "Publish the Will on Server Disconnect or unusual
> disconnect if the token (the will permission) has not expired".
>
>
>
> [JLS] I would be fine with either position, after all at the time the
> “publish” event occurred the token was valid, this is just deferring
> relaying it to subscribers.
>
>
>
> Jim
>
>
>
>
>
> Thanks again for these comments, will create the necessary github issues
> and start revising the text.
>
>
>
> Best,
>
>
>
>
> Jim
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>
>