idnits 2.17.1 draft-ietf-ace-mqtt-tls-profile-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 490 has weird spacing: '...rotocol name ...' == Line 878 has weird spacing: '...rotocol name ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 13, 2020) is 1377 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-XXXX' is mentioned on line 996, but not defined == Unused Reference: 'RFC7250' is defined on line 1112, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-bormann-core-ace-aif (ref. 'I-D.bormann-core-ace-aif') == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-35 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-13 == Outdated reference: A later version (-09) exists of draft-ietf-cose-x509-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'MQTT-OASIS-Standard' -- Possible downref: Non-RFC (?) normative reference: ref. 'MQTT-OASIS-Standard-v5' == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-12 == Outdated reference: A later version (-09) exists of draft-ietf-ace-pubsub-profile-01 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group C. Sengul 3 Internet-Draft Brunel University 4 Intended status: Standards Track A. Kirby 5 Expires: January 14, 2021 Oxbotica 6 P. Fremantle 7 University of Portsmouth 8 July 13, 2020 10 MQTT-TLS profile of ACE 11 draft-ietf-ace-mqtt-tls-profile-06 13 Abstract 15 This document specifies a profile for the ACE (Authentication and 16 Authorization for Constrained Environments) framework to enable 17 authorization in an Message Queuing Telemetry Transport (MQTT)-based 18 publish-subscribe messaging system. Proof-of-possession keys, bound 19 to OAuth2.0 access tokens, are used to authenticate and authorize 20 MQTT Clients. The protocol relies on TLS for confidentiality and 21 MQTT server (broker) authentication. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 14, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 1.2. ACE-Related Terminology . . . . . . . . . . . . . . . . . 4 60 1.3. MQTT-Related Terminology . . . . . . . . . . . . . . . . 4 61 2. Authorizing Connection Requests . . . . . . . . . . . . . . . 7 62 2.1. Client Token Request to the Authorization Server (AS) . . 8 63 2.2. Client Connection Request to the Broker (C) . . . . . . . 9 64 2.2.1. Client-Server Authentication over TLS and MQTT . . . 9 65 2.2.2. authz-info: The Authorization Information Topic . . . 10 66 2.2.3. Transporting Access Token Inside the MQTT CONNECT . . 11 67 2.2.4. Authentication Using AUTH Property . . . . . . . . . 13 68 2.2.4.1. Proof-of-Possession Using a Challenge from the 69 TLS session . . . . . . . . . . . . . . . . . . . 13 70 2.2.4.2. Proof-of-Possession via Broker-generated 71 Challenge/Response . . . . . . . . . . . . . . . 13 72 2.2.5. Token Validation . . . . . . . . . . . . . . . . . . 14 73 2.2.6. The Broker's Response to Client Connection Request . 15 74 2.2.6.1. Unauthorised Request: Authorisation Server 75 Discovery . . . . . . . . . . . . . . . . . . . . 15 76 2.2.6.2. Authorisation Success . . . . . . . . . . . . . . 15 77 3. Authorizing PUBLISH and SUBSCRIBE Messages . . . . . . . . . 16 78 3.1. PUBLISH Messages from the Publisher Client to the Broker 16 79 3.2. PUBLISH Messages from the Broker to the Subscriber 80 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 3.3. Authorizing SUBSCRIBE Messages . . . . . . . . . . . . . 17 82 4. Token Expiration and Reauthentication . . . . . . . . . . . . 18 83 5. Handling Disconnections and Retained Messages . . . . . . . . 18 84 6. Reduced Protocol Interactions for MQTT v3.1.1 . . . . . . . . 19 85 6.1. Token Transport . . . . . . . . . . . . . . . . . . . . . 19 86 6.2. Handling Authorization Errors . . . . . . . . . . . . . . 20 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 89 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 92 10.2. Informative References . . . . . . . . . . . . . . . . . 25 93 Appendix A. Checklist for profile requirements . . . . . . . . . 25 94 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 26 95 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 29 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 98 1. Introduction 100 This document specifies a profile for the ACE framework 101 [I-D.ietf-ace-oauth-authz]. In this profile, Clients and Servers 102 (Brokers) use MQTT to exchange Application Messages. The protocol 103 relies on TLS for communication security between entities. The MQTT 104 protocol interactions are described based on the MQTT v5.0 - the 105 OASIS Standard [MQTT-OASIS-Standard-v5]. Since it is expected that 106 MQTT deployments will continue to support MQTT v3.1.1 clients, this 107 document also describes a reduced set of protocol interactions for 108 MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard]. However, 109 MQTT v5.0 is the RECOMMENDED version as it works more naturally with 110 ACE-style authentication and authorization. 112 MQTT is a publish-subscribe protocol and after connecting to the MQTT 113 Server (Broker), a Client can publish and subscribe to multiple 114 topics. The Broker, which acts as the Resource Server (RS), is 115 responsible for distributing messages published by the publishers to 116 their subscribers. In the rest of the document the terms "RS", "MQTT 117 Server" and "Broker" are used interchangeably. 119 Messages are published under a Topic Name, and subscribers must 120 subscribe to the Topic Names to receive the corresponding messages. 121 The Broker uses the Topic Name in a published message to determine 122 which subscribers to relay the messages. In this document, topics, 123 more specifically, Topic Names, are treated as resources. The 124 Clients are assumed to have identified the publish/subscribe topics 125 of interest out-of-band (topic discovery is not a feature of the MQTT 126 protocol). A Resource Owner can pre-configure policies at the 127 Authorisation Server (AS) that give Clients publish or subscribe 128 permissions to different topics. 130 Clients prove their permission to publish/subscribe to topics hosted 131 on an MQTT broker using an access token, bound to a proof-of- 132 possession (PoP) key. This document describes how to authorize the 133 following exchanges between the Clients and the Broker. 135 o Connection requests from the Clients to the Broker 137 o Publish requests from the Clients to the Broker, and from the 138 Broker to the Clients 140 o Subscribe requests from Clients to the Broker 142 Clients use MQTT PUBLISH message to publish to a topic. This 143 document does not protect the payload of the PUBLISH message from the 144 Broker. Hence, the payload is not signed or encrypted specifically 145 for the subscribers. This functionality may be implemented using the 146 proposal outlined in the CoAP Pub-Sub Profile 147 [I-D.ietf-ace-pubsub-profile]. 149 To provide communication confidentiality and RS authentication, TLS 150 is used, and TLS 1.3 is RECOMMENDED. This document makes the same 151 assumptions as Section 4 of the ACE framework 152 [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with 153 the AS and setting up keying material. While the Client-Broker 154 exchanges are only over MQTT, the required Client-AS and RS-AS 155 interactions are described for HTTPS-based communication, using 156 'application/ace+json' content type, and unless otherwise specified, 157 using JSON encoding. The token may be a reference or JSON Web Token 158 (JWT). For JWTs, this document follows RFC 7800 [RFC7800] for PoP 159 semantics for JWTs. The Client-AS and RS-AS MAY also use protocols 160 other than HTTP, e.g. Constrained Application Protocol (CoAP) or 161 MQTT. Implementations MAY also use 'application/ace+cbor' content 162 type, and CBOR encoding, and CBOR Web Token (CWT) and associated PoP 163 semantics to reduce the protocol memory and bandwidth requirements. 164 For more information, see Proof-of-Possession Key Semantics for CBOR 165 Web Tokens (CWTs) [RFC8747]. 167 1.1. Requirements Language 169 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in BCP 172 14 [RFC2119] [RFC8174], when, and only when, they appear in all 173 capitals, as shown here. 175 1.2. ACE-Related Terminology 177 The terminology for entities in the architecture is defined in OAuth 178 2.0 RFC 6749 [RFC6749] such as "Client" (C), "Resource Server" (RS) 179 and "Authorization Server" (AS). 181 The term "resource" is used to refer to an MQTT Topic Name, which is 182 defined in Section 1.3. Hence, the "Resource Owner" is any entity 183 that can authoritatively speak for the topic. 185 Certain security-related terms such as "authentication", 186 "authorization", "confidentiality", "(data) integrity", "message 187 authentication code", and "verify" are taken from RFC 4949 [RFC4949]. 189 1.3. MQTT-Related Terminology 191 The document describes message exchanges as MQTT protocol 192 interactions. The Clients are MQTT Clients, which connect to the 193 Broker to publish and subscribe to Application Messages, labelled 194 with their topics. For additional information, please refer to the 195 MQTT v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT 196 v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard]. 198 MQTTS 199 Secured transport profile of MQTT. MQTTS runs over TLS. 201 Broker 202 The Server in MQTT. It acts as an intermediary between the 203 Clients that publish Application Messages, and the Clients 204 that made Subscriptions. The Broker acts as the Resource 205 Server for the Clients. 207 Client 208 A device or program that uses MQTT. 210 Session 211 A stateful interaction between a Client and a Broker. Some 212 Sessions last only as long as the network connection, others 213 can span multiple network connections. 215 Application Message 216 The data carried by the MQTT protocol. The data has an 217 associated Quality-of-Service (QoS) level and a Topic Name. 219 QoS level 220 The level of assurance for the delivery of an Application 221 Message. The QoS level can be 0-2, where "0" indicates "At 222 most once delivery", "1" "At least once delivery", and "2" 223 "Exactly once delivery". 225 Topic Name 226 The label attached to an Application Message, which is 227 matched to a Subscription. 229 Subscription 230 A Subscription comprises a Topic Filter and a maximum QoS. A 231 Subscription is associated with a single session. 233 Topic Filter 234 An expression that indicates interest in one or more Topic 235 Names. Topic Filters may include wildcards. 237 MQTT sends various control messages across a network connection. The 238 following is not an exhaustive list and the control packets that are 239 not relevant for authorization are not explained. These include, for 240 instance, the PUBREL and PUBCOMP packets used in the 4-step handshake 241 required for QoS level 2. 243 CONNECT 244 Client request to connect to the Broker. This is the first 245 packet sent by a Client. 247 CONNACK 248 The Broker connection acknowledgment. CONNACK packets 249 contain return codes indicating either a success or an error 250 state to in response to a Client's CONNECT packet. 252 AUTH 253 Authentication Exchange. An AUTH packet is sent from the 254 Client to the Broker or from the Broker to the Client as part 255 of an extended authentication exchange. AUTH Properties 256 include Authentication Method and Authentication Data. The 257 Authentication Method is set in the CONNECT packet, and 258 consequent AUTH packets follow the same Authentication 259 Method. The contents of the Authentication Data are defined 260 by the Authentication Method. 262 PUBLISH 263 Publish request sent from a publishing Client to the Broker, 264 or from the Broker to a subscribing Client. 266 PUBACK 267 Response to PUBLISH request with QoS level 1. PUBACK can be 268 sent from the Broker to a Client or a Client to the Broker. 270 PUBREC 271 Response to PUBLISH request with QoS level 2. PUBREC can be 272 sent from the Broker to a Client or a Client to the Broker. 274 SUBSCRIBE 275 Subscribe request sent from a Client. 277 SUBACK 278 Subscribe acknowledgment. 280 PINGREQ 281 A ping request sent from a Client to the Broker. It signals 282 to the Broker that the Client is alive, and is used to 283 confirm that the Broker is also alive. The "Keep Alive" 284 period is set in the CONNECT message. 286 PINGRESP 287 Response sent by the Broker to the Client in response to 288 PINGREQ. It indicates the Broker is alive. 290 Will 291 If the network connection is not closed normally, the Broker 292 sends a last Will message for the Client, if the Client 293 provided one in its CONNECT message. If the Will Flag is 294 set, then the payload of the CONNECT message includes 295 information about the Will. The information consists of the 296 Will Properties, Will Topic, and Will Payload fields. 298 2. Authorizing Connection Requests 300 This section specifies how Client connections are authorized by the 301 MQTT Broker. Figure 1 shows the basic protocol flow during 302 connection set-up. The token request and response use the token 303 endpoint at the AS, specified in Section 5.6 of the ACE framework 304 [I-D.ietf-ace-oauth-authz]. Steps (D) and (E) are optional and use 305 the introspection endpoint, specified in Section 5.7 of the ACE 306 framework. The Client and the Broker use HTTPS to communicate to AS 307 via these endpoints. The Client and the Broker use MQTT to 308 communicate between them. 310 If the Client is resource-constrained, a Client Authorisation Server 311 may carry out the token request on behalf of the Client, and later, 312 onboard the Client with the token. Also, the C-AS and Broker-AS 313 interfaces may be implemented using protocols other than HTTPS, e.g. 314 CoAP or MQTT. The interactions between a Client and its Client 315 Authorization Server for token onboarding, and support for MQTTS- 316 based token requests at the AS are out of scope of this document. 318 +---------------------+ 319 | Client | 320 | | 321 +---(A) Token request--| Client - | 322 | | Authorization | 323 | +-(B) Access token-> Server Interface | 324 | | | (HTTPS) | 325 | | |_____________________| 326 | | | | 327 +--v-------------+ | Pub/Sub Interface | 328 | Authorization | | (MQTTS) | 329 | Server | +-----------^---------+ 330 |________________| | | 331 | ^ (C)Connection (F)Connection 332 | | request + response 333 | | access token | 334 | | | | 335 | | +---v--------------+ 336 | | | Broker (MQTTS) | 337 | | |__________________| 338 | +(D)Introspection-| | 339 | request (optional) | RS-AS interface | 340 | | (HTTPS) | 341 +-(E)Introspection---->|__________________| 342 response (optional) 344 Figure 1: Connection set-up 346 2.1. Client Token Request to the Authorization Server (AS) 348 The first step in the protocol flow (Figure 1 (A)) is the token 349 acquisition by the Client from the AS. The Client and the AS MUST 350 perform mutual authentication. The Client requests an access token 351 from the AS as described in Section 5.6.1 of the ACE framework 352 [I-D.ietf-ace-oauth-authz], however, it MUST set the profile 353 parameter to 'mqtt_tls'. The media format is 'application/ace+json'. 354 The AS uses JSON in the payload of its responses to both to the 355 Client and the RS. 357 If the AS successfully verifies the access token request and 358 authorizes the Client for the indicated audience (i.e. RS) and 359 scopes (i.e. publish/subscribe permissions over topics), the AS 360 issues an access token (Figure 1 (B)). The response includes the 361 parameters described in Section 5.6.2 of the ACE framework 362 [I-D.ietf-ace-oauth-authz]. The returned token is assumed to be 363 Proof-of-Possession (PoP) token by default. This document follows 364 RFC 7800 [RFC7800] for PoP semantics for JWTs. The PoP token 365 includes a 'cnf' parameter with a symmetric or asymmetric PoP key. 367 Note that the 'cnf' parameter in the web tokens are to be consumed by 368 the RS and not the Client. For the asymmetric case, the PoP token 369 may include the 'rs_cnf' parameter containing the information about 370 the public key to be used by the RS to authenticate as described in 371 [I-D.ietf-ace-oauth-params]. 373 The AS returns error responses for JSON-based interactions following 374 Section 5.2 of RFC 6749 [RFC6749]. When CBOR is used, the 375 interactions must implement Section 5.6.3 of the ACE framework 376 [I-D.ietf-ace-oauth-authz]. 378 2.2. Client Connection Request to the Broker (C) 380 2.2.1. Client-Server Authentication over TLS and MQTT 382 The Client and the Broker MUST perform mutual authentication. The 383 Client MUST authenticate to the Broker either over MQTT or TLS. For 384 MQTT, the options are "None" and "ace". For TLS, the options are 385 "Anon" for an anonymous client, and "Known(RPK/PSK)" for Raw Public 386 Keys (RPK) and Pre-Shared Keys (PSK), respectively. Combined, client 387 authentication has the following options: 389 o "TLS:Anon-MQTT:None": This option is used only for the topics that 390 do not require authorization, including the "authz-info" topic. 391 Publishing to the "authz-info" topic is described in 392 Section 2.2.2. 394 o "TLS:Anon-MQTT:ace": The token is transported inside the CONNECT 395 message, and MUST be validated using one of the methods described 396 in Section 2.2.2. This option also supports a tokenless 397 connection request for AS discovery. 399 o "TLS:Known(RPK/PSK)-MQTT:none": For the RPK, the token MUST have 400 been published to the "authz-info" topic. For the PSK, the token 401 MAY be, alternatively, provided in the "psk_identity". The TLS 402 session set-up is as described in DTLS profile for ACE 403 [I-D.ietf-ace-dtls-authorize]. 405 o "TLS:Known(RPK/PSK)-MQTT:ace": This option SHOULD NOT be chosen. 406 In any case, the token transported in the CONNECT overwrites any 407 permissions passed during the TLS authentication. 409 It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace. 411 The Broker MUST be authenticated during the TLS handshake. If the 412 Client authentication uses TLS:Known(RPK/PSK), then the Broker is 413 authenticated using the respective method. Otherwise, to 414 authenticate the Broker, the client MUST validate a public key from a 415 X.509 certificate or an RPK from the Broker against the 'rs_cnf' 416 parameter in the token response. The AS MAY include the thumbprint 417 of the RS's X.509 certificate in the 'rs_cnf' (thumbprint as defined 418 in [I-D.ietf-cose-x509]). In this case, the client MUST validate the 419 RS certificate against this thumbprint. 421 2.2.2. authz-info: The Authorization Information Topic 423 In the cases when the Client MUST transport the token to the Broker 424 first, the Client connects to the Broker to publish its token to the 425 "authz-info" topic. The "authz-info" topic MUST be publish-only 426 (i.e. the Clients are not allowed to subscribe to it). "authz-info" 427 is not protected, and hence, the Client uses the "TLS:Anon-MQTT:None" 428 option over a TLS connection. After publishing the token, the Client 429 disconnects from the Broker and is expected to reconnect using client 430 authentication over TLS (i.e. TLS:Known(RPK/PSK)-MQTT:none). 432 The Broker stores and indexes all tokens received to the "authz-info" 433 topic in its key store (similar to DTLS profile for ACE 434 [I-D.ietf-ace-dtls-authorize]). This profile follows the 435 recommendation of Section 5.8.1 of the ACE framework 436 [I-D.ietf-ace-oauth-authz], and expects that the Broker stores only 437 one token per proof-of-possession key, and any other token linked to 438 the same key overwrites an existing token. 440 The Broker MUST verify the validity of the token (i.e. through local 441 validation or introspection) as described in Section 2.2.5. To 442 validate the token, RS MAY need to introspect the token with the AS, 443 e.g. if the token is a reference. If the token is not valid, the 444 Broker MUST discard the token. Depending on the QoS level of the 445 PUBLISH message, the Broker may return the error response as a PUBACK 446 or a DISCONNECT message. 448 If the QoS level is equal to 0, and the token is invalid or the 449 claims cannot be obtained in the case of an introspected token, the 450 Broker MUST send a DISCONNECT message with the reason code '0x87 (Not 451 authorized)'. If the PUBLISH payload does not parse to a token, the 452 RS MUST send a DISCONNECT with the reason code '0x99 (Payload format 453 invalid)'. 455 If the QoS level of the PUBLISH message is greater than or equal to 456 1, the Broker MUST return 'Not authorized' in PUBACK. If the PUBLISH 457 payload does not parse to a token, the PUBACK reason code is '0x99 458 (Payload format invalid)'. 460 It must be noted that when the RS sends the 'Not authorized' 461 response, this corresponds to the token being invalid, and not that 462 the actual PUBLISH message was not authorized. Given that the 463 "authz-info" is a public topic, this response is not expected to 464 cause confusion. 466 2.2.3. Transporting Access Token Inside the MQTT CONNECT 468 This section describes how the Client transports the token to the 469 Broker (RS) inside the CONNECT message. If this method is used, the 470 Client TLS connection is expected to be anonymous, and the Broker is 471 authenticated during the TLS connection set-up. The approach 472 described in this section is similar to an earlier proposal by 473 Fremantle et al [fremantle14]. 475 Figure 2 shows the structure of the MQTT CONNECT message used in MQTT 476 v5.0. A CONNECT message is composed of a fixed header, a variable 477 header and a payload. The fixed header contains the Control Packet 478 Type (CPT), Reserved, and Remaining Length fields. The Variable 479 Header contains the Protocol Name, Protocol Level, Connect Flags, 480 Keep Alive, and Properties fields. The Connect Flags in the variable 481 header specify the properties of the MQTT session. It also indicates 482 the presence or absence of some fields in the Payload. The payload 483 contains one or more encoded fields, namely a unique Client 484 identifier for the Client, a Will Topic, Will Payload, User Name and 485 Password. All but the Client identifier can be omitted depending on 486 flags in the Variable Header. 488 0 8 16 24 32 489 +------------------------------------------------------+ 490 |CPT=1 | Rsvd.|Remaining len.| Protocol name len. = 4 | 491 +------------------------------------------------------+ 492 | 'M' 'Q' 'T' 'T' | 493 +------------------------------------------------------+ 494 | Proto.level=5|Connect flags| Keep alive | 495 +------------------------------------------------------+ 496 | Property length | 497 | Auth. Method (0x15) | 'ace' | 498 | Auth. Data (0x16) | token or | 499 | token + PoP data | 500 +------------------------------------------------------+ 501 | Payload | 502 +------------------------------------------------------+ 504 Figure 2: MQTT v5 CONNECT control message with ACE authentication. 505 (CPT=Control Packet Type) 507 The CONNECT message flags are Username, Password, Will retain, Will 508 QoS, Will Flag, Clean Start, and Reserved. Figure 8 shows how the 509 flags MUST be set to use AUTH packets for authentication and 510 authorisation, i.e. the username and password flags MUST be set to 0. 512 An MQTT v5.0 RS MAY also support token transport using Username and 513 Password to provide a security option for MQTT v3.1.1 clients, as 514 described in Section 6. 516 +-----------------------------------------------------------+ 517 |User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| 518 | Flag |Flag | | | |Start| | 519 +-----------------------------------------------------------+ 520 | 0 | 0 | X | X X | X | X | 0 | 521 +-----------------------------------------------------------+ 523 Figure 3: CONNECT flags for AUTH 525 The Will Flag indicates that a Will message needs to be sent if the 526 network connection is not closed normally. The situations in which 527 the Will message is published include disconnections due to I/O or 528 network failures, and the server closing the network connection due 529 to a protocol error. The Client may set the Will Flag as desired 530 (marked as 'X' in Figure 3). If the Will Flag is set to 1 and the 531 Broker accepts the connection request, the Broker must store the Will 532 message and publish it when the network connection is closed 533 according to Will QoS and Will retain parameters and MQTT Will 534 management rules. To avoid publishing Will Messages in the case of 535 temporary network disconnections, the Client may specify a Will Delay 536 Interval in the Will Properties. Section 5 explains how the Broker 537 deals with the retained messages in further detail. 539 In MQTT v5.0, the Client signals a clean session (i.e. the session 540 does not continue an existing session), by setting the Clean Start 541 Flag to 1 and, the Session Expiry Interval to 0 in the CONNECT 542 message. In this profile, the Broker SHOULD always start with a 543 clean session regardless of how these parameters are set. Starting a 544 clean session helps the Broker avoid keeping unnecessary session 545 state for unauthorised clients. If the Broker starts a clean 546 session, the Broker MUST set the Session Present flag to 0 in the 547 CONNACK packet to signal this to the Client. 549 If necessary, the Broker MAY support session continuation, and hence, 550 maintain and use client state from the existing session. The client 551 state MAY include token and its introspection result (for reference 552 tokens) in addition to the MQTT session state. When reconnecting to 553 the Broker, the Client MUST still provide a token, as well as setting 554 the Clean Start to 0 and supplying a Session Expiry interval in the 555 CONNECT message. The Broker MUST perform proof-of-possession 556 validation on the provided token. If the token matches the stored 557 state, the Broker MAY skip introspecting a token by reference, and 558 use the stored introspection result. Continuing, both the Client and 559 the Broker MUST resend any unacknowledged PUBLISH packets (where QoS 560 > 0) and PUBREL packets. The Broker MUST still verify the Client is 561 authorized to receive or send these packets. When a Client connects 562 with a long Session Expiry Interval, the Broker may need to maintain 563 Client's MQTT session state after it disconnects for an extended 564 period. Brokers SHOULD implement administrative policies to limit 565 misuse. 567 2.2.4. Authentication Using AUTH Property 569 To use AUTH, the Client MUST set the Authentication Method as a 570 property of a CONNECT packet by using the property identifier 21 571 (0x15). This is followed by a UTF-8 Encoded String containing the 572 name of the Authentication Method, which MUST be set to 'ace'. If 573 the RS does not support this profile, it sends a CONNACK with a 574 Reason Code of '0x8C (Bad authentication method)'. 576 The Authentication Method is followed by the Authentication Data, 577 which has a property identifier 22 (0x16) and is binary data. The 578 binary data in MQTT is represented by a two-byte integer length, 579 which indicates the number of data bytes, followed by that number of 580 bytes. Based on the Authentication Data, this profile allows: 582 o Proof-of-Possession using a challenge from the TLS session 584 o Proof-of-Possession via Broker generated challenge/response 586 2.2.4.1. Proof-of-Possession Using a Challenge from the TLS session 588 For this option, the Authentication Data MUST contain the two-byte 589 integer token length, the token, and the keyed message digest (MAC) 590 or the Client signature. The content to calculate the keyed message 591 digest (MAC) or the Client signature (for the proof-of-possession) is 592 obtained using a TLS exporter ([RFC5705] for TLS 1.2 and for TLS 1.3, 593 Section 7.5 of [RFC8446]). The content is exported from TLS using 594 the exporter label 'EXPORTER-ACE-MQTT-Sign-Challenge', an empty 595 context, and length of 32 bytes. The token is also validated as 596 described in Section 2.2.5 and, the server responds with a CONNACK 597 with the appropriate response code. The client cannot reauthenticate 598 using this method during the same session ( see Section 4). ) 600 2.2.4.2. Proof-of-Possession via Broker-generated Challenge/Response 602 For this option, the RS follows a Broker-generated challenge/response 603 protocol. The success case is illustrated in Figure 4. If the 604 Authentication Data contains only the two-byte integer token length 605 and the token, the RS MUST respond with an AUTH packet, with the 606 Authenticate Reason Code set to '0x18 (Continue Authentication)'. 607 This packet includes the Authentication Method, which MUST be set to 608 'ace' and Authentication Data. The Authentication Data MUST NOT be 609 empty and contains an 8-byte nonce as a challenge for the Client. 610 The Client responds to this with an AUTH packet with a reason code 611 '0x18 (Continue Authentication)'. Similarly, the Client packet sets 612 the Authentication Method to 'ace'. The Authentication Data in the 613 Client's response is formatted as the client nonce length, the client 614 nonce, and the signature or MAC computed over the RS nonce 615 concatenated with the client nonce. Next, the token is validated as 616 described in Section 2.2.5. 618 The client MAY also re-authenticate using this flow. 620 Resource 621 Client Server 622 | | 623 |<===========>| TLS connection set-up 624 | | 625 | | 626 +------------>| CONNECT with Authentication Data 627 | | contains only token 628 | | 629 <-------------+ AUTH '0x18 (Cont. Authentication)' 630 | | 8-byte nonce as RS challenge 631 | | 632 |------------>| AUTH '0x18 (Cont. Authentication)' 633 | | 8-byte client nonce + signature/MAC 634 | | 635 | |---+ Token validation 636 | | | (may involve introspection) 637 | |<--+ 638 | | 639 |<------------+ CONNACK '0x00 (Success)' 641 Figure 4: PoP Challenge/Response Protocol Flow - Success 643 2.2.5. Token Validation 645 The RS MUST verify the validity of the token either locally (e.g. in 646 the case of a self-contained token) or the RS MAY send an 647 introspection request to the AS. RS MUST verify the claims according 648 to the rules set in the Section 5.8.1.1 of the ACE framework 649 [I-D.ietf-ace-oauth-authz]. 651 To authenticate the Client, the RS validates the signature or the 652 MAC, depending on how the PoP protocol is implemented. HS256 and 653 Ed25519 are mandatory to implement depending on the choice of 654 symmetric or asymmetric validation. Validation of the signature or 655 MAC MUST fail if the signature algorithm is set to "none", when the 656 key used for the signature algorithm cannot be determined, or the 657 computed and received signature/MAC do not match. 659 2.2.6. The Broker's Response to Client Connection Request 661 Based on the validation result (obtained either via local inspection 662 or using the /introspection interface of the AS), the Broker MUST 663 send a CONNACK message to the Client. 665 2.2.6.1. Unauthorised Request: Authorisation Server Discovery 667 If the Client does not provide a valid token or omits the 668 Authentication Data field, the Broker triggers AS discovery. The 669 Broker MUST NOT process any data sent by the Client after the CONNECT 670 packet including AUTH packets (Note that this is different in MQTT 671 v5.0, the Broker is allowed to process AUTH packets even if the 672 Broker rejects the CONNECT). 674 The Broker responds with the CONNACK reason code '0x87 (Not 675 Authorized)' and includes a User Property (identified by 38 (0x26)) 676 for the AS Request Creation Hints. The User Property is a UTF-8 677 string pair, composed of a name and a value. The name of the User 678 Property MUST be set to "ace_as_hint". The value of the user 679 property is a UTF-8 encoded JSON string containing the mandatory "AS" 680 parameter, and the optional parameters "audience", "kid", "cnonce", 681 and "scope" as defined in Section 5.1.2 of the ACE framework 682 [I-D.ietf-ace-oauth-authz]. 684 2.2.6.2. Authorisation Success 686 On success, the reason code of the CONNACK is '0x00 (Success)'. If 687 the Broker starts a new session, it MUST also set Session Present to 688 0 in the CONNACK packet to signal a clean session to the Client. 689 Otherwise, it MUST set Session Present to 1. In case of an invalid 690 PoP token, the CONNACK reason code is '0x87 (Not Authorized)'. 692 If the Broker accepts the connection, it MUST store the token until 693 the end of the connection. On Client or Broker disconnection, the 694 Client is expected to transport a token again on the next connection 695 attempt. 697 If the token is not self-contained and the Broker uses token 698 introspection, it MAY cache the validation result to authorize the 699 subsequent PUBLISH and SUBSCRIBE messages. PUBLISH and SUBSCRIBE 700 messages, which are sent after a connection set-up, do not contain 701 access tokens. If the introspection result is not cached, then the 702 RS needs to introspect the saved token for each request. The Broker 703 SHOULD also use a cache time out to introspect tokens regularly. 705 3. Authorizing PUBLISH and SUBSCRIBE Messages 707 To authorize a Client's PUBLISH and SUBSCRIBE messages, the Broker 708 uses the scope field in the token (or in the introspection result). 709 The scope field contains the publish and subscribe permissions for 710 the Client. The scope is a JSON array, each item following the 711 Authorization Information Format (AIF) for ACE 712 [I-D.bormann-core-ace-aif]. The specific data model for MQTT is: 714 AIF-MQTT = AIF-Generic 715 AIF-Generic = [* [topic_filter,permissions]] 716 topic_filter = tstr 717 permissions = [+permission] 718 permission = "pub"/"sub" 720 Figure 5: AIF-MQTT data model 722 Topic filters are implemented according to Section 4.7 of MQTT v5.0 - 723 the OASIS Standard [MQTT-OASIS-Standard-v5] and includes special 724 wildcard characters. The multi-level wildcard, '#', matches any 725 number of levels within a topic, and the single-level wildcard, '+', 726 matches one topic level. 728 An example scope field may contain: 730 [["topic1", ["pub","sub"]], ["topic2/#",["pub"]], ["+/topic3",["sub"]]] 732 Figure 6: Example scope 734 This access token gives publish ("pub") and subscribe ("sub") 735 permissions to the 'topic1', publish permission to all the subtopics 736 of 'topic2', and subscribe permission to all topic3, skipping one 737 level. If the Will Flag is set, then the Broker MUST check that the 738 token allows the publication of the Will message (i.e. the Will Topic 739 filter is found in the scope). 741 3.1. PUBLISH Messages from the Publisher Client to the Broker 743 On receiving the PUBLISH message, the Broker MUST use the type of 744 message (i.e. PUBLISH) and the Topic name in the message header to 745 match against the scope string in the cached token or its 746 introspection result. Following the example in the previous section, 747 a client sending a PUBLISH message to 'a/topic3' would be allowed to 748 publish, as the scope includes the string 'publish_+/topic3'. 750 If the Client is allowed to publish to the topic, the Broker must 751 publish the message to all valid subscribers of the topic. In the 752 case of an authorization failure, the Broker MUST return an error, if 753 the Client has set the QoS level of the PUBLISH message to greater 754 than or equal to 1. Depending on the QoS level, the Broker responds 755 with either a PUBACK or PUBREC packet with reason code '0x87 (Not 756 authorized)'. On receiving a PUBACK with '0x87 (Not authorized)', 757 the Client MAY reauthenticate by providing a new token as described 758 in Section 4. 760 For QoS level 0, the Broker sends a DISCONNECT with reason code '0x87 761 (Not authorized)' and closes the network connection. Note that the 762 server-side DISCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1, 763 the server needs to drop the connection). 765 3.2. PUBLISH Messages from the Broker to the Subscriber Clients 767 To forward PUBLISH messages to the subscribing Clients, the Broker 768 identifies all the subscribers that have valid matching topic 769 subscriptions (i.e. the tokens are valid, and token scopes allow a 770 subscription to the particular topic). The Broker sends a PUBLISH 771 message with the Topic name to all the valid subscribers. 773 The Broker MUST NOT forward messages to the unauthorized subscribers. 774 There is no way to inform the Clients with invalid tokens that an 775 authorization error has occurred other than sending a DISCONNECT 776 message. The Broker SHOULD send a DISCONNECT message with the reason 777 code '0x87 (Not authorized)'. 779 3.3. Authorizing SUBSCRIBE Messages 781 In MQTT, a SUBSCRIBE message is sent from a Client to the Broker to 782 create one or more subscriptions to one or more topics. The 783 SUBSCRIBE message may contain multiple Topic Filters. The Topic 784 Filters may include wildcard characters. 786 On receiving the SUBSCRIBE message, the Broker MUST use the type of 787 message (i.e. SUBSCRIBE) and the Topic Filter in the message header 788 to match against a scope string of the stored token or introspection 789 result. The Topic Filters MUST be equal or a subset of the scopes 790 associated with the Client's token. 792 As a response to the SUBSCRIBE message, the Broker issues a SUBACK 793 message. For each Topic Filter, the SUBACK packet includes a return 794 code matching the QoS level for the corresponding Topic Filter. In 795 the case of failure, the return code is 0x87, indicating that the 796 Client is 'Not authorized'. A reason code is returned for each Topic 797 Filter. Therefore, the Client may receive success codes for a subset 798 of its Topic Filters while being unauthorized for the rest. 800 4. Token Expiration and Reauthentication 802 The Broker MUST check for token expiration whenever a CONNECT, 803 PUBLISH or SUBSCRIBE message is received or sent. The Broker SHOULD 804 check for token expiration on receiving a PINGREQUEST message. The 805 Broker MAY also check for token expiration periodically, e.g. every 806 hour. This may allow for early detection of a token expiry. 808 The token expiration is checked by checking the 'exp' claim of a JWT 809 or introspection response, or via performing an introspection request 810 with the AS as described in Section 5.7 of the ACE framework 811 [I-D.ietf-ace-oauth-authz]. Token expirations may trigger the RS to 812 send PUBACK, SUBACK and DISCONNECT messages with return code set to 813 'Not authorised'. After sending a DISCONNECT message, the network 814 connection is closed, and no more messages can be sent. However, as 815 a response to the PUBACK and SUBACK, the Client MAY reauthenticate. 816 The Clients MAY also proactively update their tokens, i.e. before 817 they receive a message with 'Not authorized' return code. 819 To start reauthentication, the Client MUST send an AUTH packet with 820 reason code '0x19 (Re-authentication)'. The Client MUST set the 821 Authentication Method as 'ace' and transport the new token in the 822 Authentication Data. The Broker accepts reauthentication requests if 823 the Client has already submitted a token (may be expired) and 824 validated via the challenge-response PoP as defined in 825 Section 2.2.4.2. The Client MUST use the challenge-response PoP. 826 Otherwise, the Broker MUST deny the request. If the reauthentication 827 fails, the Broker MUST send a DISCONNECT with the reason code '0x87 828 (Not Authorized)'. 830 5. Handling Disconnections and Retained Messages 832 In the case of a Client DISCONNECT, the Broker deletes all the 833 session state but MUST keep the retained messages. By setting a 834 RETAIN flag in a PUBLISH message, the publisher indicates to the 835 Broker that it should store the most recent message for the 836 associated topic. Hence, the new subscribers can receive the last 837 sent message from the publisher of that particular topic without 838 waiting for the next PUBLISH message. The Broker MUST continue 839 publishing the retained messages as long as the associated tokens are 840 valid. 842 In case of disconnections due to network errors or server 843 disconnection due to a protocol error (which includes authorization 844 errors), the Will message must be sent if the Client supplied a Will 845 in the CONNECT message. The Client's token scopes MUST include the 846 Will Topic. The Will message MUST be published to the Will Topic 847 regardless of whether the corresponding token has expired. In the 848 case of a server-side DISCONNECT, the server returns the '0x87 Not 849 Authorized' return code to the Client. 851 6. Reduced Protocol Interactions for MQTT v3.1.1 853 This section describes a reduced set of protocol interactions for the 854 MQTT v3.1.1 Clients. An MQTT v5.0 Broker MAY implement these 855 interactions for the MQTT v3.1.1 clients; MQTT v5.0 clients are NOT 856 RECOMMENDED to use the flows described in this section. Brokers that 857 do not support MQTT v3.1.1 clients return a CONNACK packet with 858 Reason Code '0x84 (Unsupported Protocol Version)' in response to the 859 connection requests. 861 6.1. Token Transport 863 As in MQTT v5.0, The Token MAY either be transported before by 864 publishing to the "authz-info" topic, or inside the CONNECT message. 866 In MQTT v3.1.1, after the Client published to the "authz-info" topic, 867 the Broker cannot communicate the result of the token validation as 868 PUBACK reason codes or server-side DISCONNECT messages are not 869 supported. In any case, an invalid token would fail the subsequent 870 TLS handshake, which can prompt the Client to obtain a valid token. 872 To transport the token to the Broker inside the CONNECT message, the 873 Client uses the username and password fields. Figure 7 shows the 874 structure of the MQTT CONNECT message. 876 0 8 16 24 32 877 +------------------------------------------------------+ 878 |CPT=1 | Rsvd.|Remaining len.| Protocol name len. = 4 | 879 +------------------------------------------------------+ 880 | 'M' 'Q' 'T' 'T' | 881 +------------------------------------------------------+ 882 | Proto.level=4|Connect flags| Keep alive | 883 +------------------------------------------------------+ 884 | Payload | 885 | Client Identifier | 886 | Username as access token (UTF-8) | 887 | Password length (2 Bytes) | 888 | Password data as signature/MAC (binary) | 889 +------------------------------------------------------+ 891 Figure 7: MQTT CONNECT control message. (CPT=Control Packet Type, 892 Rsvd=Reserved, len.=length, Proto.=Protocol) 894 Figure 8 shows how the MQTT connect flags MUST be set to initiate a 895 connection with the Broker. 897 +-----------------------------------------------------------+ 898 |User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| 899 | flag |flag | | | | | | 900 +-----------------------------------------------------------+ 901 | 1 | 1 | X | X X | X | X | 0 | 902 +-----------------------------------------------------------+ 904 Figure 8: MQTT CONNECT flags. (Rsvd=Reserved) 906 The Broker SHOULD NOT accept session continuation. To this end, the 907 Broker ignores how the Clean Session Flag is set, and on connection 908 success, the Broker MUST set the Session Present flag to 0 in the 909 CONNACK packet to indicate a clean session to the Client. If the 910 Broker wishes to support session continuation, it MUST still perform 911 proof-of-possession validation on the provided Client token. MQTT 912 v3.1.1 does not use a Session Expiry Interval, and the Client expects 913 that the Broker maintains the session state after it disconnects. 914 However, stored Session state can be discarded as a result of 915 administrator policies, and Brokers SHOULD implement the necessary 916 policies to limit misuse. 918 The Client may set the Will Flag as desired (marked as 'X' in 919 Figure 8). Username and Password flags MUST be set to 1 to ensure 920 that the Payload of the CONNECT message includes both Username and 921 Password fields. 923 The CONNECT in MQTT v3.1.1 does not have a field to indicate the 924 authentication method. To signal that the Username field contains an 925 ACE token, this field MUST be prefixed with 'ace' keyword, which is 926 followed by the access token. The Password field MUST be set to the 927 keyed message digest (MAC) or signature associated with the access 928 token for proof-of-possession. The Client MUST apply the PoP key on 929 the challenge derived from the TLS session as described in 930 Section 2.2.4.1. 932 In MQTT v3.1.1, the MQTT Username as a UTF-8 encoded string (i.e. is 933 prefixed by a 2-byte length field followed by UTF-8 encoded character 934 data) and may be up to 65535 bytes. Therefore, an access token that 935 is not a valid UTF-8 MUST be Base64 [RFC4648] encoded. (The MQTT 936 Password allows binary data up to 65535 bytes.) 938 6.2. Handling Authorization Errors 940 Handling errors are more primitive in MQTT v3.1.1 due to not having 941 appropriate error fields, error codes, and server-side DISCONNECTs. 942 Therefore, the broker will disconnect on almost any error and may not 943 keep session state, necessitating clients to make a greater effort to 944 ensure that tokens remain valid and not attempt to publish to topics 945 that they do not have permissions for. The following lists how the 946 broker responds to specific errors. 948 o CONNECT without a token: It is not possible to support AS 949 discovery via sending a tokenless CONNECT message to the Broker. 950 This is because a CONNACK packet in MQTT v3.1.1 does not include a 951 means to provide additional information to the Client. Therefore, 952 AS discovery needs to take place out-of-band. CONNECT attempt 953 MUST fail. 955 o Client-RS PUBLISH authorization failure: In the case of a failure, 956 it is not possible to return an error in MQTT v3.1.1. 957 Acknowledgement messages only indicate success. In the case of an 958 authorization error, the Broker SHOULD disconnect the Client. 959 Otherwise, it MUST ignore the PUBLISH message. Also, as 960 DISCONNECT messages are only sent from a Client to the Broker, the 961 server disconnection needs to take place below the application 962 layer. 964 o SUBSCRIBE authorization failure: In the SUBACK packet, the return 965 code must be 0x80 indicating 'Failure' for the unauthorized 966 topic(s). Note that, in both MQTT versions, a reason code is 967 returned for each Topic Filter. 969 o RS-Client PUBLISH authorization failure: When RS is forwarding 970 PUBLISH messages to the subscribed Clients, it may discover that 971 some of the subscribers are no more authorized due to expired 972 tokens. These token expirations SHOULD lead to disconnecting the 973 Client rather than silently dropping messages. 975 7. IANA Considerations 977 This document registers 'EXPORTER-ACE-MQTT-Sign-Challenge' from 978 Section 2.2.4.1 in the TLS Exporter Label Registry TLS-REGISTRIES 979 [RFC8447]. 981 In addition, the following registrations are done for the ACE OAuth 982 Profile Registry following the procedure specified in 983 [I-D.ietf-ace-oauth-authz]. 985 Note to the RFC editor: Please replace all occurrences of "[RFC- 986 XXXX]" with the RFC number of this specification and delete this 987 paragraph. 989 Name: mqtt_tls 990 Description: Profile for delegating Client authentication and 991 authorization using MQTT as the application protocol and TLS For 992 transport layer security. 994 CBOR Value: 996 Reference: [RFC-XXXX] 998 8. Security Considerations 1000 This document specifies a profile for the Authentication and 1001 Authorization for Constrained Environments (ACE) framework 1002 [I-D.ietf-ace-oauth-authz]. Therefore, the security considerations 1003 outlined in [I-D.ietf-ace-oauth-authz] apply to this work. 1005 In addition, the security considerations outlined in MQTT v5.0 - the 1006 OASIS Standard [MQTT-OASIS-Standard-v5] and MQTT v3.1.1 - the OASIS 1007 Standard [MQTT-OASIS-Standard] apply. Mainly, this document provides 1008 an authorization solution for MQTT, the responsibility of which is 1009 left to the specific implementation in the MQTT standards. In the 1010 following, we comment on a few relevant issues based on the current 1011 MQTT specifications. 1013 After the RS validates an access token and accepts a connection from 1014 a client, it caches the token to authorize a Client's publish and 1015 subscribe requests in an ongoing session. RS does not cache any 1016 invalid tokens. If a client's permissions get revoked but the access 1017 token has not expired, the RS may still grant publish/subscribe to 1018 revoked topics. If the RS caches the token introspection responses, 1019 then the RS should use a reasonable cache timeout to introspect 1020 tokens regularly. When permissions change dynamically, it is 1021 expected that AS also follows a reasonable expiration strategy for 1022 the access tokens. 1024 The RS may monitor Client behaviour to detect potential security 1025 problems, especially those affecting availability. These include 1026 repeated token transfer attempts to the public "authz-info" topic, 1027 repeated connection attempts, abnormal terminations, and Clients that 1028 connect but do not send any data. If the RS supports the public 1029 "authz-info" topic, described in Section 2.2.2, then this may be 1030 vulnerable to a DDoS attack, where many Clients use the "authz-info" 1031 public topic to transport fictitious tokens, which RS may need to 1032 store indefinitely. 1034 For MQTT v5.0, when a Client connects with a long Session Expiry 1035 Interval, the RS may need to maintain Client's MQTT session state 1036 after it disconnects for an extended period. For MQTT v3.1.1, the 1037 session state may need to be stored indefinitely, as it does not have 1038 a Session Expiry Interval feature. The RS SHOULD implement 1039 administrative policies to limit misuse of the session continuation 1040 by the Client. 1042 9. Privacy Considerations 1044 The privacy considerations outlined in [I-D.ietf-ace-oauth-authz] 1045 apply to this work. 1047 In MQTT, the RS is a central trusted party and may forward 1048 potentially sensitive information between Clients. This document 1049 does not protect the contents of the PUBLISH message from the Broker, 1050 and hence, the content of the PUBLISH message is not signed or 1051 encrypted separately for the subscribers. This functionality may be 1052 implemented using the proposal outlined in the CoAP Pub-Sub Profile 1053 [I-D.ietf-ace-pubsub-profile]. However, this solution would still 1054 not provide privacy for other properties of the message such as Topic 1055 Name. 1057 10. References 1059 10.1. Normative References 1061 [I-D.bormann-core-ace-aif] 1062 Bormann, C., "An Authorization Information Format (AIF) 1063 for ACE", draft-bormann-core-ace-aif-09 (work in 1064 progress), June 2020. 1066 [I-D.ietf-ace-oauth-authz] 1067 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1068 H. Tschofenig, "Authentication and Authorization for 1069 Constrained Environments (ACE) using the OAuth 2.0 1070 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35 1071 (work in progress), June 2020. 1073 [I-D.ietf-ace-oauth-params] 1074 Seitz, L., "Additional OAuth Parameters for Authorization 1075 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 1076 params-13 (work in progress), April 2020. 1078 [I-D.ietf-cose-x509] 1079 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1080 Header parameters for carrying and referencing X.509 1081 certificates", draft-ietf-cose-x509-06 (work in progress), 1082 March 2020. 1084 [MQTT-OASIS-Standard] 1085 Banks, A., Ed. and R. Gupta, Ed., "OASIS Standard MQTT 1086 Version 3.1.1 Plus Errata 01", 2015, . 1089 [MQTT-OASIS-Standard-v5] 1090 Banks, A., Ed., Briggs, E., Ed., Borgendale, K., Ed., and 1091 R. Gupta, Ed., "OASIS Standard MQTT Version 5.0", 2017, 1092 . 1095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", BCP 14, RFC 2119, 1097 DOI 10.17487/RFC2119, March 1997, 1098 . 1100 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1101 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1102 . 1104 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1105 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1106 March 2010, . 1108 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1109 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1110 . 1112 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1113 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1114 Transport Layer Security (TLS) and Datagram Transport 1115 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1116 June 2014, . 1118 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 1119 Possession Key Semantics for JSON Web Tokens (JWTs)", 1120 RFC 7800, DOI 10.17487/RFC7800, April 2016, 1121 . 1123 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1124 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1125 May 2017, . 1127 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1128 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1129 . 1131 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1132 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1133 . 1135 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1136 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1137 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 1138 2020, . 1140 10.2. Informative References 1142 [fremantle14] 1143 Fremantle, P., Aziz, B., Kopecky, J., and P. Scott, 1144 "Federated Identity and Access Management for the Internet 1145 of Things", research International Workshop on Secure 1146 Internet of Things, September 2014, 1147 . 1149 [I-D.ietf-ace-dtls-authorize] 1150 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 1151 L. Seitz, "Datagram Transport Layer Security (DTLS) 1152 Profile for Authentication and Authorization for 1153 Constrained Environments (ACE)", draft-ietf-ace-dtls- 1154 authorize-12 (work in progress), July 2020. 1156 [I-D.ietf-ace-pubsub-profile] 1157 Palombini, F., "Pub-Sub Profile for Authentication and 1158 Authorization for Constrained Environments (ACE)", draft- 1159 ietf-ace-pubsub-profile-01 (work in progress), July 2020. 1161 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1162 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1163 . 1165 Appendix A. Checklist for profile requirements 1167 o AS discovery: AS discovery is possible with the MQTT v5.0 1168 described in Section 2.2. 1170 o The communication protocol between the Client and RS: MQTT 1172 o The security protocol between the Client and RS: TLS 1174 o Client and RS mutual authentication: Several options are possible 1175 and described in Section 2.2.1. 1177 o Content format: For the HTTPS interactions with AS, "application/ 1178 ace+json". 1180 o PoP protocols: Either symmetric or asymmetric keys can be 1181 supported. 1183 o Unique profile identifier: mqtt_tls 1185 o Token introspection: RS uses HTTPS /introspect interface of AS. 1187 o Token request: Client or its Client AS uses HTTPS /token interface 1188 of AS. 1190 o /authz-info endpoint: It MAY be supported using the method 1191 described in Section 2.2.2, but is not protected. 1193 o Token transport: Via "authz-info" topic, or in MQTT CONNECT 1194 message for both versions of MQTT. AUTH extensions also used for 1195 authentication and re-authentication for MQTT v5.0 as described in 1196 Section 2.2 and in Section 4. 1198 Appendix B. Document Updates 1200 Version 05 to 06: 1202 o Replace the orignally proposed scope format with AIF model. 1203 Defined the AIF-MQTT, gave an example with a JSON array. Added a 1204 normative reference to the AIF draft. 1206 o Clarified client connection after submitting token via "authz- 1207 info" topic as TLS:Known(RPK/PSK)-MQTT:none. 1209 o Expanded acronyms on their first use including the ones in the 1210 title. 1212 o Added a definition for "Session". 1214 o Corrected "CONNACK" definition, which earlier said it's the first 1215 packet sent by the broker. 1217 o Added a statement that the the broker will disconnect on almost 1218 any error and may not keep session state. 1220 o Clarified that the broker does not cache invalid tokens. 1222 Version 04 to 05: 1224 o Reorganised Section 2 such that "Unauthorised Request: 1225 Authorisation Server Discovery" is presented under Section 2. 1227 o Fixed Figure 2 to remove the "empty" word. 1229 o Clarified that MQTT v5.0 Brokers may implement username/password 1230 option for transporting the ACE token only for MQTT v.3.1.1 1231 clients. This option is not recommended for MQTT v.5.0 clients. 1233 o Changed Clean Session requirement both for MQTT v.5.0 and v.3.1.1. 1234 The Broker SHOULD NOT, instead of MUST NOT, continue sessions. 1235 Clarified expected behaviour if session continuation is supported. 1236 Added to the Security Considerations the potential misuse of 1237 session continuation. 1239 o Fixed the Authentication Data to include token length for the 1240 Challenge/Response PoP. 1242 o Added that Authorisation Server Discovery is triggered if a token 1243 is invalid and not only missing. 1245 o Clarified that the Broker should not accept any other packets from 1246 Client after CONNECT and before sending CONNACK. 1248 o Added that client reauthentication is accepted only for the 1249 challenge/response PoP. 1251 o Added Ed25519 as mandatory to implement. 1253 o Fixed typos. 1255 Version 03 to 04: 1257 o Linked the terms Broker and MQTT server more at the introduction 1258 of the document. 1260 o Clarified support for MQTTv3.1.1 and removed phrases that might be 1261 considered as MQTTv5 is backwards compatible with MQTTv3.1.1 1263 o Corrected the Informative and Normative references. 1265 o For AS discovery, clarified the CONNECT message omits the 1266 Authentication Data field. Specified the User Property MUST be 1267 set to "ace_as_hint" for AS Request Creation Hints. 1269 o Added that MQTT v5 brokers MAY also implement reduced interactions 1270 described for MQTTv3.1.1. 1272 o Added to Section 3.1, in case of an authorisation failure and QoS 1273 level 0, the RS sends a DISCONNECT with reason code '0x87 (Not 1274 authorized)'. 1276 o Added a pointer to section 4.7 of MQTTv5 spec for more information 1277 on topic names and filters. 1279 o Added HS256 and RSA256 are mandatory to implement depending on the 1280 choice of symmetric or asymmetric validation. 1282 o Added MQTT to the TLS exporter label to make it application 1283 specific: 'EXPORTER-ACE-MQTT-Sign-Challenge'. 1285 o Added a format for Authentication Data so that length values 1286 prefix the token (or client nonce) when Authentication Data 1287 contains more than one piece of information. 1289 o Clarified clients still connect over TLS (server-side) for the 1290 authz-info flow. 1292 Version 02 to 03: 1294 o Added the option of Broker certificate thumbprint in the 'rs_cnf' 1295 sent to the Client. 1297 o Clarified the use of a random nonce from the TLS Exporter for PoP, 1298 added to the IANA requirements that the label should be 1299 registered. 1301 o Added a client nonce, when Challenge/Response Authentication is 1302 used between Client and Broker. 1304 o Clarified the use of the "authz-info" topic and the error response 1305 if token validation fails. 1307 o Added clarification on wildcard use in scopes for publish/ 1308 subscribe permissions 1310 o Reorganised sections so that token authorisation for publish/ 1311 subscribe messages are better placed. 1313 Version 01 to 02: 1315 o Clarified protection of Application Message payload as out of 1316 scope, and cited draft-palombini-ace-coap-pubsub-profile for a 1317 potential solution 1319 o Expanded Client connection authorization to capture different 1320 options for Client and Broker authentication over TLS and MQTT 1322 o Removed Payload (and specifically Client Identifier) from proof- 1323 of-possession in favor of using tls-exporter for a TLS-session 1324 based challenge. 1326 o Moved token transport via "authz-info" topic from the Appendix to 1327 the main text. 1329 o Clarified Will scope. 1331 o Added MQTT AUTH to terminology. 1333 o Typo fixes, and simplification of figures. 1335 Version 00 to 01: 1337 o Present the MQTTv5 as the RECOMMENDED version, and MQTT v3.1.1 for 1338 backward compatibility. 1340 o Clarified Will message. 1342 o Improved consistency in the use of terminology and upper/lower 1343 case. 1345 o Defined Broker and MQTTS. 1347 o Clarified HTTPS use for C-AS and RS-AS communication. Removed 1348 reference to actors document, and clarified the use of client 1349 authorization server. 1351 o Clarified the Connect message payload and Client Identifier. 1353 o Presented different methods for passing the token and PoP. 1355 o Added new figures to explain AUTH packets exchange, updated 1356 CONNECT message figure. 1358 Acknowledgements 1360 The authors would like to thank Ludwig Seitz for his review and his 1361 input on the authorization information endpoint, presented in the 1362 appendix. 1364 Authors' Addresses 1365 Cigdem Sengul 1366 Brunel University 1367 Dept. of Computer Science 1368 Uxbridge UB8 3PH 1369 UK 1371 Email: csengul@acm.org 1373 Anthony Kirby 1374 Oxbotica 1375 1a Milford House, Mayfield Road, Summertown 1376 Oxford OX2 7EL 1377 UK 1379 Email: anthony@anthony.org 1381 Paul Fremantle 1382 University of Portsmouth 1383 School of Computing, Buckingham House 1384 Portsmouth PO1 3HE 1385 UK 1387 Email: paul.fremantle@port.ac.uk