ACE Working Group                                              C. Sengul
Internet-Draft                                                   Nominet
Intended status: Standards Track                                A. Kirby
Expires: November 8, 2019 April 7, 2020                                          Oxbotica
                                                            P. Fremantle
                                                University of Portsmouth
                                                             May 7,
                                                         October 5, 2019

                        MQTT-TLS profile of ACE
                   draft-ietf-ace-mqtt-tls-profile-00
                   draft-ietf-ace-mqtt-tls-profile-01

Abstract

   This document specifies a profile for the ACE (Authentication and
   Authorization for Constrained Environments) to enable authorization
   in an MQTT-based publish-subscribe messaging system.  Proof-of-
   possession keys, bound to OAuth2.0 access tokens, are used to
   authenticate and authorize publisher and subscriber clients. MQTT Clients.  The protocol relies on TLS
   for confidentiality and server authentication.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 8, 2019. April 7, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     1.2.  ACE-Related Terminology . . . . . . . . . . . . . . . . .   4
     1.3.  MQTT-Related Terminology  . . . . . . . . . . . . . . . .   4
   2.  Basic  Protocol Interactions . . . . . . . . . . . . . . . . .   5 . . .   6
     2.1.  Authorizing Connection Establishment  . . . . . . . . . .   6   7
       2.1.1.  Client Authorization Server (CAS) and Token Request to the Authorization Server (AS) Interaction   8
       2.1.2.  Client Connection Request to the Broker (C) . . . . .   8
         2.1.2.1.  Proof-of-Possession over Predefined Field . . . .  10
         2.1.2.2.  Proof-of-Possession via challenge/response  . . .  11
         2.1.2.3.  Unauthorised Request: Authorisation Server
                   Discovery . . .   7
       2.1.2.  Client Connection Request to the Broker . . . . . . .   8 . . . . . . . . . .  12
       2.1.3.  Token Validation  . . . . . . . . . . . . . . . . . .  10  12
       2.1.4.  The Broker's Response to Client Connection Request  .  11  13
     2.2.  Authorizing PUBLISH Messages  . . . . . . . . . . . . . .  12  13
       2.2.1.  PUBLISH Messages from the Publisher Client to the
               Broker  . . . . . . . . . . . . . . . . . . . . . . .  12  13
       2.2.2.  PUBLISH Messages from the Broker to the Subscriber
               Clients . . . . . . . . . . . . . . . . . . . . . . .  12  14
     2.3.  Authorizing SUBSCRIBE Messages  . . . . . . . . . . . . .  13  14
     2.4.  Token Expiration and Reauthentication . . . . . . . . . . . . . . . . . . . .  13  15
     2.5.  Handling Disconnections and Retained Messages . . . . . .  13  15
   3.  Improved  Reduced Protocol Interactions with for MQTT v5 . v3.1.1 . . . . . . . .  14  16
     3.1.  Token Transport via Authentication Exchange (AUTH) . . .  14 . . . . . . . . . . . . . . . . . .  16
     3.2.  Handling Authorization Errors and Client Re-authentication . . . .  16 . . . . . . . . . .  17
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17  18
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  17  18
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  18  19
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18  19
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  18  19
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  19  20
   Appendix A.  Checklist for profile requirements . . . . . . . . .  20  21
   Appendix B.  The Authorization Information Endpoint . . . . . . .  21
   Appendix C.  Document Updates . . . . . . . . . . . . . . . . . .  22
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  21  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21  23

1.  Introduction

   This document specifies a profile for the ACE framework
   [I-D.ietf-ace-oauth-authz].  In this profile, clients Clients and a resource
   server Broker
   use MQTT to communicate. exchange Application messages.  The protocol relies on
   TLS for communication security between entities.  The basic MQTT protocol
   interactions follow are described based on the MQTT v3.1.1 v5.0 - the OASIS
   Standard
   [MQTT-OASIS-Standard].  In addition, [MQTT-OASIS-Standard-v5].  It is expected that MQTT
   deployments will retain backward compatibility for MQTT v3.1.1
   clients, and therefore, this document describes
   improvements to the basic a reduced set of
   protocol with the new interactions suited to MQTT v5.0 v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard-v5] (e.g., improved authentication
   exchange and error reporting).  Both versions are expected
   [MQTT-OASIS-Standard].  However, it is RECOMMENDED to be
   supported in practice, use MQTT v5.0
   as it works more naturally with ACE-style authentication and therefore, covered in this document.
   authorization.

   MQTT is a publish-subscribe protocol and supports two main types of
   client
   Client operation: publish and subscribe.  Once connected, a client Client
   can publish to multiple topics, and subscribe to multiple topics;
   however, for this document, these actions are described separately. topics.
   The MQTT broker Broker is responsible for distributing messages published by
   the publishers to the appropriate subscribers.  Each publish message
   contains a topic, Topic Name, which is used by the broker Broker to filter the
   subscribers for the message.  Subscribers must subscribe to the
   topics to receive the corresponding messages.

   In this document, message topics are treated as resources.  Clients
   use an access token, bound to a key (the proof-of-possession key) to
   authorize with the MQTT broker Broker their connection and publish/subscribe
   permissions to topics.  In the context of this ACE profile, the MQTT
   broker
   Broker acts as the resource server. Resource Server (RS).  In the rest of the document
   RS and Broker are used interchangeably.  To provide communication
   confidentiality and resource server Resource Server authentication, TLS is used.

   Clients use client authorization servers [I-D.ietf-ace-actors] to
   obtain tokens from the authorization server.  The communication
   protocol between the client authorization server and the
   authorization server is assumed to be HTTPS.  Also, if the broker
   supports token introspection, it is assumed to use HTTPS to
   communicate with the authorization server.  These interfaces MAY be
   implemented using other protocols, e.g., CoAP or MQTT.
   This document makes the same assumptions as the Section 4 of the ACE
   framework [I-D.ietf-ace-oauth-authz] regarding client Client and RS
   registration with the AS and establishing of keying material.

   This document describes the authorization of the following exchanges
   between publisher and subscriber clients, Clients and the broker. Broker.

   o  Connection establishment between the clients Clients and the broker Broker

   o  Publish messages from the publishers Clients to the broker, Broker, and from the
      broker
      Broker to the subscribers Clients

   o  Subscribe messages from the subscribers Clients to the broker

   In Section 2, these exchanges are described based on the MQTT v3.1.1
   - Broker

   While the OASIS Standard [MQTT-OASIS-Standard].  These Client-Broker exchanges are also
   supported by the new MQTT v5 - over MQTT, the OASIS Standard
   [MQTT-OASIS-Standard-v5].  Section 3 describes how they 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
   improved by a
   reference, or JWT.  For JWT tokens, this document follows RFC 7800
   [RFC7800] for PoP semantics for JWTs.  The Client-AS and RS-AS may
   also be based on CoAP.  It is also possible to use 'application/
   ace+cbor' content type, and CBOR encoding, and CWT and associated PoP
   semantics to reduce the new MQTT v5. 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.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174], when, and only when, they appear in all
   capitals, as shown here.

