CoRE Working Group M. Tiloca Internet-Draft R. Hoeglund Updates: 7252, 7390, 7641 (if approved) RISE AB Intended status: Standards Track C. Amsuess Expires: May 7, 2020 F. Palombini Ericsson AB November 04, 2019 Observe Notifications as CoAP Multicast Responses draft-tiloca-core-observe-multicast-notifications-01 Abstract 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 to all the clients observing a same target resource. This document defines how a CoAP server sends observe notifications as response messages over multicast, by 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 from the CoAP server to the multiple observer clients. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 7, 2020. Tiloca, et al. Expires May 7, 2020 [Page 1] Internet-Draft Observe Multicast Notifications November 2019 Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 4 3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 6 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Protection of Multicast Notifications with Group OSCORE . . . 9 5.1. OSCORE Group in Informative Response . . . . . . . . . . 9 5.2. Server-Side Requirements . . . . . . . . . . . . . . . . 11 5.3. Client-Side Requirements . . . . . . . . . . . . . . . . 12 6. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction The Constrained Application Protocol (CoAP) [RFC7252] has been extended with a number of mechanisms, including resource Observation [RFC7641]. 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 over IP multicast [RFC7390], and [I-D.dijk-core-groupcomm-bis] has been enabling Observe registration requests over multicast, in order for clients to efficiently register as observers of a resource hosted at multiple servers. Tiloca, et al. Expires May 7, 2020 [Page 2] Internet-Draft Observe Multicast Notifications November 2019 However, in a number of use cases, using multicast messages for responses would also be desirable. That is, it would be useful that a server sends observe notifications for a same target resource to multiple observers as responses over IP multicast. For instance, in CoAP publish-subscribe [I-D.ietf-core-coap-pubsub], multiple clients can subscribe to a topic, by observing the related resource hosted at the responsible broker. When a new value is published on that topic, it would be convenient for the broker to send a single multicast notification at once, to all the subscriber clients observing that topic. A different use case concerns clients observing a same registration resource at the CoRE Resource Directory [I-D.ietf-core-resource-directory]. For example, multiple clients can benefit of observation for discovering (to-be-created) OSCORE groups [I-D.ietf-core-oscore-groupcomm], by retrieving from the Resource Directory updated links and descriptions to join them through the respective Group Manager [I-D.tiloca-core-oscore-discovery]. More in general, multicast notifications would be beneficial whenever several CoAP clients observe a same target resource at a CoAP server, and can be all notified at once by means of a single response message. However, CoAP does not currently define response messages over IP multicast. This specification fills this gap and provides the following twofold contribution. First, it defines a method to deliver Observe notifications as CoAP responses over IP multicast. In the proposed method, the group of potential observers entrusts the server to manage the Token space for multicast notifications. By doing so, the server provides all the observers of a target resource with the same Token value to bind to their own observation. That Token value is then used in every multicast notification for that target resource. This is achieved by means of an informative unicast response sent by the server to each observer client. Second, this specification defines how to use Group OSCORE [I-D.ietf-core-oscore-groupcomm] to protect multicast notifications end-to-end between the server and the observer clients. This is also achieved by means of the informative unicast response mentioned above, which additionally includes parameter values used by the server to secure every multicast notification for the target resource by using Group OSCORE. This provides a secure binding between each of such notifications and the observation of each of the clients. Tiloca, et al. Expires May 7, 2020 [Page 3] Internet-Draft Observe Multicast Notifications November 2019 1.1. 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 [RFC2119] [RFC8174] 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 [RFC7252], group communication for CoAP [RFC7390][I-D.dijk-core-groupcomm-bis], Observe [RFC7641], CBOR [RFC7049], OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. This specification additionally defines the following terminology. o Traditional observation. A resource observation associated to a single observer client, as defined in [RFC7641]. o Group observation. A resource observation associated to a group of clients. The server sends notifications for the group-observed resource over IP multicast to all the observer clients. o Phantom request. The CoAP request message that the server would have received to generate a group observation on one of its resources. The phantom request is generated inside the server and does not hit the wire. o Informative response. A CoAP response message that the server sends to a given client via unicast, providing the client with information on a group observation. 2. Server-Side Requirements The server can, at any time, start a group observation on one of its resources. Practically, the server may want to do that under the following circumstances. o In the absence of observations for the target resource, the server receives a registration request from a first client wishing to start a traditional observation on that resource. o When a certain amount of traditional observations has been established on the target resource, the server decides to make those clients part of a group observation on that resource. Tiloca, et al. Expires May 7, 2020 [Page 4] Internet-Draft Observe Multicast Notifications November 2019 When it wants to start a group observation on one of its resources, and assuming it knows the multicast IP address to use to send multicast notifications to, the server proceeds as follows. 1. The server builds a phantom observation request, i.e. a GET request with an Observe option set to 0 (register). 2. The server selects a currently available value T, from the token space used for messages from the chosen multicast IP address to the server address intended for accessing the target resource. That token space is under exclusive control of the server. 3. The server processes the phantom observation request above, without transmitting it on the wire. The request is addressed to the resource for which the server wants to start the group observation, as if sent from the group of observers, i.e. with the multicast IP address as source address. 4. Upon processing the self-generated phantom request, the server interprets it as an observe registration received from the group of potential observer clients. In particular, from then on, the server MUST use T as its own local Token value associated to that observation, with respect to the (next hop towards the) clients. 5. The server does not immediately respond to the phantom observation request with a multicast notification. The server stores the phantom observation request as is, throughout the lifetime of the group observation. After having started a group observation on a target resource, the server proceeds as follows. o For each traditional observation ongoing on the target resource, the server MAY cancel that observation, and then adds the corresponding client to the list of observers taking part in the group observation. The server sends to each of such clients an informative response message, encoded as a unicast response with response code 5.03 (Service Unavailable). As per [RFC7641], such a response does not include an Observe option. The response MUST be Confirmable and MUST NOT encode link-local addresses. The payload of the response is a CBOR map including the following fields. * The IP multicast address where the server will hereafter send multicast notifications for the target resource, encoded as a CBOR byte string, with CBOR label "address". Tiloca, et al. Expires May 7, 2020 [Page 5] Internet-Draft Observe Multicast Notifications November 2019 * The byte serialization of the phantom observation request received by the server, encoded as a CBOR byte string, with CBOR label "registr". * Optionally, the current representation of the target resource, encoded as a CBOR byte string, with CBOR label "res". o Upon receiving a registration request to observe the target resource, the server does not create a corresponding individual observation for the requesting client. Instead, the server adds that client to the list of observers taking part in the group observation of the target resource, and replies to the client with the same informative response message defined above, which MUST be Confirmable and MUST include the current representation of the target resource. Note that this also applies when, with no ongoing traditional observations on the target resource, the server receives a registration request from a first client and decides to start a group observation on the target resource. o Upon a change of the status of the target resource, the server sends a multicast notification, intended to all the clients taking part in the group observation of that resource. In particular, each of such multicast notifications: * MUST be sent to the IP multicast address indicated in the informative response message to the observer clients. * MUST include an Observe option, as per [RFC7641]. * MUST have the same Token value T of the phantom registration request that started the group observation, also included in the informative response message to the observer clients. That is, every multicast notification for a target resource is not bound to the observation requests from the different clients, but rather to the phantom registration associated to the whole set of clients currently taking part in the group observation of that resource. 3. Client-Side Requirements A client sends an observation request to the server as described in [RFC7641], i.e. a GET request with an Observe option set to 0 (register). The request MUST NOT encode link-local addresses. If the server is not configured to accept registrations on that target resource with a group observation, this would still result in a positive notification response to the client as described in [RFC7641]. Tiloca, et al. Expires May 7, 2020 [Page 6] Internet-Draft Observe Multicast Notifications November 2019 Upon receiving the informative response defined in Section 2, the client proceeds as follows. 1. The client configures an observation of the target resource from a CoAP endpoint associated to the multicast IP address, and stores the phantom registration request specified in the informative response from the server. The group observation is bound to the phantom registration request. In particular, the client MUST use its Token value T as its own local Token value associated to that group observation, with respect to the (next hop towards the) server. The particular way to achieve this is implementation specific. 2. If a traditional observation to the target resource is ongoing, the client MAY silently cancel it without notifying the server. 3. If the informative response from the server includes the current representation of the target resource, the client considers it as received from an observe notification and processes it as usual. From then on, the client will receive, accept and process multicast notifications about the state of the target resource from the server, as responses to the phantom registration request and with Token value T. 4. Example The following example refers to two clients C_1 and C_2 that register to observe a resource /r at a Server S. 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 M_addr , and starts the group observation upon receiving a registration request from a first client that wishes to start a traditional observation on the resource /r. C_1 ------------------ [ Unicast ] --------------------> S /r | GET | | Token: 0x4a | | Observe: 0 (Register) | | | | (S allocates the available Token value 0xff .) | | | Tiloca, et al. Expires May 7, 2020 [Page 7] Internet-Draft Observe Multicast Notifications November 2019 | (S sends to itself a phantom observation request Ph_req | | as coming from the IP multicast address M_addr .) | | ------------------------------------------------- | | / | | \----------------------------------------------------> | /r | GET | | Token: 0xff | | Observe: 0 (Register) | | | | (S creates a group observation of /r .) | | | | (S adds C_1 to the list of observers taking | | part in the group observation of /r .) | | | C_1 <--------------------- [ Unicast ] ----------------- S | 5.03 | | Token: 0x4a | | Payload: { address : M_addr , | | registr : Ph_req , | | res : "1234" } | | | | | C_2 ------------------ [ Unicast ] --------------------> S /r | GET | | Token: 0x01 | | Observe: 0 (Register) | | | | (S adds C_2 to the list of observers taking | | part in the group observation of /r .) | | | C_2 <--------------------- [ Unicast ] ----------------- S | 5.03 | | Token: 0x01 | | Payload: { address : M_addr , | | registr : Ph_req , | | res : "1234" } | | | | | | (The value of the resource /r changes to "5678".) | | | C_1 | + <-------------------- [ Multicast ] ---------------- S C_2 (Destination address: M_addr) | | 2.05 | | Token: 0xff | | Observe: 11 | | Payload: "5678" | | | Tiloca, et al. Expires May 7, 2020 [Page 8] Internet-Draft Observe Multicast Notifications November 2019 5. Protection of Multicast Notifications with Group OSCORE A server can protect multicast notifications by using Group OSCORE [I-D.ietf-core-oscore-groupcomm]. In such a case, both the server and the clients interested in receiving multicast notifications from that server have to be members of the same OSCORE group. Clients MAY discover the OSCORE group to refer to by using the method in [I-D.tiloca-core-oscore-discovery], also based on the CoRE Resource Directory (RD) [I-D.ietf-core-resource-directory]. Alternatively, the server MAY communicate to the client what OSCORE group to join, as described in Section 5.1. Furthermore, both the clients and the server MAY join the OSCORE group by using the approach described in [I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework for Authentication and Authorization in constrained environments [I-D.ietf-ace-oauth-authz]. Further details on how to discover the OSCORE group and join it are out of the scope of this specification. Alternative security protocols than Group OSCORE, such as OSCORE [RFC8613] and/or DTLS [RFC6347][I-D.ietf-tls-dtls13], can be used to protect other exchanges via unicast between the server and each client, including the original client registration (see Section 3). 5.1. OSCORE Group in Informative Response This section describes a mechanism for the server to communicate to the client what OSCORE group to join in order to decrypt and verify the multicast notifications protected with group OSCORE. The client MAY use the information provided by the server to start the ACE joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore]. This mechanism is OPTIONALLY supported by client and server. Additionally to what defined in Section 2, the CBOR map in the informative response payload contains the following fields: o The URI for joining the OSCORE group at the respective Group Manager, encoded as a CBOR text string, with CBOR label "join- uri". If the procedure described in [I-D.ietf-ace-key-groupcomm-oscore] is used for joining, this field specifically indicates the URI of the group-membership resource at the Group Manager. o The name of the OSCORE group, encoded as a CBOR text string, with CBOR label "sec-gp". Tiloca, et al. Expires May 7, 2020 [Page 9] Internet-Draft Observe Multicast Notifications November 2019 o Optionally, the URI of the Authorization Server associated to the Group Manager for the OSCORE group, encoded as a CBOR text string, with CBOR label "as-uri". o Optionally, the algorithm used to countersign messages, encoded as a text string or an int, with value taken from the 'Value' column of the "COSE Algorithms" registry defined in [RFC8152], with CBOR label "cs-alg". o Optionally, the elliptic curve for the algorithm used to countersign messages, encoded as a text string or an int, with value taken from the 'Value' column of the "COSE Elliptic Curve" registry defined in [RFC8152], with CBOR label "cs-crv". o Optionally, the key type of countersignature keys used to countersign messages, encoded as a text string or an int, with value taken from the 'Value' column of the "COSE Key Types" registry defined in [RFC8152], with CBOR label "cs-kty". o Optionally, the encoding of the public keys, encoded as an int, with value taken from the 'Confirmation Key' column of the "CWT Confirmation Method" registry defined in [I-D.ietf-ace-cwt-proof-of-possession], with CBOR label "cs-kenc". Future specifications may define additional values for this parameter. o Optionally, the AEAD algorithm, encoded as a text string or an int, with value taken from the 'Value' column of the "COSE Algorithms" registry defined in [RFC8152], with CBOR label "alg". o Optionally, the HKDF algorithm, encoded as a text string or an int, with value taken from the 'Value' column of the "COSE Algorithms" registry defined in [RFC8152], with CBOR label "hkdf". The values of 'cs_alg', 'cs_crv', 'cs_kty' and 'cs_kenc' provide an early knowledge of the format and encoding of public keys used in the OSCORE group. Thus, the client does not need to ask the Group Manager for this information as a preliminary step before the (ACE) join process, or to perform a trial-and-error exchange with the Group Manager upon joining the group. Hence, the client is able to provide the Group Manager with its own public key in the correct expected format and encoding, at the very first step of the (ACE) join process. The values of 'cs_alg', 'alg' and 'hkdf' provide an early knowledge of the algorithms used in the OSCORE group. Thus, the client is able to decide whether to actually proceed with the (ACE) join process, depending on its support for the indicated algorithms. Tiloca, et al. Expires May 7, 2020 [Page 10] Internet-Draft Observe Multicast Notifications November 2019 As mentioned above, since this mechanism is OPTIONAL, all the fields are OPTIONAL in the informative response. However, the "join-uri" and "sec-gp" fields MUST be present if the mechanism is implemented and run. If any of the fields are present without the "join-uri" and "sec-gp" fields present, the client MUST ignore these fields, since they would not be sufficient to start the (ACE) join procedure. When this happens, the client MAY try sending a new registration request to the server (see Section 3). Otherwise, the client SHOULD explicitly withdraw from the group observation, as defined in Section 3. 5.2. Server-Side Requirements When using Group OSCORE to protect multicast notifications, the server performs as described in Section 2, with the following differences. o The phantom registration request MUST be secured, by using Group OSCORE. To this end, the server protects the phantom registration request as if it was the actual sender, i.e. by using its own Sender Context. As a consequence, the server consumes the current value of its own Sender Sequence Number SN in the OSCORE group, and hence updates it to SN* = (SN + 1). Consistently, the OSCORE option in the phantom registration request includes: * As 'kid', the Sender ID of the server in the OSCORE group. * As 'piv', the previously consumed sender sequence number value SN of the server in the OSCORE group, i.e. (SN* - 1). o Upon sending every multicast notification for the target resource, the server protects it with Group OSCORE. In particular, the process described in Section 6.3 of [I-D.ietf-core-oscore-groupcomm] applies, with the following additions when building the two OSCORE 'external_aad' to encrypt and countersign the multicast notification (see Sections 3.1 and 3.2 of [I-D.ietf-core-oscore-groupcomm]). * The 'request_kid' is the 'kid' value in the OSCORE option of the phantom registration request, i.e. the Sender ID of the server. * The 'request_piv' is the 'piv' value in the OSCORE option of the phantom registration request, i.e. the consumed sender sequence number SN of the server. Tiloca, et al. Expires May 7, 2020 [Page 11] Internet-Draft Observe Multicast Notifications November 2019 5.3. Client-Side Requirements When using Group OSCORE to protect multicast notifications, the client performs as described in Section 3, with the following differences. o Upon receiving the informative response from the server, the client retrieves the specified phantom registration request, and extracts the 'kid' and 'piv' fields of its OSCORE option. o From then on, when verifying multicast notifications for that target resource as described in Section 6.4 of [I-D.ietf-core-oscore-groupcomm], the client MUST use the extracted 'kid' as 'request_kid' and the extracted 'piv' as 'request_piv', in the two 'external_aad' for decrypting and verifying every multicast notification from the server for the target resource (see Sections 3.1 and 3.2 of [I-D.ietf-core-oscore-groupcomm]). The particular way to achieve this is implementation specific. 6. Example with Group OSCORE The following example refers to two clients C_1 and C_2 that register to observe a resource /r at a Server S. 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 M_addr , and starts the group observation upon receiving a registration request from a first client that wishes to start a traditional observation on the resource /r. Pairwise communication over unicast are protected with OSCORE, while S protects multicast notifications with Group OSCORE. Specifically: o C_1 and S have a pairwise OSCORE Security Context. In particular, C_1 has 'kid' = 1 as Sender ID, and SN_1 = 101 as Sequence Number. Also, S has 'kid' = 3 as Sender ID, and SN_3 = 301 as Sequence Number. o C_2 and S have a pairwise OSCORE Security Context. In particular, C_2 has 'kid' = 2 as Sender ID, and SN_2 = 201 as Sequence Number. Also, S has 'kid' = 4 as Sender ID, and SN_4 = 401 as Sequence Number. o S is a member of the OSCORE group with name "myGroup", and 'kid_context' = "feedca57ab2e" as Group ID. In the OSCORE group, S has 'kid' = 5 as Sender ID, and SN_5 = 501 as Sequence Number. Tiloca, et al. Expires May 7, 2020 [Page 12] Internet-Draft Observe Multicast Notifications November 2019 C_1 ------------- [ Unicast w/ OSCORE ] ---------------> S /r | GET | | Token: 0x4a | | Observe: 0 (Register) | | OSCORE: {kid: 1 ; piv: 101 ; ...} | | | | (S allocates the available Token value 0xff .) | | | | | | (S sends to itself a phantom observation request Ph_req | | as coming from the IP multicast address M_addr .) | | -------------------------------------------------- | | / | | \-----------------------------------------------------> | /r | GET | | Token: 0xff | | Observe: 0 (Register) | | OSCORE: {kid: 5 ; piv: 501 ; ...} | | | | (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) | | | | (S creates a group observation of /r .) | | | | (S adds C_1 to the list of observers taking | | part in the group observation of /r .) | | | | | C_1 <---------------- [ Unicast w/ OSCORE ] ------------- S | 5.03 | | Token: 0x4a | | OSCORE: {piv: 301; ...} | | Payload: { address : M_addr , | | registr : Ph_req , | | res : "1234" , | | join-uri : coap://myGM/group-oscore/myGroup | | sec-gp : "myGroup" } | | | | | C_2 ------------- [ Unicast w/ OSCORE ] ---------------> S /r | GET | | Token: 0x01 | | Observe: 0 (Register) | | OSCORE: {kid: 2 ; piv: 201 ; ...} | | | | (S adds C_2 to the list of observers taking | | part in the group observation of /r .) | | | C_2 <---------------- [ Unicast w/ OSCORE ] ------------- S Tiloca, et al. Expires May 7, 2020 [Page 13] Internet-Draft Observe Multicast Notifications November 2019 | 5.03 | | Token: 0x01 | | OSCORE: {piv: 401; ...} | | Payload: { address : M_addr , | | registr : Ph_req , | | res : "1234" , | | join-uri : coap://myGM/group-oscore/myGroup | | sec-gp : "myGroup" } | | | | | | (The value of the resource /r changes to "5678".) | | | C_1 | + <------------ [ Multicast w/ Group OSCORE ] --------- S C_2 (Destination address: M_addr) | | 2.05 | | Token: 0xff | | Observe: 11 | | OSCORE: {kid: 5; piv: 502 ; ...} | | Payload: "5678" | | | The two external_aad used to encrypt and countersign the multicast notification above have 'req_kid' = 5 and 'req_iv' = 501. These are indicated in the 'kid' and 'iv' field of the OSCORE option of the phantom observation request, which is included in the 'registr' parameter of the unicast informative response to the two clients. Thus, the two clients can build the two same external_aad for decrypting and verifying this multicast notification and the following ones. 7. Security Considerations The same security considerations from [RFC7252][RFC7390][RFC7641][I-D .dijk-core-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this document. If multicast notifications are protected using Group OSCORE, the original registration requests and related unicast (notification) responses MUST also be secured, including and especially the informative responses from the server. This prevents on-path active adversaries from altering the conveyed IP multicast address and serialized phantom request. Thus, it ensures secure binding between every multicast notification for a same observed resource and the phantom request that started the group observation of that resource. Tiloca, et al. Expires May 7, 2020 [Page 14] Internet-Draft Observe Multicast Notifications November 2019 To this end, clients and servers SHOULD use OSCORE or Group OSCORE, so ensuring that the secure binding above is enforced end-to-end between the server and each observing client. 8. IANA Considerations This document has the following actions for IANA. TODO: registry for labels of the map in the informative response. 9. References 9.1. Normative References [I-D.dijk-core-groupcomm-bis] Dijk, E., Wang, C., and M. Tiloca, "Group Communication for the Constrained Application Protocol (CoAP)", draft- dijk-core-groupcomm-bis-01 (work in progress), July 2019. [I-D.ietf-core-oscore-groupcomm] Tiloca, M., Selander, G., Palombini, F., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", draft-ietf-core-oscore-groupcomm-06 (work in progress), November 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Tiloca, et al. Expires May 7, 2020 [Page 15] Internet-Draft Observe Multicast Notifications November 2019 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . 9.2. Informative References [I-D.ietf-ace-cwt-proof-of-possession] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- possession-11 (work in progress), October 2019. [I-D.ietf-ace-key-groupcomm-oscore] Tiloca, M., Park, J., and F. Palombini, "Key Management for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- oscore-03 (work in progress), November 2019. [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-25 (work in progress), October 2019. [I-D.ietf-core-coap-pubsub] Koster, M., Keranen, A., and J. Jimenez, "Publish- Subscribe Broker for the Constrained Application Protocol (CoAP)", draft-ietf-core-coap-pubsub-09 (work in progress), September 2019. [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, "CoRE Resource Directory", draft-ietf-core- resource-directory-23 (work in progress), July 2019. [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", draft-ietf-tls-dtls13-33 (work in progress), October 2019. [I-D.tiloca-core-oscore-discovery] Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE Groups with the CoRE Resource Directory", draft-tiloca- core-oscore-discovery-03 (work in progress), July 2019. Tiloca, et al. Expires May 7, 2020 [Page 16] Internet-Draft Observe Multicast Notifications November 2019 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, . [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, . Acknowledgments The authors sincerely thank Carsten Bormann, Klaus Hartke, John Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander for their comments and feedback. The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC. Authors' Addresses Marco Tiloca RISE AB Isafjordsgatan 22 Kista SE-16440 Stockholm Sweden Email: marco.tiloca@ri.se Rikard Hoeglund RISE AB Isafjordsgatan 22 Kista SE-16440 Stockholm Sweden Email: rikard.hoglund@ri.se Christian Amsuess Hollandstr. 12/4 Vienna 1020 Austria Email: christian@amsuess.com Tiloca, et al. Expires May 7, 2020 [Page 17] Internet-Draft Observe Multicast Notifications November 2019 Francesca Palombini Ericsson AB Torshamnsgatan 23 Kista SE-16440 Stockholm Sweden Email: francesca.palombini@ericsson.com Tiloca, et al. Expires May 7, 2020 [Page 18]