idnits 2.17.1 draft-tiloca-core-observe-multicast-notifications-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 : ---------------------------------------------------------------------------- -- 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 (July 06, 2019) is 1756 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-00 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-05 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-02 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-24 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-08 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-22 == 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) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 5 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: January 7, 2020 7 F. Palombini 8 Ericsson AB 9 July 06, 2019 11 Observe Notifications as CoAP Multicast Responses 12 draft-tiloca-core-observe-multicast-notifications-00 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 CoAP clients registered as observers. 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 January 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. The Override-Token Option . . . . . . . . . . . . . . . . . . 4 65 3. The Override-AAD Option . . . . . . . . . . . . . . . . . . . 5 66 4. Resource Observation . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Client Registration . . . . . . . . . . . . . . . . . . . 6 68 4.2. Multicast Notifications . . . . . . . . . . . . . . . . . 7 69 4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5. Token Values for Multicast Notifications . . . . . . . . . . 9 71 6. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 11 72 7. Protection of Multicast Notifications with Group OSCORE . . . 11 73 7.1. Secure Binding of Multicast Notifications . . . . . . . . 12 74 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 9.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 15 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 80 10.2. Informative References . . . . . . . . . . . . . . . . . 17 81 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 The Constrained Application Protocol (CoAP) [RFC7252] has been 87 extended with a number of mechanisms, including resource Observation 88 [RFC7641]. This enables CoAP clients to register at a CoAP server as 89 "observers" of a resource, and hence being automatically notified 90 with an unsolicited response upon changes of the resource state. 92 CoAP supports group communication over IP multicast [RFC7390], and 93 [I-D.dijk-core-groupcomm-bis] has been enabling Observe registration 94 requests over multicast, in order for clients to efficiently register 95 as observers of a resource hosted at multiple servers. 97 However, in a number of use cases, the opposite usage of multicast 98 messages would be also desirable. That is, it would be useful that a 99 server sends observe notifications for a same target resource to 100 multiple observer clients, as responses over IP multicast. 102 For instance, in CoAP publish-subscribe [I-D.ietf-core-coap-pubsub], 103 multiple clients can subscribe to a topic, by observing the related 104 resource hosted at the responsible broker. When a new value is 105 published on that topic, it would be convenient for the broker to 106 send a single multicast notification at once, to all the subscriber 107 clients observing that topic. 109 A different use case concerns clients observing a registration 110 resource at the CoRE Resource Directory 111 [I-D.ietf-core-resource-directory]. For example, multiple clients 112 can benefit of observation for discovering (to-be-created) OSCORE 113 groups [I-D.ietf-core-oscore-groupcomm] and retrieving updated 114 information to join them through their respective Group Manager 115 [I-D.tiloca-core-oscore-discovery]. 117 More in general, multicast notifications would be beneficial whenever 118 several CoAP clients observe a same target resource at a CoAP server, 119 and can be all notified at once by means of a single response 120 message. However, CoAP does not currently define response messages 121 over IP multicast. This specification fills this gap and provides 122 the following twofold contribution. 124 First, it defines a method to deliver Observe notifications as CoAP 125 responses over IP multicast. The proposed method relies on the 126 server managing the Token space for multicast notifications, by 127 providing all the observers of a target resource with the same Token 128 value to bind to their own observation. That Token value is used in 129 every multicast notification for that target resource. This is 130 achieved by introducing a new CoAP option used in the notification 131 response to the original registration request from each client. 133 Second, this specification defines how to use Group OSCORE 134 [I-D.ietf-core-oscore-groupcomm] to protect multicast notifications 135 end-to-end between the server and the observer clients. This is 136 achieved by introducing a second new CoAP option used in the 137 notification response to the original registration request from each 138 client. The option specifies parameter values that the server uses 139 to secure every multicast notification for the target resource by 140 using Group OSCORE. This provides a secure binding between each of 141 such notifications and the observation of each of the clients. 143 1.1. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 Readers are expected to be familiar with terms and concepts described 152 in CoAP [RFC7252], group communication for CoAP 153 [RFC7390][I-D.dijk-core-groupcomm-bis], Observe [RFC7641], CBOR 154 [RFC7049], OSCORE [I-D.ietf-core-object-security], and Group OSCORE 155 [I-D.ietf-core-oscore-groupcomm]. 157 2. The Override-Token Option 159 The Override-Token option defined in this section has the properties 160 summarized in Figure 1, which extends Table 4 of [RFC7252]. 162 Since the option is not Safe-to-Forward, the column "N" is filled 163 with a dash. The Override-Token option contains a Token value. 165 +------+---+---+---+---+----------------+--------+--------+---------+ 166 | No. | C | U | N | R | Name | Format | Length | Default | 167 +------+---+---+---+---+----------------+--------+--------+---------+ 168 | TBD1 | X | x | - | | Override-Token | opaque | 1-8 | (none) | 169 +------+---+---+---+---+----------------+--------+--------+---------+ 171 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 173 Figure 1: The Override-Token Option. 175 This document specifically defines how this option is used to support 176 Observe notifications over IP multicast (see Section 4). 178 If a server provides multicast notifications for a target resource, 179 the server includes the Override-Token option in the unicast 180 notification response sent as the first reply to a registration 181 request from each client to that resource, i.e. a GET request with 182 the Observe option set to 0. The server indicates a same immutable 183 Token value T in the Override-Token option of each of these first 184 replies. In any other circumstance, this option is not included. 186 The server will use that same Token value T when sending multicast 187 notifications to registered clients observing that resource. This 188 ensures that every multicast notification for that resource is 189 expected on the same Token value T by each observing client. 191 The Override-Token option is of class U for OSCORE 192 [I-D.ietf-core-object-security][I-D.ietf-core-oscore-groupcomm], 193 since intermediaries may be present, and may replace it with a new 194 instance (see Section 6). 196 3. The Override-AAD Option 198 The Override-AAD option defined in this section has the properties 199 summarized in Figure 2, which extends Table 4 of [RFC7252]. 201 +------+---+---+---+---+--------------+--------+--------+---------+ 202 | No. | C | U | N | R | Name | Format | Length | Default | 203 +------+---+---+---+---+--------------+--------+--------+---------+ 204 | TBD2 | X | | | | Override-AAD | (*) | 3-255 | (none) | 205 +------+---+---+---+---+--------------+--------+--------+---------+ 207 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 208 (*) See below. 210 Figure 2: The Override-AAD Option 212 If a server that provides multicast notifications for a target 213 resource protects them with Group OSCORE 214 [I-D.ietf-core-oscore-groupcomm], the server includes the Override- 215 AAD option in the unicast notification response sent as the first 216 reply to a registration request from each client to that resource, 217 i.e. a GET request with the Observe option set to 0. In any other 218 circumstance, this option is not included. 220 The Override-AAD option contains a CBOR array [RFC7049] composed of 221 the two following elements. 223 o The first element is a CBOR byte string, which encodes the Sender 224 ID of the server in the OSCORE group. 226 o The second element is a CBOR integer, which encodes a particular 227 value SN of the Sender Sequence Number of the server in the OSCORE 228 group. 230 The server uses this same immutable pair to build the two OSCORE 231 'external_aad' (see Section 5.4 of [I-D.ietf-core-object-security] 232 and Sections 3.1 and 3.2 of [I-D.ietf-core-oscore-groupcomm]), when 233 encrypting and countersigning every multicast notification for the 234 observed resource using Group OSCORE 235 [I-D.ietf-core-oscore-groupcomm]. 237 This ensures that every multicast notification for a same observed 238 resource is securely bound to the first unicast notification sent to 239 each client observing that resource. 241 The Override-AAD option is of class E for OSCORE 242 [I-D.ietf-core-object-security][I-D.ietf-core-oscore-groupcomm]. 244 4. Resource Observation 246 Clients interested in receiving multicast notifications from a server 247 have to first register their interest, as described in Section 4.1. 248 This registration is performed over unicast, i.e. comprising both the 249 observation request and the first notification response. 251 Upon a change of the state of the target resource, the server sends a 252 multicast notification, i.e. a single CoAP response over Multicast IP 253 intended to all the clients in the list of observers of that 254 resource, as described in Section 4.2. Multicast notifications MUST 255 be non-confirmable. 257 Interested clients need to know the IP multicast address and UDP port 258 number where the server sends multicast notifications for the target 259 resource(s). To this end, a possible approach may rely on the CoRE 260 Resource Directory (RD) and the RD-Groups usage pattern (see 261 Appendix A of [I-D.ietf-core-resource-directory]). In particular, 262 application groups may be registered to the RD, as composed of the 263 resource(s) for which a server provides multicast notifications, and 264 specifying the used IP multicast address and UDP port number. 265 Further details on how clients retrieve this information are out of 266 the scope of this specification. 268 The server MUST NOT send multicast notifications to unmanaged IP 269 multicast addresses, such as All CoAP Nodes (see Section 12.8 of 270 [RFC7252]). 272 4.1. Client Registration 274 The registration process occurs according to the following steps. 276 1. A client sends an observation request to the server as described 277 in [RFC7641], i.e. a GET request with an Observe option set to 0 278 (register). 280 2. If the list of observers for the target resource has just changed 281 from empty to including one observer, the server selects a 282 currently available value T from its Token space and exclusively 283 assigns it as Token value to the list of observers of the target 284 resource (see also related considerations in Section 5). That 285 is, from then on, the server MUST use T as its own local Token 286 value associated to that observation, with respect to the (next 287 hop towards the) client. 289 3. The server adds the client to the list of observers of the target 290 resource. 292 4. The server sends a unicast response notification to the client as 293 described in [RFC7641], i.e. a 2.05 (Content) or 2.03 (Valid) 294 response with an Observe option including a sequence number. 295 Additionally, the server includes an Override-Token option 296 defined in Section 2, which MUST contain the value T. Note that 297 every client further added to the same non-empty list of 298 observers of that target resource receives a notification 299 response to its registration request with the same value T 300 included in the Override-Token option. 302 5. Upon receiving the unicast notification response to the 303 observation request, the client retrieves the Override-Token 304 option and the conveyed value T. The client interprets this 305 response as if the server: i) has successfully added an entry 306 with the client endpoint and Token value T to the list of 307 observers of the target resource; and ii) will notify changes to 308 the state of the target resource, by means of multicast 309 notifications with Token value T. The client MAY adopt a policy 310 for re-registering its interest for observation, if the Override- 311 Token option includes a Token value already in use with that 312 server. Clients MUST treat as non valid and silently discard 313 responses that include an Override-Token option but do not 314 include also an Observe option. 316 6. From then on, the client MUST be able to receive, accept and 317 process multicast notifications about the state of the target 318 resource from the server. To this end, the client is required to 319 know in advance the IP multicast address and port number where 320 the server will send multicast notifications to. Also, from then 321 on, the client MUST use T as its own local Token value associated 322 to that observation, with respect to the (next hop towards the) 323 server. The particular way to achieve this is implementation 324 specific. 326 4.2. Multicast Notifications 328 Upon a change of the status of the target resource, the server sends 329 a multicast notification intended to all the clients in the list of 330 observers of that resource. In particular, a multicast notification 331 MUST include an Observe option, as specified in [RFC7641]. 333 Compared to notifications as described in [RFC7641], the following 334 two differences apply for a multicast notification. 336 o It is sent as a single CoAP response over Multicast IP. 338 o It has Token value T, as indicated to every interested client in 339 the Override-Token option of the notification response to its 340 observation request to the target resource (see Section 4.1). 342 That is, every multicast notification for a target resource is not 343 bound to the different original observation requests, but rather to 344 the whole set of clients currently in the list of observers of that 345 resource. 347 4.3. Example 349 The following example refers to two clients C_1 and C_2 that register 350 to observe a resource /r at a Server S. 352 Before the following exchanges occur, no clients are observing the 353 resource /r , which has value "1234". 355 C_1 ------------------ [ Unicast ] --------------------> S /r 356 | GET | 357 | Token: 0x4a | 358 | Observe: 0 (Register) | 359 | | 360 | (S adds C_1 to the list of observers of /r .) | 361 | | 362 | (S allocates the available Token value 0xff .) | 363 | | 364 | | 365 C_1 <--------------------- [ Unicast ] ----------------- S 366 | 2.05 | 367 | Token: 0x4a | 368 | Observe: 10 | 369 | Override-Token: 0xff | 370 | Payload: "1234" | 371 | | 372 C_2 ------------------ [ Unicast ] --------------------> S /r 373 | GET | 374 | Token: 0x01 | 375 | Observe: 0 (Register) | 376 | | 377 | (S adds C_2 to the list of observers of /r .) | 378 | | 379 C_2 <--------------------- [ Unicast ] ----------------- S 380 | 2.05 | 381 | Token: 0x01 | 382 | Observe: 10 | 383 | Override-Token: 0xff | 384 | Payload: "1234" | 385 | | 386 | (The value of the resource /r changes to "5678".) | 387 | | 388 C_1 | 389 + <-------------------- [ Multicast ] ---------------- S 390 C_2 | 391 | 2.05 | 392 | Token: 0xff | 393 | Observe: 11 | 394 | Payload: "5678" | 395 | | 397 5. Token Values for Multicast Notifications 399 The Token space for multicast notifications is shared by all the 400 clients that have registered to observe resources at a server. As 401 described in Section 4, the server aligns all the clients observing a 402 same resource to consider a same Token value, which is then used in 403 every multicast notification sent for that resource. 405 This specification updates [RFC7252] by defining the Token values in 406 Figure 3 as intended for multicast notifications. 408 A server supporting the Override-Token option and Observe multicast 409 notifications MUST use the Token values in Figure 3 for its multicast 410 notifications and as content of the Override-Token option. A server 411 MUST NOT use the same Token value in multicast notifications for 412 multiple resources currently under observation. 414 A client supporting the Override-Token option and Observe multicast 415 notifications MUST NOT use the Token values in Figure 3 for its 416 outgoing messages, except when explicitly cancelling the observation, 417 i.e. a GET request to the server with an Observe option set to 1 (see 418 Section 3.6 of [RFC7641]). That GET request has the same Token value 419 used by the server in the multicast notifications for that 420 observation. 422 This ensures clients to correctly distinguish a multicast 423 notification from a regular (notification) response, as well as to 424 correctly bind the former with the corresponding observation, while 425 the latter with the corresponding original request. 427 +------------+-------------------------------------------+-------+ 428 | Token size | Token value range | Range | 429 | (Bytes) | | size | 430 +------------+-------------------------------------------+-------+ 431 | 1 | [0xf0 , 0xff] | 16 | 432 +------------+-------------------------------------------+-------+ 433 | 2 | [0xffc0 , 0xffff] | 64 | 434 +------------+-------------------------------------------+-------+ 435 | 3 | [0xffff00 , 0xffffff] | 256 | 436 +------------+-------------------------------------------+-------+ 437 | 4 | [0xfffffbff , 0xffffffff] | 1024 | 438 +------------+-------------------------------------------+-------+ 439 | 5 | [0xfffffff7ff , 0xffffffffff] | 2048 | 440 +------------+-------------------------------------------+-------+ 441 | 6 | [0xffffffffefff , 0xffffffffffff] | 4096 | 442 +------------+-------------------------------------------+-------+ 443 | 7 | [0xffffffffffdfff , 0xffffffffffffff] | 8192 | 444 +------------+-------------------------------------------+-------+ 445 | 8 | [0xffffffffffffbfff , 0xffffffffffffffff] | 16384 | 446 +------------+-------------------------------------------+-------+ 448 Figure 3: Range of Token values for multicast notifications. 450 6. Intermediaries 452 In case intermediaries such as CoAP proxies are involved, the same 453 approach described in Section 4 is used independently on both the 454 client- and server-side of each proxy. Care must be taken to only 455 use IP multicast addresses that have all the same meaning on all 456 interfaces of the involved hops. 458 Upon receiving the unicast response to an original observation 459 request, a proxy on the path between the server and a client performs 460 the following actions. 462 o The proxy retrieves the Token value T from the Override-Token 463 option. From then on, the proxy MUST use T as its own local Token 464 value associated to that observation, with respect to the next hop 465 towards the server. 467 o The proxy MAY remove the original Override-Token option. In such 468 a case, the proxy MUST include a new Override-Token option. The 469 newly included Override-Token option specifies a Token value T' 470 (which may be equal to T), consistently with the rules defined in 471 Section 5. From then on, the proxy uses T' as its own local Token 472 value associated to that observation, with respect to the next hop 473 towards the clients. Otherwise, if the proxy does not remove the 474 Override-Token option, the proxy uses T as its own local Token 475 value associated to that observation, with respect to the next hop 476 towards the clients. 478 The process described above starts at the server and continues until 479 the clients are eventually reached. Even in the presence of 480 intermediaries, this ensures general conflict-free synchronization of 481 Token values at each hop on the path from the server to the clients. 483 7. Protection of Multicast Notifications with Group OSCORE 485 A server can protect multicast notifications by using Group OSCORE 486 [I-D.ietf-core-oscore-groupcomm]. In such a case, both the server 487 and the clients interested in receiving multicast notifications from 488 that server have to be members of the same OSCORE group. 490 Building on the approach suggested in Section 4.1 to discover IP 491 multicast addresses and UDP port numbers, clients may discover the 492 OSCORE group to refer to by using the method in 493 [I-D.tiloca-core-oscore-discovery], also based on the CoRE Resource 494 Directory (RD) [I-D.ietf-core-resource-directory]. 496 Furthermore, both the clients and server may join the OSCORE group by 497 using the approach described in [I-D.ietf-ace-key-groupcomm-oscore] 498 and based on the ACE framework for Authentication and Authorization 499 in constrained environments [I-D.ietf-ace-oauth-authz]. 501 Further details on how to discover the OSCORE group and join it are 502 out of the scope of this specification. 504 Alternative security protocols than Group OSCORE, such as OSCORE 505 [I-D.ietf-core-object-security] and/or DTLS [RFC6347], can be used to 506 protect other unicast exchanges between the server and each client, 507 including the original client registration described in Section 4.1. 509 7.1. Secure Binding of Multicast Notifications 511 When using Group OSCORE to protect multicast notifications, the 512 registration process occurs as described in Section 4.1, with the 513 following additions. 515 o If the list of observers for the target resource has just changed 516 from empty to including one observer, the server consumes the 517 current value of its own Sender Sequence Number SN in the OSCORE 518 group, and hence updates it to SN* = (SN + 1). 520 Note for implementation: a possible way to achieve this is for the 521 server to produce a dummy request addressed to the OSCORE group, 522 and protect it using its own Sender Context of the Group OSCORE 523 Security Context. This dummy request is not actually transmitted, 524 i.e. it does not hit the wire. 526 o Upon sending the unicast first notification response to a just 527 registered client, the server includes in that response an 528 Override-AAD option defined in Section 3. The option MUST contain 529 the pair ('kid' ; 'piv') encoded as defined in Section 3, where 530 'kid' is the Sender ID of the server in the OSCORE group, while 531 'piv' is the previously consumed Sender Sequence Number value SN 532 of the server in the OSCORE group, i.e. (SN* - 1). Note that 533 every client further added to the same non-empty list of observers 534 of that target resource receives a notification response to its 535 registration request including the exact same pair ('kid' ; 'piv') 536 in the Override-AAD option. 538 o Upon receiving the unicast notification response to the 539 observation request, the client retrieves the Override-AAD option 540 and the conveyed pair ('kid' ; 'piv'). From then on, when 541 verifying multicast notifications as described in Section 6.4 of 542 [I-D.ietf-core-oscore-groupcomm], the client MUST use 'kid' as 543 'request_kid' and 'piv' as 'request_piv' in the two 'external_aad' 544 for decrypting and verifying every multicast notification from the 545 server for the target resource (see Sections 3.1 and 3.2 of 547 [I-D.ietf-core-oscore-groupcomm]). The particular way to achieve 548 this is implementation specific. Clients MUST treat as non valid 549 and silently discard responses that include an Override-AAD option 550 but that do not include also both an Override-Token option and an 551 Observe option. A client has to be a current member of the OSCORE 552 group comprising also the server and associated to the target 553 resource, and MUST otherwise silently discard responses that 554 include an Override-AAD option. 556 Upon sending every multicast notification for the target resource as 557 described in Section 4.2, the server protects it with Group OSCORE. 558 In particular, the process described in Section 6.3 of 559 [I-D.ietf-core-oscore-groupcomm] applies, with the following 560 differences when building the two OSCORE 'external_aad' to encrypt 561 and countersign the multicast notification (see Sections 3.1 and 3.2 562 of [I-D.ietf-core-oscore-groupcomm]). 564 o The 'request_kid' contains the 'kid' value that the server 565 specifies to clients as first element in the Override-AAD option, 566 when replying to the their registration request. 568 o The 'request_piv' contains the 'piv' value that the server 569 specifies to clients as second element in the Override-AAD option, 570 when replying to their registration request. 572 7.2. Example 574 The following example refers to two clients C_1 and C_2 that register 575 to observe a resource /r at a Server S. Pairwise communication over 576 unicast are protected with OSCORE, while S protects multicast 577 notifications with Group OSCORE. 579 Before the following exchanges occur, no clients are observing the 580 resource /r , which has value "1234". In addition: 582 o C_1 and S have a pairwise OSCORE Security Context. In particular, 583 C_1 has 'kid' = 1 as Sender ID, and SN_1 = 101 as Sequence Number. 584 Also, S has 'kid' = 3 as Sender ID, and SN_3 = 301 as Sequence 585 Number. 587 o C_2 and S have a pairwise OSCORE Security Context. In particular, 588 C_2 has 'kid' = 2 as Sender ID, and SN_2 = 201 as Sequence Number. 589 Also, S has 'kid' = 4 as Sender ID, and SN_4 = 401 as Sequence 590 Number. 592 o C_1, C_2 and S are members of an OSCORE group with 'kid_context' = 593 "feedca57ab2e" as Group ID. In the OSCORE group, S has 'kid' = 5 594 as Sender ID, and SN_5 = 501 as Sequence Number. 596 C_1 ------------ [ Unicast w/ OSCORE ] -----------------> S /r 597 | GET | 598 | Token: 0x4a | 599 | Observe: 0 (Register) | 600 | OSCORE: {kid: 1 ; piv: 101 ; ...} | 601 | | 602 | (S adds C_1 to the list of observers of /r .) | 603 | | 604 | (S allocates the available Token value 0xff .) | 605 | | 606 | (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) | 607 | | 608 C_1 <--------------- [ Unicast w/ OSCORE ] --------------- S 609 | 2.05 | 610 | Token: 0x4a | 611 | Observe: 10 | 612 | OSCORE: {piv: 301; ...} | 613 | Override-Token: 0xff | 614 | Override-AAD: {5 ; 501} | 615 | Payload: "1234" | 616 | | 617 C_2 ------------ [ Unicast w/ OSCORE ] -----------------> S /r 618 | GET | 619 | Token: 0x01 | 620 | Observe: 0 (Register) | 621 | OSCORE: {kid: 2 ; piv: 201 ; ...} | 622 | | 623 | (S adds C_2 to the list of observers of /r .) | 624 | | 625 C_2 <--------------- [ Unicast w/ OSCORE ] --------------- S 626 | 2.05 | 627 | Token: 0x01 | 628 | Observe: 10 | 629 | OSCORE: {piv: 401 ; ...} | 630 | Override-Token: 0xff | 631 | Override-AAD: {5 ; 501} | 632 | Payload: "1234" | 633 | | 634 | (The value of the resource /r changes to "5678".) | 635 | | 636 C_1 | 637 + <------------ [ Multicast w/ Group OSCORE ] ---------- S 638 C_2 | 639 | 2.05 | 640 | Token: 0xff | 641 | Observe: 11 | 642 | OSCORE: {kid: 5 ; piv: 502 ; ...} | 643 | Payload: "5678" | 645 The two external_aad used to encrypt and countersign the multicast 646 notification above have 'req_kid' = 5 and 'req_iv' = 501, as 647 indicated in the Override-AAD option to the two clients. Thus, the 648 two clients can build the two same external_aad for decrypting and 649 verifying this multicast notification and the following ones. 651 8. Security Considerations 653 The same security considerations from [RFC7252][RFC7390][RFC7641][I-D 654 .dijk-core-groupcomm-bis][I-D.ietf-core-object-security][I-D.ietf-cor 655 e-oscore-groupcomm] hold for this document. 657 The Override-Token option is of class U for OSCORE, hence 658 intermediaries and on-path active adversaries are able to modify its 659 value. This yields the same effects of altering the Token value of 660 CoAP messages. 662 If multicast notifications are protected using Group OSCORE, the 663 original registration requests and related unicast notification 664 responses MUST also be secured. This prevents on-path active 665 adversaries from altering the Override-AAD option, and thus ensures 666 secure binding between every multicast notification for a same 667 observed resource and the first notification response sent to each 668 client observing that resource. 670 To this end, clients and servers MUST use OSCORE or Group OSCORE, for 671 which the Override-AAD option is of class E and would thus be hidden 672 also from intermediaries such as CoAP proxies. This ensures that the 673 secure binding above is enforced end-to-end between the server and 674 each observing client. 676 9. IANA Considerations 678 This document has the following actions for IANA. 680 9.1. CoAP Option Numbers Registry 682 IANA is asked to enter the following option numbers to the "CoAP 683 Option Numbers" registry defined in [RFC7252] within the "CoRE 684 Parameters" registry. 686 +--------+------------------+-------------------+ 687 | Number | Name | Reference | 688 +--------+------------------+-------------------+ 689 | TBD1 | Override-Token | [[this document]] | 690 +--------+------------------+-------------------+ 691 | TBD2 | Override-AAD | [[this document]] | 692 +--------+------------------+-------------------+ 694 10. References 696 10.1. Normative References 698 [I-D.dijk-core-groupcomm-bis] 699 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 700 for the Constrained Application Protocol (CoAP)", draft- 701 dijk-core-groupcomm-bis-00 (work in progress), March 2019. 703 [I-D.ietf-core-object-security] 704 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 705 "Object Security for Constrained RESTful Environments 706 (OSCORE)", draft-ietf-core-object-security-16 (work in 707 progress), March 2019. 709 [I-D.ietf-core-oscore-groupcomm] 710 Tiloca, M., Selander, G., Palombini, F., and J. Park, 711 "Group OSCORE - Secure Group Communication for CoAP", 712 draft-ietf-core-oscore-groupcomm-05 (work in progress), 713 July 2019. 715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 716 Requirement Levels", BCP 14, RFC 2119, 717 DOI 10.17487/RFC2119, March 1997, 718 . 720 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 721 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 722 October 2013, . 724 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 725 Application Protocol (CoAP)", RFC 7252, 726 DOI 10.17487/RFC7252, June 2014, 727 . 729 [RFC7641] Hartke, K., "Observing Resources in the Constrained 730 Application Protocol (CoAP)", RFC 7641, 731 DOI 10.17487/RFC7641, September 2015, 732 . 734 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 735 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 736 May 2017, . 738 10.2. Informative References 740 [I-D.ietf-ace-key-groupcomm-oscore] 741 Tiloca, M., Park, J., and F. Palombini, "Key Management 742 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 743 oscore-02 (work in progress), July 2019. 745 [I-D.ietf-ace-oauth-authz] 746 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 747 H. Tschofenig, "Authentication and Authorization for 748 Constrained Environments (ACE) using the OAuth 2.0 749 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 750 (work in progress), March 2019. 752 [I-D.ietf-core-coap-pubsub] 753 Koster, M., Keranen, A., and J. Jimenez, "Publish- 754 Subscribe Broker for the Constrained Application Protocol 755 (CoAP)", draft-ietf-core-coap-pubsub-08 (work in 756 progress), March 2019. 758 [I-D.ietf-core-resource-directory] 759 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 760 Amsuess, "CoRE Resource Directory", draft-ietf-core- 761 resource-directory-22 (work in progress), July 2019. 763 [I-D.tiloca-core-oscore-discovery] 764 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 765 Groups with the CoRE Resource Directory", draft-tiloca- 766 core-oscore-discovery-03 (work in progress), July 2019. 768 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 769 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 770 January 2012, . 772 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 773 the Constrained Application Protocol (CoAP)", RFC 7390, 774 DOI 10.17487/RFC7390, October 2014, 775 . 777 Acknowledgments 779 The authors sincerely thank John Mattsson, Ludwig Seitz and Goeran 780 Selander for their comments and feedback. 782 The work on this document has been partly supported by VINNOVA and 783 the Celtic-Next project CRITISEC. 785 Authors' Addresses 787 Marco Tiloca 788 RISE AB 789 Isafjordsgatan 22 790 Kista SE-16440 Stockholm 791 Sweden 793 Email: marco.tiloca@ri.se 795 Rikard Hoeglund 796 RISE AB 797 Isafjordsgatan 22 798 Kista SE-16440 Stockholm 799 Sweden 801 Email: rikard.hoglund@ri.se 803 Christian Amsuess 804 Hollandstr. 12/4 805 Vienna 1020 806 Austria 808 Email: christian@amsuess.com 810 Francesca Palombini 811 Ericsson AB 812 Torshamnsgatan 23 813 Kista SE-16440 Stockholm 814 Sweden 816 Email: francesca.palombini@ericsson.com