idnits 2.17.1 draft-tiloca-core-groupcomm-proxy-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 : ---------------------------------------------------------------------------- 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 (July 13, 2020) is 1376 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 (-10) exists of draft-ietf-core-groupcomm-bis-00 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-09 == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-07 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-05 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group M. Tiloca 3 Internet-Draft RISE AB 4 Intended status: Standards Track E. Dijk 5 Expires: January 14, 2021 IoTconsultancy.nl 6 July 13, 2020 8 Proxy Operations for CoAP Group Communication 9 draft-tiloca-core-groupcomm-proxy-01 11 Abstract 13 This document specifies the operations performed by a forward-proxy, 14 when using the Constrained Application Protocol (CoAP) in group 15 communication scenarios. Proxy operations involve the processing of 16 individual responses from servers, as reply to a single request sent 17 by the client over unicast to the proxy, and then distributed by the 18 proxy over IP multicast to the servers. When receiving the different 19 responses via the proxy, the client is able to distinguish them and 20 their originator servers, by acquiring their addressing information. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 14, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. The Multicast-Signaling Option . . . . . . . . . . . . . . . 3 59 3. The Response-Forwarding Option . . . . . . . . . . . . . . . 4 60 4. Requirements and Objectives . . . . . . . . . . . . . . . . . 5 61 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Request Sending . . . . . . . . . . . . . . . . . . . . . 7 63 5.2. Request Processing at the Proxy . . . . . . . . . . . . . 8 64 5.3. Request and Response Processing at the Server . . . . . . 8 65 5.4. Response Processing at the Proxy . . . . . . . . . . . . 9 66 5.5. Response Processing at the Client . . . . . . . . . . . . 10 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 6.1. Client Authentication . . . . . . . . . . . . . . . . . . 11 69 6.2. Multicast-Signaling Option . . . . . . . . . . . . . . . 11 70 6.3. Response-Forwarding Option . . . . . . . . . . . . . . . 12 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 7.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 12 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 8.2. Informative References . . . . . . . . . . . . . . . . . 14 76 Appendix A. Using OSCORE Between Client and Proxy . . . . . . . 14 77 A.1. Protecting the Request . . . . . . . . . . . . . . . . . 14 78 A.2. Verifying the Request . . . . . . . . . . . . . . . . . . 15 79 A.3. Protecting the Response . . . . . . . . . . . . . . . . . 15 80 A.4. Verifying the Response . . . . . . . . . . . . . . . . . 15 81 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 The Constrained Application Protocol (CoAP) [RFC7252] allows the 87 presence of forward-proxies, as intermediary entities supporting 88 clients to perform requests on their behalf. 90 CoAP supports also group communication over IP multicast 91 [I-D.ietf-core-groupcomm-bis], where a group request can be addressed 92 to multiple recipient servers, each of which may reply with an 93 individual unicast response. As discussed in Section 2.3.3 of 94 [I-D.ietf-core-groupcomm-bis], this group communication scenario 95 poses a number of issues and limitations to proxy operations. 97 In particular, the client sends a single unicast request to the 98 proxy, which the proxy forwards to a group of servers over IP 99 multicast. Later on, the proxy delivers back to the client multiple 100 responses to the original unicast request. As defined by [RFC7252], 101 the multiple responses are delivered to the client inside separate 102 CoAP messages, all matching (by Token) to the client's original 103 unicast request. A possible alternative approach of performing 104 aggregation of responses into a single CoAP response would require a 105 specific aggregation content-format, which is not available yet. 106 Both these approaches have open issues. 108 This specification considers the former approach of how the proxy 109 forwards the individual responses to a CoAP group request back to the 110 client. The described method addresses all the related issues raised 111 in Section 2.3.3 of [I-D.ietf-core-groupcomm-bis]. 113 To this end, a dedicated signaling protocol is defined, using two new 114 CoAP options. In particular, the client can explicitly confirm its 115 support for receiving multiple responses to a proxied unicast 116 request, i.e. one per originator server, and for how long it is 117 willing to wait for responses. Also, each server originating a 118 response indicates to the client its own addressing information. 119 This enables the client to distinguish the multiple, diffent 120 responses by origin and to possibly contact one or more of the 121 individual servers by a unicast request, optionally bypassing the 122 forward-proxy. 124 1.1. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 Readers are expected to be familiar with terms and concepts defined 133 in CoAP [RFC7252], Group Communication for CoAP 134 [I-D.ietf-core-groupcomm-bis], OSCORE [RFC8613] and Group OSCORE 135 [I-D.ietf-core-oscore-groupcomm]. 137 2. The Multicast-Signaling Option 139 The Multicast-Signaling Option defined in this section has the 140 properties summarized in Figure 1, which extends Table 4 of 141 [RFC7252]. The option is intended only for CoAP requests. 143 Since the option is not Safe-to-Forward, the column "N" indicates a 144 dash for "not applicable". The value of the Multicast-Signaling 145 Option specifies a timeout value in seconds, encoded as an unsigned 146 integer (see Section 3.2 of [RFC7252]). 148 +------+---+---+---+---+------------+--------+--------+---------+ 149 | No. | C | U | N | R | Name | Format | Length | Default | 150 +------+---+---+---+---+------------+--------+--------+---------+ 151 | | | | | | | | | | 152 | TBD1 | | x | - | | Multicast- | uint | 1-5 B | (none) | 153 | | | | | | Signaling | | | | 154 | | | | | | | | | | 155 +------+---+---+---+---+------------+--------+--------+---------+ 156 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 157 (*) See below. 159 Figure 1: The Multicast-Signaling Option. 161 This document specifically defines how this option is used by a 162 client, to indicate to a forward-proxy its support for and interest 163 in receiving multiple responses to a proxied CoAP group request, i.e. 164 one per originator server, and for how long it is willing to wait for 165 receiving responses via that proxy (see Section 5.1 and Section 5.2). 167 The client, when sending a CoAP group request to a proxy via IP 168 unicast, to be forwarded by the proxy to a targeted group of servers, 169 includes the Multicast-Signaling Option into the request. The option 170 value indicates after what time period in seconds the client will 171 stop accepting responses matching its original unicast request, with 172 the exception of notifications if CoAP Observe is used [RFC7641]. 173 This allows the intermediary proxy to stop forwarding responses back 174 to the client, if received from the servers later than a timeout 175 expiration. 177 The Multicast-Signaling Option is of class U for OSCORE 178 [RFC8613][I-D.ietf-core-oscore-groupcomm]. 180 3. The Response-Forwarding Option 182 The Response-Forwarding Option defined in this section has the 183 properties summarized in Figure 2, which extends Table 4 of 184 [RFC7252]. The option is intended only for CoAP responses, and 185 builds on the Base-Uri option from Section 3 of 186 [I-D.bormann-coap-misc]. 188 Since the option is intended only for responses, the column "N" 189 indicates a dash. 191 +------+---+---+---+---+------------+--------+--------+---------+ 192 | No. | C | U | N | R | Name | Format | Length | Default | 193 +------+---+---+---+---+------------+--------+--------+---------+ 194 | | | | | | | | | | 195 | TBD2 | | | - | | Response- | string | 8-20 B | (none) | 196 | | | | | | Forwarding | | | | 197 | | | | | | | | | | 198 +------+---+---+---+---+------------+--------+--------+---------+ 199 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 200 (*) See below. 202 Figure 2: The Response-Forwarding Option. 204 This document specifically defines how this option is used by a proxy 205 that forwards a request originated by a client over IP multicast. 207 Upon receiving a response to that request from a server, the proxy 208 includes the Response-Forwarding Option into the response sent to the 209 originator client (see Section 5). The proxy uses the option to 210 indicate to the client the addressing information of the server 211 generating the response. 213 The client can use the addressing information of the server specified 214 in the option to identify the response originator and possibly send 215 later unicast requests to directly, or via the proxy as CoAP unicast 216 requests. 218 The option value is an absolute-URI with no query component 219 ([RFC3986], Section 4.3). If the port number is omitted in the 220 authority component, it is assumed that the port number where to send 221 unicast requests to the server is the same port number specified in 222 the group URI of the original unicast CoAP group request sent to the 223 proxy (see Section 5.1). 225 The Response-Forwarding Option is of class E for OSCORE 226 [RFC8613][I-D.ietf-core-oscore-groupcomm]. 228 4. Requirements and Objectives 230 This specification assumes that the following requirements are 231 fulfilled. 233 o REQ1. The CoAP proxy is explicitly configured (white-list) to 234 allow proxied CoAP group requests from specific client(s). 236 o REQ2. The CoAP proxy MUST identify a client sending a CoAP group 237 request, in order to verify whether the client is white-listed to 238 do so. For example, this can rely on one of the following. 240 * A DTLS channel [RFC6347][I-D.ietf-tls-dtls13] between the 241 client and the proxy, where the client has also been 242 authenticated during the secure channel establishment. 244 * A pairwise OSCORE Security Context between the client and the 245 proxy, as described in Appendix A. 247 o REQ3. If secure, end-to-end communication is required between the 248 client and the servers in the CoAP group, exchanged messages MUST 249 be protected by using Group OSCORE 250 [I-D.ietf-core-oscore-groupcomm], as discussed in Section 5.2 of 251 [I-D.ietf-core-groupcomm-bis]. This requires the client and the 252 servers to have previously joined the correct OSCORE group, for 253 instance by using the approach described in 254 [I-D.ietf-ace-key-groupcomm-oscore]. The correct OSCORE group to 255 join can be pre-configured or alternatively discovered, for 256 instance by using the approach described in 257 [I-D.tiloca-core-oscore-discovery]. 259 This specification defines how to achieve the following objectives. 261 o OBJ1. The CoAP proxy gets an indication from the client that it 262 is in fact interested to and capable to receive multiple responses 263 to its unicast request containing a CoAP group URI. 265 o OBJ2. The CoAP proxy learns how long it should wait for responses 266 to a proxied request, before starting to ignore following 267 responses (except for notifications, if CoAP Observe is used 268 [RFC7641]). 270 o OBJ3. The CoAP proxy returns individual unicast responses to the 271 client, each of which matches the original unicast request to the 272 proxy. 274 o OBJ4. The CoAP client is able to distinguish the different 275 responses to the original unicast request, as well as their 276 corresponding originator servers. 278 o OBJ5. The CoAP client is enabled to optionally contact one or 279 more of the responding servers in the future, either directly or 280 via the CoAP proxy. 282 5. Protocol Description 283 5.1. Request Sending 285 In order to send a request addressed to a group of servers via the 286 CoAP proxy, the client proceeds as follows. 288 1. The client prepares a request addressed to the CoAP proxy. The 289 request specifies the group URI as a string in the Proxi-URI 290 option, or by using the Proxy-Scheme option with the group URI 291 constructed from the URI-* options (see Section 2.3.3 of 292 [I-D.ietf-core-groupcomm-bis]). 294 2. The client MUST retain the Token value used for this original 295 unicast request beyond the reception of a first response matching 296 it. To this end, the client follows the same rules for Token 297 retention defined for multicast requests in Section 2.3.1 of 298 [I-D.ietf-core-groupcomm-bis]. In particular, it picks an amount 299 of time T to wait for before freeing up the Token value, such 300 that: 302 * T is smaller than the amount of time Tr it may pick to wait 303 for before potentially reusing the Token value. 305 * T includes the expected worst-case time taken by the request 306 and response processing on the forward-proxy plus the servers 307 in the addressed CoAP group. 309 * T includes the expected worst-case round-trip delay between 310 client and proxy, and between proxy and servers. 312 3. The client includes the Multicast-Signaling Option defined in 313 Section 2 into the unicast request to send to the proxy. The 314 option value specifies an amount of time T' < T. The difference 315 (T - T') should include the expected worst-case round-trip time 316 between the client and the forward-proxy. 318 4. The client processes the request as defined in 319 [I-D.ietf-core-groupcomm-bis], and also as in 320 [I-D.ietf-core-oscore-groupcomm] when secure group communication 321 is used between the client and the servers. 323 5. If OSCORE is used to protect the leg between the client and the 324 proxy (see REQ2 in Section 4), the client (further) protects the 325 unicast request as resulting at the end of step 4. In 326 particular, the client uses the pairwise OSCORE Security Context 327 it has with the proxy, as described in Appendix A.1. 329 6. The client sends the request to the proxy as a unicast CoAP 330 message. 332 5.2. Request Processing at the Proxy 334 Upon receiving the request from the client, the proxy proceeds as 335 follows. 337 1. If OSCORE is used to protect the leg between the client and the 338 proxy (see REQ2 in Section 4), the proxy decrypts the request 339 using the pairwise OSCORE Security Context it has with the 340 client, as described in Appendix A.4. 342 2. The proxy identifies the client, and verifies that the client is 343 in fact white-listed to have its requests proxyied to CoAP group 344 URIs. 346 3. The proxy verifies the presence of the Multicast-Signaling 347 Option, as a confirmation that the client is fine to receive 348 multiple responses matching the same original request. 350 4. The proxy retrieves the value T' from the Multicast-Signaling 351 Option, and then removes the option from the client's request. 353 5. The proxy forwards the client's request to the group of servers. 354 In particular, the proxy sends it as a CoAP group request over IP 355 multicast, addressed to the group URI specified by the client. 357 6. The proxy sets a timeout with the value T' retrieved from the 358 Multicast-Signaling Option of the original unicast request. The 359 proxy will ignore responses to the forwarded group request coming 360 from servers, if received after the timeout expiration, with the 361 exception of Observe notifications (see Section 5.4). 363 5.3. Request and Response Processing at the Server 365 Upon receiving the group request from the proxy, a server proceeds as 366 follows. 368 1. The server processes the group request as defined in 369 [I-D.ietf-core-groupcomm-bis], and also as in 370 [I-D.ietf-core-oscore-groupcomm] when secure group communication 371 is used between the client and the server. 373 2. The server processes the response to be forwarded back to the 374 client as defined in [I-D.ietf-core-groupcomm-bis], and also as 375 in [I-D.ietf-core-oscore-groupcomm] when secure group 376 communication is used between the client and the server. 378 5.4. Response Processing at the Proxy 380 Upon receiving a response matching the group request before the 381 amount of time T' has elapsed, the proxy proceeds as follows. 383 1. The proxy includes the Response-Forwarding Option defined in 384 Section 3 into the response. The proxy specifies as option value 385 the addressing information of the server generating the response, 386 encoded as an absolute-URI as defined in Section 3. In 387 particular: 389 * The authority component MUST specify the server IPv6 address 390 if the multicast request was destined for an IPv6 multicast 391 address, and MUST specify the server IPv4 address if the 392 multicast request was destined for an IPv4 address. 394 * The authority component MUST specify the port number of the 395 server as the source port number of the response, if this 396 differs from the port number specified in the group URI of the 397 original unicast CoAP group request (see Section 5.1). 398 Otherwise, the authority component MAY omit the port number. 400 When using Observe [RFC7641], the proxy includes the Response- 401 Forwarding Option also in every notification, including non-2.xx 402 notifications resulting in removing the proxy from the list of 403 observers. 405 2. If OSCORE is used to protect the leg between the client and the 406 proxy (see REQ2 in Section 4), the proxy (further) protects the 407 response using the pairwise OSCORE Security Context it has with 408 the client, as described in Appendix A.3. 410 3. The proxy forwards the response back to the client. 412 Upon timeout expiration, i.e. T' seconds after having sent the group 413 request over IP multicast, the proxy frees up its local Token value 414 associated to that request. Thus, following late responses to the 415 same group request will be discarded and not forwarded back to the 416 client. 418 When using CoAP Observe [RFC7641], the Token value is freed up only 419 if, after the timeout expiration, no 2.xx (Success) responses 420 matching the group request and also including an Observe option have 421 been received. Then, as long as observations are active with servers 422 in the group for the target resource of the group request, 423 notifications from those servers are forwarded back to the client. 425 5.5. Response Processing at the Client 427 Upon receiving from the proxy a response matching the original 428 unicast request before the amount of time T has elapsed, the client 429 proceeds as follows. 431 1. The client processes the response as defined in 432 [I-D.ietf-core-groupcomm-bis]. 434 2. If OSCORE is used to protect the leg between the client and the 435 proxy (see REQ2 in Section 4), the client decrypts the response 436 using the pairwise OSCORE Security Context it has with the proxy, 437 as described in Appendix A.4. 439 3. If secure group communication is used between the client and the 440 servers, the client processes the response, possibly as outcome 441 of step 2, as defined in [I-D.ietf-core-oscore-groupcomm]. 443 4. The client identifies the originator server, whose addressing 444 information is specified as value of the Response-Forwarding 445 Option. If the port number is omitted in the value of the 446 Response-Forwarding Option, the client MUST assume that the port 447 number where to send unicast requests to the server is the same 448 port number specified in the group URI of the original unicast 449 CoAP group request sent to the proxy (see Section 5.1). 451 In particular, the client is able to distinguish different responses 452 as originated by different servers. Optionally, the client may 453 contact one or more of those servers individually, i.e. directly 454 (bypassing the proxy) or indirectly (via a proxied CoAP unicast 455 request). 457 Upon the timeout expiration, i.e. T seconds after having sent the 458 original unicast request to the proxy, the client frees up its local 459 Token value associated to that request. Note that, upon this timeout 460 expiration, the Token value is not eligible for possible reuse yet 461 (see Section 5.1). Thus, until the actual amount of time before 462 enabling Token reusage has elapsed, following late responses to the 463 same request forwarded by the proxy will be discarded, as not 464 matching (by Token) any active request from the client. 466 When using CoAP Observe [RFC7641], the Token value is freed up only 467 if, after the timeout expiration, no 2.xx (Success) responses 468 matching the original unicast request and also including an Observe 469 option have been received. If at least one such response has been 470 received, the client continues receiving those notifications as 471 forwarded by the proxy, as long as the observation for the target 472 resource of the original unicast request is active. 474 6. Security Considerations 476 The security considerations from [RFC7252][I-D.ietf-core-groupcomm-bi 477 s][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this document. 479 Furthermore, the following additional considerations hold. 481 6.1. Client Authentication 483 As per the requirement REQ2 (see Section 4), the client has to 484 authenticate to the proxy when sending a group request to forward. 485 This leverages an established security association between the client 486 and the proxy, that the client uses to protect the group request, 487 before sending it to the proxy. 489 Note that, if the group request is (also) protected with Group 490 OSCORE, i.e. end-to-end between the client and the servers, the proxy 491 can authenticate the client by successfully verifying the 492 countersignature embedded in the group request. This requires that, 493 for each client to authenticate, the proxy stores the public key used 494 by that client in the OSCORE group. 496 Nevertheless, the client SHOULD still rely on a full-fledged, 497 pairwise secure association with the proxy. In addition to ensuring 498 the integrity of group requests sent to the proxy (see Section 6.2 499 and Section 6.3), this prevents the proxy from forwarding replayed 500 group requests with a valid countersignature, as injected by an 501 active, on-path adversary. 503 6.2. Multicast-Signaling Option 505 The Multicast-Signaling Option is of class U for OSCORE 506 [RFC8613][I-D.ietf-core-oscore-groupcomm]. This allows the proxy to 507 access the option value and retrieve the timeout value T', as well as 508 to remove the option altogether before forwarding the group request 509 to the servers. 511 The security association between the client and the proxy MUST 512 provide message integrity, so that further possible intermediaries as 513 well as on-path active adversaries are not able to remove the option 514 or alter its content, before the group request reaches the proxy. 515 Removing the option would otherwise result in the proxy not 516 forwarding the group request to the servers. Instead, altering the 517 option content would result in the proxy accepting and forwarding 518 back responses for an amount of time different than the one actually 519 indicated by the client. 521 The security association between the client and the proxy SHOULD also 522 provide message confidentiality. Otherwise, further intermediares as 523 well as on-path passive adversaries would be able to simply access 524 the option content, and thus learn for how long the client is willing 525 to receive responses from the servers in the group via the proxy. 526 This may in turn be used to perform a more efficient, selective 527 suppression of responses from the servers. 529 When the client (further) protects the unicast request sent to the 530 proxy with OSCORE (see Appendix A) and/or with DTLS, both message 531 integrity and message confidentiality are achieved in the leg between 532 the client and the proxy. 534 6.3. Response-Forwarding Option 536 The Response-Forwarding Option is of class E for OSCORE 537 [RFC8613][I-D.ietf-core-oscore-groupcomm], and thus can be protected 538 end-to-end between the client and the proxy, which includes the 539 option into a server response before forwarding it back to the 540 client. 542 Since the security association between the client and the proxy 543 provides message integrity, any further intermediaries or on-path 544 active adversaries are not able to undetectably remove the Response- 545 Forwarding Option from a forwarded server response. This ensures 546 that the client can correctly distinguish the different responses and 547 identify their corresponding originator server. 549 7. IANA Considerations 551 This document has the following actions for IANA. 553 7.1. CoAP Option Numbers Registry 555 IANA is asked to enter the following option numbers to the "CoAP 556 Option Numbers" registry defined in [RFC7252] within the "CoRE 557 Parameters" registry. 559 +--------+---------------------+-------------------+ 560 | Number | Name | Reference | 561 +--------+---------------------+-------------------+ 562 | TBD1 | Multicast-Signaling | [[this document]] | 563 +--------+---------------------+-------------------+ 564 | TBD2 | Response-Forwarding | [[this document]] | 565 +--------+---------------------+-------------------+ 567 8. References 569 8.1. Normative References 571 [I-D.ietf-core-groupcomm-bis] 572 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 573 for the Constrained Application Protocol (CoAP)", draft- 574 ietf-core-groupcomm-bis-00 (work in progress), March 2020. 576 [I-D.ietf-core-oscore-groupcomm] 577 Tiloca, M., Selander, G., Palombini, F., and J. Park, 578 "Group OSCORE - Secure Group Communication for CoAP", 579 draft-ietf-core-oscore-groupcomm-09 (work in progress), 580 June 2020. 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, 584 DOI 10.17487/RFC2119, March 1997, 585 . 587 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 588 Resource Identifier (URI): Generic Syntax", STD 66, 589 RFC 3986, DOI 10.17487/RFC3986, January 2005, 590 . 592 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 593 Application Protocol (CoAP)", RFC 7252, 594 DOI 10.17487/RFC7252, June 2014, 595 . 597 [RFC7641] Hartke, K., "Observing Resources in the Constrained 598 Application Protocol (CoAP)", RFC 7641, 599 DOI 10.17487/RFC7641, September 2015, 600 . 602 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 603 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 604 May 2017, . 606 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 607 "Object Security for Constrained RESTful Environments 608 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 609 . 611 8.2. Informative References 613 [I-D.bormann-coap-misc] 614 Bormann, C. and K. Hartke, "Miscellaneous additions to 615 CoAP", draft-bormann-coap-misc-27 (work in progress), 616 November 2014. 618 [I-D.ietf-ace-key-groupcomm-oscore] 619 Tiloca, M., Park, J., and F. Palombini, "Key Management 620 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 621 oscore-07 (work in progress), June 2020. 623 [I-D.ietf-tls-dtls13] 624 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 625 Datagram Transport Layer Security (DTLS) Protocol Version 626 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 627 2020. 629 [I-D.tiloca-core-oscore-discovery] 630 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 631 Groups with the CoRE Resource Directory", draft-tiloca- 632 core-oscore-discovery-05 (work in progress), March 2020. 634 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 635 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 636 January 2012, . 638 Appendix A. Using OSCORE Between Client and Proxy 640 This section describes how OSCORE is used to protect messages 641 exchanged by a client and a proxy, using their pairwise OSCORE 642 Security Context. 644 This is especially convenient for the communication scenario 645 addressed in this document, when the client already supports and uses 646 Group OSCORE [I-D.ietf-core-oscore-groupcomm], to protect messages 647 end-to-end with the servers. 649 A.1. Protecting the Request 651 Before sending the CoAP request to the proxy, the client protects it 652 using the pairwise OSCORE Security Context it has with the proxy. 654 The client processes the CoAP request as defined in [RFC8613], with 655 the following differences. 657 o The Proxy-Uri option, if present, is not decomposed and recomposed 658 as defined in Section 4.1.3.3 of [RFC8613]. 660 o The following options, if present, are processed as Class E. 662 * Proxy-Uri, Proxy-Scheme, Uri-Host and Uri-Port. 664 * OSCORE, which is present if Group OSCORE is used between the 665 client and the servers, to achieve end-to-end secure group 666 communication. 668 Furthermore, the Multicast-Signaling Option is processed as Class E. 670 As in [RFC8613], the resulting message includes an outer OSCORE 671 Option, which reflects the usage of the pairwise OSCORE Security 672 Context between the client and the proxy. 674 A.2. Verifying the Request 676 The proxy verifies the CoAP request as defined in [RFC8613]. 678 If secure group communication is also used between the client and the 679 servers, the resulting request to be forwarded to the servers is 680 protected with Group OSCORE [I-D.ietf-core-oscore-groupcomm], and it 681 includes a different OSCORE Option, which reflects the usage of the 682 group OSCORE Security Context between the client and the servers. 684 A.3. Protecting the Response 686 The proxy protects the CoAP response received from a server, using 687 the pairwise OSCORE Security Context it has with the client. 689 The proxy processes the CoAP response as defined in [RFC8613], with 690 the difference that the OSCORE Option, if present, is processed as 691 Class E. This is the case if Group OSCORE is used between the client 692 and the servers, to achieve end-to-end secure group communication. 694 As in [RFC8613], the resulting message to be forwarded back to the 695 client includes a different OSCORE Option, which reflects the usage 696 of the pairwise OSCORE Security Context between the client and the 697 proxy. 699 A.4. Verifying the Response 701 The client verifies the CoAP response received from the proxy as 702 defined in [RFC8613]. 704 If secure group communication is also used between the client and the 705 servers, the resulting response is protected with Group OSCORE 706 [I-D.ietf-core-oscore-groupcomm]. In particular, it includes a 707 different OSCORE Option, which reflects the usage of the group OSCORE 708 Security Context between the client and the servers. 710 Acknowledgments 712 The authors sincerely thank Christian Amsuess, Jim Schaad and Goeran 713 Selander for their comments and feedback. 715 The work on this document has been partly supported by VINNOVA and 716 the Celtic-Next project CRITISEC. 718 Authors' Addresses 720 Marco Tiloca 721 RISE AB 722 Isafjordsgatan 22 723 Kista SE-16440 Stockholm 724 Sweden 726 Email: marco.tiloca@ri.se 728 Esko Dijk 729 IoTconsultancy.nl 730 \________________\ 731 Utrecht 732 The Netherlands 734 Email: esko.dijk@iotconsultancy.nl