1.2.  ACE-Related Terminology

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

   The term "endpoint" is used following its OAuth definition, to denote
   resources such as /token and /introspect at the AS.

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

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

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.  For
   additional information, please refer to the MQTT
   v3.1.1 v5.0 - the OASIS
   Standard [MQTT-OASIS-Standard] [MQTT-OASIS-Standard-v5] or the MQTT v5 v3.1.1 - the OASIS
   Standard [MQTT-OASIS-Standard-v5].

   Topic name [MQTT-OASIS-Standard].

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

   Broker
           The label attached to Server in MQTT and acts as an application message, which is
           matched to a subscription.

   Topic filter
           An expression intermediary between
           Clients that indicates interest in one or more topic
           names.  Topic filters may include wildcards.

   Subscription
           A subscription comprises a Topic filter publish Application Messages, and a maximum quality
           of service (QoS). the Clients
           that made Subscriptions.  The Broker acts as the Resource
           Server for the Clients.

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

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

   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.

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

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

   PUBLISH
           Publish packet that can be sent from a client Client to the broker, Broker,
           or from the broker Broker to a client. Client.

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

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

   SUBSCRIBE
           The client Client subscribe request.

   SUBACK
           Subscribe acknowledgment.

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

   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.

2.  Basic  Protocol Interactions

   This section describes the following exchanges between publisher and
   subscriber clients, Clients, the broker,
   Broker, and the authorization server Authorization Server according to the MQTT v3.1.1 - the OASIS Standard
   [MQTT-OASIS-Standard].  These exchanges are compatible also with the
   new MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5].  In
   addition, Section 3 describes how these exchanges may be improved
   with the MQTT v5. v5.0.

   o  Authorizing connection establishment between the clients Clients and the
      broker
      Broker

   o  Authorizing publish messages from the publishers Clients to the broker, Broker, and
      from the broker Broker to the subscribers Clients

   o  Authorizing subscribe messages from the subscribers Clients to the broker

   Message Broker

   Section 3 describes how these exchanges can also be supported using
   the MQTT v3.1.1.  MQTT v5.0 brokers MAY also only support the basic
   operation; however, this is NOT RECOMMENDED.

   In this profile document, message topics are treated as resources.
   The publisher and
   subscriber clients 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 connection request carries a token specifying the permissions that
   the client has (e.g., publish permission to a given topic).  A resource owner can pre-configure policies at
   the AS that give clients Clients publish or subscribe permissions to
   different topics.

2.1.  Authorizing Connection Establishment

   This section specifies how publishers and subscribers Clients establish an authorized connection
   to an MQTT broker.  The Broker.  Figure 1 shows the basic protocol flow during
   connection establishment.The token request and response use the
   /token endpoint of the authorization server, as specified in the
   Section 5 5.6 of the ACE framework [I-D.ietf-ace-oauth-authz].

   Figure 1 shows  Steps
   (D) and (E) are optional, and use the basic protocol flow during connection
   establishment. introspection endpoint,
   specified in the Section 5.7 of the ACE framework.  The step (C), client onboarding, Client and
   Broker use HTTPS to communicate to AS via these endpoints.  If the
   Client is resource-constrained, a Client Authorisation Server may
   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.  The
   interactions between a Client and its Client Authorization Server for
   token onboarding, and the MQTTS support for token requests are out of
   scope of this document.  Steps (E) and (F) are optional.

                               +----------------+

                             +---------------------+
                             | Client              |
                             |                     |
      +---(A) Token request----| request--| Client -            |
      |                      | Authorization       |
      |   +-(B) Access token-->| token-> Server Interface    |
      |   |                    |________________|
      |   |                  |       (HTTPS)       |
      |                (C) Client On-boarding   |                  |_____________________|
      |   |                  |                     |                  +---------v-----+
   +--v-------------+        | Publisher or  |
   |  Pub/Sub Interface  |
   | Subscriber  Authorization |        |  Authorization     (MQTTS)         |        |_______________|
   |  Server        |            |       ^        +-----------^---------+
   |________________|            |       |
      |    ^             (D)Connection  (G)Connection             (C)Connection  (F)Connection
      |    |               request +    response
      |    |               access token  |
      |    |                     |       |
      |    |                 +---v--------------+
      |    |                 |   Broker (MQTTS) |
      |    +(E)Introspection-| Resource Server    |                 |__________________|
      |    +(D)Introspection-|                  |
      |   request (optional) | RS-AS interface  |
      |                      |
      +-(F)Introspection---->|__________________|     (HTTPS)      |
      +-(E)Introspection---->|__________________|
        response (optional)

                    Figure 1: Connection establishment

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

   The first step in the protocol flow (Figure 1 (A)) is the token
   acquisition by the client authorization server (CAS) Client from the AS.  If
   a client has enough resources and can support HTTPS, or optionally
   the AS supports MQTTS, these steps can instead be carried out by a
   client directly.  When requesting an access
   token from the AS, the CAS 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 content type media format is set to
   "application/json". 'application/
   ace+json'.  The profile parameter is 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.

   If the AS successfully verifies the access token request and
   authorizes the client Client for the indicated audience (e.g., RS) and
   scopes (e.g., publish/subscribe permissions over topics), the AS
   issues an access token (Figure 1 (B)).  The response includes the
   parameters described in Section 5.6.2 of the ACE framework
   [I-D.ietf-ace-oauth-authz].  The included token is assumed to be
   Proof-of-Possession (PoP) token by default.  Hence,  This document follows
   RFC 7800 [RFC7800] for PoP semantics for JWTs.  The PoP token
   includes a 'cnf' parameter with a symmetric or asymmetric PoP key is returned.  The token may be
   a reference, or a CBOR or JWT web token. key.
   Note that the 'cnf' parameter in the web tokens are to be consumed by
   the resource server and not the client.  For more information on Proof of Possession
   semantics in JWTs see RFC 7800 [RFC7800] and for CWTs, see Proof-of-
   Possession Key Semantics for CBOR Web Tokens (CWTs)
   [I-D.ietf-ace-cwt-proof-of-possession].

   In the case Client.

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

