]> RISE AB

Isafjordsgatan 22 Kista 16440 Stockholm Sweden marco.tiloca@ri.se

RISE AB

Isafjordsgatan 22 Kista 16440 Stockholm Sweden rikard.hoglund@ri.se

Hollandstr. 12/4 Vienna 1020 Austria christian@amsuess.com

Ericsson AB

Torshamnsgatan 23 Kista 16440 Stockholm Sweden francesca.palombini@ericsson.com

WIT CoRE Working Group Internet-Draft The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. Instead of sending a distinct unicast notification to each different client, a server can alternatively send a single notification as a response message over multicast, to all the clients observing the same target resource. When doing so, the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to-end between the server and the observer clients. This document describes how multicast notifications can be used in network setups that leverage a proxy, e.g., in order to accommodate clients that are not able to directly listen to multicast traffic. The present version -00 refers to version -12 of draft-ietf-core-observe-multicast-notifications, which includes content about proxies that is also included in the present document. Such content will be removed from draft-ietf-core-observe-multicast-notifications in its next revision. Discussion Venues Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Constrained Application Protocol (CoAP) has been extended with a number of mechanisms, including resource Observation . This enables CoAP clients to register at a CoAP server as "observers" of a resource, and hence being automatically notified with an unsolicited response upon changes of the resource state. CoAP supports group communication , e.g., over IP multicast. This includes support for Observe registration requests over multicast, in order for clients to efficiently register as observers of a resource hosted at multiple servers. In a number of use cases, it is conversely desirable that a server sends observe notifications for the same target resource to multiple observers at once. In general, this is beneficial when several CoAP clients observe the same target resource at a CoAP server, and thus they could all be notified at once by means of a single response message. To this end, defines a method that a server can use to deliver observe notifications as CoAP responses addressed to multiple clients, e.g., over IP multicast. Also, it defines how to use the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) to protect multicast notifications end-to-end between the server and the observer clients. This document describes how the method specified in can be used in network setups that leverage a proxy, e.g., in order to accommodate clients that are not able to directly listen to multicast traffic.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with terms and concepts described in CoAP , group communication for CoAP , Observe , Concise Data Definition Language (CDDL) , Concise Binary Object Representation (CBOR) , Object Security for Constrained RESTful Environments (OSCORE) , Group OSCORE , and Constrained Resource Identifiers (CRIs) . Readers are also expected to be familiar with terms and concepts described in , particularly with the terms "traditional observation", "group observation", "phantom request", and "informative response".

High-Level Overview of Available Variants Building on what is specified in , this document considers network setups where proxies are deployed, which is expected in case (some of) the clients participating in the group observation are not capable to listen to multicast traffic. In such setups, a proxy directly receives multicast notifications from the server and relays them back to the clients. Therefore, with respect to , this document introduces additional variants to enforce a group observation. As a complement to , the rest of this section provides an overview of such additional variants, which differ as to whether exchanged messages are protected end-to-end between the observer clients and the server.

• Variant with proxy and without end-to-end security - Messages pertaining to the group observation are not protected end-to-end between the clients and the server. This basic case is defined in . An example is provided in .
• Variant with proxy and with end-to-end security - Messages pertaining to the group observation are protected end-to-end between the clients and the server, by using the security protocol Group OSCORE . In particular, the clients are required to separately provide the proxy with the obtained phantom request, thus enabling the proxy to receive the multicast notifications from the server. This case is defined in . An example is provided in . If the participating endpoints using Group OSCORE also support the concept of Deterministic Client , the same advantages mentioned in for the case without a proxy apply (see ). In addition, this allows for a more efficient setup and enforcement of the group observation, by reducing the amount of message exchanges and allowing the proxy to effectively serve protected multicast notifications from its cache. An example is provided in .

Setup with Proxies This section specifies how the approach presented in Sections and of works when a proxy is used between the clients and the server. In addition to what is specified in and , the following applies. A client sends its original observation request to the proxy. If the proxy is not already registered at the server for that target resource, the proxy forwards the observation request to the server, hence registering itself as an observer. If the server has an ongoing group observation for the target resource or decides to start one, the server considers the proxy as taking part in the group observation and replies to the proxy with an informative response. Upon receiving an informative response, the proxy performs as specified for the client in , with the peculiarity that "consuming" the last notification (if present) means populating its cache. In particular, by using the information retrieved from the informative response, the proxy configures an observation of the target resource at the origin server, acting as a client directly taking part in the group observation. As a consequence, the proxy listens to the IP multicast address and port number indicated by the server, i.e., per the CRI specified by a dedicated element of 'tpi_details' within the 'tp_info' parameter, in the informative response. In particular, when transporting CoAP over UDP, the CRI is conveyed by the element 'tpi_client' (see ). Furthermore, multicast notifications will match the phantom request stored at the proxy, based on the Token value specified by a dedicated element of 'tpi_details' within the 'tp_info' parameter, in the informative response. In particular, when transporting CoAP over UDP, the Token value is specified by the element 'tpi_token' (see ). Then, the proxy performs the following actions.

• If the 'last_notif' field is not present, the proxy responds to the client with an Empty Acknowledgement (if indicated by the message type, and if the proxy has not already done so).
• If the 'last_notif' field is present, the proxy rebuilds the latest multicast notification, as defined in . Then, the proxy responds to the client, by forwarding back the latest multicast notification.

