idnits 2.17.1 draft-tiloca-core-observe-multicast-notifications-01.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7390, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7252, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7641, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 1632 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 (-03) exists of draft-dijk-core-groupcomm-bis-01 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-06 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-03 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-25 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-23 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-33 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-03 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group M. Tiloca 3 Internet-Draft R. Hoeglund 4 Updates: 7252, 7390, 7641 (if approved) RISE AB 5 Intended status: Standards Track C. Amsuess 6 Expires: May 7, 2020 7 F. Palombini 8 Ericsson AB 9 November 04, 2019 11 Observe Notifications as CoAP Multicast Responses 12 draft-tiloca-core-observe-multicast-notifications-01 14 Abstract 16 The Constrained Application Protocol (CoAP) allows clients to 17 "observe" resources at a server, and receive notifications as unicast 18 responses upon changes of the resource state. In some use cases, 19 such as based on publish-subscribe, it would be convenient for the 20 server to send a single notification to all the clients observing a 21 same target resource. This document defines how a CoAP server sends 22 observe notifications as response messages over multicast, by 23 synchronizing all the observers of a same resource on a same shared 24 Token value. Besides, this document defines how Group OSCORE can be 25 used to protect multicast notifications end-to-end from the CoAP 26 server to the multiple observer clients. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 7, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 4 65 3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 6 66 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. Protection of Multicast Notifications with Group OSCORE . . . 9 68 5.1. OSCORE Group in Informative Response . . . . . . . . . . 9 69 5.2. Server-Side Requirements . . . . . . . . . . . . . . . . 11 70 5.3. Client-Side Requirements . . . . . . . . . . . . . . . . 12 71 6. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 12 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 76 9.2. Informative References . . . . . . . . . . . . . . . . . 16 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 The Constrained Application Protocol (CoAP) [RFC7252] has been 83 extended with a number of mechanisms, including resource Observation 84 [RFC7641]. This enables CoAP clients to register at a CoAP server as 85 "observers" of a resource, and hence being automatically notified 86 with an unsolicited response upon changes of the resource state. 88 CoAP supports group communication over IP multicast [RFC7390], and 89 [I-D.dijk-core-groupcomm-bis] has been enabling Observe registration 90 requests over multicast, in order for clients to efficiently register 91 as observers of a resource hosted at multiple servers. 93 However, in a number of use cases, using multicast messages for 94 responses would also be desirable. That is, it would be useful that 95 a server sends observe notifications for a same target resource to 96 multiple observers as responses over IP multicast. 98 For instance, in CoAP publish-subscribe [I-D.ietf-core-coap-pubsub], 99 multiple clients can subscribe to a topic, by observing the related 100 resource hosted at the responsible broker. When a new value is 101 published on that topic, it would be convenient for the broker to 102 send a single multicast notification at once, to all the subscriber 103 clients observing that topic. 105 A different use case concerns clients observing a same registration 106 resource at the CoRE Resource Directory 107 [I-D.ietf-core-resource-directory]. For example, multiple clients 108 can benefit of observation for discovering (to-be-created) OSCORE 109 groups [I-D.ietf-core-oscore-groupcomm], by retrieving from the 110 Resource Directory updated links and descriptions to join them 111 through the respective Group Manager 112 [I-D.tiloca-core-oscore-discovery]. 114 More in general, multicast notifications would be beneficial whenever 115 several CoAP clients observe a same target resource at a CoAP server, 116 and can be all notified at once by means of a single response 117 message. However, CoAP does not currently define response messages 118 over IP multicast. This specification fills this gap and provides 119 the following twofold contribution. 121 First, it defines a method to deliver Observe notifications as CoAP 122 responses over IP multicast. In the proposed method, the group of 123 potential observers entrusts the server to manage the Token space for 124 multicast notifications. By doing so, the server provides all the 125 observers of a target resource with the same Token value to bind to 126 their own observation. That Token value is then used in every 127 multicast notification for that target resource. This is achieved by 128 means of an informative unicast response sent by the server to each 129 observer client. 131 Second, this specification defines how to use Group OSCORE 132 [I-D.ietf-core-oscore-groupcomm] to protect multicast notifications 133 end-to-end between the server and the observer clients. This is also 134 achieved by means of the informative unicast response mentioned 135 above, which additionally includes parameter values used by the 136 server to secure every multicast notification for the target resource 137 by using Group OSCORE. This provides a secure binding between each 138 of such notifications and the observation of each of the clients. 140 1.1. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 Readers are expected to be familiar with terms and concepts described 149 in CoAP [RFC7252], group communication for CoAP 150 [RFC7390][I-D.dijk-core-groupcomm-bis], Observe [RFC7641], CBOR 151 [RFC7049], OSCORE [RFC8613], and Group OSCORE 152 [I-D.ietf-core-oscore-groupcomm]. 154 This specification additionally defines the following terminology. 156 o Traditional observation. A resource observation associated to a 157 single observer client, as defined in [RFC7641]. 159 o Group observation. A resource observation associated to a group 160 of clients. The server sends notifications for the group-observed 161 resource over IP multicast to all the observer clients. 163 o Phantom request. The CoAP request message that the server would 164 have received to generate a group observation on one of its 165 resources. The phantom request is generated inside the server and 166 does not hit the wire. 168 o Informative response. A CoAP response message that the server 169 sends to a given client via unicast, providing the client with 170 information on a group observation. 172 2. Server-Side Requirements 174 The server can, at any time, start a group observation on one of its 175 resources. Practically, the server may want to do that under the 176 following circumstances. 178 o In the absence of observations for the target resource, the server 179 receives a registration request from a first client wishing to 180 start a traditional observation on that resource. 182 o When a certain amount of traditional observations has been 183 established on the target resource, the server decides to make 184 those clients part of a group observation on that resource. 186 When it wants to start a group observation on one of its resources, 187 and assuming it knows the multicast IP address to use to send 188 multicast notifications to, the server proceeds as follows. 190 1. The server builds a phantom observation request, i.e. a GET 191 request with an Observe option set to 0 (register). 193 2. The server selects a currently available value T, from the token 194 space used for messages from the chosen multicast IP address to 195 the server address intended for accessing the target resource. 196 That token space is under exclusive control of the server. 198 3. The server processes the phantom observation request above, 199 without transmitting it on the wire. The request is addressed to 200 the resource for which the server wants to start the group 201 observation, as if sent from the group of observers, i.e. with 202 the multicast IP address as source address. 204 4. Upon processing the self-generated phantom request, the server 205 interprets it as an observe registration received from the group 206 of potential observer clients. In particular, from then on, the 207 server MUST use T as its own local Token value associated to that 208 observation, with respect to the (next hop towards the) clients. 210 5. The server does not immediately respond to the phantom 211 observation request with a multicast notification. The server 212 stores the phantom observation request as is, throughout the 213 lifetime of the group observation. 215 After having started a group observation on a target resource, the 216 server proceeds as follows. 218 o For each traditional observation ongoing on the target resource, 219 the server MAY cancel that observation, and then adds the 220 corresponding client to the list of observers taking part in the 221 group observation. The server sends to each of such clients an 222 informative response message, encoded as a unicast response with 223 response code 5.03 (Service Unavailable). As per [RFC7641], such 224 a response does not include an Observe option. The response MUST 225 be Confirmable and MUST NOT encode link-local addresses. The 226 payload of the response is a CBOR map including the following 227 fields. 229 * The IP multicast address where the server will hereafter send 230 multicast notifications for the target resource, encoded as a 231 CBOR byte string, with CBOR label "address". 233 * The byte serialization of the phantom observation request 234 received by the server, encoded as a CBOR byte string, with 235 CBOR label "registr". 237 * Optionally, the current representation of the target resource, 238 encoded as a CBOR byte string, with CBOR label "res". 240 o Upon receiving a registration request to observe the target 241 resource, the server does not create a corresponding individual 242 observation for the requesting client. Instead, the server adds 243 that client to the list of observers taking part in the group 244 observation of the target resource, and replies to the client with 245 the same informative response message defined above, which MUST be 246 Confirmable and MUST include the current representation of the 247 target resource. Note that this also applies when, with no 248 ongoing traditional observations on the target resource, the 249 server receives a registration request from a first client and 250 decides to start a group observation on the target resource. 252 o Upon a change of the status of the target resource, the server 253 sends a multicast notification, intended to all the clients taking 254 part in the group observation of that resource. In particular, 255 each of such multicast notifications: 257 * MUST be sent to the IP multicast address indicated in the 258 informative response message to the observer clients. 260 * MUST include an Observe option, as per [RFC7641]. 262 * MUST have the same Token value T of the phantom registration 263 request that started the group observation, also included in 264 the informative response message to the observer clients. That 265 is, every multicast notification for a target resource is not 266 bound to the observation requests from the different clients, 267 but rather to the phantom registration associated to the whole 268 set of clients currently taking part in the group observation 269 of that resource. 271 3. Client-Side Requirements 273 A client sends an observation request to the server as described in 274 [RFC7641], i.e. a GET request with an Observe option set to 0 275 (register). The request MUST NOT encode link-local addresses. If 276 the server is not configured to accept registrations on that target 277 resource with a group observation, this would still result in a 278 positive notification response to the client as described in 279 [RFC7641]. 281 Upon receiving the informative response defined in Section 2, the 282 client proceeds as follows. 284 1. The client configures an observation of the target resource from 285 a CoAP endpoint associated to the multicast IP address, and 286 stores the phantom registration request specified in the 287 informative response from the server. The group observation is 288 bound to the phantom registration request. In particular, the 289 client MUST use its Token value T as its own local Token value 290 associated to that group observation, with respect to the (next 291 hop towards the) server. The particular way to achieve this is 292 implementation specific. 294 2. If a traditional observation to the target resource is ongoing, 295 the client MAY silently cancel it without notifying the server. 297 3. If the informative response from the server includes the current 298 representation of the target resource, the client considers it as 299 received from an observe notification and processes it as usual. 301 From then on, the client will receive, accept and process multicast 302 notifications about the state of the target resource from the server, 303 as responses to the phantom registration request and with Token value 304 T. 306 4. Example 308 The following example refers to two clients C_1 and C_2 that register 309 to observe a resource /r at a Server S. Before the following 310 exchanges occur, no clients are observing the resource /r , which has 311 value "1234". 313 The server S sends multicast notifications to the IP multicast 314 address M_addr , and starts the group observation upon receiving a 315 registration request from a first client that wishes to start a 316 traditional observation on the resource /r. 318 C_1 ------------------ [ Unicast ] --------------------> S /r 319 | GET | 320 | Token: 0x4a | 321 | Observe: 0 (Register) | 322 | | 323 | (S allocates the available Token value 0xff .) | 324 | | 325 | (S sends to itself a phantom observation request Ph_req | 326 | as coming from the IP multicast address M_addr .) | 327 | ------------------------------------------------- | 328 | / | 329 | \----------------------------------------------------> | /r 330 | GET | 331 | Token: 0xff | 332 | Observe: 0 (Register) | 333 | | 334 | (S creates a group observation of /r .) | 335 | | 336 | (S adds C_1 to the list of observers taking | 337 | part in the group observation of /r .) | 338 | | 339 C_1 <--------------------- [ Unicast ] ----------------- S 340 | 5.03 | 341 | Token: 0x4a | 342 | Payload: { address : M_addr , | 343 | registr : Ph_req , | 344 | res : "1234" } | 345 | | 346 | | 347 C_2 ------------------ [ Unicast ] --------------------> S /r 348 | GET | 349 | Token: 0x01 | 350 | Observe: 0 (Register) | 351 | | 352 | (S adds C_2 to the list of observers taking | 353 | part in the group observation of /r .) | 354 | | 355 C_2 <--------------------- [ Unicast ] ----------------- S 356 | 5.03 | 357 | Token: 0x01 | 358 | Payload: { address : M_addr , | 359 | registr : Ph_req , | 360 | res : "1234" } | 361 | | 362 | | 363 | (The value of the resource /r changes to "5678".) | 364 | | 365 C_1 | 366 + <-------------------- [ Multicast ] ---------------- S 367 C_2 (Destination address: M_addr) | 368 | 2.05 | 369 | Token: 0xff | 370 | Observe: 11 | 371 | Payload: "5678" | 372 | | 374 5. Protection of Multicast Notifications with Group OSCORE 376 A server can protect multicast notifications by using Group OSCORE 377 [I-D.ietf-core-oscore-groupcomm]. In such a case, both the server 378 and the clients interested in receiving multicast notifications from 379 that server have to be members of the same OSCORE group. 381 Clients MAY discover the OSCORE group to refer to by using the method 382 in [I-D.tiloca-core-oscore-discovery], also based on the CoRE 383 Resource Directory (RD) [I-D.ietf-core-resource-directory]. 384 Alternatively, the server MAY communicate to the client what OSCORE 385 group to join, as described in Section 5.1. Furthermore, both the 386 clients and the server MAY join the OSCORE group by using the 387 approach described in [I-D.ietf-ace-key-groupcomm-oscore] and based 388 on the ACE framework for Authentication and Authorization in 389 constrained environments [I-D.ietf-ace-oauth-authz]. Further details 390 on how to discover the OSCORE group and join it are out of the scope 391 of this specification. 393 Alternative security protocols than Group OSCORE, such as OSCORE 394 [RFC8613] and/or DTLS [RFC6347][I-D.ietf-tls-dtls13], can be used to 395 protect other exchanges via unicast between the server and each 396 client, including the original client registration (see Section 3). 398 5.1. OSCORE Group in Informative Response 400 This section describes a mechanism for the server to communicate to 401 the client what OSCORE group to join in order to decrypt and verify 402 the multicast notifications protected with group OSCORE. The client 403 MAY use the information provided by the server to start the ACE 404 joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore]. 405 This mechanism is OPTIONALLY supported by client and server. 407 Additionally to what defined in Section 2, the CBOR map in the 408 informative response payload contains the following fields: 410 o The URI for joining the OSCORE group at the respective Group 411 Manager, encoded as a CBOR text string, with CBOR label "join- 412 uri". If the procedure described in 413 [I-D.ietf-ace-key-groupcomm-oscore] is used for joining, this 414 field specifically indicates the URI of the group-membership 415 resource at the Group Manager. 417 o The name of the OSCORE group, encoded as a CBOR text string, with 418 CBOR label "sec-gp". 420 o Optionally, the URI of the Authorization Server associated to the 421 Group Manager for the OSCORE group, encoded as a CBOR text string, 422 with CBOR label "as-uri". 424 o Optionally, the algorithm used to countersign messages, encoded as 425 a text string or an int, with value taken from the 'Value' column 426 of the "COSE Algorithms" registry defined in [RFC8152], with CBOR 427 label "cs-alg". 429 o Optionally, the elliptic curve for the algorithm used to 430 countersign messages, encoded as a text string or an int, with 431 value taken from the 'Value' column of the "COSE Elliptic Curve" 432 registry defined in [RFC8152], with CBOR label "cs-crv". 434 o Optionally, the key type of countersignature keys used to 435 countersign messages, encoded as a text string or an int, with 436 value taken from the 'Value' column of the "COSE Key Types" 437 registry defined in [RFC8152], with CBOR label "cs-kty". 439 o Optionally, the encoding of the public keys, encoded as an int, 440 with value taken from the 'Confirmation Key' column of the "CWT 441 Confirmation Method" registry defined in 442 [I-D.ietf-ace-cwt-proof-of-possession], with CBOR label "cs-kenc". 443 Future specifications may define additional values for this 444 parameter. 446 o Optionally, the AEAD algorithm, encoded as a text string or an 447 int, with value taken from the 'Value' column of the "COSE 448 Algorithms" registry defined in [RFC8152], with CBOR label "alg". 450 o Optionally, the HKDF algorithm, encoded as a text string or an 451 int, with value taken from the 'Value' column of the "COSE 452 Algorithms" registry defined in [RFC8152], with CBOR label "hkdf". 454 The values of 'cs_alg', 'cs_crv', 'cs_kty' and 'cs_kenc' provide an 455 early knowledge of the format and encoding of public keys used in the 456 OSCORE group. Thus, the client does not need to ask the Group 457 Manager for this information as a preliminary step before the (ACE) 458 join process, or to perform a trial-and-error exchange with the Group 459 Manager upon joining the group. Hence, the client is able to provide 460 the Group Manager with its own public key in the correct expected 461 format and encoding, at the very first step of the (ACE) join 462 process. 464 The values of 'cs_alg', 'alg' and 'hkdf' provide an early knowledge 465 of the algorithms used in the OSCORE group. Thus, the client is able 466 to decide whether to actually proceed with the (ACE) join process, 467 depending on its support for the indicated algorithms. 469 As mentioned above, since this mechanism is OPTIONAL, all the fields 470 are OPTIONAL in the informative response. However, the "join-uri" 471 and "sec-gp" fields MUST be present if the mechanism is implemented 472 and run. If any of the fields are present without the "join-uri" and 473 "sec-gp" fields present, the client MUST ignore these fields, since 474 they would not be sufficient to start the (ACE) join procedure. When 475 this happens, the client MAY try sending a new registration request 476 to the server (see Section 3). Otherwise, the client SHOULD 477 explicitly withdraw from the group observation, as defined in 478 Section 3. 480 5.2. Server-Side Requirements 482 When using Group OSCORE to protect multicast notifications, the 483 server performs as described in Section 2, with the following 484 differences. 486 o The phantom registration request MUST be secured, by using Group 487 OSCORE. To this end, the server protects the phantom registration 488 request as if it was the actual sender, i.e. by using its own 489 Sender Context. As a consequence, the server consumes the current 490 value of its own Sender Sequence Number SN in the OSCORE group, 491 and hence updates it to SN* = (SN + 1). Consistently, the OSCORE 492 option in the phantom registration request includes: 494 * As 'kid', the Sender ID of the server in the OSCORE group. 496 * As 'piv', the previously consumed sender sequence number value 497 SN of the server in the OSCORE group, i.e. (SN* - 1). 499 o Upon sending every multicast notification for the target resource, 500 the server protects it with Group OSCORE. In particular, the 501 process described in Section 6.3 of 502 [I-D.ietf-core-oscore-groupcomm] applies, with the following 503 additions when building the two OSCORE 'external_aad' to encrypt 504 and countersign the multicast notification (see Sections 3.1 and 505 3.2 of [I-D.ietf-core-oscore-groupcomm]). 507 * The 'request_kid' is the 'kid' value in the OSCORE option of 508 the phantom registration request, i.e. the Sender ID of the 509 server. 511 * The 'request_piv' is the 'piv' value in the OSCORE option of 512 the phantom registration request, i.e. the consumed sender 513 sequence number SN of the server. 515 5.3. Client-Side Requirements 517 When using Group OSCORE to protect multicast notifications, the 518 client performs as described in Section 3, with the following 519 differences. 521 o Upon receiving the informative response from the server, the 522 client retrieves the specified phantom registration request, and 523 extracts the 'kid' and 'piv' fields of its OSCORE option. 525 o From then on, when verifying multicast notifications for that 526 target resource as described in Section 6.4 of 527 [I-D.ietf-core-oscore-groupcomm], the client MUST use the 528 extracted 'kid' as 'request_kid' and the extracted 'piv' as 529 'request_piv', in the two 'external_aad' for decrypting and 530 verifying every multicast notification from the server for the 531 target resource (see Sections 3.1 and 3.2 of 532 [I-D.ietf-core-oscore-groupcomm]). The particular way to achieve 533 this is implementation specific. 535 6. Example with Group OSCORE 537 The following example refers to two clients C_1 and C_2 that register 538 to observe a resource /r at a Server S. Before the following 539 exchanges occur, no clients are observing the resource /r , which has 540 value "1234". 542 The server S sends multicast notifications to the IP multicast 543 address M_addr , and starts the group observation upon receiving a 544 registration request from a first client that wishes to start a 545 traditional observation on the resource /r. 547 Pairwise communication over unicast are protected with OSCORE, while 548 S protects multicast notifications with Group OSCORE. Specifically: 550 o C_1 and S have a pairwise OSCORE Security Context. In particular, 551 C_1 has 'kid' = 1 as Sender ID, and SN_1 = 101 as Sequence Number. 552 Also, S has 'kid' = 3 as Sender ID, and SN_3 = 301 as Sequence 553 Number. 555 o C_2 and S have a pairwise OSCORE Security Context. In particular, 556 C_2 has 'kid' = 2 as Sender ID, and SN_2 = 201 as Sequence Number. 557 Also, S has 'kid' = 4 as Sender ID, and SN_4 = 401 as Sequence 558 Number. 560 o S is a member of the OSCORE group with name "myGroup", and 561 'kid_context' = "feedca57ab2e" as Group ID. In the OSCORE group, 562 S has 'kid' = 5 as Sender ID, and SN_5 = 501 as Sequence Number. 564 C_1 ------------- [ Unicast w/ OSCORE ] ---------------> S /r 565 | GET | 566 | Token: 0x4a | 567 | Observe: 0 (Register) | 568 | OSCORE: {kid: 1 ; piv: 101 ; ...} | 569 | | 570 | (S allocates the available Token value 0xff .) | 571 | | 572 | | 573 | (S sends to itself a phantom observation request Ph_req | 574 | as coming from the IP multicast address M_addr .) | 575 | -------------------------------------------------- | 576 | / | 577 | \-----------------------------------------------------> | /r 578 | GET | 579 | Token: 0xff | 580 | Observe: 0 (Register) | 581 | OSCORE: {kid: 5 ; piv: 501 ; ...} | 582 | | 583 | (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) | 584 | | 585 | (S creates a group observation of /r .) | 586 | | 587 | (S adds C_1 to the list of observers taking | 588 | part in the group observation of /r .) | 589 | | 590 | | 591 C_1 <---------------- [ Unicast w/ OSCORE ] ------------- S 592 | 5.03 | 593 | Token: 0x4a | 594 | OSCORE: {piv: 301; ...} | 595 | Payload: { address : M_addr , | 596 | registr : Ph_req , | 597 | res : "1234" , | 598 | join-uri : coap://myGM/group-oscore/myGroup | 599 | sec-gp : "myGroup" } | 600 | | 601 | | 602 C_2 ------------- [ Unicast w/ OSCORE ] ---------------> S /r 603 | GET | 604 | Token: 0x01 | 605 | Observe: 0 (Register) | 606 | OSCORE: {kid: 2 ; piv: 201 ; ...} | 607 | | 608 | (S adds C_2 to the list of observers taking | 609 | part in the group observation of /r .) | 610 | | 611 C_2 <---------------- [ Unicast w/ OSCORE ] ------------- S 612 | 5.03 | 613 | Token: 0x01 | 614 | OSCORE: {piv: 401; ...} | 615 | Payload: { address : M_addr , | 616 | registr : Ph_req , | 617 | res : "1234" , | 618 | join-uri : coap://myGM/group-oscore/myGroup | 619 | sec-gp : "myGroup" } | 620 | | 621 | | 622 | (The value of the resource /r changes to "5678".) | 623 | | 624 C_1 | 625 + <------------ [ Multicast w/ Group OSCORE ] --------- S 626 C_2 (Destination address: M_addr) | 627 | 2.05 | 628 | Token: 0xff | 629 | Observe: 11 | 630 | OSCORE: {kid: 5; piv: 502 ; ...} | 631 | Payload: "5678" | 632 | | 634 The two external_aad used to encrypt and countersign the multicast 635 notification above have 'req_kid' = 5 and 'req_iv' = 501. These are 636 indicated in the 'kid' and 'iv' field of the OSCORE option of the 637 phantom observation request, which is included in the 'registr' 638 parameter of the unicast informative response to the two clients. 639 Thus, the two clients can build the two same external_aad for 640 decrypting and verifying this multicast notification and the 641 following ones. 643 7. Security Considerations 645 The same security considerations from [RFC7252][RFC7390][RFC7641][I-D 646 .dijk-core-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] 647 hold for this document. 649 If multicast notifications are protected using Group OSCORE, the 650 original registration requests and related unicast (notification) 651 responses MUST also be secured, including and especially the 652 informative responses from the server. This prevents on-path active 653 adversaries from altering the conveyed IP multicast address and 654 serialized phantom request. Thus, it ensures secure binding between 655 every multicast notification for a same observed resource and the 656 phantom request that started the group observation of that resource. 658 To this end, clients and servers SHOULD use OSCORE or Group OSCORE, 659 so ensuring that the secure binding above is enforced end-to-end 660 between the server and each observing client. 662 8. IANA Considerations 664 This document has the following actions for IANA. 666 TODO: registry for labels of the map in the informative response. 668 9. References 670 9.1. Normative References 672 [I-D.dijk-core-groupcomm-bis] 673 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 674 for the Constrained Application Protocol (CoAP)", draft- 675 dijk-core-groupcomm-bis-01 (work in progress), July 2019. 677 [I-D.ietf-core-oscore-groupcomm] 678 Tiloca, M., Selander, G., Palombini, F., and J. Park, 679 "Group OSCORE - Secure Group Communication for CoAP", 680 draft-ietf-core-oscore-groupcomm-06 (work in progress), 681 November 2019. 683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 684 Requirement Levels", BCP 14, RFC 2119, 685 DOI 10.17487/RFC2119, March 1997, 686 . 688 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 689 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 690 October 2013, . 692 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 693 Application Protocol (CoAP)", RFC 7252, 694 DOI 10.17487/RFC7252, June 2014, 695 . 697 [RFC7641] Hartke, K., "Observing Resources in the Constrained 698 Application Protocol (CoAP)", RFC 7641, 699 DOI 10.17487/RFC7641, September 2015, 700 . 702 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 703 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 704 May 2017, . 706 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 707 "Object Security for Constrained RESTful Environments 708 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 709 . 711 9.2. Informative References 713 [I-D.ietf-ace-cwt-proof-of-possession] 714 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 715 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 716 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 717 possession-11 (work in progress), October 2019. 719 [I-D.ietf-ace-key-groupcomm-oscore] 720 Tiloca, M., Park, J., and F. Palombini, "Key Management 721 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 722 oscore-03 (work in progress), November 2019. 724 [I-D.ietf-ace-oauth-authz] 725 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 726 H. Tschofenig, "Authentication and Authorization for 727 Constrained Environments (ACE) using the OAuth 2.0 728 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-25 729 (work in progress), October 2019. 731 [I-D.ietf-core-coap-pubsub] 732 Koster, M., Keranen, A., and J. Jimenez, "Publish- 733 Subscribe Broker for the Constrained Application Protocol 734 (CoAP)", draft-ietf-core-coap-pubsub-09 (work in 735 progress), September 2019. 737 [I-D.ietf-core-resource-directory] 738 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 739 Amsuess, "CoRE Resource Directory", draft-ietf-core- 740 resource-directory-23 (work in progress), July 2019. 742 [I-D.ietf-tls-dtls13] 743 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 744 Datagram Transport Layer Security (DTLS) Protocol Version 745 1.3", draft-ietf-tls-dtls13-33 (work in progress), October 746 2019. 748 [I-D.tiloca-core-oscore-discovery] 749 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 750 Groups with the CoRE Resource Directory", draft-tiloca- 751 core-oscore-discovery-03 (work in progress), July 2019. 753 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 754 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 755 January 2012, . 757 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 758 the Constrained Application Protocol (CoAP)", RFC 7390, 759 DOI 10.17487/RFC7390, October 2014, 760 . 762 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 763 RFC 8152, DOI 10.17487/RFC8152, July 2017, 764 . 766 Acknowledgments 768 The authors sincerely thank Carsten Bormann, Klaus Hartke, John 769 Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander for their 770 comments and feedback. 772 The work on this document has been partly supported by VINNOVA and 773 the Celtic-Next project CRITISEC. 775 Authors' Addresses 777 Marco Tiloca 778 RISE AB 779 Isafjordsgatan 22 780 Kista SE-16440 Stockholm 781 Sweden 783 Email: marco.tiloca@ri.se 785 Rikard Hoeglund 786 RISE AB 787 Isafjordsgatan 22 788 Kista SE-16440 Stockholm 789 Sweden 791 Email: rikard.hoglund@ri.se 793 Christian Amsuess 794 Hollandstr. 12/4 795 Vienna 1020 796 Austria 798 Email: christian@amsuess.com 799 Francesca Palombini 800 Ericsson AB 801 Torshamnsgatan 23 802 Kista SE-16440 Stockholm 803 Sweden 805 Email: francesca.palombini@ericsson.com