2.1.2.  Client Connection Request to the Broker

   Once the client acquires the token, it can use it to request an MQTT
   connection to the broker over a TLS session with server
   authentication (Figure 1 (D)). (C)

   This section describes how the client
   transporting Client transports the token to the broker
   Broker (RS) via the CONNECT control message after the TLS handshake.
   This is similar to an earlier proposal by Fremantle et al.
   [fremantle14].  An improvement to this
   is presented in Section 3 for the MQTT v5 - the OASIS Standard
   [MQTT-OASIS-Standard-v5].  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.  This may additionally require that
   the client Client transports the token to the broker Broker before the connection
   establishment.  To this end, the broker Broker MAY support /authz-info
   endpoint via the "authz-info" topic.  Then, to transport the token, clients
   Clients publish to "authz-info" topic unauthorized.  The topic
   "authz-info" MUST be publish-only for clients Clients (i.e., the
   clients Clients are
   not allowed to subscribe to it).  This option is described in more
   detail in Appendix B.

   When

   After the client wishes to connect token acquisition, the Client connects to the broker, it uses RS (Broker)
   using the CONNECT message of MQTT. 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.  The
   client needs to use this raw public key in the TLS handshake together
   with an out-of-band validation technique (see RFC 7250 [RFC7250] for
   details).

   Figure 2 shows the structure of the MQTT CONNECT control message. message used
   in MQTT v5.0.  A CONNECT message is composed of a fixed header, a
   variable header and a payload.  The fixed header contains Control
   Packet Type (CPT), Reserved, and Remaining Length.  The Variable
   Header contains the Protocol Name, Protocol Level, Connect Flags,
   Keep Alive, and Properties.  The Connect Flags in the variable header
   specify the behavior of the MQTT connection.  It also indicates the
   presence or absence of fields in the Payload.  The payload contains
   one or more encoded fields, namely a unique Client identifier for the
   Client, a Will Topic, Will Payload, User Name and Password.  All but
   the Client identifier can be omitted depending on flags in the
   Variable Header.

          0            8            16            24            32
          +------------------------------------------------------+
          |CPT=1 | Rsvd.|Remaining len.| Protocol  name len. = 4 |
          +------------------------------------------------------+
          |                      'M' 'Q' 'T' 'T'                 |
          +------------------------------------------------------+
          | Proto.level=4|Connect Proto.level=5|Connect flags|          Keep alive     |
          +------------------------------------------------------+
          | Payload                 Property length                      |
          |     Username as access token (UTF-8)          Auth. Method (0x15) | 'ace'                 |     Password length (2 Bytes)
          |          Auth. Data (0x16)   |     Password empty or token or     |
          |                                token + PoP data as signature/MAC (binary)      |
          +------------------------------------------------------+
          |                           ...           Payload: Client Identifier                 |
          +------------------------------------------------------+

    Figure 2: MQTT CONNECT control message.  (CPT=Control Packet Type,
               Rsvd=Reserved, len.=length, Proto.=Protocol)

   To communicate the necessary connection parameters, the Client uses
   the appropriate flags of the CONNECT message.  Figure 3 shows how

   Connect Flags include Clean Start, Will, Will QoS, Will Retain,
   Password and Username flags.  Figure 6 shows how the MQTT connect
   flags MUST be set to initiate a connection with the
   broker. Broker.

   +-----------------------------------------------------------+
   |User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.|
   | flag    |flag |           |        |         |     |      |
   +-----------------------------------------------------------+
   | 1 0       | 1 0   |    X      |   X X  |   X     |  1   |  0  |
   +-----------------------------------------------------------+

              Figure 3: MQTT CONNECT flags.  (Rsvd=Reserved)

   To ensure that the client and achieve a clean session (i.e., the broker discard any previous session
   and start a new session, starts without an
   existing session), the Clean Session Start Flag MUST be set to 1.  In
   addition, if the Session Expiry Interval is present in the CONNECT
   message, it MUST be set to 0.

   The Will flag Flag indicates that a Will message needs to be sent when a
   client disconnection occurs. if
   network connection is not closed normally.  The situations in which
   the Will message is published include disconnections due to I/O or
   network failures, and the server closing the networking network connection due
   to a protocol error.  The client Client may set the Will flag Flag as desired
   (marked as 'X' in Figure 3).  If the Will flag Flag is set to 1 and the broker
   Broker accepts the connection request, the broker Broker must store the Will
   message, and publish it when the network connection is closed
   according to Will QoS and Will retain parameters, and MQTT Will
   management rules.  To avoid publishing Will Messages in the case of
   temporary network disconnections, the Client my specify a Will Delay
   Interval in Will Properties.  Section 2.5 explains how the broker Broker
   deals with the retained messages in further detail.

   Finally, Username and Password flags MUST be set to 1 to ensure that
   the Payload of

   For token transport, the CONNECT message includes both Username and
   Password fields. RS SHOULD support AUTH (Authentication
   Exchange) method.  The CONNECT message defaults to ACE for authentication RS MAY support token transport via username
   and
   authorization.  For the basic operation password, which is described in Section 3 for MQTT v3.1.1.  The
   rest of this section, section describes the Username field MUST be set to AUTH method, for which the access token.  The Password
   field
   username and password flags MUST be set to 0.

   To implement the keyed message digest (MAC) or signature
   associated with the access token for proof-of-possession.  The client
   MAY apply AUTH (Authentication Exchange) method, the PoP key either to Client
   MUST set the entire request by computing Authentication Method as a
   keyed message digest (for symmetric key) or property of a digital signature (for
   asymmetric key).  The CONNECT message is assumed to have enough
   randomness in packet
   by using the payload, and inside property identifier 21 (0x15).  This is followed by a TLS session (excluding
   UTF-8 Encoded String containing the
   0-RTT case) will not be exposed to a replay attack.  When either
   cannot name of the authentication
   method, which MUST be guaranteed, set to 'ace'.  If the Password MAY also contain RS does not support this
   profile, it sends a nonce.

   Section 3.1.3 CONNACK with a Reason Code of MQTT v3.1.1 - '0x8C (Bad
   authentication method)'.

   The Authentication Method is followed by the OASIS Standard
   [MQTT-OASIS-Standard] defines Authentication Data,
   which has a property identifier 22 (0x16) and is binary data.  Based
   on the MQTT Username as Authentication Data, this profile allows:

   o  Proof-of-Possession over predefined field

   o  Proof-of-Possession via challenge/response

   o  Unauthorised request: Authorisation Server discovery

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.  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, which Encoded String (i.e., is prefixed by with a 2-byte two-byte
   integer length field followed by UTF-8
   encoded character data up to 65535 bytes.  Therefore an access token that is not gives the number of bytes in a valid UTF-8 MUST
   encoded string itself).  The Client Identifier may be Base64 [RFC4648] encoded.  (The
   MQTT Password allows binary data up to 65535 1-23 UTF-8
   encoded bytes, and so, does not
   require encoding.)

