Re: [auth48] AUTH48: RFC-to-be 9431 <draft-ietf-ace-mqtt-tls-profile-17> for your review

[Anthony Kirby <[e-mail]>]

I approve this RFC for publication.  Many thanks, Anthony

On Mon, 3 Jul 2023, 11:16 Cigdem Sengul, <[e-mail]> wrote:

> Hello,
> Thank you for the revisions. I only have the following change:
>
> 2.2.5.  Broker Token Validation
>
> OLD: i.e., a CWT token uses COSE, while a JWT token uses JOSE.
>
> NEW: i.e., a CWT  uses COSE, while a JWT uses JOSE.
>
> The rest looks great, and after this minor edit, I approve this RFC for
> publication.
> Thank you very much for all your work.
> Kind regards,
> --Cigdem
>
>
> On Tue, 20 Jun 2023 at 22:56, Alanna Paloma <[e-mail]> wrote:
>
>> Hi Cigdem,
>>
>> Thank you for your reply.  We have updated as requested.
>>
>> The files have been posted here (please refresh):
>>  https://www.rfc-editor.org/authors/rfc9431.xml
>>  https://www.rfc-editor.org/authors/rfc9431.txt
>>  https://www.rfc-editor.org/authors/rfc9431.html
>>  https://www.rfc-editor.org/authors/rfc9431.pdf
>>
>> The relevant diff files have been posted here:
>>  https://www.rfc-editor.org/authors/rfc9431-diff.html (comprehensive
>> diff)
>>  https://www.rfc-editor.org/authors/rfc9431-auth48diff.html (AUTH48
>> changes)
>>
>> Please review the document carefully and contact us with any further
>> updates you may have.  Note that we do not make changes once a document is
>> published as an RFC.
>>
>> We will await approvals from each party listed on the AUTH48 status page
>> below prior to moving this document forward in the publication process.
>>
>> For the AUTH48 status of this document, please see:
>>  https://www.rfc-editor.org/auth48/rfc9431
>>
>> Thank you,
>> RFC Editor/ap
>>
>>
>> > On Jun 20, 2023, at 8:34 AM, Cigdem Sengul <[e-mail]>
>> wrote:
>> >
>> > Thank you for your email. Please see my responses below.
>> > --Cigdem
>> >
>> > On Tue, 20 Jun 2023 at 00:00, <[e-mail]> wrote:
>> > Authors,
>> >
>> > While reviewing this document during AUTH48, please resolve (as
>> necessary) the following
>> > questions, which are also in the XML file.
>> >
>> > 1) <!--[rfced] To avoid awkward hyphenation, may we update the title as
>> follows?
>> >
>> > Original:
>> > Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication
>> > and Authorization for Constrained Environments (ACE) Framework
>> >
>> > Perhaps:
>> > Message Queuing Telemetry Transport (MQTT) and TLS Profile for the
>> > Authentication and Authorization for Constrained Environments (ACE)
>> > Framework
>> > -->
>> >
>> > I suggest:
>> >
>> > Message Queuing Telemetry Transport (MQTT) and Transport Layer Security
>> (TLS) profile of Authentication
>> > and Authorization for Constrained Environments (ACE) Framework
>> >
>> >
>> >
>> > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
>> the
>> > title) for use on https://www.rfc-editor.org/search. -->
>> >
>> > publish-subscribe, authorization information format
>> >
>> >
>> >
>> > 3) <!--[rfced] Please clarify; how does "and setting up the keying
>> material"
>> > relate to the rest of the sentence? Is it a second topic for which
>> > assumptions are made? Or, should "and" be "while"?
>> >
>> > Original:
>> >    This document makes the same assumptions as Section 4 of the ACE
>> >    framework [I-D.ietf-ace-oauth-authz] regarding Client and RS
>> >    registration with the AS and setting up the keying material.
>> >
>> > Perhaps:
>> >    This document makes the same assumptions as Section 4 of the ACE
>> >    framework [RFC9200] regarding Client and RS registration with the AS
>> >    and regarding the setup of the keying material.
>> > -->
>> >
>> >
>> > Suggested:
>> > This document makes the same assumptions as Section 4 of the ACE
>> >    framework [RFC9200] regarding Client and RS registration with the AS
>> >    for setting up the keying material.
>> >
>> >
>> > 4) <!--[rfced] Should this instance of "JWT token" be updated to read
>> simply as "JWT" to
>> > avoid redundancy (if expanded, "JWT token" would read "JSON Web Token
>> token")?
>> >
>> > Original:
>> >   A JWT token uses JOSE, while a CWT token uses COSE
>> >   [RFC8152] for security protection.
>> >
>> > Perhaps:
>> >   A JWT uses JOSE, while a CWT token uses COSE
>> >   [RFC8152] for security protection.
>> >
>> > Suggested (as the same argument applies to CWT):
>> >  A JWT uses JOSE, while a CWT uses COSE
>> >   [RFC8152] for security protection.
>> >
>> >
>> >
>> > Similarly, should "PSK key be updated to "PSK" (if expanded, "PSK key"
>> would read
>> > Pre-Shared Key key")?
>> >
>> > Original:
>> >    To use TLS 1.3 with pre-shared keys, the Client utilizes the PSK key
>> >    extension specified in [RFC8446] using the key conveyed in the "cnf"
>> >    parameter of the AS response.
>> >
>> > Perhaps:
>> >    To use TLS 1.3 with pre-shared keys, the Client utilizes the PSK
>> >    extension specified in [RFC8446] using the key conveyed in the "cnf"
>> >    parameter of the AS response.
>> > -->
>> >
>> > Yes, accepting the suggestion.
>> >
>> >
>> >
>> > 5) <!--[rfced] As "confidentiality" is not a term listed in RFC 4949
>> but "data
>> > confidentiality" is listed, we have updated the list below accordingly.
>> > Please let us know if further updates are needed.
>> >
>> > Original:
>> >    Certain security-related terms such as "authentication",
>> >    "authorization", "confidentiality", "(data) integrity", "message
>>
>> >    authentication code", and "verify" are taken from [RFC4949].
>> >
>> > Perhaps:
>> >    Certain security-related terms such as "authentication",
>> >    "authorization", "data confidentiality", "(data) integrity",
>> "message
>> >    authentication code", and "verify" are taken from [RFC4949].
>> > -->
>> >
>> > Yes, accepting the suggestion.
>> >
>> >
>> >
>> > 6) <!--[rfced] Please clarify; what does "labeled with their topics"
>> > refer to?
>> >
>> > Original:
>> >    The Clients are MQTT Clients, which connect to the
>> >    Broker to publish and subscribe to Application Messages, labelled
>> >    with their topics.
>> >
>> > Perhaps (if the Clients are labeled):
>> >    The Clients are MQTT Clients, which connect to the
>> >    Broker to publish and subscribe to Application Messages, and are
>> labeled
>> >    with their topics.
>> >
>> > Or (if the Application Messages are labeled):
>> >    The Clients are MQTT Clients, which connect to the
>> >    Broker to publish and subscribe to Application Messages (which are
>> >    labeled with their topics).
>> > -->
>> >
>> > The Or version is correct version and accepted: the Application
>> Messages are labeled.
>> > (This was written like this because MQTT v5 standard defines Topic Name
>> as
>> > The label attached to an Application Message which is matched against
>> the Subscriptions known to the Server.)
>> >
>> >
>> > 7) <!--[rfced] Should "Connection" be "Network Connection"?
>> >
>> > Original:
>> >   If the Network
>> >   Connection is closed without the Client first sending a
>> >   DISCONNECT packet with Reason Code 0x00 (Normal
>> >   disconnection) and the Connection has a Will Message, the
>> >   Will Message is published.
>> >
>> > Perhaps:
>> >   If the Network
>> >   Connection is closed without the Client first sending a
>> >   DISCONNECT packet with reason code 0x00 (Normal
>> >   disconnection) and the Network Connection has a Will Message, the
>> >   Will Message is published.
>> > -->
>> >
>> > It should remain as original.
>> > This was taken from MQTT v5 document: "If the Network Connection is
>> closed without the Client first sending a DISCONNECT packet with Reason
>> Code 0x00 (Normal disconnection) and the Connection has a Will Message, the
>> Will Message is published".
>> > The second "Connection" refers to MQTT Connection.
>> >
>> > Perhaps if unclear:
>> >   If the Network Connection is closed without the Client first sending a
>> >   DISCONNECT packet with reason code 0x00 (Normal
>> >   disconnection) and the MQTT Connection has a Will Message, the
>> >   Will Message is published.
>> >
>> >
>> >
>> > 8) <!--[rfced] Figure 1 has been widened slightly for readability;
>> > please review. Specifically, a single space was added after
>> > (C), (D), (E), and (F), which matches how (A) and (B) appear,
>> > and the second lines of labels were indented. The side-by-side diff
>> > file is here: https://www.rfc-editor.org/authors/rfc9431-rfcdiff.html
>> > -->
>> >
>> > This is all good.
>> >
>> >
>> >
>> > 9) <!--[rfced] Regarding Figure 2, may "Len." be changed to "Len" to
>> match
>> > other instances within this figure, or is this difference intentional?
>> > Also, will it be clear to readers how to read this diagram?
>> Specifically,
>> > the "Authentication Method" and "Authentication Data" portions seem
>> unclear.
>> > -->
>> >
>> >
>> > Please change "Len." to "Len".
>> > The figure is explained in  2.2.4.2.
>> > Old:
>> > To use AUTH, the Client MUST set the Authentication Method as a
>> property of a CONNECT packet by using the property identifier 21 (0x15).
>> This is followed by a UTF-8-encoded string containing the name of the
>> Authentication Method, which MUST be set to "ace". If the Broker does not
>> support this profile, it sends a CONNACK packet with reason code 0x8C (Bad
>> authentication method).
>> >
>> > New:
>> > Figure 2 shows the Authentication Method and Authentication Data fields
>> when the client authenticates using AUTH property. The Client MUST set the
>> Authentication Method as a property of a CONNECT packet by using the
>> property identifier 21 (0x15). This is followed by a UTF-8-encoded string
>> containing the name of the Authentication Method, which MUST be set to
>> "ace". If the Broker does not support this profile, it sends a CONNACK
>> packet with reason code 0x8C (Bad authentication method).
>> >
>> >
>> >
>> > 10) <!-- [rfced] Please review the "type" attribute of each sourcecode
>> element
>> > in the XML file to ensure correctness. If the current list of preferred
>> > values for "type" (
>> https://www.rfc-editor.org/materials/sourcecode-types.txt)
>> > does not contain an applicable type, then feel free to let us
>> > know. Also, it is acceptable to leave the "type" attribute not
>> > set.
>> >
>> > In addition, review each artwork element. Specifically,
>> > should any artwork element be tagged as sourcecode or another
>> > element?
>> >  -->
>> >
>> > "cddl" type is correct for the artwork in Figure 8.
>> >
>> > Fig 9 should be tagged with "sourcecode", with type "json".
>> >
>> > There is no other artwork to be tagged as source code.
>> >
>> >
>> >
>> > 11) <!--[rfced] As "PINGREQ" is defined in Section 1.3, we have updated
>> > "PINGREQUEST" to "PINGREQ". Please let us know if further updates are
>> needed.
>> >
>> > Original:
>> >   The Broker SHOULD check
>> >   for token expiration on receiving a PINGREQUEST.
>> >
>> > Current:
>> >   The Broker SHOULD check
>> >   for token expiration on receiving a PINGREQ packet.
>> > -->
>> >
>> > Thank you.
>> >
>> >
>> >
>> > 12) <!--[rfced] Do you agree with these changes (added 'the',
>> capitalized 'Client'
>> > to match usage within the document)? If so, we will ask IANA to update
>> the
>> > description in the registry (
>> https://www.iana.org/assignments/media-type-sub-parameters/)
>> > accordingly.
>> >
>> > Original: Permissions for MQTT client as defined in ...
>> >
>> > Current:  Permissions for the MQTT Client as defined in ...
>> > -->
>> >
>> > That is OK.
>> >
>> > 13) <!--[rfced] Please clarify the last part of this sentence;
>> specifically,
>> > what does the "which" clause describe? Is it the transport tokens that
>> > the Broker may need to store until they expire?
>> >
>> > Original:
>> >    If the Broker supports the public
>> >    "authz-info" topic, described in Section 2.2.2, then this may be
>> >    vulnerable to a DDoS attack, where many Clients use the "authz-info"
>> >    public topic to transport tokens that are not meant to be used, and
>> >    which the Broker may need to store until the tokens expire.
>> >
>> > Perhaps:
>> >    If the Broker supports the public
>> >    "authz-info" topic, described in Section 2.2.2, then this may be
>> >    vulnerable to a DDoS attack, where many Clients use the "authz-info"
>> >    public topic to to transport tokens that are not meant to be used
>> >    and that the Broker may need to store until they expire.
>> > -->
>> >
>> > Yes, it is the tokens that need to be stored. Accepting the suggestion.
>> >
>> >
>> > 14) <!--[rfced] RFC 7525 has been obsoleted by RFC 9325, and RFC 8152
>> has been
>> > obsoleted by RFC 9052. May these references be updated accordingly?
>> >
>> > RFC 7525 is cited once:
>> >    For TLS 1.2, however, a client
>> >    MUST support TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 for PSKs [RFC8442]
>> >    and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for RPKs [RFC8422], as
>> >    recommended in [RFC7525] (and adjusted to be a PSK cipher suite as
>> >    appropriate).
>> >
>> > RFC 8152 is cited once:
>> >    A JWT token uses JOSE, while a CWT token uses COSE
>> >    [RFC8152] for security protection.
>> > -->
>> >
>> >
>> > Yes, please.
>> >
>> >
>> > 15) <!-- [rfced] FYI, we have added expansions for the following
>> abbreviations
>> > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
>> > expansion in the document carefully to ensure correctness.
>> >
>> > Concise Binary Object Representation (CBOR)
>> > JSON Web Encryption (JWE)
>> > -->
>> >
>> > Correct.
>> >
>> >
>> > 16) <!--[rfced] We have made the following terminology capitalized for
>> consistency.
>> > Please review this occurrences carefully and let us know if further
>> updates
>> > are necessary.
>> >
>> > Will
>> > Will Delay Interval
>> > Will Flag
>> > Will Message
>> > Will Properties
>> > Will Retain
>> > Will Topic
>> > Will QoS
>> > -->
>> >
>> > All capitalizations are correct.
>> >
>> >
>> > 17) <!--[rfced] Throughout the text, the following terminology appears
>> to be used inconsistently.
>> >
>> > a) We have updated to use the form on the right. Please let us know of
>> any objections.
>> >
>> > Control Packet / control packet
>> > Fixed Header / fixed header
>> > password / Password
>> > Payload / payload
>> > username / Username
>> > Variable Header / variable header
>> >
>> > "Control Packet", "Fixed Header", and "Variable Header" are capitalized
>> in the MQTTv5 specification and, therefore, were capitalised here. (Source:
>> https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html)
>> >
>> > Password - capital is correct.
>> >
>> > "Username" is "User Name" in MQTTv5, and would be good if we keep the
>> same field names exactly as the MQTT protocol specifies in their
>> specification.
>> > (I acknowledge that the original text did not do a consistent job of
>> that).
>> >
>> > b) Please review the terms below and let us know if/how they may be
>> made consistent.
>> >
>> > Session vs. session
>> > Subscription vs. subscription
>> > -->
>> >
>> > For session, the following need to be capitalised:
>> > Section 1.3
>> > Old:
>> >  A Subscription comprises a Topic Filter and a maximum QoS. A
>> Subscription is associated with a single session.
>> > New:
>> >   A Subscription comprises a Topic Filter and a maximum QoS. A
>> Subscription is associated with a single Session.
>> >
>> > Section 2.2.4.1
>> > Old: The Connect flags in the variable header specify the properties of
>> the MQTT session.
>> > New: The Connect flags in the variable header specify the properties of
>> the MQTT Session.
>> >
>> > Old: In MQTT v5.0, the Client signals a clean session (i.e., that the
>> session does not continue an existing session) by setting the Clean Start
>> flag to 1 in the CONNECT packet. In this profile, the Client SHOULD always
>> start with a clean session. The Broker MAY also signal that it does not
>> support session continuation by setting the Session Expiry Interval to 0 in
>> the CONNACK. If the Broker starts a clean session, the Broker MUST set the
>> Session Present flag to 0 in the CONNACK packet to signal this to the
>> Client.
>> >
>> > New: In MQTT v5.0, the Client signals a new Session (i.e., that the
>> Session does not continue an existing Session) by setting the Clean Start
>> flag to 1 in the CONNECT packet. In this profile, the Client SHOULD always
>> start with a new Session. The Broker MAY also signal that it does not
>> support the continuation of an existing Session by setting the Session
>> Expiry Interval to 0 in the CONNACK. If the Broker starts a new Session,
>> the Broker MUST set the Session Present flag to 0 in the CONNACK packet to
>> signal this to the Client.
>> > --------
>> > Old: The Broker MAY support session continuation, e.g., if the Broker
>> requires it for QoS reasons. In this case, if a CONNECT packet is received
>> with Clean Start set to 0 and there is a Session associated with the Client
>> Identifier, the Broker MUST resume communications with the Client based on
>> the state from the existing Session. In its response, the Broker MUST set
>> the Session Present flag to 1 in the CONNACK packet to signal session
>> continuation to the Client. The session state stored by the Client and the
>> Broker is described in Section 5.
>> >
>> > New: The Broker MAY support continuing an existing Session, e.g., if
>> the Broker requires it for QoS reasons. In this case, if a CONNECT packet
>> is received with Clean Start set to 0, and there is a Session associated
>> with the Client Identifier, the Broker MUST resume communications with the
>> Client based on the state from the existing Session. In its response, the
>> Broker MUST set the Session Present flag to 1 in the CONNACK packet to
>> signal the continuation of an existing Session to the Client. The Session
>> State stored by the Client and the Broker is described in Section 5.
>> >
>> > Old: When reconnecting to a Broker that supports session continuation,
>> the Client MUST still provide a token in addition to using the same Client
>> Identifier and setting the Clean Start to 0. The Broker MUST still perform
>> PoP validation on the provided token. If the token matches the stored
>> state, the Broker MAY skip introspecting a token-by-reference and use the
>> stored introspection result. The Broker MUST also verify the Client is
>> authorized to receive or send MQTT packets that are pending transmission.
>> When a Client connects with a long Session Expiry Interval, the Broker may
>> need to maintain the Client's MQTT session state after it disconnects for
>> an extended period. Brokers SHOULD implement administrative policies to
>> limit misuse.
>> >
>> > New: When reconnecting to a Broker that supports continuing existing
>> Sessions, the Client MUST still provide a token in addition to using the
>> same Client Identifier and setting the Clean Start to 0. The Broker MUST
>> still perform PoP validation on the provided token. If the token matches
>> the stored state, the Broker MAY skip introspecting a token-by-reference
>> and use the stored introspection result. The Broker MUST also verify the
>> Client is authorized to receive or send MQTT packets that are pending
>> transmission. When a Client connects with a long Session Expiry Interval,
>> the Broker may need to maintain the Client's MQTT Session State after it
>> disconnects for an extended period. Brokers SHOULD implement administrative
>> policies to limit misuse.
>> > ------
>> > Old: Note that, according to the MQTT standard, the Broker uses the
>> Client Identifier to identify the session state. In the case of a Client
>> Identifier collision, a Client may take over another Client's session.
>> >
>> > New: Note that, according to the MQTT standard, the Broker uses the
>> Client Identifier to identify the Session State. In the case of a Client
>> Identifier collision, a Client may take over another Client's Session.
>> > ---------
>> > Section 2.4.2
>> > Old: If the Broker starts a new session, it MUST also set Session
>> Present to 0 in the CONNACK packet to signal a clean session to the Client.
>> Otherwise, it MUST set Session Present to 1.
>> >
>> > New: If the Broker starts a new Session, it MUST also set Session
>> Present to 0 in the CONNACK packet to signal a new Session to the Client.
>> Otherwise, it MUST set Session Present to 1.
>> >
>> > Section 5
>> > Old: In the case of a Client DISCONNECT, if the Session Expiry Interval
>> is set to 0, the Broker doesn't maintain session state but MUST keep the
>> retained messages. If the Broker maintains session state, the state MAY
>> include the token and its introspection result (for reference tokens) in
>> addition to the MQTT session state. The MQTT session state is identified by
>> the Client Identifier and includes the following:
>> >
>> > the Client subscription state,
>> >
>> > New:
>> > In the case of a Client DISCONNECT, if the Session Expiry Interval is
>> set to 0, the Broker doesn't store the Session State but MUST keep the
>> retained messages. If the Broker stores the Session State, the state MAY
>> include the token and its introspection result (for reference tokens) in
>> addition to the MQTT Session State. The MQTT Session State is identified by
>> the Client Identifier and includes the following:
>> >
>> > the Client Subscriptions,
>> > ----
>> > Old:
>> >    * if the Session is currently not connected, the time at which the
>> Session will end and session state will be discarded.
>> > The token/introspection state is not part of the MQTT session state,
>> and PoP validation is required for each new connection, regardless of
>> whether MQTT session continuation is used.
>> >
>> > New:
>> > * if the Session is currently not connected, the time at which the
>> Session will end and the Session State will be discarded.
>> > The token/introspection state is not part of the MQTT Session State,
>> and PoP validation is required for each new connection, regardless of
>> whether existing MQTT Sessions are continued.
>> >
>> > (Note that Session State is capitalised in MQTT Spec.)
>> >
>> > Section 6.1
>> > Old:  The Client SHOULD set the Clean flag to 1 to always start a new
>> session. If the Clean flag is set to 0, the Broker MUST resume
>> communications with the Client based on the state from the current Session
>> (as identified by the Client Identifier). If there is no Session associated
>> with the Client Identifier, the Broker MUST create a new session. The
>> Broker MUST set the Session Present flag in the CONNACK packet accordingly,
>> i.e., 0 to indicate a clean session to the Client and 1 to indicate session
>> continuation. The Broker MUST still perform PoP validation on the provided
>> Client token. MQTT v3.1.1 does not use a Session Expiry Interval, and the
>> Client expects that the Broker maintains the session state after it
>> disconnects. However, the stored session state can be discarded as a result
>> of administrator action or policies (e.g., defining an automated response
>> based on storage capabilities), and Brokers SHOULD implement administrative
>> policies to limit misuse.
>> >
>> > New: The Client SHOULD set the Clean flag to 1 to always start a new
>> Session. If the Clean flag is set to 0, the Broker MUST resume
>> communications with the Client based on the state from the current Session
>> (as identified by the Client Identifier). If there is no Session associated
>> with the Client Identifier, the Broker MUST create a new Session. The
>> Broker MUST set the Session Present flag in the CONNACK packet accordingly,
>> i.e., 0 to indicate a new Session to the Client and 1 to indicate that the
>> existing Session is continued. The Broker MUST still perform PoP validation
>> on the provided Client token. MQTT v3.1.1 does not use a Session Expiry
>> Interval, and the Client expects that the Broker maintains the Session
>> State after it disconnects. However, the stored Session State can be
>> discarded as a result of administrator action or policies (e.g., defining
>> an automated response based on storage capabilities), and Brokers SHOULD
>> implement administrative policies to limit misuse.
>> >
>> > Section 6.2
>> > Old: Therefore, the Broker will disconnect on almost any error and may
>> not keep the session state, necessitating that clients make a greater
>> effort to ensure that tokens remain valid and do not attempt to publish to
>> topics that they do not have permissions for.
>> >
>> > New: Therefore, the Broker will disconnect on almost any error and may
>> not keep the Session State, necessitating that clients make a greater
>> effort to ensure that tokens remain valid and do not attempt to publish to
>> topics that they do not have permissions for.
>> >
>> > Section 8
>> > Old: After the Broker validates an access token and accepts a
>> connection from a client, it caches the token to authorize a Client's
>> publish and subscribe requests in an ongoing session.
>> >
>> > New: After the Broker validates an access token and accepts a
>> connection from a client, it caches the token to authorize a Client's
>> publish and subscribe requests in an ongoing Session.
>> >
>> > Old: For MQTT v5.0, when a Client connects with a long Session Expiry
>> Interval, the Broker may need to maintain the Client's MQTT session state
>> after it disconnects for an extended period. For MQTT v3.1.1, the session
>> state may need to be stored indefinitely, as it does not have a Session
>> Expiry Interval feature. The Broker SHOULD implement administrative
>> policies to limit misuse of the session continuation by the Client.
>> >
>> > New: For MQTT v5.0, when a Client connects with a long Session Expiry
>> Interval, the Broker may need to maintain the Client's MQTT Session State
>> after it disconnects for an extended period. For MQTT v3.1.1, the Session
>> State may need to be stored indefinitely, as it does not have a Session
>> Expiry Interval feature. The Broker SHOULD implement administrative
>> policies to limit misuse by the Client resulting from continuing existing
>> Sessions.
>> >
>> > =====================================
>> > All "subscription" instances are to be capitalised to "Subscription"
>> with the following exceptions, which suggest additional changes following
>> MQTT specification:
>> >
>> > Section 3.2
>> > Old: To forward PUBLISH packets to the subscribing Clients, the Broker
>> identifies all the subscribers that have valid matching topic subscriptions
>> to the Topic Name of the PUBLISH packet (i.e., the tokens are valid, and
>> token scopes allow a subscription to this particular Topic Name).
>> >
>> > New: To forward PUBLISH packets to the subscribing Clients, the Broker
>> identifies all the subscribers that have valid matching Topic Subscriptions
>> to the Topic Name of the PUBLISH packet (i.e., the tokens are valid, and
>> token scopes allow a Subscription to this particular Topic Name).
>> > ---------------------
>> > Section 3.3
>> > Old: For example, if the Client sends a subscription request for topic
>> "a/b/*" and has a token that permits "a/*", this is a valid subscription
>> request, as "a/b/*" is a subset of "a/*". (The process is similar to a
>> Broker matching the Topic Name in a PUBLISH packet against the
>> Subscriptions known to the Server.)
>> >
>> > New: For example, if the Client sends a SUBSCRIBE request for topic
>> "a/b/*" and has a token that permits "a/*", this is a valid SUBSCRIBE
>> request, as "a/b/*" is a subset of "a/*". (The process is similar to a
>> Broker matching the Topic Name in a PUBLISH packet against the
>> Subscriptions known to the Server.)
>> > -------------------------------
>> >
>> >
>> >
>> > 18) <!-- [rfced] Please review the "Inclusive Language" portion of the
>> online
>> > Style Guide <
>> https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>> > and let us know if any changes are needed.
>> >
>> > Note that our script did not flag any words in particular, but this
>> should still
>> > be reviewed as a best practice.
>> > -->
>> >
>> > This was reviewed earlier, and no issues are expected.
>> >
>> > Please let me know if i need to make further clarifications.
>> > Kind regards,
>> > --Cigdem
>> >
>> > On Jun 19, 2023, [e-mail] wrote:
>> >
>> > *****IMPORTANT*****
>> >
>> > Updated 2023/06/19
>> >
>> > RFC Author(s):
>> > --------------
>> >
>> > Instructions for Completing AUTH48
>> >
>> > Your document has now entered AUTH48.  Once it has been reviewed and
>> > approved by you and all coauthors, it will be published as an RFC.
>> > If an author is no longer available, there are several remedies
>> > available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>> >
>> > You and you coauthors are responsible for engaging other parties
>> > (e.g., Contributors or Working Group) as necessary before providing
>> > your approval.
>> >
>> > Planning your review
>> > ---------------------
>> >
>> > Please review the following aspects of your document:
>> >
>> > *  RFC Editor questions
>> >
>> >   Please review and resolve any questions raised by the RFC Editor
>> >   that have been included in the XML file as comments marked as
>> >   follows:
>> >
>> >   <!-- [rfced] ... -->
>> >
>> >   These questions will also be sent in a subsequent email.
>> >
>> > *  Changes submitted by coauthors
>> >
>> >   Please ensure that you review any changes submitted by your
>> >   coauthors.  We assume that if you do not speak up that you
>> >   agree to changes submitted by your coauthors.
>> >
>> > *  Content
>> >
>> >   Please review the full content of the document, as this cannot
>> >   change once the RFC is published.  Please pay particular attention to:
>> >   - IANA considerations updates (if applicable)
>> >   - contact information
>> >   - references
>> >
>> > *  Copyright notices and legends
>> >
>> >   Please review the copyright notice and legends as defined in
>> >   RFC 5378 and the Trust Legal Provisions
>> >   (TLP – https://trustee.ietf.org/license-info/).
>> >
>> > *  Semantic markup
>> >
>> >   Please review the markup in the XML file to ensure that elements of
>> >   content are correctly tagged.  For example, ensure that <sourcecode>
>> >   and <artwork> are set correctly.  See details at
>> >   <https://authors.ietf.org/rfcxml-vocabulary>.
>> >
>> > *  Formatted output
>> >
>> >   Please review the PDF, HTML, and TXT files to ensure that the
>> >   formatted output, as generated from the markup in the XML file, is
>> >   reasonable.  Please note that the TXT will have formatting
>> >   limitations compared to the PDF and HTML.
>> >
>> >
>> > Submitting changes
>> > ------------------
>> >
>> > To submit changes, please reply to this email using ‘REPLY ALL’ as all
>> > the parties CCed on this message need to see your changes. The parties
>> > include:
>> >
>> >   *  your coauthors
>> >
>> >   *  [e-mail] (the RPC team)
>> >
>> >   *  other document participants, depending on the stream (e.g.,
>> >      IETF Stream participants are your working group chairs, the
>> >      responsible ADs, and the document shepherd).
>> >
>> >   *  [e-mail], which is a new archival mailing
>> list
>> >      to preserve AUTH48 conversations; it is not an active discussion
>> >      list:
>> >
>> >     *  More info:
>> >
>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>> >
>> >     *  The archive itself:
>> >        https://mailarchive.ietf.org/arch/browse/auth48archive/
>> >
>> >     *  Note: If only absolutely necessary, you may temporarily opt out
>> >        of the archiving of messages (e.g., to discuss a sensitive
>> matter).
>> >        If needed, please add a note at the top of the message that you
>> >        have dropped the address. When the discussion is concluded,
>> >        [e-mail] will be re-added to the CC list
>> and
>> >        its addition will be noted at the top of the message.
>> >
>> > You may submit your changes in one of two ways:
>> >
>> > An update to the provided XML file
>> > — OR —
>> > An explicit list of changes in this format
>> >
>> > Section # (or indicate Global)
>> >
>> > OLD:
>> > old text
>> >
>> > NEW:
>> > new text
>> >
>> > You do not need to reply with both an updated XML file and an explicit
>> > list of changes, as either form is sufficient.
>> >
>> > We will ask a stream manager to review and approve any changes that seem
>> > beyond editorial in nature, e.g., addition of new text, deletion of
>> text,
>> > and technical changes.  Information about stream managers can be found
>> in
>> > the FAQ.  Editorial changes do not require approval from a stream
>> manager.
>> >
>> >
>> > Approving for publication
>> > --------------------------
>> >
>> > To approve your RFC for publication, please reply to this email stating
>> > that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>> > as all the parties CCed on this message need to see your approval.
>> >
>> >
>> > Files
>> > -----
>> >
>> > The files are available here:
>> >   https://www.rfc-editor.org/authors/rfc9431.xml
>> >   https://www.rfc-editor.org/authors/rfc9431.html
>> >   https://www.rfc-editor.org/authors/rfc9431.pdf
>> >   https://www.rfc-editor.org/authors/rfc9431.txt
>> >
>> > Diff file of the text:
>> >   https://www.rfc-editor.org/authors/rfc9431-diff.html
>> >   https://www.rfc-editor.org/authors/rfc9431-rfcdiff.html (side by
>> side)
>> >
>> > Diff of the XML:
>> >   https://www.rfc-editor.org/authors/rfc9431-xmldiff1.html
>> >
>> > The following files are provided to facilitate creation of your own
>> > diff files of the XML.
>> >
>> > Initial XMLv3 created using XMLv2 as input:
>> >   https://www.rfc-editor.org/authors/rfc9431.original.v2v3.xml
>> >
>> > XMLv3 file that is a best effort to capture v3-related format updates
>> > only:
>> >   https://www.rfc-editor.org/authors/rfc9431.form.xml
>> >
>> >
>> > Tracking progress
>> > -----------------
>> >
>> > The details of the AUTH48 status of your document are here:
>> >   https://www.rfc-editor.org/auth48/rfc9431
>> >
>> > Please let us know if you have any questions.
>> >
>> > Thank you for your cooperation,
>> >
>> > RFC Editor
>> >
>> > --------------------------------------
>> > RFC9431 (draft-ietf-ace-mqtt-tls-profile-17)
>> >
>> > Title            : Message Queuing Telemetry Transport (MQTT)-TLS
>> profile of Authentication and Authorization for Constrained Environments
>> (ACE) Framework
>> > Author(s)        : C. Sengul, A. Kirby
>> > WG Chair(s)      : Daniel Migault, Loganaden Velvindron
>> > Area Director(s) : Roman Danyliw, Paul Wouters
>>
>>