When responding to an observation request from a client, the proxy also adds that client (and its Token) to the list of its registered observers for the target resource, next to the older observations. Upon receiving a multicast notification from the server, the proxy forwards it back separately to each observer client over unicast. Note that the notification forwarded back to a certain client has the same Token value of the original observation request sent by that client to the proxy. Note that the proxy configures the observation of the target resource at the server only once, when receiving the informative response associated with a (newly started) group observation for that target resource. After that, when receiving an observation request from a following new client to be added to the same group observation, the proxy does not take any further action with the server. Instead, the proxy responds to the client either with the latest multicast notification if available from its cache, or with an Empty Acknowledgement otherwise, as defined above. As a result, the observer counter at the server (see ) is not incremented when a new origin client behind the proxy registers as an observer at the proxy. Instead, the observer counter takes into account only the proxy, which has registered as observer at the server and has received the informative response from the server. An example is provided in . In the general case with a chain of two or more proxies, every proxy in the chain takes the role of client with the (next hop towards the) origin server. Note that the proxy adjacent to the origin server is the only one in the chain that receives informative responses and that listens to an IP multicast address and port number to receive notifications for the group observation. Furthermore, every proxy in the chain takes the role of server with the (previous hop towards the) origin client.

Setup with Proxies and with Group OSCORE As defined in , the security protocol Group OSCORE can be used to protect multicast notifications end-to-end between the origin server and the origin clients. Since the informative responses from the origin server are protected specifically end-to-end by using OSCORE or Group OSCORE, additional actions are required in the presence of a proxy. In fact, the proxy adjacent to the origin server is not able to access the encrypted payload of such informative responses. Hence, the proxy cannot retrieve the 'ph_req' and 'tp_info' parameters necessary to correctly receive multicast notifications and forward them back to the clients. Then, differently from what is defined in , each proxy receiving an informative response simply forwards it back to the client that has sent the corresponding observation request. Note that the proxy does not even realize that the message is an informative response, since the outer Code field is set to 2.05 (Content). Upon receiving the informative response, the client does not configure an observation of the target resource. Instead, the client performs a new observe registration request, by transmitting the re-built phantom request as intended to reach the proxy adjacent to the origin server. In particular, the client includes the new Listen-To-Multicast-Responses CoAP option defined in , to provide that proxy with the transport-specific information required for receiving multicast notifications for the group observation. As a result, the observer counter at the server (see ) is incremented when, after having received the original observation request from a new origin client, the origin server replies with the informative response. In particular, the observer counter at the server reliably takes into account the new, different origin clients behind the proxy, which the server distinguishes through their security identity specified by the pair (OSCORE Sender ID, OSCORE ID Context) in the OSCORE Option of their original observation request. Note that this does not hold anymore if the origin endpoints use phantom observation requests as deterministic requests (see ). Details on the additional message exchange and processing are defined in .

Listen-To-Multicast-Responses Option In order to allow the proxy to listen to the multicast notifications sent by the server, a new CoAP option is introduced. This option MUST be supported by clients interested to take part in group observations through intermediaries and by proxies that collect multicast notifications and forward them back to the observer clients. The option is called Listen-To-Multicast-Response, is intended only for requests, and has the properties summarized in , which extends Table 4 of . The option is critical and not Safe-to-Forward. Since the option is not Safe-to-Forward, the 'N' column indicates a dash for "not applicable". The Listen-To-Multicast-Responses Option. C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

No.	C	U	N	R	Name	Format	Length	Default
TBD47	x	x	-		Listen-To- Multicast-Responses	(*)	3-1024	(none)

Note to RFC Editor: In the table above, please replace TBD47 with the registered option number. Then, please delete this paragraph. The Listen-To-Multicast-Responses Option includes the byte serialization of a CBOR array. This specifies transport-specific message information that is required for listening to the multicast notifications of a group observation and is intended to the proxy adjacent to the origin server sending those notifications. In particular, the serialized CBOR array has the same format specified in for the 'tp_info' parameter of the informative response defined in . The Listen-To-Multicast-Responses Option is of class U for OSCORE .

Message Processing Compared to , the following additions apply when informative responses are protected end-to-end between the origin server and the origin clients. After the origin server sends an informative response, each proxy simply forwards it back to the (previous hop towards the) origin client that has sent the observation request. Once received the informative response, the origin client proceeds in a different way than in :

• The client performs all the additional decryption and verification steps of on the phantom request specified in the 'ph_req' parameter and on the last notification specified in the 'last_notif' parameter (if present).
• The client builds a ticket request (see ), as intended to reach the proxy adjacent to the origin server. The ticket request is formatted as follows.
  • The Token is chosen as the client sees fit. In fact, there is no reason for this Token to be the same as the phantom request's.
  • The outer Code field, the outer CoAP options, and the encrypted payload with AEAD tag (protecting the inner Code, the inner CoAP options, and the possible plain CoAP payload) concatenated with the signature are the same of the phantom request used for the group observation. That is, they are as specified in the 'ph_req' parameter of the received informative response.
  • An outer Observe Option is included and set to 0 (register). This will usually be set in the phantom request already.
  • The client includes: the outer option Proxy-Uri or Proxy-Cri ; or the outer options (Uri-Host, Uri-Port), together with the outer option Proxy-Scheme or Proxy-Scheme-Number . These options are set in order to specify the same request URI of the original registration request sent by the client.
  • The new option Listen-To-Multicast-Responses is included as an outer option. The value is set to the byte serialization of the CBOR array specified by the 'tp_info' parameter of the informative response. Note that, except for transport-specific information such as the Token and Message ID values, every different client participating in the same group observation (hence rebuilding the same phantom request) will build the same ticket request. Note also that, identically to the phantom request, the ticket request is still protected with Group OSCORE, i.e., it has the same OSCORE Option, encrypted payload, and signature.

Then, the client sends the ticket request to the next hop towards the origin server. Every proxy in the chain forwards the ticket request to the next hop towards the origin server, until the last proxy in the chain is reached. This last proxy, adjacent to the origin server, proceeds as follows.