2.1.3.  Token Validation

   RS MUST verify contain only the validity of characters
   "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ".
   However, according to MQTTv5 standard, the token.  This validation MAY be
   done locally (e.g., Broker may except longer
   Client Identifiers, and characters not included in the case list given
   above.  Clients MUST change their Client Identifier for each session,
   if the Client Identifier is the only source of a self-contained token) or randomness in the RS
   MAY send an introspection request
   payload to the AS. defend against a replay attack.  If introspection is
   used, this section follows similar steps to those described in
   Sections 5.7 of the ACE framework [I-D.ietf-ace-oauth-authz].  The
   communication between AS and RS MAY be HTTPS, but it, in every case, Client reuses its
   Client Identifier across different sessions, the Authentication Data
   MUST be confidential, mutually authenticated also contain a nonce, and integrity protected.

   The broker MUST check if the token is active either using 'exp' claim
   of the token keyed message digest (MAC) or 'active' parameter of the introspection response.

   The access token is constructed by the AS such that RS can associate
   Client signature MUST be computed over this nonce.  Finally, the access
   token with the client key.  This document assumes that the
   Access Token is a PoP token validated as described in
   [I-D.ietf-ace-oauth-authz].  Therefore, Section 2.1.3 and the necessary information server
   responds with a CONNACK.

2.1.2.2.  Proof-of-Possession via challenge/response

   For this option, the RS follows a challenge/response protocol.  The
   success case is
   contained illustrated in Figure 4.  If the 'cnf' claim of Authentication Data
   only includes the access token and may use either
   public or shared key approaches.  The client uses token, the signature or RS MUST respond with an AUTH packet,
   with the MAC in Authenticate Reason Code set to '0x18 (Continue
   Authentication)'.  This packet includes the password field Authentication Method,
   which MUST be set to 'ace' and Authentication Data.  The
   Authentication Data MUST NOT be empty and contains a challenge for
   the Client.  The Client responds to prove this with an AUTH packet with a
   reason code '0x18 (Continue Authentication)'.  Similarly, the possession of Client
   packet sets the key. Authentication Method to 'ace'.  The resource server validates Authentication
   Data in the Client's response contains the signature or the MAC computed
   over the
   contents of the packet, authenticating the client.

   The broker uses the scope field in RS's challenge.  Next, the token (or is validated as described
   in Section 2.1.3.

                                Resource
                    Client      Server
                     |             |
                     |<===========>| TLS connection establishment
                     |             |
                     |             |
                     +------------>| CONNECT with Authentication Data
                     |             | contains only token
                     |             |
                     <-------------+ AUTH '0x18 (Continue Authentication)'
                     |             | challenge
                     |             |
                     |------------>| AUTH '0x18 (Continue Authentication)'
                     |             | signature
                     |             |
                     |             |-----+ Token validation (may involve introspection)
                     |             |     |
                     |             |<----+
                     |             |
                     |<------------+ CONNACK '0x00 (Success)'

         Figure 4: PoP Challenge/Response Protocol Flow - Success

2.1.2.3.  Unauthorised Request: Authorisation Server Discovery

   Finally, this document allows the introspection
   result) to determine the publish CONNECT message to have an empty
   Authentication Data field.  This is the AS discovery option and subscribe permissions the
   RS responds with the CONNACK reason code '0x87 (Not Authorized)' and
   includes a User Property (identified by 38 (0x26)) for the
   client.  If AS
   creation hints as dedined in the Will flag is set, then Section 5.1.2 of the broker ACE framework
   [I-D.ietf-ace-oauth-authz].

2.1.3.  Token Validation

   The RS MUST check that the
   token allows verify the publication validity of the Will message too.

   If token.  This validation MAY be
   done locally (e.g., in the token is not case of a self-contained and token) or the broker uses token
   introspection, it RS
   MAY cache the validation result send an introspection request to decide whether the AS.  If introspection is
   used, this section follows similar steps to accept subsequent PUBLISH those described in
   Sections 5.7 of the ACE framework [I-D.ietf-ace-oauth-authz].  The
   communication between AS and SUBSCRIBE messages as these
   messages, which are sent after a connection set-up, do not contain
   access tokens.  If RS MUST be confidential, mutually
   authenticated and integrity protected.

   The Broker MUST check if the introspection result token is not cached, then active either using 'exp' claim
   of the token or 'active' parameter of the introspection response.
   Also, if present in the access token, RS needs must check that the 'iss'
   corresponds to introspect AS, the 'aud' field corresponds to RS.  It also has to
   check whether the 'nbf' and the 'iat' claims are present and valid.

   To authenticate the Client, the RS validates the signature or the
   MAC, depending on how the PoP protocol is implemented.  To authorize
   the Client, the Broker uses the scope field in the saved token (or in the
   introspection result).  The scope field contains the publish and
   subscribe permissions for each request. the Client.  If the Will Flag is set,then
   the Broker MUST check that the token allows the publication of the
   Will message.

   Scope strings SHOULD be encoded as a permission, followed by an
   underscore, followed by a topic filter.  Two permissions apply to
   topics: 'publish' and 'subscribe'.  An example scope field may
   contain multiple such strings, space delimited, e.g., 'publish_topic1
   subscribe_topic2/#'.  Hence, this access token would give 'publish'
   permission to the 'topic1', 'subscribe' permission to all the
   subtopics of 'topic2'.

   Also, if present in the access token, RS must check that the 'iss'
   corresponds to AS, the 'aud' field (if not used to define topics)
   corresponds to RS.  It also has to check whether 'nbf' and 'iat'
   claims are present and valid.

