idnits 2.17.1 draft-palombini-ace-coap-pubsub-profile-00.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 -- The document date (March 13, 2017) is 2572 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) == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-05 == Outdated reference: A later version (-13) exists of draft-ietf-core-coap-pubsub-00 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-09 == Outdated reference: A later version (-06) exists of draft-seitz-ace-oscoap-profile-01 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group F. Palombini 3 Internet-Draft Ericsson 4 Intended status: Standards Track March 13, 2017 5 Expires: September 14, 2017 7 CoAP Pub-Sub Profile for Authentication and Authorization for 8 Constrained Environments (ACE) 9 draft-palombini-ace-coap-pubsub-profile-00 11 Abstract 13 This specification defines a profile for authentication and 14 authorization for publishers and subscribers in a pub-sub setting 15 scenario in a constrained environment, using the ACE framework. This 16 profile relies on transport layer or application layer security to 17 authorize the publisher to the broker. Moreover, it relies on 18 application layer security for publisher-broker and subscriber-broker 19 communication. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 14, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Publisher Profile . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Retrieval of COSE Key for protection of content . . . . . 5 60 3.2. AS1, AS2 Information . . . . . . . . . . . . . . . . . . 7 61 4. Subscriber Profile . . . . . . . . . . . . . . . . . . . . . 8 62 5. Pub-Sub Protected Communication . . . . . . . . . . . . . . . 9 63 5.1. Using COSE Objects to protect the resource representation 10 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 69 9.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 This specification defines a way to authorize nodes in a CoAP pub-sub 75 type of setting, using the ACE framework [I-D.ietf-ace-oauth-authz]. 76 The pub-sub scenario is described in [I-D.ietf-core-coap-pubsub]. 78 1.1. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 Readers are expected to be familiar with the terms and concepts 85 described in [I-D.ietf-ace-oauth-authz] and 86 [I-D.ietf-core-coap-pubsub]. 88 2. Overview 90 The objective of this specification is to specify how to protect a 91 CoAP pub-sub communication, as described in 92 [I-D.ietf-core-coap-pubsub], using Ace framework 93 ([I-D.ietf-ace-oauth-authz]) and profiles 94 ([I-D.gerdes-ace-dtls-authorize], [I-D.seitz-ace-oscoap-profile]). 96 The architecture of the scenario is shown in Figure 1. 98 +----------------+ +----------------+ 99 | | | | 100 | Authorization | | Authorization | 101 | Server 1 | | Server 2 | 102 | | | | 103 +----------------+ +----------------+ 104 ^ ^ ^ 105 | | | 106 +---------(A)----+ | +-----(E)------+ 107 | +--------------------(B)--------+ | 108 v v v 109 +------------+ +------------+ +------------+ 110 | CoAP | ----(C)---> | CoAP | | CoAP | 111 | Client - | [<--(D)-->] | Server - | | Client - | 112 | | ----(F)---> | | | | 113 | Publisher | | Broker | <----(G)---- | Subscriber | 114 | | | | -----(H)---> | | 115 +------------+ +------------+ +------------+ 117 Figure 1: Architecture CoAP pubsub with Authorization Servers 119 The RS is the broker, which contains the topic. The AS1 hosts the 120 policies about the Broker: what endpoints are allowed to Publish on 121 the Broker. The AS2 hosts the policies about the topic: what 122 endpoints are allowed to access what topic. There are four phases, 123 the first three can be done in parallel. 125 1. The Publisher requests publishing access to a broker at the AS1, 126 and communicates with the Broker to set up security. 128 2. The Publisher requests access to a specific topic at the AS2 130 3. The Subscriber requests access to a specific topic at the AS2. 132 4. The Publisher and the Subscriber securely post to and get 133 publications from the Broker. 135 This scenario requires the setup of 2 different security 136 associations: on the one hand, the Publisher has a security 137 association with the Broker, to protect the communication and 138 securely authorize the Publisher to publish on a topic (Security 139 Association 1). On the other hand, the Publisher has a security 140 association with the Subscriber, to protect the publication content 141 itself (Security Association 2). The Security Association 1 is set 142 up using AS1, the Security Association 2 is set up using AS2. 144 +------------+ +------------+ +------------+ 145 | CoAP | | CoAP | | CoAP | 146 | Client - | | Server - | | Client - | 147 | | | | | | 148 | Publisher | | Broker | | Subscriber | 149 +------------+ +------------+ +------------+ 150 : : : : 151 : '------ Security -------' : 152 : Association 1 : 153 '------------------------------- Security --------------' 154 Association 2 156 3. Publisher Profile 158 In this section, it is specified how the Publisher requests, obtains 159 and communicates to the Broker the access token, as well as the 160 retrieval of the keying material to protect the publication. 162 +----------------+ +----------------+ 163 | | | | 164 | Authorization | | Authorization | 165 | Server 1 | | Server 2 | 166 | | | | 167 +----------------+ +----------------+ 168 ^ ^ 169 | | 170 +---------(A)----+ | 171 | +--------------------(B)--------+ 172 v v 173 +------------+ +------------+ 174 | CoAP | ----(C)---> | CoAP | 175 | Client - | [<--(D)-->] | Server - | 176 | | | | 177 | Publisher | | Broker | 178 | | | | 179 +------------+ +------------+ 181 Figure 2: Phase 1: Publisher side 183 This is a combination of two independent phases: 185 o one is the establishment of a secure connection between Publisher 186 and Broker, using an ACE profile such as DTLS 187 [I-D.gerdes-ace-dtls-authorize] or OSCOAP 188 [I-D.seitz-ace-oscoap-profile]. (A)(C)(D) 190 o the other is the Publisher's retrieval of keying material to 191 protect the publication. (B) 193 In detail: 195 (A) corresponds to the Access Token Request and Response between 196 Publisher and Authorization Server to retrieve the Access Token and 197 RS (Broker) Information. As specified, the Publisher has the role of 198 a CoAP client, the Broker has the role of the CoAP server. 200 (C) corresponds to the exchange between Publisher and Broker, where 201 the Publisher sends its access token to the Broker. 203 (D) corresponds to the exchange where the Publisher establishes a 204 secure connection with the Broker. Depending on the Information 205 received in (A), this can be for example DTLS handshake, or other 206 protocols such as EDHOC. Depending on the application, there may not 207 be the need for this set up phase: for example, if OSCOAP is used 208 directly and not without EDHOC first. 210 (A), (C) and (D) details are specified in the profile used. 212 (B) corresponds to the retrieval of the keying material to protect 213 the publication. The detailed message flow is defined below. 215 3.1. Retrieval of COSE Key for protection of content 217 This phase is common to both Publisher and Subscriber. To maintain 218 the generality, the Publisher or Subscriber is referred as Client in 219 this section. 221 Client Broker AS2 222 | [----- Resource Request ---->] | | 223 | | | 224 | [<-- AS1, AS2 Information ---] | | 225 | | 226 | ------- Topic Keying Material Request ---------> | 227 | | 228 | <------------ Keying Material ------------------ | 229 | | 231 Figure 3: B: Access request - response 233 Complementary to what is defined in the DTLS profile (section 2.), to 234 determine the AS2 in charge of a topic hosted at the broker, the 235 Broker MAY send the address of both the AS in charge of the topic 236 back to the Client, as a response to a Resource Request 237 (Section 2.1). Analogously to the DTLS profile, instead of the 238 initial Unauthorized Resource Request message, the Client MAY look up 239 the desired topic in a resource directory (see 240 [I-D.ietf-core-resource-directory]). 242 After retrieving the AS2 address, the Client sends a Topic Keying 243 Material Request, which is a token-less authorization as described in 244 [I-D.seitz-ace-oauth-authz], section 6.5. More specifically, the 245 Client sends a POST request to the /token endpoint on AS2, that MUST 246 contain in the payload: 248 o the grant type set to "client_credentials", 250 o the audience parameter set to the Broker, 252 o the scope parameter set to the topic, 254 o the cnf parameter containing the Client's COSE key, if the Client 255 is a publisher, and 257 o OPTIONALLY, other additional parameters such as the client id or 258 the algorithm. 260 Note that, if present, the algorithm MUST be a Content Encryption 261 Algorithm, as defined in Section 10 of [I-D.ietf-cose-msg]. An 262 example of the payload of a Topic Keying Material Request for a 263 Publisher is specified in Figure 4. 265 { 266 "grant_type" : "client_credentials", 267 "aud" : "Broker1", 268 "scope" : "Temp", 269 "client_id" : "publisher1", 270 "cnf" : 271 { / COSE_Key / 272 / type / 1 : 2, / EC2 / 273 / kid / 2 : h'11', 274 / alg / 3 : -7, / ECDSA with SHA-256 / 275 / crv / -1 : 1 , / P-256 / 276 / x / -2 : h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de1 277 08de439c08551d', 278 / y /-3 : h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e 279 9eecd0084d19c' 280 } 281 } 283 Figure 4: Example of Topic Keying Material Request payload for a 284 Publisher 286 The AS2 verifies that the Client is authorized to access the topic 287 and, if the "cnf" parameter is present, stores the public key of the 288 Client. 290 The AS2 response contains an empty token and the keying material to 291 protect the publication ("key" field in the payload). Moreover, the 292 payload MUST contain the "profile" parameter, set to value "OSCON", 293 and the "token_type" set to "none". 295 TODO: define "key" parameter following ACE framework 297 The "key" parameter value MUST be a serialized COSE Key (see 298 Section 7 of [I-D.ietf-cose-msg]), with the following values: 300 o kty with value 4 (symmetric) 302 o alg with value defined by the AS2 (Content Encryption Algorithm) 304 o k with value the symmetric key value 306 o OPTIONALLY, kid with an identifier for the key value 308 An example for the response is detailed in Figure 5. 310 { 311 "access_token" : NULL, 312 "token_type" : "none", 313 "profile" : "OSCON", 314 "key" : h'a4010402421234030c205002e2cc3a9b92855220f255fff1c615bc' 315 /{1: 4, 2: h'1234', 3: 12, -1: h'02e2cc3a9b92855220f255fff1c615bc'}/ 316 } 318 Figure 5: Example of Topic Keying Material response payload for a 319 Publisher 321 3.2. AS1, AS2 Information 323 The Client MUST be able to process the following response message 324 from the Broker, in order to retrieve the correct AS1 and AS2 325 addresses. 327 This CoAP message MUST have the following characteristics: the CoAP 328 Code MUST be 4.01 "Unauthorized", the payload MUST be present and 329 MUST include the full URI of both AS. An example using CBOR 330 diagnostic notation is given below: 332 4.01 Unauthorized 333 Content-Format: application/ace+cbor 334 {"AS1": "coaps://as1.example.com/token", 335 "AS2": "coaps://as2.example.com/pubsubkey"} 337 Figure 6: AS1, AS2 Information example 339 4. Subscriber Profile 341 In this section, it is specified how the Subscriber retrieves the 342 keying material to protect the publication. 344 +----------------+ 345 | | 346 | Authorization | 347 | Server 2 | 348 | | 349 +----------------+ 350 ^ 351 | 352 +-----(E)------+ 353 | 354 v 355 +------------+ 356 | CoAP | 357 | Client - | 358 | | 359 | Subscriber | 360 | | 361 +------------+ 363 Figure 7: Phase 2: Subscriber side 365 Step (E) between Subscriber and AS2 corresponds to the retrieval of 366 the keying material to verify the publication, and is the same as (B) 367 between Publisher and AS2 (Section 3.1), with the following 368 differences: 370 o The POST request to the /token endpoint on AS2, does not contain 371 the cnf parameter containing the Client's COSE key. 373 o The AS2 response contains a "cnf" parameter whose value is set to 374 a COSE Key Set, (Section 7 of [I-D.ietf-cose-msg]) i.e. an array 375 of COSE Keys, which contains the public keys of all authorized 376 Publishers 378 An example of the payload of a Topic Keying Material Request and 379 corresponding response for a Subscriber is specified in Figure 8 and 380 Figure 9. 382 { 383 "grant_type" : "client_credentials", 384 "aud" : "Broker1", 385 "scope" : "Temp", 386 "client_id" : "subscriber1" 387 } 389 Figure 8: Example of Topic Keying Material Request payload for a 390 Subscriber 392 { 393 "access_token" : NULL, 394 "token_type" : "none", 395 "profile" : "OSCON", 396 "key" : h'a4010402421234030c205002e2cc3a9b92855220f255fff1c615bc', 397 /{1: 4, 2: h'1234', 3: 12, -1: h'02e2cc3a9b92855220f255fff1c615bc'}/ 398 "cnf" : [ 399 { 400 1 : 2, / type EC2 / 401 2 : h'11', / kid / 402 3 : -7, / alg ECDSA with SHA-256 / 403 -1 : 1 , / crv P-256 / 404 -2 : h'65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de43 405 9c08551d', / x / 406 -3 : h'1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd 407 0084d19c' / y / 408 } 409 ] 410 } 412 Figure 9: Example of Topic Keying Material response payload for a 413 Subscriber 415 5. Pub-Sub Protected Communication 417 This section specifies the communication Publisher-Broker and 418 Subscriber-Broker, after the previous phases have taken place. 420 +------------+ +------------+ +------------+ 421 | CoAP | | CoAP | | CoAP | 422 | Client - | | Server - | | Client - | 423 | | ----(F)---> | | | | 424 | Publisher | | Broker | <----(G)---- | Subscriber | 425 | | | | -----(H)---> | | 426 +------------+ +------------+ +------------+ 428 Figure 10: Phase 3: Secure communication between Publisher and 429 Subscriber 431 The (F) message corresponds to the publication of a topic on the 432 Broker. The publication (the resource representation) is protected 433 with COSE ([I-D.ietf-cose-msg]). The (G) message is the subscription 434 of the Subscriber, which is unprotected. The (H) message is the 435 response from the Broker, where the publication is protected with 436 COSE. 438 The flow graph is presented below. 440 Publisher Broker Subscriber 441 | --- PUT /topic ----> | | 442 | protected with COSE | | 443 | | <--- GET /topic ----- | 444 | | | 445 | | ---- response ------> | 446 | | protected with COSE | 448 Figure 11: (F), (G), (H): Example of protected communication 450 5.1. Using COSE Objects to protect the resource representation 452 The Publisher uses the symmetric COSE Key received from AS2 in 453 exchange B (Section 3.1) to protect the payload of the PUBLISH 454 operation (Section 4.3 of [I-D.ietf-core-coap-pubsub]). 455 Specifically, the COSE Key is used to create a COSE_Encrypt0 with 456 algorithm specified by AS2. The Publisher uses the private key 457 corresponding to the public key sent to the AS2 in exchange B 458 (Section 3.1) to countersign the COSE Object as specified in 459 Section 4.5 of [I-D.ietf-cose-msg]. The CoAP payload is replaced by 460 the COSE object before the publication is sent to the Broker. 462 The Subscriber uses the kid in the countersignature field in the COSE 463 object to retrieve the right public key to verify the 464 countersignature. It then uses the symmetric key received from AS2 465 to verify and decrypt the publication received in the payload of the 466 CoAP Notification from the Broker. 468 The COSE object is constructed in the following way: 470 o The protected Headers (as described in Section 3 of 471 [I-D.ietf-cose-msg]) MAY contain the kid parameter, with value the 472 kid of the symmetric COSE Key received in Section 3.1 and MUST 473 contain the content encryption algorithm 475 o The unprotected Headers MUST contain the IV and the counter 476 signature that includes: 478 * the algorithm (same value as in the asymmetric COSE Key 479 received in (B)) in the protected header 481 * the kid (same value as the kid of the asymmetric COSE Key 482 received in (B)) in the unprotected header 484 * the signature computed as specified in Section 4.5 of 485 [I-D.ietf-cose-msg] 487 o The ciphertext, computed over the plaintext that MUST contain the 488 CoAP payload. 490 The external_aad, when using AEAD, is an empty string. 492 An example is given in Figure 12 494 16( 495 [ 496 / protected / h'a2010c04421234' / { 497 \ alg \ 1:12, \ AES-CCM-64-64-128 \ 498 \ kid \ 4: h'1234' 499 } / , 500 / unprotected / { 501 / iv / 5:h'89f52f65a1c580', 502 / countersign / 7:[ 503 / protected / h'a10126' / { 504 \ alg \ 1:-7 505 } / , 506 / unprotected / { 507 / kid / 4:h'11' 508 }, 509 / signature / SIG / 64 bytes signature / 510 ] 511 }, 512 / ciphertext / h'8df0a3b62fccff37aa313c8020e971f8aC8d' 513 ] 514 ) 516 Figure 12: Example of COSE Object sent in the payload of a PUBLISH 517 operation 519 The encryption and decryption operations are described in sections 520 5.3 and 5.4 of [I-D.ietf-cose-msg]. 522 6. Security Considerations 524 In the profile described above, the Publisher and Subscriber use 525 asymmetric crypto, which would make the message exchange quite heavy 526 for small constrained devices. Moreover, all Subscribers must be 527 able to access the public keys of all the Publishers to a specific 528 topic to be able to verify the publications. Such a database could 529 be set up and managed by the same entity having control of the topic, 530 i.e. AS2. 532 An application where it is not critical that only authorized 533 Publishers can publish on a topic may decide not to make use of the 534 asymmetric crypto and only use symmetric encryption/MAC to 535 confidentiality and integrity protect the publication, but this is 536 not recommended since, as a result, any authorized Subscribers with 537 access to the Broker may forge unauthorized publications without 538 being detected. In this symmetric case the Subscribers would only 539 need one symmetric key per topic, and would not need to know any 540 information about the Publishers, that can be anonymous to it and the 541 Broker. 543 Subscribers can be excluded from future publications through re- 544 keying for a certain topic. This could be set up to happen on a 545 regular basis, for certain applications. How this could be done is 546 out of scope for this work. 548 The Broker is only trusted with verifying that the Publisher is 549 authorized to publish, but is not trusted with the publications 550 itself, which it cannot read nor modify. In this setting, caching of 551 publications on the Broker is still allowed. 553 TODO: expand on security and Privacy considerations 555 7. IANA Considerations 557 TODO: "key" parameter, OSCON profile identifier 559 8. Acknowledgments 561 The author wishes to thank John Mattsson, Ludwig Seitz and Goeran 562 Selander for the useful discussion that helped shape this document. 564 9. References 565 9.1. Normative References 567 [I-D.ietf-ace-oauth-authz] 568 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 569 H. Tschofenig, "Authentication and Authorization for 570 Constrained Environments (ACE)", draft-ietf-ace-oauth- 571 authz-05 (work in progress), February 2017. 573 [I-D.ietf-core-coap-pubsub] 574 Koster, M., Keranen, A., and J. Jimenez, "Publish- 575 Subscribe Broker for the Constrained Application Protocol 576 (CoAP)", draft-ietf-core-coap-pubsub-00 (work in 577 progress), October 2016. 579 [I-D.ietf-cose-msg] 580 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 581 draft-ietf-cose-msg-24 (work in progress), November 2016. 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, 585 DOI 10.17487/RFC2119, March 1997, 586 . 588 9.2. Informative References 590 [I-D.gerdes-ace-dtls-authorize] 591 Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and 592 L. Seitz, "Datagram Transport Layer Security (DTLS) 593 Profile for Authentication and Authorization for 594 Constrained Environments (ACE)", draft-gerdes-ace-dtls- 595 authorize-01 (work in progress), March 2017. 597 [I-D.ietf-core-resource-directory] 598 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 599 Resource Directory", draft-ietf-core-resource-directory-09 600 (work in progress), October 2016. 602 [I-D.seitz-ace-oauth-authz] 603 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 604 H. Tschofenig, "Authorization for the Internet of Things 605 using OAuth 2.0", draft-seitz-ace-oauth-authz-00 (work in 606 progress), October 2015. 608 [I-D.seitz-ace-oscoap-profile] 609 Seitz, L. and F. Palombini, "OSCOAP profile of ACE", 610 draft-seitz-ace-oscoap-profile-01 (work in progress), 611 October 2016. 613 Author's Address 615 Francesca Palombini 616 Ericsson 618 Email: francesca.palombini@ericsson.com