| ACE Working Group | C. Sengul |
| Internet-Draft | Nominet |
| Intended status: Standards Track | A. Kirby |
| Expires: May 6, 2020 | Oxbotica |
| P. Fremantle | |
| University of Portsmouth | |
| November 3, 2019 |
MQTT-TLS profile of ACE
draft-ietf-ace-mqtt-tls-profile-02
This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) framework 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 MQTT Clients. The protocol relies on TLS for confidentiality and server authentication.
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 May 6, 2020.
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.
This document specifies a profile for the ACE framework [I-D.ietf-ace-oauth-authz]. In this profile, Clients and a Broker use MQTT to exchange Application Messages. The protocol relies on TLS for communication security between entities. The MQTT protocol interactions are described based on the MQTT v5.0 - the OASIS Standard. It is expected that MQTT deployments will retain backward compatibility for MQTT v3.1.1 clients, and therefore, this document also describes a reduced set of protocol interactions suited to MQTT v3.1.1 - the OASIS Standard. However, it is RECOMMENDED to use MQTT v5.0 as it works more naturally with ACE-style authentication and authorization.
MQTT is a publish-subscribe protocol and after connecting to the MQTT Broker, a Client can publish and subscribe to multiple topics. The MQTT Broker is responsible for distributing messages published by the publishers to the appropriate subscribers. Publisher messages contains a Topic Name, which is used by the 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. The Clients are assumed to have identified the publish/subscribe topics of interest out-of-band (topic discovery is not a feature of the MQTT protocol). A resource owner can pre-configure policies at the AS that give Clients publish or subscribe permissions to different topics.
Clients use an access token, bound to a proof-of-possession (PoP) key to authorize with the MQTT Broker their connection and publish/subscribe permissions to topics. In the context of this ACE profile, the MQTT Broker acts as the Resource Server (RS). In the rest of the document RS and Broker are used interchangeably. This document describes the following exchanges between Clients and the Broker.
To provide communication confidentiality and Resource Server authentication, TLS is used, and TLS 1.3 is RECOMMENDED. This document makes the same assumptions as the Section 4 of the ACE framework regarding Client and RS registration with the Authorization Server (AS) and setting up keying material. While the Client-Broker exchanges are only over MQTT, the required Client-AS and RS-AS interactions are described for HTTPS-based communication, using 'application/ace+json' content type, and unless otherwise specified, using JSON encoding. The token may be a reference, or JSON Web Token (JWT). For JWT tokens, this document follows RFC 7800 for PoP semantics for JWTs. The Client-AS and RS-AS may also be other than HTTPS e.g., CoAP or MQTT. It may also be possible to use 'application/ace+cbor' content type, and CBOR encoding, and CBOR Web Token (CWT) and associated PoP semantics to reduce the protocol memory and bandwidth requirements. For more information on Proof of Possession semantics for CWTs, see Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs).
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.
The terminology for entities in the architecture is defined in OAuth 2.0 RFC 6749 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, which is defined in Section 1.3. Hence, the "Resource Owner" is any entity that can authoritatively speak for the topic.
Certain security-related terms such as "authentication", "authorization", "confidentiality", "(data) integrity", "message authentication code", and "verify" are taken from RFC 4949.
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 v5.0 - the OASIS Standard or the MQTT v3.1.1 - the OASIS Standard.
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.
This section specifies how Client connections can be authorized by an MQTT Broker.Figure 1 shows the basic protocol flow during connection set-up.The token request and response use the /token endpoint of the authorization server, specified in the Section 5.6 of the ACE framework. Steps (D) and (E) are optional, and use the introspection endpoint, specified in the Section 5.7 of the ACE framework. The Client and Broker use HTTPS to communicate to AS via these endpoints. The Client and Broker use only MQTT to communicate between them.
If the Client is resource-constrained, the Client's Authorisation Server may carry out the token request on behalf of the Client, and later, onboard the Client with the token. Also, the C-AS and Broker-AS interfaces may be implemented using protocols other than HTTPS, 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.
+---------------------+
| Client |
| |
+---(A) Token request--| Client - |
| | Authorization |
| +-(B) Access token-> Server Interface |
| | | (HTTPS) |
| | |_____________________|
| | | |
+--v-------------+ | Pub/Sub Interface |
| Authorization | | (MQTTS) |
| Server | +-----------^---------+
|________________| | |
| ^ (C)Connection (F)Connection
| | request + response
| | access token |
| | | |
| | +---v--------------+
| | | Broker (MQTTS) |
| | |__________________|
| +(D)Introspection-| |
| request (optional) | RS-AS interface |
| | (HTTPS) |
+-(E)Introspection---->|__________________|
response (optional)
Figure 1: Connection set-up
The first step in the protocol flow (Figure 1 (A)) is the token acquisition by the Client from the AS. When requesting an access token from the AS, the Client follows the token request as is described in Section 5.6.1 of the ACE framework, howevever, it MUST set the profile parameter to 'mqtt_tls'. The media format is 'application/ace+json'. The AS uses a JSON structure in the payload of its responses both to the Client and the RS.
If the AS successfully verifies the access token request and authorizes the Client for the indicated audience (i.e., RS) and scopes (i.e., 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. The included token is assumed to be Proof-of-Possession (PoP) token by default. This document follows RFC 7800 for PoP semantics for JWTs. The PoP token includes a 'cnf' parameter with a symmetric or asymmetric PoP key. The 'cnf' parameter in the web tokens are to be consumed by the resource server and not the Client. The PoP token may include a 'rs_cnf' parameter containing the information about the public key used by the RS to authenticate as described in [I-D.ietf-ace-oauth-params].
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.
The Client and the Broker MUST perform mutual authentication. The Client MAY authenticate to the Broker over MQTT or TLS. For MQTT, the options are "None" and "ace". For TLS, the options are "Anon" for anonynous client, and "Known(RPK/PSK)" for Raw Public Keys (RPK) and Pre-Shared Keys (PSK), respectively. Combined, the Client authentication takes the following options:
It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace.
The Broker MUST be authenticated during TLS handshake. If the Client authentication included TLS:Known(RPK/PSK), then the Broker is authenticated using the respective method. For the other Client Authentication cases, to authenticate the Broker, the client MAY either have the ability to receive and validate a server-side certificate or an RPK from the Broker against the 'rs_cnf' parameter in the token.
In the cases when the Client MUST transport the token to the Broker before the TLS handshake, the Client connects to the Broker and publishes its token to the "authz-info" topic. The "authz-info" topic MUST be publish-only for Clients (i.e., the Clients are not allowed to subscribe to it). The Broker stores and indexes all tokens received to this topic in its key store similar to DTLS profile for ACE.
The Broker must verify the validity of the token (i.e., through local validation or introspection) as described in Section 2.2.5. The Broker returns 'Not authorized' error to a PUBLISH request if the QoS level of this PUBLISH message is greater or equal to 1. After publishing the token, the Client disconnects from the Broker and is expected to try reconnecting over TLS.
This section describes how the Client transports the token to the Broker (RS) inside the CONNECT message. If this method is used, the Client TLS connection is expected to be anonymous, and the Broker is authenticated during the TLS connection set-up. The approach described in this section is similar to an earlier proposal by Fremantle et al. [fremantle14].
Figure 2 shows the structure of the MQTT CONNECT 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=5|Connect flags| Keep alive |
+------------------------------------------------------+
| Property length |
| Auth. Method (0x15) | 'ace' |
| Auth. Data (0x16) | empty or token or |
| token + PoP data |
+------------------------------------------------------+
| Payload |
+------------------------------------------------------+
Figure 2: MQTT v5 CONNECT control message with ACE authentication. (CPT=Control Packet Type)
The CONNECT message flags include Username, Password, Will retain, Will QoS, Will Flag, Clean Start, and Reserved. Figure 6 shows how the MQTT connect flags MUST be set to use AUTH packets for authentication and authorisation. For AUTH, the username and password flags MUST be set to 0. The RS MAY support token transport using username and password (the CONNECT message for that option is described in Section 7 for MQTT v3.1.1).
+-----------------------------------------------------------+
|User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.|
| flag |flag | | | | | |
+-----------------------------------------------------------+
| 0 | 0 | X | X X | X | X | 0 |
+-----------------------------------------------------------+
Figure 3: CONNECT flags for AUTH
The Will Flag indicates that a Will message needs to be sent 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 network connection due to a protocol error. The Client may set the Will Flag as desired (marked as 'X' in Figure 3). If the Will Flag is set to 1 and the Broker accepts the connection request, the 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 may specify a Will Delay Interval in Will Properties. Section 6 explains how the Broker deals with the retained messages in further detail.
In MQTT v5, to achieve a clean session (i.e., the session starts without an existing session), the Client sets the Clean Start Flag to 1 and, the Session Expiry Interval to 0 in the CONNECT message. However, in this profile, the Broker MUST always start with a clean session regardless of how these parameters are set. The Broker MUST set the Session Present flag to 0 in the CONNACK packet as a response.
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 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 22 (0x16) and is binary data. Based on the Authentication Data, this profile allows:
For this option, the Authentication Data MUST contain the token and the keyed message digest (MAC) or the Client signature. The challenge that is used as part of the proof-of-possession, i.e., to calculate the keyed message digest (MAC) or the Client signature, is obtained using using a TLS exporter ([RFC5705] for TLS 1.2 and for TLS 1.3, Section 7.5 of [RFC8446]). The token is also validated as described in Section 2.2.5 and the server responds with a CONNACK with the appropriate response code.
For this option, the RS follows a Broker-generated challenge/response protocol. The success case is illustrated in Figure 4. If the Authentication Data only includes the token, the RS MUST respond with an AUTH packet, with the Authenticate Reason Code set to '0x18 (Continue Authentication)'. This packet includes the Authentication Method, which MUST be set to 'ace' and Authentication Data. The Authentication Data MUST NOT be empty and contains 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. Next, the token is validated as described in Section 2.2.5.
Resource
Client Server
| |
|<===========>| TLS connection set-up
| |
| |
+------------>| 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
Finally, this document allows the CONNECT message to have the Authentication Method set to 'ace' followed by an empty Authentication Data field. This is the AS discovery option and the RS responds with the CONNACK reason code '0x87 (Not Authorized)' and includes a User Property (identified by 38 (0x26)) for the AS creation hints as defined in the Section 5.1.2 of the ACE framework.
The RS MUST verify the validity of the token either locally (e.g., in the case of a self-contained token) or the RS MAY send an introspection request to the AS. RS MUST verify the claims according to the rules set in the Section 5.8.1.1 of the ACE framework.
To authenticate the Client, the RS validates the signature or the MAC, depending on how the PoP protocol is implemented. Validation of the signature or MAC MUST fail if the signature algorithm is set to "none", when the key used for the signature algorithm cannot be determined, or the computed and received signature/MAC do not match. To authorize the Client, the Broker uses the scope field in the token (or in the introspection result). The scope field contains the publish and subscribe permissions for the Client.
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'. If the Will Flag is set,then the Broker MUST check that the token allows the publication of the Will message (i.e., the scope is "publish_" followed by the Will Topic).
Based on the validation result (obtained either via local inspection or using the /introspection interface of the AS), the Broker MUST send a CONNACK message to the Client. The reason code of the CONNACK is '0x00 (Success)' if the authentication is successful. The Broker MUST also set Session Present to 0 in the CONNACK packet to signal a clean session to the Client. In case of an invalid PoP token, the CONNACK reason code is '0x87 (Not Authorized)'.
If the Broker accepts the connection, it MUST store the token until the end of connection. On Client or Broker disconnection, the Client is expected to provide a token again inside the next CONNECT message.
If the token is not self-contained and the Broker uses token introspection, it MAY cache the validation result to authorize the subsequent PUBLISH and SUBSCRIBE messages. PUBLISH and SUBSCRIBE messages, which are sent after a connection set-up, do not contain access tokens. If the introspection result is not cached, then the RS needs to introspect the saved token for each request. The Broker SHOULD use a cache time out to introspect tokens regularly.
On receiving the PUBLISH message, the Broker MUST use the type of message (i.e., PUBLISH) and the Topic name in the message header to compare against the cached token or its introspection result.
If the Client is allowed to publish to the topic, the RS must publish the message to all valid subscribers of the topic. The Broker may also return an acknowledgment message if the QoS level is greater than or equal to 1.
In case of an authorization failure, an error MAY be returned to the Client. For this the QoS level of the PUBLISH message, should be set to greater than or equal to 1. This guarantees that RS responds with either a PUBACK or PUBREC packet with reason code '0x87 (Not authorized)'.
On receiving a PUBACK with '0x87 (Not authorized)', the Client MAY reauthenticate as described in Section 5, and pass a new token following the same PoP methods as described in Figure 2.
To forward PUBLISH messages to the subscribing Clients, the Broker identifies all the subscribers that have valid matching topic subscriptions (i.e., the tokens are valid, and token scopes allow a subscription to the particular topic). The Broker sends a PUBLISH message with the Topic name to all the valid subscribers.
RS MUST stop forwarding messages to the unauthorized subscribers. There is no way to inform the Clients with invalid tokens that an authorization error has occurred other than sending a DISCONNECT message. The RS SHOULD send a DISCONNECT message with the reason code '0x87 (Not authorized)'. Note that the server-side DISCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1, the server needs to drop the connection).
In MQTT, a SUBSCRIBE message is sent from a Client to the Broker to create one or more subscriptions to one or more topics. The SUBSCRIBE message may contain multiple Topic Filters. The Topic Filters may include wildcard characters.
On receiving the SUBSCRIBE message, the Broker MUST use the type of message (i.e., SUBSCRIBE) and the Topic Filter in the message header to compare against the stored token or introspection result.
As a response to the SUBSCRIBE message, the Broker issues a SUBACK message. For each Topic Filter, the SUBACK packet includes a return code matching the QoS level for the corresponding Topic Filter. In the case of failure, the return code is 0x87, indicating that the Client is 'Not authorized'. A reason code is returned for each Topic Filter. Therefore, the Client may receive success codes for a subset of its Topic Filters while being unauthorized for the rest.
The Broker MUST check for token expiration whenever a CONNECT, PUBLISH or SUBSCRIBE message is received or sent. The Broker SHOULD check for token expiration on receiving a PINGREQUEST message. The Broker MAY also check for token expiration periodically e.g., every hour. This may allow for early detection of a token expiry.
The token expiration is checked by checking the 'exp' claim of a JWT or introspection response, or via performing an introspection request with the AS as described in Section 5.7 of the ACE framework. Token expirations may trigger the RS to send PUBACK, SUBACK and DISCONNECT messages with return code set to 'Not authorised'. After sending a DISCONNECT message, the network connection is closed, and no more messages can be sent. However, as a response to the PUBACK and SUBACK, the Client MAY re-authenticate by sending an AUTH packet with a Reason Code of 0x19 (Re-authentication).
To re-authenticate, the Client sends an AUTH packet with reason code '0x19 (Re-authentication)'. The Client MUST set the Authentication Method as 'ace' and transport the new token in the Authentication Data. The Client and the RS go through the same steps for proof of possession validation as described in Section 2.2. 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 i.e., before they receive a message with 'Not authorized' return code.
In the case of a Client DISCONNECT, 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 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 of that particular topic without waiting for the next PUBLISH message. 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 supplied a Will in the CONNECT message. The Client's token scopes MUST include the Will Topic. The Will message MUST be published to the Will Topic regardless of whether the corresponding token has expired. In the case of a server-side DISCONNECT, the server returns the '0x87 Not Authorized' return code to the Client.
This section describes a reduced set of protocol interactions for the MQTT v3.1.1 Client.
As in MQTT v5, The Token MAY either be transported before the TLS session publishing to the "authz-info" topic, or inside the CONNECT message.
In MQTT v3.1.1, after the Client published to the "authz-info" topic, it is not possible for the Broker to communicate the result of the token verification. In any case, any token authorization failure affect the subsequent TLS handshake, which can prompt the Client to obtain a valid token.
To transport the token to the Broker inside the CONNECT message, the Client uses the username and password fields of the CONNECT message. Figure 5 shows the structure of the MQTT CONNECT message.
0 8 16 24 32
+------------------------------------------------------+
|CPT=1 | Rsvd.|Remaining len.| Protocol name len. = 4 |
+------------------------------------------------------+
| 'M' 'Q' 'T' 'T' |
+------------------------------------------------------+
| Proto.level=4|Connect flags| Keep alive |
+------------------------------------------------------+
| Payload |
| Client Identifier |
| Username as access token (UTF-8) |
| Password length (2 Bytes) |
| Password data as signature/MAC (binary) |
+------------------------------------------------------+
Figure 5: MQTT CONNECT control message. (CPT=Control Packet Type, Rsvd=Reserved, len.=length, Proto.=Protocol)
Figure 6 shows how the MQTT connect flags MUST be set 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 | X | 0 |
+-----------------------------------------------------------+
Figure 6: MQTT CONNECT flags. (Rsvd=Reserved)
The Clean Session Flag is ignored, and the Broker always sets up a clean session. On connection success, the Broker MUST set the Session Present flag to 0 in the CONNACK packet.
The Client may set the Will Flag as desired (marked as 'X' in Figure 6). Username and Password flags MUST be set to 1 to ensure that the Payload of the CONNECT message includes both Username and Password fields.
The CONNECT message defaults to 'ace' for authentication and authorization as the header does not have a field to indicate the authentication method. The Username field MUST be set to the access token. The Password field MUST be set to the keyed message digest (MAC) or signature associated with the access token for proof-of-possession. The Client MUST apply the PoP key on the challenge derived from the TLS session as described in Section 2.2.4.1.
In MQTT v3.1.1, the 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 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.)
Handling errors are more primitive in MQTT v3.1.1 due to not having appropriate error fields, error codes, and server-side DISCONNECTS. In the following, we list how errors are handled without such protocol support.
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 authentication and authorization using MQTT as the application protocol and TLS For transport layer security.
Profile ID:
Change controller: IESG
Reference: [RFC-XXXX]
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 v5.0 - the OASIS Standard and MQTT v3.1.1 - the 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.0 standard. In the following, we comment on a few relevant issues based on the current MQTT specifications.
To authorize a Client's publish and subscribe requests in an ongoing session, the RS caches the access token after accepting the connection from the Client. However, if some permissions are revoked in the meantime, the RS may still grant publish/subscribe to revoked topics. If the RS caches the token 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 behaviour to detect potential security problems, especially those affecting availability. These include repeated token transfer attempts to the public "authz-info" topic, repeated connection attempts, abnormal terminations, and Clients that connect but do not send any data. If the RS supports the public "authz-info" topic, described in Section 2.2.2, then this may be vulnerable to a DDoS attack, where many Clients use the "authz-info" public topic to transport fictitious tokens, which RS may need to store indefinitely.
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 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.
| [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. |
| [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)", Internet-Draft draft-ietf-ace-cwt-proof-of-possession-11, October 2019. |
| [RFC4949] | Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007. |
| [RFC6749] | Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012. |
| [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. |
Version 01 to 02:
Version 00 to 01:
The authors would like to thank Ludwig Seitz for his review and his input on the authorization information endpoint, presented in the appendix.