idnits 2.17.1 draft-ietf-ace-mqtt-tls-profile-03.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 15 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 480 has weird spacing: '...rotocol name ...' == Line 808 has weird spacing: '...rotocol name ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 20, 2019) is 1581 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 916, but not defined == Unused Reference: 'RFC7250' is defined on line 1026, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-ace-dtls-authorize-09 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-29 == Outdated reference: A later version (-16) exists of draft-ietf-ace-oauth-params-07 == Outdated reference: A later version (-09) exists of draft-ietf-cose-x509-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'MQTT-OASIS-Standard' -- Possible downref: Non-RFC (?) normative reference: ref. 'MQTT-OASIS-Standard-v5' Summary: 1 error (**), 0 flaws (~~), 10 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 Nominet 4 Intended status: Standards Track A. Kirby 5 Expires: June 22, 2020 Oxbotica 6 P. Fremantle 7 University of Portsmouth 8 December 20, 2019 10 MQTT-TLS profile of ACE 11 draft-ietf-ace-mqtt-tls-profile-03 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 MQTT-based publish-subscribe messaging system. 18 Proof-of-possession keys, bound to OAuth2.0 access tokens, are used 19 to authenticate and authorize MQTT Clients. The protocol relies on 20 TLS for confidentiality and server authentication. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 22, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 58 1.2. ACE-Related Terminology . . . . . . . . . . . . . . . . . 4 59 1.3. MQTT-Related Terminology . . . . . . . . . . . . . . . . 5 60 2. Authorizing Connection Requests . . . . . . . . . . . . . . . 7 61 2.1. Client Token Request to the Authorization Server (AS) . . 8 62 2.2. Client Connection Request to the Broker (C) . . . . . . . 9 63 2.2.1. Client-Server Authentication over TLS and MQTT . . . 9 64 2.2.2. authz-info: The Authorization Information Topic . . . 10 65 2.2.3. Transporting Access Token Inside the MQTT CONNECT . . 11 66 2.2.4. Authentication Using AUTH Property . . . . . . . . . 12 67 2.2.4.1. Proof-of-Possession Using a Challenge from the 68 TLS session . . . . . . . . . . . . . . . . . . . 13 69 2.2.4.2. Proof-of-Possession via Broker-generated 70 Challenge/Response . . . . . . . . . . . . . . . 13 71 2.2.4.3. Unauthorised Request: Authorisation Server 72 Discovery . . . . . . . . . . . . . . . . . . . . 14 73 2.2.5. Token Validation . . . . . . . . . . . . . . . . . . 14 74 2.2.6. The Broker's Response to Client Connection Request . 15 75 3. Authorizing PUBLISH and SUBSCRIBE Messages . . . . . . . . . 15 76 3.1. PUBLISH Messages from the Publisher Client to the Broker 16 77 3.2. PUBLISH Messages from the Broker to the Subscriber 78 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 3.3. Authorizing SUBSCRIBE Messages . . . . . . . . . . . . . 16 80 4. Token Expiration and Reauthentication . . . . . . . . . . . . 17 81 5. Handling Disconnections and Retained Messages . . . . . . . . 17 82 6. Reduced Protocol Interactions for MQTT v3.1.1 . . . . . . . . 18 83 6.1. Token Transport . . . . . . . . . . . . . . . . . . . . . 18 84 6.2. Handling Authorization Errors . . . . . . . . . . . . . . 20 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 90 10.2. Informative References . . . . . . . . . . . . . . . . . 24 91 Appendix A. Checklist for profile requirements . . . . . . . . . 24 92 Appendix B. Document Updates . . . . . . . . . . . . . . . . . . 25 93 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 96 1. Introduction 98 This document specifies a profile for the ACE framework 99 [I-D.ietf-ace-oauth-authz]. In this profile, Clients and a Broker 100 use MQTT to exchange Application Messages. The protocol relies on 101 TLS for communication security between entities. The MQTT protocol 102 interactions are described based on the MQTT v5.0 - the OASIS 103 Standard [MQTT-OASIS-Standard-v5]. It is expected that MQTT 104 deployments will retain backward compatibility for MQTT v3.1.1 105 clients, and therefore, this document also describes a reduced set of 106 protocol interactions for MQTT v3.1.1 - the OASIS Standard 107 [MQTT-OASIS-Standard]. However, MQTT v5.0 is the RECOMMENDED version 108 as it works more naturally with ACE-style authentication and 109 authorization. 111 MQTT is a publish-subscribe protocol and after connecting to the MQTT 112 Broker, a Client can publish and subscribe to multiple topics. The 113 MQTT Broker is responsible for distributing messages published by the 114 publishers to their subscribers. Messages are published under a 115 Topic Name, and subscribers must subscribe to the Topic Names to 116 receive the corresponding messages. The Broker uses the Topic Name 117 in a published message to determine which subscribers to relay the 118 messages. 120 In this document, topics, more specifically, Topic Names, are treated 121 as resources. The Clients are assumed to have identified the 122 publish/subscribe topics of interest out-of-band (topic discovery is 123 not a feature of the MQTT protocol). A resource owner can pre- 124 configure policies at the AS that give Clients publish or subscribe 125 permissions to different topics. 127 Clients use an access token, bound to a proof-of-possession (PoP) key 128 to authorize with the MQTT Broker their connection and publish/ 129 subscribe permissions to topics. In the context of this ACE profile, 130 the Broker acts as the Resource Server (RS). In the rest of the 131 document the terms "RS" and "Broker" are used interchangeably. This 132 document describes how to authorise the following exchanges between 133 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 This document does not protect the contents of the PUBLISH message 143 from the Broker, and hence, the content of the the PUBLISH message is 144 not signed or encrypted separately for the subscribers. This 145 functionality may be implemented using the proposal outlined in the 146 CoAP Pub-Sub Profile [I-D.palombini-ace-coap-pubsub-profile]. 148 To provide communication confidentiality and RS authentication, TLS 149 is used and TLS 1.3 is RECOMMENDED. This document makes the same 150 assumptions as the Section 4 of the ACE framework 151 [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with 152 the AS and setting up keying material. While the Client-Broker 153 exchanges are only over MQTT, the required Client-AS and RS-AS 154 interactions are described for HTTPS-based communication, using 155 'application/ace+json' content type, and unless otherwise specified, 156 using JSON encoding. The token may be a reference, or JSON Web Token 157 (JWT). For JWT tokens, this document follows RFC 7800 [RFC7800] for 158 PoP semantics for JWTs. The Client-AS and RS-AS may also be other 159 than HTTPS e.g., CoAP or MQTT. Implementations MAY also use 160 'application/ace+cbor' content type, and CBOR encoding, and CBOR Web 161 Token (CWT) and associated PoP semantics to reduce the protocol 162 memory and bandwidth requirements. For more information on Proof of 163 Possession semantics for CWTs, see Proof-of-Possession Key Semantics 164 for CBOR Web Tokens (CWTs) [I-D.ietf-ace-cwt-proof-of-possession]. 166 1.1. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174], when, and only when, they appear in all 172 capitals, as shown here. 174 1.2. ACE-Related Terminology 176 The terminology for entities in the architecture is defined in OAuth 177 2.0 RFC 6749 [RFC6749] such as "Client" (C), "Resource Server" (RS) 178 and "Authorization Server" (AS). 180 The term "Resource" is used to refer to an MQTT Topic Name, which is 181 defined in Section 1.3. Hence, the "Resource Owner" is any entity 182 that can authoritatively speak for the topic. 184 Certain security-related terms such as "authentication", 185 "authorization", "confidentiality", "(data) integrity", "message 186 authentication code", and "verify" are taken from RFC 4949 [RFC4949]. 188 1.3. MQTT-Related Terminology 190 The document describes message exchanges as MQTT protocol 191 interactions. The Clients are MQTT Clients, which connect to the 192 Broker to publish and subscribe to Application Messages, labeled with 193 their topics. For additional information, please refer to the MQTT 194 v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1 195 - the OASIS Standard [MQTT-OASIS-Standard]. 197 MQTTS 198 Secured transport profile of MQTT. MQTTS runs over TLS. 200 Broker 201 The Server in MQTT. It acts as an intermediary between the 202 Clients that publishes Application Messages, and the Clients 203 that made Subscriptions. The Broker acts as the Resource 204 Server for the Clients. 206 Application Message 207 The data carried by the MQTT protocol. The data has an 208 associated QoS level and a Topic Name. 210 QoS level 211 The level of assurance for the delivery of an Application 212 Message. The QoS level can be 0-2, where "0" indicates "At 213 most once delivery", "1" "At least once delivery", and "2" 214 "Exactly once delivery". 216 Topic Name 217 The label attached to an Application Message, which is 218 matched to a Subscription. 220 Subscription 221 A subscription comprises a Topic Filter and a maximum Quality 222 of Service (QoS). 224 Topic Filter 225 An expression that indicates interest in one or more Topic 226 Names. Topic Filters may include wildcards. 228 MQTT sends various control messages across a network connection. The 229 following is not an exhaustive list and the control packets that are 230 not relevant for authorization are not explained. These include, for 231 instance, the PUBREL and PUBCOMP packets used in the 4-step handshake 232 required for the QoS level 2. 234 CONNECT 235 Client request to connect to the Broker. After a network 236 connection is established, this is the first packet sent by a 237 Client. 239 CONNACK 240 The Broker connection acknowledgment. The first packet sent 241 from the Broker to a Client is a CONNACK packet. CONNACK 242 packets contain return codes indicating either a success or 243 an error state to a Client. 245 AUTH 246 Authentication Exchange. An AUTH packet is sent from the 247 Client to the Broker or to the Broker to the Client as part 248 of an extended authentication exchange. AUTH Properties 249 include Authentication Method and Authentication Data. The 250 Authentication Method is set in the CONNECT packet, and 251 consequent AUTH packets follow the same Authentication 252 Method. The contents of the Authentication Data are defined 253 by the Authentication Method. 255 PUBLISH 256 Publish request sent from a publishing Client to the Broker, 257 or from the Broker to a subscribing Client. 259 PUBACK 260 Response to PUBLISH request with QoS level 1. PUBACK can be 261 sent from the Broker to a Client or a Client to the Broker. 263 PUBREC 264 Response to PUBLISH request with QoS level 2. PUBREC can be 265 sent from the Broker to a Client or a Client to the Broker. 267 SUBSCRIBE 268 The Client subscribe request. 270 SUBACK 271 Subscribe acknowledgment. 273 PINGREQ 274 A ping request sent from a Client to the Broker. It signals 275 to the Broker that the Client is alive, and is used to 276 confirm that the Broker is also alive. The "Keep Alive" 277 period is set in the CONNECT message. 279 PINGRESP 280 Response sent by the Broker to the Client in response to 281 PINGREQ. It indicates the Broker is alive. 283 Will 284 If the network connection is not closed normally, the Server 285 sends a last Will message for the Client, if the Client 286 provided one in its CONNECT message. If the Will Flag is 287 set, then the payload of the CONNECT message includes 288 information about the Will. The information consists of the 289 Will Properties, Will Topic, and Will Payload fields. 291 2. Authorizing Connection Requests 293 This section specifies how Client connections are authorized by the 294 MQTT Broker.Figure 1 shows the basic protocol flow during connection 295 set-up.The token request and response use the /token endpoint at the 296 AS, specified in the Section 5.6 of the ACE framework 297 [I-D.ietf-ace-oauth-authz]. Steps (D) and (E) are optional, and use 298 the introspection endpoint, specified in the Section 5.7 of the ACE 299 framework. The Client and Broker use HTTPS to communicate to AS via 300 these endpoints. The Client and Broker use only MQTT to communicate 301 between them. 303 If the Client is resource-constrained, a Client Authorisation Server 304 may carry out the token request on behalf of the Client, and later, 305 onboard the Client with the token. Also, the C-AS and Broker-AS 306 interfaces may be implemented using protocols other than HTTPS, e.g., 307 CoAP or MQTT. The interactions between a Client and its Client 308 Authorization Server for token onboarding, and the MQTTS support for 309 token requests are out of scope of this document. 311 +---------------------+ 312 | Client | 313 | | 314 +---(A) Token request--| Client - | 315 | | Authorization | 316 | +-(B) Access token-> Server Interface | 317 | | | (HTTPS) | 318 | | |_____________________| 319 | | | | 320 +--v-------------+ | Pub/Sub Interface | 321 | Authorization | | (MQTTS) | 322 | Server | +-----------^---------+ 323 |________________| | | 324 | ^ (C)Connection (F)Connection 325 | | request + response 326 | | access token | 327 | | | | 328 | | +---v--------------+ 329 | | | Broker (MQTTS) | 330 | | |__________________| 331 | +(D)Introspection-| | 332 | request (optional) | RS-AS interface | 333 | | (HTTPS) | 334 +-(E)Introspection---->|__________________| 335 response (optional) 337 Figure 1: Connection set-up 339 2.1. Client Token Request to the Authorization Server (AS) 341 The first step in the protocol flow (Figure 1 (A)) is the token 342 acquisition by the Client from the AS. When requesting an access 343 token from the AS, the Client follows the token request as described 344 in Section 5.6.1 of the ACE framework [I-D.ietf-ace-oauth-authz], 345 howevever, it MUST set the profile parameter to 'mqtt_tls'. The 346 media format is 'application/ace+json'. The AS uses JSON in the 347 payload of its responses to both to the Client and the RS. 349 If the AS successfully verifies the access token request and 350 authorizes the Client for the indicated audience (i.e., RS) and 351 scopes (i.e., publish/subscribe permissions over topics), the AS 352 issues an access token (Figure 1 (B)). The response includes the 353 parameters described in Section 5.6.2 of the ACE framework 354 [I-D.ietf-ace-oauth-authz]. The included token is assumed to be 355 Proof-of-Possession (PoP) token by default. This document follows 356 RFC 7800 [RFC7800] for PoP semantics for JWTs. The PoP token 357 includes a 'cnf' parameter with a symmetric or asymmetric PoP key. 358 The 'cnf' parameter in the web tokens are to be consumed by the RS 359 and not the Client. The PoP token may include a 'rs_cnf' parameter 360 containing the information about the public key used by the RS to 361 authenticate as described in [I-D.ietf-ace-oauth-params]. 363 The AS returns error responses for JSON-based interactions following 364 the Section 5.2 of RFC 6749 [RFC6749]. When CBOR is used, the 365 interactions must implement the Section 5.6.3 of ACE framework 366 [I-D.ietf-ace-oauth-authz]. 368 2.2. Client Connection Request to the Broker (C) 370 2.2.1. Client-Server Authentication over TLS and MQTT 372 The Client and the Broker MUST perform mutual authentication. The 373 Client MAY authenticate to the Broker over MQTT or TLS. For MQTT, 374 the options are "None" and "ace". For TLS, the options are "Anon" 375 for anonynous client, and "Known(RPK/PSK)" for Raw Public Keys (RPK) 376 and Pre-Shared Keys (PSK), respectively. Combined, the Client 377 authentication takes the following options: 379 o "TLS:Anon-MQTT:None": This option is used only for the topics that 380 do not require authorization, including the "authz-info" topic. 381 Publishing to the "authz-info" topic is described in 382 Section 2.2.2. 384 o "TLS:Anon-MQTT:ace": The token is transported inside the CONNECT 385 message, and MUST be validated using one of the methods described 386 in Section 2.2.2. This option also supports a tokenless 387 connection request for AS discovery. 389 o "TLS:Known(RPK/PSK)-MQTT:none": For the RPK, the token MUST have 390 been published to the "authz-info" topic. For the PSK, the token 391 MAY be, alternatively, provided in the "psk_identity". The TLS 392 session set-up is as described in DTLS profile for ACE 393 [I-D.ietf-ace-dtls-authorize]. 395 o "TLS:Known(RPK/PSK)-MQTT:ace": This option SHOULD NOT be chosen. 396 In any case, the token transported in the CONNECT overwrites any 397 permissions passed during the TLS authentication. 399 It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace. 401 The Broker MUST be authenticated during the TLS handshake. If the 402 Client authentication uses TLS:Known(RPK/PSK), then the Broker is 403 authenticated using the respective method. Otherwise, to 404 authenticate the Broker, the client MUST validate a public key from a 405 X.509 certificate or an RPK from the Broker against the 'rs_cnf' 406 parameter in the token response. The AS MAY include the thumbprint 407 of the RS's X.509 certificate in the 'rs_cnf' (thumbrint as defined 408 in [I-D.ietf-cose-x509]), then the client MUST validate the RS 409 certificate against this thumbprint. 411 2.2.2. authz-info: The Authorization Information Topic 413 In the cases when the Client MUST transport the token to the Broker 414 before the TLS handshake, the Client connects to the Broker and 415 publishes its token to the "authz-info" topic. The "authz-info" 416 topic MUST be publish-only (i.e., the Clients are not allowed to 417 subscribe to it). "authz-info" is not protected, and hence, the 418 Client authenticates with the RS using the "TLS:Anon-MQTT:None" 419 option. After publishing the token, the Client disconnects from the 420 Broker and is expected to try reconnecting over TLS. 422 The Broker stores and indexes all tokens received to this topic in 423 its key store similar to DTLS profile for ACE 424 [I-D.ietf-ace-dtls-authorize]. This profile follows the 425 recommendation of Section 5.8.1 of ACE framework 426 [I-D.ietf-ace-oauth-authz], and expects that RS stores only one token 427 per proof-of-possession key, and any other token linked to the same 428 key overwrites existing token at the RS. 430 The Broker MUST verify the validity of the token (i.e., through local 431 validation or introspection) as described in Section 2.2.5. To 432 validate the token, RS MAY need to introspect the token with the AS 433 e.g., if the token is a reference. If the token is not valid, the 434 Broker MUST discard the token. Depending on the QoS level of the 435 PUBLISH message, the Broker may return the error response as a PUBACK 436 or a DISCONNECT message. 438 If the QoS level is equal to 0, and token is invalid or the claims 439 cannot be obtained in the case of an introspected token, the Broker 440 MUST send a DISCONNECT message with the reason code '0x87 (Not 441 authorized)'. If the token does not parse to a token, the RS MUST 442 send a DISCONNECT with the reason code '0x99 (Payload format 443 invalid)'. 445 For the QoS level of the PUBLISH message is greater than or equal to 446 1, the Broker MAY return 'Not authorized' in PUBACK. If the token 447 does not parse to a token, the PUBACK reason code is '0x99 (Payload 448 format invalid)'. 450 It must be noted that when the AS sends the 'Not authorized' 451 response, this corresponds to the token being invalid, and not that 452 the actual PUBLISH message was not authorized. Given that the 453 "authz-info" is a public topic, this response is not expected to 454 cause a confusion. 456 2.2.3. Transporting Access Token Inside the MQTT CONNECT 458 This section describes how the Client transports the token to the 459 Broker (RS) inside the CONNECT message. If this method is used, the 460 Client TLS connection is expected to be anonymous, and the Broker is 461 authenticated during the TLS connection set-up. The approach 462 described in this section is similar to an earlier proposal by 463 Fremantle et al. [fremantle14]. 465 Figure 2 shows the structure of the MQTT CONNECT message used in MQTT 466 v5.0. A CONNECT message is composed of a fixed header, a variable 467 header and a payload. The fixed header contains the Control Packet 468 Type (CPT), Reserved, and Remaining Length fields. The Variable 469 Header contains the Protocol Name, Protocol Level, Connect Flags, 470 Keep Alive, and Properties fields. The Connect Flags in the variable 471 header specify the properties of the MQTT session. It also indicates 472 the presence or absence of some fields in the Payload. The payload 473 contains one or more encoded fields, namely a unique Client 474 identifier for the Client, a Will Topic, Will Payload, User Name and 475 Password. All but the Client identifier can be omitted depending on 476 flags in the Variable Header. 478 0 8 16 24 32 479 +------------------------------------------------------+ 480 |CPT=1 | Rsvd.|Remaining len.| Protocol name len. = 4 | 481 +------------------------------------------------------+ 482 | 'M' 'Q' 'T' 'T' | 483 +------------------------------------------------------+ 484 | Proto.level=5|Connect flags| Keep alive | 485 +------------------------------------------------------+ 486 | Property length | 487 | Auth. Method (0x15) | 'ace' | 488 | Auth. Data (0x16) | empty or token or | 489 | token + PoP data | 490 +------------------------------------------------------+ 491 | Payload | 492 +------------------------------------------------------+ 494 Figure 2: MQTT v5 CONNECT control message with ACE authentication. 495 (CPT=Control Packet Type) 497 The CONNECT message flags are Username, Password, Will retain, Will 498 QoS, Will Flag, Clean Start, and Reserved. Figure 6 shows how the 499 MQTT connect flags MUST be set to use AUTH packets for authentication 500 and authorisation. To use AUTH, the username and password flags MUST 501 be set to 0. The RS MAY support token transport using username and 502 password and the CONNECT message for that option is described in 503 Section 6 for MQTT v3.1.1, which is the only option available to MQTT 504 v3.1.1. 506 +-----------------------------------------------------------+ 507 |User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| 508 | Flag |Flag | | | |Start| | 509 +-----------------------------------------------------------+ 510 | 0 | 0 | X | X X | X | X | 0 | 511 +-----------------------------------------------------------+ 513 Figure 3: CONNECT flags for AUTH 515 The Will Flag indicates that a Will message needs to be sent if 516 network connection is not closed normally. The situations in which 517 the Will message is published include disconnections due to I/O or 518 network failures, and the server closing the network connection due 519 to a protocol error. The Client may set the Will Flag as desired 520 (marked as 'X' in Figure 3). If the Will Flag is set to 1 and the 521 Broker accepts the connection request, the Broker must store the Will 522 message, and publish it when the network connection is closed 523 according to Will QoS and Will retain parameters, and MQTT Will 524 management rules. To avoid publishing Will Messages in the case of 525 temporary network disconnections, the Client may specify a Will Delay 526 Interval in the Will Properties. Section 5 explains how the Broker 527 deals with the retained messages in further detail. 529 In MQTT v5, to achieve a clean session (i.e., the session does not 530 continue an existing session), the Client sets the Clean Start Flag 531 to 1 and, the Session Expiry Interval to 0 in the CONNECT message. 532 However, in this profile, the Broker MUST always start with a clean 533 session regardless of how these parameters are set. The Broker MUST 534 set the Session Present flag to 0 in the CONNACK packet to signal the 535 Client that the Broker started a clean session. 537 2.2.4. Authentication Using AUTH Property 539 To use AUTH, the Client MUST set the Authentication Method as a 540 property of a CONNECT packet by using the property identifier 21 541 (0x15). This is followed by a UTF-8 Encoded String containing the 542 name of the Authentication Method, which MUST be set to 'ace'. If 543 the RS does not support this profile, it sends a CONNACK with a 544 Reason Code of '0x8C (Bad authentication method)'. 546 The Authentication Method is followed by the Authentication Data, 547 which has a property identifier 22 (0x16) and is binary data. Based 548 on the Authentication Data, this profile allows: 550 o Proof-of-Possession using a challenge from the TLS session 551 o Proof-of-Possession via Broker generated challenge/response 553 o Unauthorised request and Authorisation Server discovery 555 2.2.4.1. Proof-of-Possession Using a Challenge from the TLS session 557 For this option, the Authentication Data MUST contain the token and 558 the keyed message digest (MAC) or the Client signature. The secret 559 that is used for the proof-of-possession calculation, i.e., to 560 calculate the keyed message digest (MAC) or the Client signature, is 561 obtained using a TLS exporter ([RFC5705] for TLS 1.2 and for TLS 1.3, 562 Section 7.5 of [RFC8446]). The secret is exported from TLS using the 563 exporter label 'EXPORTER-ACE-Sign-Challenge', an empty context, and 564 length of 32 bytes. The token is also validated as described in 565 Section 2.2.5 and the server responds with a CONNACK with the 566 appropriate response code. 568 2.2.4.2. Proof-of-Possession via Broker-generated Challenge/Response 570 For this option, the RS follows a Broker-generated challenge/response 571 protocol. The success case is illustrated in Figure 4. If the 572 Authentication Data only includes the token, the RS MUST respond with 573 an AUTH packet, with the Authenticate Reason Code set to '0x18 574 (Continue Authentication)'. This packet includes the Authentication 575 Method, which MUST be set to 'ace' and Authentication Data. The 576 Authentication Data MUST NOT be empty and contains an 8-byte nonce as 577 a challenge for the Client. The Client responds to this with an AUTH 578 packet with a reason code '0x18 (Continue Authentication)'. 579 Similarly, the Client packet sets the Authentication Method to 'ace'. 580 The Authentication Data in the Client's response contains a client- 581 generated 8-byte nonce, and the signature or MAC computed over the RS 582 nonce concatenated with the client nonce. Next, the token is 583 validated as described in Section 2.2.5. 585 Resource 586 Client Server 587 | | 588 |<===========>| TLS connection set-up 589 | | 590 | | 591 +------------>| CONNECT with Authentication Data 592 | | contains only token 593 | | 594 <-------------+ AUTH '0x18 (Continue Authentication)' 595 | | 8-byte nonce as RS challenge 596 | | 597 |------------>| AUTH '0x18 (Continue Authentication)' 598 | | 8-byte client nonce + signature/MAC 599 | | 600 | |-----+ Token validation (may involve introspection) 601 | | | 602 | |<----+ 603 | | 604 |<------------+ CONNACK '0x00 (Success)' 606 Figure 4: PoP Challenge/Response Protocol Flow - Success 608 2.2.4.3. Unauthorised Request: Authorisation Server Discovery 610 Finally, this document allows the CONNECT message to have the 611 Authentication Method set to 'ace' followed by an empty 612 Authentication Data field. This is the AS discovery option and the 613 RS responds with the CONNACK reason code '0x87 (Not Authorized)' and 614 includes a User Property (identified by 38 (0x26)) for the AS 615 creation hints as defined in the Section 5.1.2 of the ACE framework 616 [I-D.ietf-ace-oauth-authz]. 618 2.2.5. Token Validation 620 The RS MUST verify the validity of the token either locally (e.g., in 621 the case of a self-contained token) or the RS MAY send an 622 introspection request to the AS. RS MUST verify the claims according 623 to the rules set in the Section 5.8.1.1 of the ACE framework 624 [I-D.ietf-ace-oauth-authz]. 626 To authenticate the Client, the RS validates the signature or the 627 MAC, depending on how the PoP protocol is implemented. Validation of 628 the signature or MAC MUST fail if the signature algorithm is set to 629 "none", when the key used for the signature algorithm cannot be 630 determined, or the computed and received signature/MAC do not match. 632 2.2.6. The Broker's Response to Client Connection Request 634 Based on the validation result (obtained either via local inspection 635 or using the /introspection interface of the AS), the Broker MUST 636 send a CONNACK message to the Client. The reason code of the CONNACK 637 is '0x00 (Success)' if the token validation is successful. The 638 Broker MUST also set Session Present to 0 in the CONNACK packet to 639 signal a clean session to the Client. In case of an invalid PoP 640 token, the CONNACK reason code is '0x87 (Not Authorized)'. 642 If the Broker accepts the connection, it MUST store the token until 643 the end of the connection. On Client or Broker disconnection, the 644 Client is expected to provide a token again inside the next CONNECT 645 message. 647 If the token is not self-contained and the Broker uses token 648 introspection, it MAY cache the validation result to authorize the 649 subsequent PUBLISH and SUBSCRIBE messages. PUBLISH and SUBSCRIBE 650 messages, which are sent after a connection set-up, do not contain 651 access tokens. If the introspection result is not cached, then the 652 RS needs to introspect the saved token for each request. The Broker 653 SHOULD also use a cache time out to introspect tokens regularly. 655 3. Authorizing PUBLISH and SUBSCRIBE Messages 657 To authorize a Client's PUBLISH and SUBSCRIBE messages, the Broker 658 needs to use the scope field in the token (or in the introspection 659 result). The scope field contains the publish and subscribe 660 permissions for the Client. Scope strings SHOULD be encoded as a 661 permission, followed by an underscore, followed by a topic filter. 662 Two permissions apply to topic filters: 'publish' and 'subscribe'. 663 Topic filters are implemented as described in MQTT specification and 664 includes special wildcard characters. The multi-level wildcard, '#', 665 matches any number of levels within a topic, and the single-level 666 wildcard, '+', matches one topic level. 668 An example scope field may contain multiple such strings, space 669 delimited, e.g., 'publish_topic1 subscribe_topic2/#' 670 publish_+/topic3. This access token gives 'publish' permission to 671 the 'topic1', 'subscribe' permission to all the subtopics of 672 'topic2', and 'publish' permission to all topic3, skipping one level. 673 If the Will Flag is set,then the Broker MUST check that the token 674 allows the publication of the Will message (i.e., the scope is 675 "publish_" followed by the Will Topic). 677 3.1. PUBLISH Messages from the Publisher Client to the Broker 679 On receiving the PUBLISH message, the Broker MUST use the type of 680 message (i.e., PUBLISH) and the Topic name in the message header to 681 match against the scope string in the cached token or its 682 introspection result. Following the example above, a client sending 683 a PUBLISH message to 'a/topic3' would be allowed to publish, as the 684 scope includes the string 'publish_+/topic3'. 686 If the Client is allowed to publish to the topic, the RS must publish 687 the message to all valid subscribers of the topic. In the case of an 688 authorization failure, an error MAY be returned to the Client. For 689 this the QoS level of the PUBLISH message MUST be set to greater than 690 or equal to 1. This guarantees that RS responds with either a PUBACK 691 or PUBREC packet with reason code '0x87 (Not authorized)'. 693 On receiving a PUBACK with '0x87 (Not authorized)', the Client MAY 694 reauthenticate as described in Section 4, and pass a new token 695 following the same PoP methods as described in Figure 2. 697 3.2. PUBLISH Messages from the Broker to the Subscriber Clients 699 To forward PUBLISH messages to the subscribing Clients, the Broker 700 identifies all the subscribers that have valid matching topic 701 subscriptions (i.e., the tokens are valid, and token scopes allow a 702 subscription to the particular topic). The Broker sends a PUBLISH 703 message with the Topic name to all the valid subscribers. 705 RS MUST stop forwarding messages to the unauthorized subscribers. 706 There is no way to inform the Clients with invalid tokens that an 707 authorization error has occurred other than sending a DISCONNECT 708 message. The RS SHOULD send a DISCONNECT message with the reason 709 code '0x87 (Not authorized)'. Note that the server-side DISCONNECT 710 is a new feature of MQTT v5.0 (in MQTT v3.1.1, the server needs to 711 drop the connection). 713 3.3. Authorizing SUBSCRIBE Messages 715 In MQTT, a SUBSCRIBE message is sent from a Client to the Broker to 716 create one or more subscriptions to one or more topics. The 717 SUBSCRIBE message may contain multiple Topic Filters. The Topic 718 Filters may include wildcard characters. 720 On receiving the SUBSCRIBE message, the Broker MUST use the type of 721 message (i.e., SUBSCRIBE) and the Topic Filter in the message header 722 to match against a scope string of the stored token or introspection 723 result. 725 As a response to the SUBSCRIBE message, the Broker issues a SUBACK 726 message. For each Topic Filter, the SUBACK packet includes a return 727 code matching the QoS level for the corresponding Topic Filter. In 728 the case of failure, the return code is 0x87, indicating that the 729 Client is 'Not authorized'. A reason code is returned for each Topic 730 Filter. Therefore, the Client may receive success codes for a subset 731 of its Topic Filters while being unauthorized for the rest. 733 4. Token Expiration and Reauthentication 735 The Broker MUST check for token expiration whenever a CONNECT, 736 PUBLISH or SUBSCRIBE message is received or sent. The Broker SHOULD 737 check for token expiration on receiving a PINGREQUEST message. The 738 Broker MAY also check for token expiration periodically e.g., every 739 hour. This may allow for early detection of a token expiry. 741 The token expiration is checked by checking the 'exp' claim of a JWT 742 or introspection response, or via performing an introspection request 743 with the AS as described in Section 5.7 of the ACE framework 744 [I-D.ietf-ace-oauth-authz]. Token expirations may trigger the RS to 745 send PUBACK, SUBACK and DISCONNECT messages with return code set to 746 'Not authorised'. After sending a DISCONNECT message, the network 747 connection is closed, and no more messages can be sent. However, as 748 a response to the PUBACK and SUBACK, the Client MAY re-authenticate 749 by sending an AUTH packet with a Reason Code of '0x19 (Re- 750 authentication)'. 752 To re-authenticate, the Client sends an AUTH packet with reason code 753 '0x19 (Re-authentication)'. The Client MUST set the Authentication 754 Method as 'ace' and transport the new token in the Authentication 755 Data. The Client and the RS go through the same steps for proof of 756 possession validation as described in Section 2.2. The Client SHOULD 757 use the same method used for the first connection request. If the 758 re-authentication fails, the server MUST send a DISCONNECT with the 759 reason code '0x87 (Not Authorized)'. The Clients can also 760 proactively update their tokens i.e., before they receive a message 761 with 'Not authorized' return code. 763 5. Handling Disconnections and Retained Messages 765 In the case of a Client DISCONNECT, the Broker deletes all the 766 session state but MUST keep the retained messages. By setting a 767 RETAIN flag in a PUBLISH message, the publisher indicates to the 768 Broker that it should store the most recent message for the 769 associated topic. Hence, the new subscribers can receive the last 770 sent message from the publisher of that particular topic without 771 waiting for the next PUBLISH message. The Broker MUST continue 772 publishing the retained messages as long as the associated tokens are 773 valid. 775 In case of disconnections due to network errors or server 776 disconnection due to a protocol error (which includes authorization 777 errors), the Will message must be sent if the Client supplied a Will 778 in the CONNECT message. The Client's token scopes MUST include the 779 Will Topic. The Will message MUST be published to the Will Topic 780 regardless of whether the corresponding token has expired. In the 781 case of a server-side DISCONNECT, the server returns the '0x87 Not 782 Authorized' return code to the Client. 784 6. Reduced Protocol Interactions for MQTT v3.1.1 786 This section describes a reduced set of protocol interactions for the 787 MQTT v3.1.1 Client. 789 6.1. Token Transport 791 As in MQTT v5, The Token MAY either be transported before the TLS 792 session publishing to the "authz-info" topic, or inside the CONNECT 793 message. 795 In MQTT v3.1.1, after the Client published to the "authz-info" topic, 796 it is not possible for the Broker to communicate the result of the 797 token validation as PUBACK reason codes or server-side DISCONNECT 798 messages are not supported. In any case, an invalid token would fail 799 the subsequent TLS handshake, which can prompt the Client to obtain a 800 valid token. 802 To transport the token to the Broker inside the CONNECT message, the 803 Client uses the username and password fields of the CONNECT message. 804 Figure 5 shows the structure of the MQTT CONNECT message. 806 0 8 16 24 32 807 +------------------------------------------------------+ 808 |CPT=1 | Rsvd.|Remaining len.| Protocol name len. = 4 | 809 +------------------------------------------------------+ 810 | 'M' 'Q' 'T' 'T' | 811 +------------------------------------------------------+ 812 | Proto.level=4|Connect flags| Keep alive | 813 +------------------------------------------------------+ 814 | Payload | 815 | Client Identifier | 816 | Username as access token (UTF-8) | 817 | Password length (2 Bytes) | 818 | Password data as signature/MAC (binary) | 819 +------------------------------------------------------+ 821 Figure 5: MQTT CONNECT control message. (CPT=Control Packet Type, 822 Rsvd=Reserved, len.=length, Proto.=Protocol) 824 Figure 6 shows how the MQTT connect flags MUST be set to initiate a 825 connection with the Broker. 827 +-----------------------------------------------------------+ 828 |User name|Pass.|Will retain|Will QoS|Will Flag|Clean| Rsvd.| 829 | flag |flag | | | | | | 830 +-----------------------------------------------------------+ 831 | 1 | 1 | X | X X | X | X | 0 | 832 +-----------------------------------------------------------+ 834 Figure 6: MQTT CONNECT flags. (Rsvd=Reserved) 836 The Clean Session Flag is ignored, and the Broker always sets up a 837 clean session. On connection success, the Broker MUST set the 838 Session Present flag to 0 in the CONNACK packet. 840 The Client may set the Will Flag as desired (marked as 'X' in 841 Figure 6). Username and Password flags MUST be set to 1 to ensure 842 that the Payload of the CONNECT message includes both Username and 843 Password fields. 845 The CONNECT in MQTT v3.1.1 does not have a field to indicate the 846 authentication method. To signal that the Username field contains an 847 ACE token, this field MUST be prefixed with 'ace' keyword, which is 848 followed by the access token. The Password field MUST be set to the 849 keyed message digest (MAC) or signature associated with the access 850 token for proof-of-possession. The Client MUST apply the PoP key on 851 the challenge derived from the TLS session as described in 852 Section 2.2.4.1. 854 In MQTT v3.1.1, the MQTT Username as a UTF-8 encoded string (i.e., is 855 prefixed by a 2-byte length field followed by UTF-8 encoded character 856 data) and may be up to 65535 bytes. Therefore, an access token that 857 is not a valid UTF-8 MUST be Base64 [RFC4648] encoded. (The MQTT 858 Password allows binary data up to 65535 bytes.) 860 6.2. Handling Authorization Errors 862 Handling errors are more primitive in MQTT v3.1.1 due to not having 863 appropriate error fields, error codes, and server-side DISCONNECTS. 864 In the following, we list how errors are handled without such 865 protocol support. 867 o CONNECT without a token: It is not possible to support AS 868 discovery via sending a tokenless CONNECT message to the Broker. 869 This is because a CONNACK packet in MQTT v3.1.1 does not include a 870 means to provide additional information to the Client. Therefore, 871 AS discovery needs to take place out-of-band. CONNECT attempt 872 MUST fail. 874 o Client-RS PUBLISH authorization failure: In the case of a failure, 875 it is not possible to return an error in MQTT v3.1.1. 876 Acknowledgement messages only indicate success. In the case of an 877 authorization error, the Broker SHOULD disconnect the Client. 878 Otherwise, it MUST ignore the PUBLISH message. Also, as 879 DISCONNECT messages are only sent from a Client to the Broker, the 880 server disconnection needs to take place below the application 881 layer. 883 o SUBSCRIBE authorization failure: In the SUBACK packet, the return 884 code must be 0x80 indicating 'Failure' for the unauthorized 885 topic(s). Note that, in both MQTT versions, a reason code is 886 returned for each Topic Filter. 888 o RS-Client PUBLISH authorization failure: When RS is forwarding 889 PUBLISH messages to the subscribed Clients, it may discover that 890 some of the subscribers are no more authorized due to expired 891 tokens. These token expirations SHOULD lead to disconnecting the 892 Client rather than silently dropping messages. 894 7. IANA Considerations 896 This document registers 'EXPORTER-ACE-Sign-Challenge from 897 Section 2.2.4.1 in the TLS Exporter Label Registry TLS-REGISTRIES 898 [RFC8447]. 900 In addition, the following registrations are done for the ACE OAuth 901 Profile Registry following the procedure specified in 902 [I-D.ietf-ace-oauth-authz]. 904 Note to the RFC editor: Please replace all occurrences of "[RFC- 905 XXXX]" with the RFC number of this specification and delete this 906 paragraph. 908 Name: mqtt_tls 910 Description: Profile for delegating Client authentication and 911 authorization using MQTT as the application protocol and TLS For 912 transport layer security. 914 CBOR Value: 916 Reference: [RFC-XXXX] 918 8. Security Considerations 920 This document specifies a profile for the Authentication and 921 Authorization for Constrained Environments (ACE) framework 922 [I-D.ietf-ace-oauth-authz]. Therefore, the security considerations 923 outlined in [I-D.ietf-ace-oauth-authz] apply to this work. 925 In addition, the security considerations outlined in MQTT v5.0 - the 926 OASIS Standard [MQTT-OASIS-Standard-v5] and MQTT v3.1.1 - the OASIS 927 Standard [MQTT-OASIS-Standard] apply. Mainly, this document provides 928 an authorization solution for MQTT, the responsibility of which is 929 left to the specific implementation in the MQTT standards. In the 930 following, we comment on a few relevant issues based on the current 931 MQTT specifications. 933 To authorize a Client's publish and subscribe requests in an ongoing 934 session, the RS caches the access token after accepting the 935 connection from the Client. However, if some permissions are revoked 936 in the meantime, the RS may still grant publish/subscribe to revoked 937 topics. If the RS caches the token introspection responses, then the 938 RS should use a reasonable cache timeout to introspect tokens 939 regularly. When permissions change dynamically, it is expected that 940 AS also follows a reasonable expiration strategy for the access 941 tokens. 943 The RS may monitor Client behaviour to detect potential security 944 problems, especially those affecting availability. These include 945 repeated token transfer attempts to the public "authz-info" topic, 946 repeated connection attempts, abnormal terminations, and Clients that 947 connect but do not send any data. If the RS supports the public 948 "authz-info" topic, described in Section 2.2.2, then this may be 949 vulnerable to a DDoS attack, where many Clients use the "authz-info" 950 public topic to transport fictitious tokens, which RS may need to 951 store indefinitely. 953 9. Privacy Considerations 955 The privacy considerations outlined in [I-D.ietf-ace-oauth-authz] 956 apply to this work. 958 In MQTT, the RS is a central trusted party and may forward 959 potentially sensitive information between Clients. This document 960 does not protect the contents of the PUBLISH message from the Broker, 961 and hence, the content of the the PUBLISH message is not signed or 962 encrypted separately for the subscribers. This functionality may be 963 implemented using the proposal outlined in the CoAP Pub-Sub Profile 964 [I-D.palombini-ace-coap-pubsub-profile]. However, this solution 965 would still not provide privacy for other properties of the message 966 such as Topic Name. 968 10. References 970 10.1. Normative References 972 [I-D.ietf-ace-dtls-authorize] 973 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 974 L. Seitz, "Datagram Transport Layer Security (DTLS) 975 Profile for Authentication and Authorization for 976 Constrained Environments (ACE)", draft-ietf-ace-dtls- 977 authorize-09 (work in progress), December 2019. 979 [I-D.ietf-ace-oauth-authz] 980 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 981 H. Tschofenig, "Authentication and Authorization for 982 Constrained Environments (ACE) using the OAuth 2.0 983 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-29 984 (work in progress), December 2019. 986 [I-D.ietf-ace-oauth-params] 987 Seitz, L., "Additional OAuth Parameters for Authorization 988 in Constrained Environments (ACE)", draft-ietf-ace-oauth- 989 params-07 (work in progress), December 2019. 991 [I-D.ietf-cose-x509] 992 Schaad, J., "CBOR Object Signing and Encryption (COSE): 993 Headers for carrying and referencing X.509 certificates", 994 draft-ietf-cose-x509-05 (work in progress), November 2019. 996 [I-D.palombini-ace-coap-pubsub-profile] 997 Palombini, F., "CoAP Pub-Sub Profile for Authentication 998 and Authorization for Constrained Environments (ACE)", 999 draft-palombini-ace-coap-pubsub-profile-06 (work in 1000 progress), November 2019. 1002 [MQTT-OASIS-Standard] 1003 Banks, A., Ed. and R. Gupta, Ed., "OASIS Standard MQTT 1004 Version 3.1.1 Plus Errata 01", 2015, . 1007 [MQTT-OASIS-Standard-v5] 1008 Banks, A., Ed., Briggs, E., Ed., Borgendale, K., Ed., and 1009 R. Gupta, Ed., "OASIS Standard MQTT Version 5.0", 2017, 1010 . 1013 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1014 Requirement Levels", BCP 14, RFC 2119, 1015 DOI 10.17487/RFC2119, March 1997, 1016 . 1018 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1019 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1020 . 1022 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1023 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1024 March 2010, . 1026 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1027 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1028 Transport Layer Security (TLS) and Datagram Transport 1029 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1030 June 2014, . 1032 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1033 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1034 May 2017, . 1036 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1037 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1038 . 1040 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1041 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1042 . 1044 10.2. Informative References 1046 [fremantle14] 1047 Fremantle, P., Aziz, B., Kopecky, J., and P. Scott, 1048 "Federated Identity and Access Management for the Internet 1049 of Things", research International Workshop on Secure 1050 Internet of Things, September 2014, 1051 . 1053 [I-D.ietf-ace-cwt-proof-of-possession] 1054 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 1055 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 1056 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 1057 possession-11 (work in progress), October 2019. 1059 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1060 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1061 . 1063 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1064 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1065 . 1067 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 1068 Possession Key Semantics for JSON Web Tokens (JWTs)", 1069 RFC 7800, DOI 10.17487/RFC7800, April 2016, 1070 . 1072 Appendix A. Checklist for profile requirements 1074 o AS discovery: AS discovery is possible with the MQTT v5.0 1075 described in Section 2.2. 1077 o The communication protocol between the Client and RS: MQTT 1079 o The security protocol between the Client and RS: TLS 1081 o Client and RS mutual authentication: Several options are possible 1082 and descibed in Section 2.2.1. 1084 o Content format: For the HTTPS interactions with AS, "application/ 1085 ace+json". 1087 o PoP protocols: Either symmetric or asymmetric keys can be 1088 supported. 1090 o Unique profile identifier: mqtt_tls 1091 o Token introspection: RS uses HTTPS /introspect interface of AS. 1093 o Token request: Client or its Client AS uses HTTPS /token interface 1094 of AS. 1096 o /authz-info endpoint: It MAY be supported using the method 1097 described in Section 2.2.2, but is not protected. 1099 o Token transport: Via "authz-info" topic, or in MQTT CONNECT 1100 message for both versions of MQTT. AUTH extensions also used for 1101 authentication and re-authentication for MQTT v5.0 as described in 1102 Section 2.2 and in Section 4. 1104 Appendix B. Document Updates 1106 Version 02 to 03: 1108 o Added the option of Broker certificate thumbprint in the 'rs_cnf' 1109 sent to the Client. 1111 o Clarified the use of a random nonce from the TLS Exporter for PoP, 1112 added to the IANA requirements that the label should be 1113 registered. 1115 o Added a client nonce, when Challenge/Response Authentication is 1116 used between Client and Broker. 1118 o Clarified the use of the "authz-info" topic and the error response 1119 if token validation fails. 1121 o Added clarification on wildcard use in scopes for publish/ 1122 subscribe permissions 1124 o Reorganised sections so that token authorisation for publish/ 1125 subscribe messages are better placed. 1127 Version 01 to 02: 1129 o Clarified protection of Application Message payload as out of 1130 scope, and cited draft-palombini-ace-coap-pubsub-profile for a 1131 potential solution 1133 o Expanded Client connection authorization to capture different 1134 options for Client and Broker authentication over TLS and MQTT 1136 o Removed Payload (and specifically Client Identifier) from proof- 1137 of-possesion in favor of using tls-exporter for a TLS-session 1138 based challenge. 1140 o Moved token transport via "authz-info" topic from the Appendix to 1141 the main text. 1143 o Clarified Will scope. 1145 o Added MQTT AUTH to terminology. 1147 o Typo fixes, and simplification of figures. 1149 Version 00 to 01: 1151 o Present the MQTTv5 as the RECOMMENDED version, and MQTT v3.1.1 for 1152 backward compatibility. 1154 o Clarified Will message. 1156 o Improved consistency in the use of terminology, and upper/lower 1157 case. 1159 o Defined Broker and MQTTS. 1161 o Clarified HTTPS use for C-AS and RS-AS communication. Removed 1162 reference to actors document, and clarified the use of client 1163 authorization server. 1165 o Clarified the Connect message payload and Client Identifier. 1167 o Presented different methods for passing the token, and PoP. 1169 o Added new figures to explain AUTH packets exchang, updated CONNECT 1170 message figure. 1172 Acknowledgements 1174 The authors would like to thank Ludwig Seitz for his review and his 1175 input on the authorization information endpoint, presented in the 1176 appendix. 1178 Authors' Addresses 1180 Cigdem Sengul 1181 Nominet 1182 4 Kingdom Street 1183 London W2 6BD 1184 UK 1186 Email: csengul@acm.org 1187 Anthony Kirby 1188 Oxbotica 1189 1a Milford House, Mayfield Road, Summertown 1190 Oxford OX2 7EL 1191 UK 1193 Email: anthony@anthony.org 1195 Paul Fremantle 1196 University of Portsmouth 1197 School of Computing, Buckingham House 1198 Portsmouth PO1 3HE 1199 UK 1201 Email: paul.fremantle@port.ac.uk