• The proxy MUST NOT further forward the ticket request to the origin server.
• The proxy removes the option Proxy-Uri, or Proxy-Scheme, or Proxy-Cri, or Proxy-Scheme-Number from the ticket request.
• The proxy removes the Listen-To-Multicast-Responses Option from the ticket request and extracts the transport-specific information conveyed therein.
• The proxy rebuilds the phantom request associated with the group observation, by using the ticket request as directly providing the required transport-independent information. This includes the outer Code field, the outer CoAP options, and the encrypted payload with AEAD tag concatenated with the signature.
• The proxy configures an observation of the target resource at the origin server, acting as a client directly taking part in the group observation. To this end, the proxy uses the rebuilt phantom request and the transport-specific information retrieved from the Listen-To-Multicast-Responses Option. The particular way to achieve this is implementation specific.

After that, the proxy listens to the IP multicast address and port number indicated in the Listen-To-Multicast-Responses Option, i.e., per the CRI specified by a dedicated element of 'tpi_details' within the serialized CBOR array conveyed in the option. In particular, when transporting CoAP over UDP, the CRI is conveyed by the element 'tpi_client' (see ). Furthermore, multicast notifications will match the phantom request stored at the proxy, based on the Token value specified by a dedicated element of 'tpi_details' within the serialized CBOR array conveyed in the Listen-To-Multicast-Responses Option. In particular, when transporting CoAP over UDP, the Token value is specified by the element 'tpi_token' (see ). An example is provided in .

Impact from Proxies on Rough Counting of Clients in the Group Observation specifies how the approach presented in Sections and of works when a proxy is used between the origin clients and the origin server. That is, the clients register as observers at the proxy, which in turn registers as a participant to the group observation at the server, receives the multicast notifications from the server, and forwards those to the clients. With reference to the method defined in , this has an impact on the rough counting that the server performs to keep an estimate of still active and interested clients. In particular, the following applies.

• Since the Multicast-Response-Feedback-Divider Option defined in is not Safe-to-Forward, the proxy needs to recognize and understand the option in order to participate to the rough counting process. If the proxy receives a request that includes the Multicast-Response-Feedback-Divider Option but the proxy does not recognize and understand the option, then the proxy has to stop processing the request and sends a 4.02 (Bad Option) response to the observer client (see ). This results in the client terminating its observation at the proxy, after which the client stops receiving notifications for the group observation. If the proxy receives a multicast notification that includes the Multicast-Response-Feedback-Divider Option but the proxy does not recognize and understand the option, then the proxy has to stop processing the received multicast notification and sends a 5.02 (Bad Gateway) response to each of the observer clients (see ). This results in all the observer clients terminating their observation at the proxy, after which they stop receiving notifications for the group observation. Consequently, the proxy may decide to forget about its participation to the group observation at the server. This is not an issue if communications between the origin endpoints are protected end-to-end, i.e., both for the requests from the origin clients by using OSCORE or Group OSCORE, as well as for the multicast notifications from the origin server by using Group OSCORE (see and of this document). In fact, in such a case, the Multicast-Response-Feedback-Divider Option is protected end-to-end as well, and is thus hidden from the proxy. Therefore, if the server uses the rough counting process defined in but communications are not protected end-to-end between the origin endpoints, then it is practically required that the proxy recognizes and understands the Multicast-Response-Feedback-Divider Option. If that is not the case, then every execution of the rough counting process will effectively prevent the clients from receiving further notifications for the group observation, until they register again as observers at the proxy.
• The following holds when the proxy receives a multicast notification including the Multicast-Response-Feedback-Divider Option.
  • If the multicast notification is not protected end-to-end by using Group OSCORE (see ), then the Multicast-Response-Feedback-Divider Option is visible to the proxy. In this case, the proxy proceeds like defined in for an origin client, i.e., by answering to the server on its own in case it picks a random number I equal to 0. When doing so, the proxy will be counted by the server as a single client. Furthermore, the proxy MUST remove the option before forwarding the notification to (the previous hop towards) any of the origin clients. The proxy would have to rely on separate means for verifying whether the origin clients are still interested in the observation, e.g., by regularly forwarding notifications to the clients as unicast, Confirmable response messages. When no interested origin clients remain, the proxy can simply forget about being part of the group observation for the target resource at the server, like an origin client would do (see ).
  • If the multicast notification is protected end-to-end by using Group OSCORE (see and of this document), then the Multicast-Response-Feedback-Divider Option is protected end-to-end as well, and is thus hidden from the proxy. As a consequence, the proxy forwards the notification to (the previous hop towards) any of the origin clients, each of which answers to the server if it picks a random number I equal to 0.

Example with a Proxy This section provides an example when a proxy P is used between the clients and the server. The same assumptions and notation used in are used for this example. In addition, the proxy has address PRX_ADDR and listens to the port number PRX_PORT. Unless explicitly indicated, all messages transmitted on the wire are sent over unicast.