2.1.4.  The Broker's Response to Client Connection Request

   Based on the validation result (obtained either via local inspection
   or using the /introspection interface of the AS), the broker Broker MUST
   send a CONNACK message to the client. Client.  The broker responses may follow either the MQTT v3.1.1 - the OASIS
   Standard [MQTT-OASIS-Standard] or the MQTT v5 - the OASIS Standard
   [MQTT-OASIS-Standard-v5], depending on which version(s) the broker
   supports.

   In MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard], it is not
   possible to support AS discovery via sending a tokenless CONNECT
   message to reason code of the broker.  This is because a CONNACK packet does not
   include a means to provide additional information to the client.
   Therefore, AS discovery needs to take place out-of-band.  This
   is
   remedied in '0x00 (Success)' if the MQTT v5 - authentication is successful.  In case of
   an invalid PoP token, the OASIS Standard [MQTT-OASIS-Standard-v5]
   and a solution CONNACK reason code is described in Section 3. '0x87 (Not
   Authorized)'.

   If the RS accepts the connection, it MUST store the token.

2.2.  Authorizing PUBLISH Messages

2.2.1.  PUBLISH Messages from token until the Publisher
   end of connection.  On Client to or RS disconnection, the Broker

   On receiving token is
   discarded, and the PUBLISH message, Client MUST provide a token inside each 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 broker saved token for each request.  The Broker
   SHOULD use a cache time out to introspect tokens regularly.

2.2.  Authorizing PUBLISH Messages

2.2.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 Topic name in the message header to
   compare against the cached token or its introspection result.

   If the client Client is allowed to publish to the topic, the RS must publish
   the message to all valid subscribers of the topic.  The broker Broker may
   also return an acknowledgment message if the QoS level is greater
   than or equal to 1.

   In case of a an authorization failure, it is not possible to return an error in MQTT
   v3.1.1 - MAY be returned to the OASIS Standard [MQTT-OASIS-Standard].  Acknowledgement
   messages only indicate success.  In
   Client.  For this the case QoS level of an authorization
   error, the broker SHOULD disconnect the client.  Otherwise, it MUST
   ignore the PUBLISH message.  Also, DISCONNECT messages are only sent
   from a client message, should be set
   to the broker.  So, server disconnection needs greater than or equal to take
   place below 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 application layer.  However, Client MAY
   reauthenticate as described in MQTT v5 - the OASIS
   Standard [MQTT-OASIS-Standard-v5], it is possible to indicate failure Section 2.4, and provide pass a reason code.  Section 3 describes new token
   following the same PoP methods as described in more detail how
   MQTT v5 handles PUBLISH authorization errors. Figure 2.

2.2.2.  PUBLISH Messages from the Broker to the Subscriber Clients

   To forward PUBLISH messages to the subscribing clients, Clients, the broker 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 name). topic).  The broker Broker sends a PUBLISH
   message with the topic Topic name and the topic message to all the valid subscribers.

   In MQTT, after connection establishment,

   RS MUST stop forwarding messages to the unauthorized subscribers.
   For Clients with invalid tokens, there is no way to inform a
   client the Client
   that an authorization error has occurred for previously
   subscribed topics, e.g., token expiry.  In the case of an
   authorization error, the broker disconnects the client.  In the MQTT
   v3.1.1 - other than sending a
   DISCONNECT message.  The RS SHOULD send a DISCONNECT message with the OASIS Standard [MQTT-OASIS-Standard],
   reason code '0x87 (Not authorized)'.  Note that the MQTT server-side
   DISCONNECT messages are only sent from is a client to the broker.
   Therefore, new feature of MQTT v5.0 (in MQTT v3.1.1, the server disconnection
   needs to take place below the
   application layer.  In MQTT v5 - drop the OASIS Standard
   [MQTT-OASIS-Standard-v5], a server-side DISCONNECT message is
   possible and described in Section 3. connection).

2.3.  Authorizing SUBSCRIBE Messages

   In MQTT, a SUBSCRIBE message is sent from a client Client to the broker Broker to
   create one or more subscriptions to one or more topics.  The
   SUBSCRIBE message may contain multiple topic filters. Topic Filters.  The topic
   filters Topic
   Filters may include wildcard characters.

   On receiving the SUBSCRIBE message, the broker Broker MUST use the type of
   message (i.e., SUBSCRIBE) and the topic filter Topic Filter in the message header
   to compare against the stored token or introspection result.

   As a response to the SUBSCRIBE message, the broker Broker issues a SUBACK
   message.  For each topic filter, Topic Filter, the SUBACK packet includes a return
   code matching the QoS level for the corresponding topic filter. Topic Filter.  In
   the case of failure, the return code, in MQTT v3.1.1, must be 0x80
   indicating 'Failure'.  In MQTT v5, the appropriate return code is 0x87, indicating that the client
   Client is 'Not authorized'.  Note that, in
   both MQTT versions, a  A reason code is returned for each topic filter. Topic
   Filter.  Therefore, the client Client may receive success codes for a subset
   of its
   topic filters, Topic Filters while being unauthorized for the rest.

2.4.  Token Expiration and Reauthentication

   The broker Broker MUST check for token expiration whenever a CONNECT,
   PUBLISH or SUBSCRIBE message is received or sent.  The broker Broker SHOULD
   check for token expiration on receiving a PINGREQUEST message.  This
   may allow for early detection of a token expiry.

   The token expiration is checked by checking the 'exp' claim of a CWT/ JWT
   or introspection response, or via performing an introspection request
   with the Authorization server as described in Section 5.7 of the ACE
   framework [I-D.ietf-ace-oauth-authz].  In the basic operation, token  Token expirations MAY lead to disconnecting the associated client.
   However, in MQTT v5 - may trigger
   the OASIS Standard [MQTT-OASIS-Standard-v5],
   better error handling and re-authentication are possible.  This is
   explained in more detail in Section 3.