Example of Group Observation with a Proxy | | Token: 0x4a | GET | | | Observe: 0 (register) | | | | Proxy-Uri: "coap://sensor.example/r" | | | | | | +------->| Token: 0x5e | | | GET | Observe: 0 (register) | | | | Uri-Host: "sensor.example" | | | | Uri-Path: "r" | | | | | | | | (S allocates the available Token value 0x7b) | | | | | | | | (S sends to itself a phantom observation | | | | request PH_REQ as coming from the | | | | IP multicast address GRP_ADDR) | | | | | | | .-----+ | | | / | | | | \ | | | | `---->| Token: 0x7b | | | GET | Observe: 0 (register) | | | | Uri-Host: "sensor.example" | | | | Uri-Path: "r" | | | | | | | | (S creates a group observation of /r) | | | | | | | | (S increments the observer counter | | | | for the group observation of /r) | | | | | | | | | | | | | | |<-------+ Token: 0x5e | | | 5.03 | Content-Format: application/ | | | | informative-response+cbor | | | | Max-Age: 0 | | | | | | | | Payload: { | | | | / tp_info / 0 : [ | | | | cri'coap://SRV_ADDR:SRV_PORT/', | | | | cri'coap://GRP_ADDR:GRP_PORT/', | | | | 0x7b], | | | | / last_notif / 2 : bstr(0x45 | OPT | 0xff | | | | | PAYLOAD) | | | | } | | | | | | | | (PAYLOAD in 'last_notif' : "1234") | | | | | | | | | | | | (The proxy starts listening to the | | | | GRP_ADDR address and the GRP_PORT port.) | | | | | | | | (The proxy adds C1 to its list of observers.) | | | | |<------------+ | Token: 0x4a | 2.05 | | | Observe: 54120 | | | | | | | | Payload: "1234" | | | | ... ... ... ... | | | | | +----->| | Token: 0x01 | | GET | | Observe: 0 (register) | | | | Proxy-Uri: "coap://sensor.example/r" | | | | | | | | (The proxy has a fresh cache representation) | | | | | |<-----+ | Token: 0x01 | | 2.05 | | Observe: 54120 | | | | | | | | Payload: "1234" | | | | ... ... ... ... | | | | | | | | (The value of the resource | | | | /r changes to "5678".) | | | | | | | (#) | | | |<-------+ Token: 0x7b | | | 2.05 | Observe: 11 | | | | | | | | Payload: "5678" | | | | |<------------+ | Token: 0x4a | 2.05 | | | Observe: 54123 | | | | | | | | Payload: "5678" | | | | | |<-----+ | Token: 0x01 | | 2.05 | | Observe: 54123 | | | | | | | | Payload: "5678" | | | | (#) Sent over IP multicast to GROUP_ADDR:GROUP_PORT. ]]>

Note that the proxy has all the information to understand the observation request from C2 and can immediately start to serve the still fresh values. This behavior is mandated by , i.e., the proxy registers itself only once with the next hop and fans out the notifications it receives to all the registered clients.

Example with a Proxy and with Group OSCORE This section provides an example when a proxy P is used between the clients and the server, and Group OSCORE is used to protect multicast notifications end-to-end between the server and the clients. The same assumptions and notation used in are used for this example. In addition, the proxy has address PRX_ADDR and listens to the port number PRX_PORT. Unless explicitly indicated, all messages transmitted on the wire are sent over unicast and protected with OSCORE end-to-end between a client and the server.

Example of Group Observation with a Proxy and Group OSCORE | | Token: 0x4a | FETCH | | | Observe: 0 (register) | | | | OSCORE: {kid: 0x01; piv: 101; ...} | | | | Uri-Host: "sensor.example" | | | | Proxy-Scheme: "coap" | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x01 (GET), | | | | Observe: 0 (register), | | | | Uri-Path: "r", | | | | | | | | } | | | | | | +-------->| Token: 0x5e | | | FETCH | Observe: 0 (register) | | | | OSCORE: {kid: 0x01; piv: 101; ...} | | | | Uri-Host: "sensor.example" | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x01 (GET), | | | | Observe: 0 (register), | | | | Uri-Path: "r", | | | | | | | | } | | | | | | | | | | | | (S allocates the available | | | | Token value 0x7b .) | | | | | | | | (S sends to itself a phantom observation | | | | request PH_REQ as coming from the | | | | IP multicast address GRP_ADDR) | | | (#) | | | | .------+ | | | / | | | | \ | | | | `----->| Token: 0x7b | | | FETCH | Observe: 0 (register) | | | | OSCORE: {kid: 0x05; piv: 501; | | | | kid context: 0x57ab2e; ...} | | | | Uri-Host: "sensor.example" | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x01 (GET), | | | | Observe: 0 (register), | | | | Uri-Path: "r", | | | | | | | | } | | | | | | | | | | | | (S steps SN_5 in the Group OSCORE | | | | Security Context : SN_5 <-- 502) | | | | | | | | (S creates a group observation of /r) | | | | | | | | | | | | (S increments the observer counter | | | | for the group observation of /r) | | | | | | |<--------+ Token: 0x5e | | | 2.05 | OSCORE: {piv: 301; ...} | | | | Max-Age: 0 | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 5.03 (Service Unavailable), | | | | Content-Format: application/ | | | | informative-response+cbor, | | | | , | | | | 0xff, | | | | Payload { | | | | / tp_info / 0 : [ | | | | cri'coap://SRV_ADDR:SRV_PORT/', | | | | cri'coap://GRP_ADDR:GRP_PORT/', | | | | 0x7b], | | | | / ph_req / 1 : bstr(0x05 | | | | | OPT | 0xff | | | | | PAYLOAD | SIGN), | | | | / last_notif / 2 : bstr(0x45 | | | | | OPT | 0xff | | | | | PAYLOAD | SIGN), | | | | / join_uri / 4 : "coap://myGM/ | | | | ace-group/myGroup", | | | | / sec_gp / 5 : "myGroup" | | | | } | | | | } | | | | |<--------------+ | Token: 0x4a | 2.05 | | | OSCORE: {piv: 301; ...} | | | | | | | | 0xff | | | | (Same Encrypted_payload) | | | | | (#) | | | +-------------->| | Token: 0x4b | FETCH | | | Observe: 0 (register) | | | | OSCORE: {kid: 0x05 ; piv: 501; | | | | kid context: 0x57ab2e; ...} | | | | Uri-Host: "sensor.example" | | | | Proxy-Scheme: "coap" | | | | Listen-To-Multicast-Responses: { | | | | [cri'coap://SRV_ADDR:SRV_PORT/', | | | | cri'coap://GRP_ADDR:GRP_PORT/', | | | | 0x7b] | | | | } | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x01 (GET), | | | | Observe: 0 (register), | | | | Uri-Path: "r", | | | | | | | | } | | | | | | | | | | | | (The proxy starts listening to the | | | | GRP_ADDR address and the GRP_PORT port.) | | | | | | | | (The proxy adds C1 to | | | | its list of observers.) | | | | |<--------------+ | | | ACK | | ... ... ... ... | | | | | +------>| | Token: 0x01 | | FETCH | | Observe: 0 (register) | | | | OSCORE: {kid: 0x02; piv: 201; ...} | | | | Uri-Host: "sensor.example" | | | | Proxy-Scheme: "coap" | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x01 (GET), | | | | Observe: 0 (register), | | | | Uri-Path: "r", | | | | | | | | } | | | | | | +-------->| Token: 0x5f | | | FETCH | Observe: 0 (register) | | | | OSCORE: {kid: 0x02; piv: 201; ...} | | | | Uri-Host: "sensor.example" | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x01 (GET), | | | | Observe: 0 (register), | | | | Uri-Path: "r", | | | | | | | | } | | | | | | | | (S increments the observer counter | | | | for the group observation of /r) | | | | | | |<--------+ Token: 0x5f | | | 2.05 | OSCORE: {piv: 401; ...} | | | | Max-Age: 0 | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 5.03 (Service Unavailable), | | | | Content-Format: application/ | | | | informative-response+cbor, | | | | , | | | | 0xff, | | | | Payload { | | | | / tp_info / 0 : [ | | | | cri'coap://SRV_ADDR:SRV_PORT/', | | | | cri'coap://GRP_ADDR:GRP_PORT/', | | | | 0x7b], | | | | / ph_req / 1 : bstr(0x05 | | | | | OPT | 0xff | | | | | PAYLOAD | SIGN), | | | | / last_notif / 2 : bstr(0x45 | | | | | OPT | 0xff | | | | | PAYLOAD | SIGN), | | | | / join_uri / 4 : "coap://myGM/ | | | | ace-group/myGroup", | | | | / sec_gp / 5 : "myGroup" | | | | } | | | | } | | | | | |<------+ | Token: 0x01 | | 2.05 | | OSCORE: {piv: 401; ...} | | | | | | | | 0xff | | | | (Same Encrypted_payload) | | (#) | | | +------>| | Token: 0x02 | | FETCH | | Observe: 0 (register) | | | | OSCORE: {kid: 0x05; piv: 501; | | | | kid context: 57ab2e; ...} | | | | Uri-Host: "sensor.example" | | | | Proxy-Scheme: "coap" | | | | Listen-To-Multicast-Responses: { | | | | [cri'coap://SRV_ADDR:SRV_PORT/', | | | | cri'coap://GRP_ADDR:GRP_PORT/', | | | | 0x7b] | | | | } | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x01 (GET), | | | | Observe: 0 (register), | | | | Uri-Path: "r", | | | | | | | | } | | | | | | | | | | | | (The proxy adds C2 to | | | | its list of observers.) | |<------+ | | | ACK | | | | | | ... ... ... ... | | | | | | | | (The value of the resource | | | | /r changes to "5678".) | | | | | | | (##) | | | |<--------+ Token: 0x7b | | | 2.05 | Observe: 11 | | | | OSCORE: {kid: 0x05; piv: 502; ...} | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 2.05 (Content), | | | | Observe: [empty], | | | | , | | | | 0xff, | | | | Payload: "5678" | | | | } | | | | | (#) | | | |<--------------+ | Token: 0x4b | 2.05 | | | Observe: 54123 | | | | OSCORE: {kid: 0x05; piv: 502; ...} | | | | | | | | 0xff | | | | (Same Encrypted_payload and Signature) | | (#) | | | |<------+ | Token: 0x02 | | 2.05 | | Observe: 54123 | | | | OSCORE: {kid: 0x05; piv: 502; ...} | | | | | | | | 0xff | | | | (Same Encrypted_payload and signature) | | | | (#) Sent over unicast, and protected with Group OSCORE end-to-end between the server and the clients. (##) Sent over IP multicast to GROUP_ADDR:GROUP_PORT, and protected with Group OSCORE end-to-end between the server and the clients. ]]>

Unlike in the unprotected example in , the proxy does not have all the information to perform request deduplication and can only recognize the identical request once the client sends the ticket request.

Example with a Proxy and with Deterministic Requests This section provides an example when a proxy P is used between the clients and the server, and Group OSCORE is used to protect multicast notifications end-to-end between the server and the clients. In addition, the phantom request is especially a deterministic request (see ), which is protected with the pairwise mode of Group OSCORE as defined in . Since the server replies to such a deterministic request with an informative response that is not protected (see ), the proxy is able to retrieve from the informative response everything needed to set itself as an observer in the group observation and to start listening to multicast notifications. In particular, each client sends the deterministic request to the proxy as a ticket request (see ). However, differently from what is defined in where the ticket request is not a deterministic request, the clients do not include a Listen-to-Multicast-Responses Option. This results in the proxy forwarding the ticket request (i.e., the phantom observation request) to the server and obtaining the information required to listen to multicast notifications, unless the proxy has already set itself to do so. Also, the proxy will be able to serve multicast notifications from its cache as per . discusses how, when using a deterministic request as a phantom observation request, the observer counter at the server (see ) is not reliably incremented when new clients start participating in the group observation. The same applies also if a proxy is deployed. That is, the origin server increments its observer counter after having sent the informative response to the proxy, as a reply to the deterministic request forwarded to the origin server on behalf of the first origin client that contacted the proxy. After that, the same deterministic request sent by any origin client will not be forwarded to the origin server, but will instead produce a cache hit at the proxy that will serve the client accordingly. Hence, the observer counter at the server is not further incremented as additional, new origin clients start participating in the group observation through the proxy. Also in this case, the security identity associated with the sender of any deterministic request in the OSCORE group is exactly the same one, i.e., the pair (SID, OSCORE ID Context), where SID is the OSCORE Sender ID of the Deterministic Client in the OSCORE group, which all the clients in the group rely on to produce deterministic requests.

Assumptions and Walkthrough The example provided in this appendix as reflected by the message exchange shown in assumes the following.

1. The OSCORE group supports deterministic requests. Thus, the server creates the phantom request as a deterministic request , stores it locally as one of its issued phantom requests, and starts the group observation.
2. The server makes the phantom request available through other means, e.g., a pub-sub broker, together with the transport-specific information for listening to multicast notifications bound to the phantom request (see ).
3. Since the phantom request is a deterministic request, the server can more efficiently make it available in its smaller, plain version. The clients can obtain it from the particular alternative source and protect it as per , thus all computing the same deterministic request to be used as phantom observation request.
4. If the client does not rely on a proxy between itself and the server, it simply sets the group observation and starts listening to multicast notifications. Building on Step 2 above, the same would happen if the phantom request was not specifically a deterministic request.
5. If the client relies on a proxy between itself and the server, it uses the phantom request as a ticket request (see ). However, unlike the case considered in where the ticket request is not a deterministic request, the client does not include a Listen-to-Multicast-Responses Option in the phantom request sent to the proxy.
6. Unlike for the case considered in , here the proxy does not know that the request is exactly a ticket request for subscribing to multicast notifications. Thus, the proxy simply forwards the ticket request to the server like it normally would.
7. The server receives the ticket request, which is a deviation from the case where the ticket request is not a deterministic request and stops at the proxy (see ). Then, the server recognizes the phantom request among the stored ones, through a byte-by-byte comparison of the incoming message minus the transport-related fields (see ). Consequently, the server does not perform any Group OSCORE processing on it.
8. The server replies with an unprotected informative response (see ), including: the transport-specific information, (optionally) the phantom request, and (optionally) the latest notification. Note that the phantom request can be omitted, since it is the deterministic phantom request from the client, and thus "in terms of transport-independent information, identical to the registration request from the client" (see ).
9. From the received informative response, the proxy retrieves everything needed to set itself as an observer in the group observation and it starts listening to multicast notifications. If the informative response includes a latest notification, the proxy caches it and forwards it back to the client. Otherwise, the proxy replies with an empty ACK (if it has not done it already and the request from the client was Confirmable).
10. Like in the case with a non-deterministic phantom request considered in , the proxy fans out the multicast notifications to the origin clients as they come. Also, as new clients following the first one contact the proxy, the latter does not have to contact the server again as in , since the deterministic phantom request would produce a cache hit as per . Thus, the proxy can serve such clients with the latest fresh multicast notification from its cache.

Message Exchange The same assumptions and notation used in are used for this example. As a recap of some specific values:

• Two clients C1 and C2 register to observe a resource /r at a server S, which has address SRV_ADDR and listens to the port number SRV_PORT. Before the following exchanges occur, no clients are observing the resource /r , which has value "1234".
• The server S sends multicast notifications to the IP multicast address GRP_ADDR and port number GRP_PORT, and starts the group observation already after creating the deterministic phantom request to early disseminate.
• S is a member of the OSCORE group with 'kid context' = 0x57ab2e as Group ID. In the OSCORE group, S has 'kid' = 0x05 as Sender ID and SN_5 = 501 as Sender Sequence Number.

In addition:

• The proxy has address PRX_ADDR and listens to the port number PRX_PORT.
• The deterministic client in the OSCORE group has 'kid' = 0x09.

Unless explicitly indicated, all messages transmitted on the wire are sent over unicast and protected with Group OSCORE end-to-end between a client and the server.

Example of Group Observation with a Proxy and Group OSCORE, where the Phantom Request is a Deterministic Request | Token: 0x7b | | | FETCH | Uri-Host: "sensor.example" | | | | Observe: 0 (register) | | | | OSCORE: {kid: 0x09 ; piv: 0 ; | | | | kid context: 0x57ab2e ; ... } | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x01 (GET), | | | | Observe: 0 (register), | | | | Uri-Path: "r", | | | | | | | | } | | | | | | | | (S creates a group observation of /r) | | | | | | | | (The server does not respond to PH_REQ. | | | | The server stores PH_REQ locally and | | | | makes it available at an external source) | | | | | | | | | | | | (C1 obtains PH_REQ and sends it to P) | | | | | | | | +-------------->| | Token: 0x4a | FETCH | | | Uri-Host: "sensor.example" | | | | Observe: 0 (register) | | | | OSCORE: {kid: 0x09 ; piv: 0 ; | | | | kid context: 0x57ab2e ; ... } | | | | Proxy-Scheme: "coap" | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x01 (GET), | | | | Observe: 0 (register), | | | | Uri-Path: "r", | | | | | | | | } | | | | | | +-------->| Token: 0x5e | | | FETCH | Uri-Host: "sensor.example" | | | | Observe: 0 (register) | | | | OSCORE: {kid: 0x09 ; piv: 0 ; | | | | kid context: 0x57ab2e ; ... } | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x01 (GET), | | | | Observe: 0 (register), | | | | Uri-Path: "r", | | | | | | | | } | | | | | | | | (S recognizes PH_REQ through byte-by-byte | | | | comparison against the stored one, and | | | | skips any Group OSCORE processing) | | | | | | | | (S prepares the "last notification" | | | | response defined below) | | | | | | | | 0x45 (2.05 Content) | | | | Observe: 10 | | | | OSCORE: {kid: 0x05 ; piv: 501 ; ...} | | | | Max-Age: 3000 | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x45 (2.05 Content), | | | | Observe: [empty], | | | | Payload: "1234" | | | | } | | | | | | | | | | | | (S increments the observer counter | | | | for the group observation of /r) | | | | | | | | (S responds to the proxy with an | | | | unprotected informative response) | | | (#) | | | |<--------+ Token: 0x5e | | | 5.03 | Content-Format: application/ | | | | informative-response+cbor | | | | Max-Age: 0 | | | | 0xff | | | | Payload { | | | | / tp_info / 0 : [ | | | | cri'coap://SRV_ADDR:SRV_PORT/', | | | | cri'coap://GRP_ADDR:GRP_PORT/', | | | | 0x7b], | | | | / last_notif / 2 : | | | | } | | | | | | | | (P extracts PH_REQ and starts listening | | | | to multicast notifications with Token | | | | 0x7b at GRP_ADDR:GRP_PORT) | | | | | | | | (P extracts the "last notification" | | | | response, caches it and forwards | | | | it back to C1) | | | | |<--------------+ | Token: 0x4a | 2.05 | | | Observe: 54120 | | | | OSCORE: {kid: 0x05 ; piv: 501 ; ...} | | | | Max-Age: 2995 | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x45 (2.05 Content), | | | | Observe: [empty], | | | | Payload: "1234" | | | | } | | | | | | | | ... ... ... ... | | | | | | | | (C2 obtains PH_REQ and sends it to P) | | | | | +------>| | Token: 0x01 | | FETCH | | Uri-Host: "sensor.example" | | | | Observe: 0 (register) | | | | OSCORE: {kid: 0x09 ; piv: 0 ; | | | | kid context: 0x57ab2e; ...} | | | | Proxy-Scheme: "coap" | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x01 (GET), | | | | Observe: 0 (register), | | | | Uri-Path: "r", | | | | | | | | } | | | | | | | | (P serves C2 from it cache) | | | | | |<------+ | Token: 0x01 | | 2.05 | | Observe: 54120 | | | | OSCORE: {kid: 0x05 ; piv: 501 ; ...} | | | | Max-Age: 1800 | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x45 (2.05 Content), | | | | Observe: [empty], | | | | Payload: "1234" | | | | } | | | | | | | | ... ... ... ... | | | | | | | | (The value of the resource | | | | /r changes to "5678".) | | | | | | | (##) | | | |<--------+ Token: 0x7b | | | 2.05 | Observe: 11 | | | | OSCORE: {kid: 0x05; piv: 502 ; ...} | | | | | | | | 0xff | | | | Encrypted_payload { | | | | 0x45 (2.05 Content), | | | | Observe: [empty], | | | | , | | | | 0xff, | | | | Payload: "5678" | | | | } | | | | | | | | | | | | (P updates its cache entry | | | | with this notification) | | | | |<--------------+ | Token: 0x4a | 2.05 | | | Observe: 54123 | | | | OSCORE: {kid: 0x05; piv: 502 ; ...} | | | | | | | | 0xff | | | | (Same Encrypted_payload and signature) | | | | | |<------+ | Token: 0x01 | | 2.05 | | Observe: 54123 | | | | OSCORE: {kid: 0x05; piv: 502 ; ...} | | | | | | | | 0xff | | | | (Same Encrypted_payload and signature) | | | | (#) Sent over unicast and unprotected. (##) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected with Group OSCORE end-to-end between the server and the clients. ]]>

Example with a Reverse-Proxy and with Deterministic Requests This section describes an example where specifically a reverse-proxy PRX is used between the clients and the server (see ). Like for the example in , the phantom request is especially a deterministic request (see ), which is protected with the pairwise mode of Group OSCORE as defined in . The same assumptions compiled in apply in this scenario too, with the following differences:

• Assumption (2): when the server makes the phantom request available through other means (see ), the accompanying group observation data does not specify client-side, transport-specific information for listening to multicast notifications bound to the phantom request.
• Assumption (4): this assumption does not apply, since all the clients rely on PRX, although they are not aware to communicate with a proxy.

Furthermore, the following assumptions apply to this scenario:

• The server knows the address PRX_ADDR and port number PRX_PORT that PRX exposes to the clients when acting as stand-in for the server. That is, a request sent with destination address PRX_ADDR and port number PRX_PORT will reach PRX, which forwards the request to the server.
• When the server makes the phantom request available through other means (see ), the accompanying group observation data is such that:
  • It provides server-side, transport-specific information, which consists of the address PRX_ADDR and port number PRX_PORT associated with PRX.
  • It does not provide any further client-side, transport-specific information.
  Assuming that the group information data has a format consistent with the 'tp_info' array of the informative response (see ), this means that the 'tp_info' array includes only the 'tpi_server' element specifying a CRI with addressing information PRX_ADDR and PRX_PORT (i.e., targeting PRX). That is, 'tp_info' does not include the 'tpi_details' element, regardless of what is expected per the transport used.

Taking Part in Group Observations The rest of this section describes how a client can take part in a group observation. If any of the following conditions does not hold, then the client first performs the initialization procedure described in .

• The client has already obtained the group observation data specifying the deterministic phantom request, which the server has made available through other means (see ).
• The client is already a member of the correct OSCORE group.

The main process consists of the following steps.

1. From the group observation data, the client knows the deterministic phantom request PH_REQ, the address PRX_ADDR, and the port number PRX_PORT, but no other client-side, transport-specific information. In such a particular situation, the client sends PH_REQ with destination address PRX_ADDR and port number PRX_PORT, i.e., to PRX.
2. Upon receiving PH_REQ, PRX performs the same actions performed by the proxy in the scenario of . That is, if PH_REQ results in a cache hit at PRX, then PRX replies to the client with the latest multicast notification for the target resource from its cache and takes no further actions. Otherwise, PRX forwards PH_REQ to the server. After recognizing PH_REQ byte-by-byte, the server replies to PRX with an unprotected informative response, where 'tp_info' specifies the information to receive multicast notifications for the target resource. Based on such information, PRX starts listening to multicast notifications. If the informative response includes a latest notification, then PRX caches that notification and forwards it to the client.

Editor's note: add a figure showing an example of message exchange.

Client Initialization Procedure The following early initialization procedure is performed by a client that does not have the group observation data and/or is not a member of the correct OSCORE group, before starting the main process described in . The client is minimally provided with the pair (PRX_ADDR, PRX_PORT) associated with PRX, which the client believes to be targeting the origin server. a. The client sends a traditional Observe registration request with destination address PRX_ADDR and port number PRX_PORT, i.e., to PRX. The request is protected with (Group) OSCORE, i.e., end-to-end between the client and the server. b. PRX receives the request and forwards it to the server, as usual. c. The server replies with a 5.03 (Service Unavailable) informative response. The response is protected with (Group) OSCORE, i.e., end-to-end between the client and the server. The payload of the response specifies the following parameters:

• The 'tp_info' parameter, within which the 'tpi_server' element is a CRI with addressing information PRX_ADDR and PRX_PORT (i.e., targeting PRX). The 'tp_info' parameter does not include the 'tpi_details' element, regardless of what is expected per the transport used.
• The 'ph_req' parameter, conveying the deterministic phantom request PH_REQ.
• Optionally, parameters conveying information that the client can use for joining the OSCORE group if that has not happened yet, or the keying material used in the OSCORE group if the server is managing it (see ).

d. PRX receives the protected informative response and forwards it to the client, as usual. e. Upon receiving the protected informative response, the client takes its payload as the group observation data for the group observation of interest. Per the instructions specified in the response, the client takes the necessary steps to join the correct OSCORE group, in case it is not already a member.

Security Considerations In addition to the security considerations from , the following considerations hold for this document.

Listen-To-Multicast-Responses Option The CoAP option Listen-To-Multicast-Responses defined in is of class U for OSCORE and Group OSCORE . This allows the proxy adjacent to the origin server to access the option value conveyed in a ticket request (see ) and to retrieve from it the transport-specific information about a phantom request. By doing so, the proxy becomes able to configure an observation of the target resource and to receive multicast notifications that match the phantom request. Any proxy in the chain, as well as further possible intermediaries or on-path active adversaries, are thus able to remove the option or alter its content, before the ticket request reaches the proxy adjacent to the origin server. Removing the option would result in the proxy adjacent to the origin server to not configure the group observation, if that has not happened yet. In such a case, the proxy would not receive the corresponding multicast notifications to be forwarded back to the clients. Altering the option content would result in the proxy adjacent to the origin server to incorrectly configure a group observation (e.g., as based on a wrong multicast IP address) hence preventing the correct reception of multicast notifications and their forwarding to the clients; or to configure bogus group observations that are currently not active on the origin server. In order to prevent what is described above, the ticket requests conveying the Listen-To-Multicast-Responses Option can be additionally protected hop-by-hop, e.g., by using OSCORE (see ) and/or DTLS .

IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

CoAP Option Numbers Registry IANA is asked to enter the following option number to the "CoAP Option Numbers" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. Registrations in the CoAP Option Numbers Registry

Number	Name	Reference
TBD47	Listen-To-Multicast-Responses	[RFC-XXXX]

For the Listen-To-Multicast-Responses Option, the preferred value range is 0-255. In particular, 47 is the preferred option number. Note to RFC Editor: In the table above, please replace TBD47 with the registered option number. Then, please delete this paragraph and the previous paragraph.

References Normative References IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 by adding a column on the "URI Schemes" registry as well as a note on how that registry cooperates with the "CRI Scheme Numbers for Certain Unregistered Scheme Names" registry created by the present RFC. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision -26 is taking on the results from the 2025-10-09 // IESG telechat (issue #140), by integrating the CRI scheme number // column into the URI scheme registry created by RFC 7595 and // keeping the URI-Scheme registration process essentially unchanged // from the point of view of a registrant that does not have any // special requirements on the CRI scheme number assigned. Also, the // cri'' application-extension syntax has been moved to draft-ietf- // cbor-edn-literals, which is currently lagging behind in the // approval process. RISE AB RISE AB Ericsson AB The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing a same target resource. This document updates RFC7252 and RFC7641, and defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end between the server and the observer clients. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References RISE AB Group communication with the Constrained Application Protocol (CoAP) can be secured end-to-end using Group Object Security for Constrained RESTful Environments (Group OSCORE), also across untrusted intermediary proxies. However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This specification restores cacheability of protected responses at proxies, by introducing consensus requests which any client in a group can send to one server or multiple servers in the same group. RISE AB RISE AB Object Security for Constrained RESTful Environments (OSCORE) can be used to protect CoAP messages end-to-end between two endpoints at the application layer, also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines rules to escalate the protection of a CoAP option, in order to encrypt and integrity-protect it whenever possible. Finally, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints; and between an application endpoint and an intermediary or between two intermediaries. Therefore, this document updates RFC 8613. Furthermore, this document updates RFC 8768, by explicitly defining the processing with OSCORE for the CoAP option Hop-Limit. The approach defined in this document can be seamlessly used with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347.

Document Updates

Version -00

• Imported content about proxies from draft-ietf-core-observe-multicast-notifications-12.

Acknowledgments The authors sincerely thank , , , , , , , and for their comments and feedback. The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).