2.5.  Handling Disconnections and Retained Messages

   According RS to MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard],
   only Client DISCONNECT messages are allowed.  In MQTT v5 - the OASIS
   Standard [MQTT-OASIS-Standard-v5], server-side send PUBACK, SUBACK and DISCONNECT messages
   are possible, allowing to return '0x87 Not Authorized' with return
   code set to
   the client.

   In the case of 'Not authorised'.  As a DISCONNECT, due to response, the Clean Session flag, Client MAY re-
   authenticate by sending an AUTH packet with a Reason Code of 0x19
   (Re-authentication)

   To re-authenticate, the
   broker deletes all session 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.1.2.  If the re-
   authentication fails, the server MUST send a DISCONNECT with the
   reason code '0x87 (Not Authorized)'.  The Clients can also
   proactively update their tokens before they receive a message with
   'Not authorized' return code.

2.5.  Handling Disconnections and Retained Messages

   In the case of a Client DISCONNECT, due to the Clean Session flag,
   the Broker deletes all session state but MUST keep the retained
   messages.  By setting a RETAIN flag in a PUBLISH message, the
   publisher indicates to the broker Broker that it should store the most
   recent message for the associated topic.  Hence, the new subscribers
   can receive the last sent message from the publisher for of that
   particular topic without waiting for the next PUBLISH message.  In the case of a
   disconnection, the broker  The
   Broker MUST continue publishing the retained messages as long as the
   associated tokens are valid.

   In case of disconnections due to network errors or server
   disconnection due to a protocol error (which includes authorization
   errors), the Will message must be sent if the client Client supplied a Will
   in the CONNECT request message.  The Client's token provided in the CONNECT
   request must cover scopes MUST include the
   Will topic. Topic.  The Will message MUST be published to the Will topic Topic
   when the network connection is closed regardless of whether the
   corresponding token has expired.

3.  Improved Protocol Interactions with MQTT v5  In the new MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5],
   several new capabilities are introduced, which enable better
   integration with ACE.  The newly enhanced authentication and re-
   authentication methods support a wider range case of authentication flows
   beyond username and password.  With a server-side
   DISCONNECT, the server returns the '0x87 Not Authorized' return code
   to the Client.

3.  Reduced Protocol Interactions for MQTT v5, there is v3.1.1

   This section describes a clearly
   defined approach for using token-based authorization.  Also, it is
   possible reduced set of protocol interactions for a client to request a re-authentication avoiding
   disconnection.  Finally, MQTT v5 generally improves error reporting,
   enabling better response to authorization failures during publishing
   messages to the subscribers.
   MQTT v3.1.1 Client.

3.1.  Token Transport via Authentication Exchange (AUTH)

   To initiate the authentication and authorization flow, as before, the
   CAS initiates transport the token request as in Section 2.1.  When the client
   wishes to connect to the RS (broker), it uses Broker, the CONNECT message of
   MQTT.  Figure 4 shows Clients use the structure username
   and password fields of the MQTT CONNECT control message used in after the TLS
   handshake.  Figure 5 shows the structure of the MQTT v5. CONNECT message.

          0            8            16            24            32
          +------------------------------------------------------+
          |CPT=1 | Rsvd.|Remaining len.| Protocol  name len. = 4 |
          +------------------------------------------------------+
          |                      'M' 'Q' 'T' 'T'                 |
          +------------------------------------------------------+
          | Proto.level=5|Connect Proto.level=4|Connect flags|          Keep alive     |
          +------------------------------------------------------+
          |                 Property length Payload                                              |
          |          Auth. Method (0x15)     Client Identifier                                | 'ace'
          |     Username as access token (UTF-8)                     |          Auth. Data (0x16)
          | empty or token or     Password length (2 Bytes)                        |
          |                                token + PoP     Password data as signature/MAC (binary)          |
          +------------------------------------------------------+

    Figure 4: 5: MQTT CONNECT control message.  (CPT=Control Packet Type,
               Rsvd=Reserved, len.=length, Proto.=Protocol)

   To communicate the necessary connection parameters, the client uses
   the appropriate flags of the CONNECT message.  To achieve a clean
   session (i.e., the session should start without an existing session),

   Figure 6 shows how the new MQTT v5 session connect flags MUST be set appropriately: to initiate a
   connection with the Broker.

   +-----------------------------------------------------------+
   |User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.|
   | flag    |flag |           |        |         |     |      |
   +-----------------------------------------------------------+
   | 1       | 1   |    X      |   X X  |   X     |  1   |  0  |
   +-----------------------------------------------------------+

              Figure 6: MQTT CONNECT flags.  (Rsvd=Reserved)

   The Clean
   Start Session Flag MUST be set to 1 1.  The Client may set the Will
   Flag as desired (marked as 'X' in Figure 6).  Username and Session Expiry Interval Password
   flags MUST be set to 0.

   With the enhanced authentication capabilities, it is not necessary 1 to
   overload ensure that the username and password fields in Payload of the CONNECT
   message for
   ACE authentication.  Nevertheless, the RS MUST support includes both methods
   for supporting the token: (1) Token transport via username and
   password Username and (2) using the new AUTH (Authentication Exchange) method. Password fields.

   The token transport via username CONNECT message defaults to ACE for authentication and password is as described in
   Section 2.1.2.
   authorization.  The rest of this section describes the AUTH method.

   To use the AUTH method, the username flag Username field MUST be set to 0, and the
   password flag MUST be set to 0. access token.

   The client can set the
   Authentication Method as a property of a CONNECT packet by setting
   Auth Properties (with the property identifier 0x15).  The client must
   MUST set the UTF-8 encoded string containing the name of the
   authentication method as 'ace'.  If the RS does not support this
   profile, it sends a CONNACK with a Reason Code of '0x8C (Bad
   authentication method)'

   The Authentication Method is followed by the Authentication Data,
   which has a property identifier 0x16.  Authentication data is binary
   data and is defined by the authentication method.  The RS MAY support
   different implementations for transporting the authentication data.
   The first option is that Authentication data contains both the token
   and the keyed message digest (MAC) or signature as described in
   Section 2.1.2.  The encoding of this field MAY use CBOR and COSE.  In
   this case, the token validation proceeds as described in
   Section 2.1.3 and the server responds with a CONNACK.  The reason
   code of the CONNACK is '0x00 (Success)' if the authentication is
   successful.  In case of an invalid PoP token, the CONNACK reason code
   is '0x87 (Not Authorized)'.

   The second option that RS may accept is a challenge/response
   protocol.  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 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 the
   signature or MAC computed over the RS's challenge.  To this, the
   server responds with a CONNACK and return code '0x00 (Success)' if
   the authentication is successful.  In case of an invalid PoP token,
   the CONNACK reason code is '0x87 (Not Authorized)'.

   Finally, this document allows the CONNECT message to have an empty
   Authentication Data field.  This is the AS discovery option and Password field MUST be set to the
   RS responds keyed message digest (MAC) or
   signature associated with the CONNACK reason code '0x87 (Not Authorized)' and
   includes a User Property access token for proof-of-possession.
   The Client MUST apply the AS information.  AS Information
   contains PoP key to the absolute URI of AS, and MAY also contain a cnonce payload as described in the
   Section 5.1 of 2.1.2.1.

   In MQTT v3.1.1, the ACE framework
   [I-D.ietf-ace-oauth-authz].  This information MAY MQTT Username as a UTF-8 encoded string (i.e., is
   prefixed by a 2-byte length field followed by UTF-8 encoded character
   data) and may be CBOR up to 65535 bytes.  Therefore, an access token that
   is not a valid UTF-8 MUST be Base64 [RFC4648] encoded.  (The MQTT
   Password allows binary data up to 65535 bytes.)

3.2.  Handling Authorization Errors and Client Re-authentication

   Handling errors are more primitive in MQTT v5 allows better v3.1.1 due to not having
   appropriate error reporting.  To take advantage of this for
   PUBLISH messages, fields, error codes, and server-side DISCONNECTS.
   In the QoS level should be set following, we list how errors are handled without such
   protocol support.

   o  CONNECT without a token: It is not possible to greater than or
   equal support AS
      discovery via sending a tokenless CONNECT message to 1. the Broker.
      This guarantees that RS responds with either is because a PUBACK or
   PUBREC CONNACK packet with reason code '0x87 (Not authorized)' in MQTT v3.1.1 does not include a
      means to provide additional information to the Client.  Therefore,
      AS discovery needs to take place out-of-band.  CONNECT attempt
      MUSY fail.

   o  Client-RS PUBLISH authorization failure: In case of a failure, it
      is not possible to return an error in MQTT v3.1.1.
      Acknowledgement messages only indicate success.  In the case of an
      authorization error, the Broker SHOULD disconnect the Client.
      Otherwise, it MUST ignore the PUBLISH message.  Also, DISCONNECT
      messages are only sent from a Client to the case of
   an authorization error.  Similarly, for Broker.  So, server
      disconnection needs to take place below the application layer.

   o  SUBSCRIBE case, authorization failure: In the SUBACK packet has a reason packet, the return
      code set to '0x87 (Not authorized)' must be 0x80 indicating 'Failure' for the unauthorized
      topic(s).  Note that, in both MQTT versions, a reason code is
      returned for each Topic Filter.

   o  RS-Client PUBLISH authorization failure: When RS is forwarding
      PUBLISH messages to the subscribed clients, Clients, it may discover that
      some of the subscribers are no more authorized due to expired
      tokens.  In this case, the RS  These token expirations 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 (in MQTT v3.1.1, the server needed to drop the
   connection).  RS MUST stop forwarding messages lead to disconnecting the unauthorized
   subscribers.

   In the case of a PUBACK with '0x87 (Not authorized)', the client can
   update its token using the Re-authentication feature of MQTT v5.

   Also, the clients can proactively update their tokens without waiting
   for such a PUBACK.  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 the previous
   section.  If the re-authentication fails, the server MUST send a
   DISCONNECT with the reason code '0x87 (Not Authorized)'.
      Client, rather than silently dropping messages.

4.  IANA Considerations

   The following registrations are done for the ACE OAuth Profile
   Registry following the procedure specified in
   [I-D.ietf-ace-oauth-authz].

   Note to the RFC editor: Please replace all occurrences of "[RFC-
   XXXX]" with the RFC number of this specification and delete this
   paragraph.

   Profile name: mqtt_tls

   Profile description: Profile for delegating client Client authentication and
   authorization using MQTT as the application protocol and TLS For
   transport layer security.

   Profile ID:

   Change controller: IESG

   Reference: [RFC-XXXX]

5.  Security Considerations

   This document specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework
   [I-D.ietf-ace-oauth-authz].  Therefore, the security considerations
   outlined in [I-D.ietf-ace-oauth-authz] apply to this work.

   In addition, the security considerations outlined in MQTT v3.1.1 v5.0 - the
   OASIS Standard [MQTT-OASIS-Standard] [MQTT-OASIS-Standard-v5] and MQTT v5 v3.1.1 - the OASIS
   Standard [MQTT-OASIS-Standard-v5] [MQTT-OASIS-Standard] apply.  Mainly, this document provides
   an authorization solution for MQTT, the responsibility of which is
   left to the specific implementation in MQTT v5 - the OASIS
   Standard [MQTT-OASIS-Standard-v5]. v5.0 standard.  In the
   following, we comment on a few relevant issues based on the current
   MQTT specifications.

   In this document, RS uses the PoP access token to authenticate the
   client.
   Client.  If the client Client is able, TLS certificates sent from the client Client
   can be used by the RS to authenticate the client. Client.  The TLS
   certificate from Client may
   authenticate the RS MUST be used by either using a server cerficate or the RPK
   method.  In the case of RPK, client needs to authenticate use this raw public key
   in the RS. TLS handshake together with an out-of-band validation
   technique (see [RFC7250] for details).

   To authorize a client's Client's publish and subscribe requests in an ongoing
   session, the RS caches the access token after accepting the
   connection from the client. Client.  However, if some permissions are revoked
   in the meantime, the RS may still grant publish/subscribe to revoked
   topics until
   topics.  If the session ends or RS caches the token expires. introspection responses, then the
   RS should use a reasonable cache timeout to introspect tokens
   regularly.  When permissions change dynamically, it is expected that
   AS also follows a reasonable expiration strategy for the access
   tokens.

   The RS may monitor client 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 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 Clients use the "authz-info"
   public topic to transport fictitious tokens, which RS may need to
   store indefinitely.

6.  Privacy Considerations

   The privacy considerations outlined in [I-D.ietf-ace-oauth-authz]
   apply to this work.

   In MQTT, the RS is a central trusted party and may forward
   potentially sensitive information between clients. Clients.  Clients may
   choose to encrypt the payload of their messages.  However, this would
   not provide privacy for other properties of the message such as topic
   name. Topic
   Name.

7.  References

7.1.  Normative References

   [I-D.gerdes-ace-dtls-authorize]
              Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
              L. Seitz, "Datagram Transport Layer Security (DTLS)
              Profile for Authentication and Authorization for
              Constrained Environments (ACE)", draft-gerdes-ace-dtls-
              authorize-01 (work in progress), March 2017.

   [I-D.ietf-ace-oauth-authz]
              Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments (ACE) using the OAuth 2.0
              Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24
              (work in progress), March 2019.

   [MQTT-OASIS-Standard]
              Banks, A., Ed. and R. Gupta, Ed., "OASIS Standard MQTT
              Version 3.1.1 Plus Errata 01", 2015, <http://docs.oasis-
              open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html>.

   [MQTT-OASIS-Standard-v5]
              Banks, A., Ed., Briggs, E., Ed., Borgendale, K., Ed., and
              R. Gupta, Ed., "OASIS Standard MQTT Version 5.0", 2017,
              <http://docs.oasis-open.org/mqtt/mqtt/v5.0/os/
              mqtt-v5.0-os.html>.
              <http://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-
              v5.0-os.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <https://www.rfc-editor.org/info/rfc7250>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2.  Informative References

   [fremantle14]
              Fremantle, P., Aziz, B., Kopecky, J., and P. Scott,
              "Federated Identity and Access Management for the Internet
              of Things", research International Workshop on Secure
              Internet of Things, September 2014,
              <http://dx.doi.org/10.1109/SIoT.2014.8>.

   [I-D.ietf-ace-actors]
              Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
              architecture for authorization in constrained
              environments", draft-ietf-ace-actors-07 (work in
              progress), October 2018.

   [I-D.ietf-ace-cwt-proof-of-possession]
              Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
              Tschofenig, "Proof-of-Possession Key Semantics for CBOR
              Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
              possession-06
              possession-08 (work in progress), February October 2019.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/info/rfc4949>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
              Possession Key Semantics for JSON Web Tokens (JWTs)",
              RFC 7800, DOI 10.17487/RFC7800, April 2016,
              <https://www.rfc-editor.org/info/rfc7800>.

Appendix A.  Checklist for profile requirements

   o  AS discovery: For the basic protocol using either MQTT v3.1.1 or
      MQTT v5, the clients/client authorization servers need to be
      configured out-of-band.  RS does not provide any hints to help AS
      discovery. AS discovery is possible with the MQTT v5 extensions v5.0
      described in Section 3. 2.1.2.

   o  The communication protocol between the client Client and RS: MQTT

   o  The security protocol between the client Client and RS: TLS

   o  Client and RS mutual authentication: RS provides a server
      certificate or RPK during TLS handshake.  Client transports token
      and MAC via the MQTT CONNECT message.  Other methods for transporting the
      token with the MQTT v5 extensions described in Section 3.

   o  Content format: For the HTTPS interactions with AS, "application/
      json".
      ace+json".  The MQTT payloads may be formatted JSON or CBOR. in JSON.

   o  PoP protocols: Either symmetric or asymmetric keys can be
      supported.

   o  Unique profile identifier: mqtt_tls

   o  Token introspection: RS uses HTTPS /introspect interface of AS.

   o  Token request: CAS uses HTTPS /token interface of AS.

   o  /authz-info endpoint: It MAY be supported using the method
      described in Appendix B, but is not protected.

   o  Token transport: In MQTT CONNECT message or using the for both versions of
      MQTT.  AUTH extensions also used for authentication and re-
      authentication for MQTT v5 v5.0 as described in Section 3. 2.1.2.

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 Broker accepting PUBLISH messages to
   a public "authz-info" topic.  A client Client using this method MUST first
   connect to the broker, Broker, and publish the access token using the "authz-
   info" topic.  The broker Broker must verify the validity of the token (i.e.,
   through local validation or introspection).  After publishing the
   token, the client Client disconnects from the broker Broker and is expected to try
   reconnecting over TLS.

   In MQTT v5.0, the Broker can return 'Not authorized' error to a
   PUBLISH request for QoS greater or equal to 1.  In MQTT v3.1.1, after
   the client Client published to the "authz-info" topic, it is not possible
   for the broker Broker to communicate the result of the token verification.
   In MQTT v5, the broker can return 'Not
   authorized' error to a PUBLISH request for QoS greater or equal to 1.
   In any case, any token authorization failure affect the subsequent
   TLS handshake, which can prompt the client Client to obtain a valid token.

Appendix C.  Document Updates

   Version 00 to 01:

   o  Present the MQTTv5 as the RECOMMENDED version, and MQTT v3.1.1 for
      backward compatibility.

   o  Clarified Will message.

   o  Improved consistency in the use of terminology, and upper/lower
      case.

   o  Defined Broker and MQTTS.

   o  Clarified HTTPS use for C-AS and RS-AS communication.  Removed
      reference to actors document, and clarified the use of client
      authorization server.

   o  Clarified the Connect message payload and Client Identifier.

   o  Presented different methods for passing the token, and PoP.

   o  Added new figures for AUTH methods, updated CONNECT message
      figure.

Acknowledgements

   The authors would like to thank Ludwig Seitz for his review and his
   input on the authorization information endpoint, presented in the
   appendix.

Authors' Addresses

   Cigdem Sengul
   Nominet
   2
   4 Kingdom Street
   London  W2 6BD
   UK

   Email: Cigdem.Sengul@nominet.uk

   Anthony Kirby
   Oxbotica
   1a Milford House, Mayfield Road, Summertown
   Oxford  OX2 7EL
   UK

   Email: anthony@anthony.org

   Paul Fremantle
   University of Portsmouth
   School of Computing, Buckingham House
   Portsmouth  PO1 3HE
   UK

   Email: paul.fremantle@port.ac.uk