Skip to main content

Group Communication for the Constrained Application Protocol (CoAP)
draft-dijk-core-groupcomm-bis-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Esko Dijk , Chonggang Wang , Marco Tiloca
Last updated 2019-07-08 (Latest revision 2019-03-10)
Replaced by draft-ietf-core-groupcomm-bis
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dijk-core-groupcomm-bis-01
Internet-Draft        Group Communication for CoAP             July 2019

   group members; manages, renews and provides keying material in the
   group; and drives the join process for new group members.

   As recommended in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint
   can join an OSCORE group by using the method 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].

   A CoAP endpoint can discover OSCORE groups and retrieve information
   to join them through their Group Managers by using the method
   described in [I-D.tiloca-core-oscore-discovery] and based on the CoRE
   Resource Directory [I-D.ietf-core-resource-directory].

   If security is required, CoAP group communication as described in
   this specification MUST use Group OSCORE.  In particular, a CoAP
   group as defined in Section 2.1.1 and using secure group
   communication is associated to an OSCORE group, which includes:

   o  All members of the CoAP group, i.e. the CoAP endpoints configured
      (also) as CoAP servers and listening to the group's multicast IP
      address.

   o  All further CoAP endpoints configured only as CoAP clients, that
      send (multicast) CoAP requests to the CoAP group.

4.1.  Secure Group Maintenance

   Additional key management operations on the OSCORE group are
   required, depending also on the security requirements of the
   application (see Section 5.2).  That is:

   o  Adding new members to a CoAP group or enabling new client-only
      endpoints to interact with that group require also that each of
      such members/endpoints join the corresponding OSCORE group.  By
      doing so, they are securely provided with the necessary
      cryptographic material.  In case backward security is needed, this
      also requires to first renew such material and distribute it to
      the current members/endpoints, before new ones are added and join
      the OSCORE group.

   o  In case forward security is needed, removing members from a CoAP
      group or stopping client-only endpoints from interacting with that
      group requires removing such members/endpoints from the
      corresponding OSCORE group.  To this end, new cryptographic
      material is generated and securely distributed only to the
      remaining members/endpoints.  This ensures that only the members/
      endpoints intended to remain are able to continue participating to

Dijk, et al.             Expires January 9, 2020               [Page 17]
Internet-Draft        Group Communication for CoAP             July 2019

      secure group communication, while the evicted ones are not able
      to.

   The key management operations mentioned above are entrusted to the
   Group Manager responsible for the OSCORE group
   [I-D.ietf-core-oscore-groupcomm], and it is RECOMMENDED to perform
   them according to the approach described in
   [I-D.ietf-ace-key-groupcomm-oscore].

5.  Security Considerations

   This section provides security considerations for CoAP group
   communication using IP multicast.

5.1.  CoAP NoSec Mode

   CoAP group communication, if not protected, is vulnerable to all the
   attacks mentioned in Section 11 of [RFC7252] for IP multicast.

   Thus, for sensitive and mission-critical applications (e.g., health
   monitoring systems and alarm monitoring systems), it is NOT
   RECOMMENDED to deploy CoAP group communication in NoSec mode.

   Without application-layer security, CoAP group communication SHOULD
   only be deployed in applications that are non-critical, and that do
   not involve or may have an impact on sensitive data and personal
   sphere.  These include, e.g., read-only temperature sensors deployed
   in non-sensitive environments, where the client reads out the values
   but does not use the data to control actuators or to base an
   important decision on.

   Discovery of devices and resources is a typical use case where NoSec
   mode is applied, since the devices involved do not have yet
   configured any mutual security relations at the time the discovery
   takes place.

5.2.  Group OSCORE

   Group OSCORE provides end-to-end application-level security.  This
   has many desirable properties, including maintaining security
   assurances while forwarding traffic through intermediaries (proxies).
   Application-level security also tends to more cleanly separate
   security from the dynamics of group membership (e.g., the problem of
   distributing security keys across large groups with many members that
   come and go).

   For sensitive and mission-critical applications, CoAP group
   communication MUST be protected by using Group OSCORE as specified in

Dijk, et al.             Expires January 9, 2020               [Page 18]
Internet-Draft        Group Communication for CoAP             July 2019

   [I-D.ietf-core-oscore-groupcomm].  The same security considerations
   from Section 8 of [I-D.ietf-core-oscore-groupcomm] hold for this
   specification.

5.2.1.  Group Key Management

   A key management scheme for secure revocation and renewal of group
   keying material, namely group rekeying, should be adopted in OSCORE
   groups.  In particular, the key management scheme should preserve
   backward and forward security in the OSCORE group, if the application
   requires so (see Section 2.1 of [I-D.ietf-core-oscore-groupcomm]).

   Group policies should also take into account the time that the key
   management scheme requires to rekey the group, on one hand, and the
   expected frequency of group membership changes, i.e. nodes' joining
   and leaving, on the other hand.

   In fact, it may be desirable to not rekey the group upon every single
   membership change, in case members' joining and leaving are frequent,
   and at the same time a single group rekeying instance takes a non
   negligible time to complete.

   In such a case, the Group Manager may consider to rekey the group,
   e.g., after a minum number of nodes have joined or left the group
   within a pre-defined time interval, or according to communication
   patterns with predictable intervals of network inactivity.  This
   would prevent paralizing communications in the group, when a slow
   rekeying scheme is used and frequently invoked.

   This comes at the cost of not continuously preserving backward and
   forward security, since group rekeying might not occur upon every
   single group membership change.  That is, latest joined nodes would
   have access to the key material used prior to their join, and thus be
   able to access past group communications protected with that key
   material.  Similarly, until the group is rekeyed, latest left nodes
   would preserve access to group communications protected with the
   retained key material.

5.2.2.  Source Authentication

   CoAP endpoints using Group OSCORE countersign their outgoing
   messages, by means of the countersignature algorithm used in the
   OSCORE group.  This ensures source authentication of messages
   exchanged by CoAP endpoints through CoAP group communication.  In
   fact, it allows to verify that a received message has actually been
   originated by a specific and identified member of the OSCORE group.

Dijk, et al.             Expires January 9, 2020               [Page 19]
Internet-Draft        Group Communication for CoAP             July 2019

   Appendix F of [I-D.ietf-core-oscore-groupcomm] discusses a number of
   cases where a recipient CoAP endpoint may skip the verification of
   countersignatures, possibly on a per-message basis.  However, this is
   NOT RECOMMENDED.  That is, a CoAP endpoint receiving a message
   secured with Group OSCORE SHOULD always verify the countersignature.

5.2.3.  Counteraction of Attacks

   Group OSCORE addresses security attacks mentioned in Sections
   11.2-11.6 of [RFC7252], with particular reference to their execution
   over IP multicast.  That is: it provides confidentiality and
   integrity of request/response data through proxies also in multicast
   settings; it prevents amplification attacks carried out through
   responses to injected requests over IP multicast; it limits the
   impact of attacks based on IP spoofing; it prevents cross-protocol
   attacks; it derives the group key material from, among other things,
   a Master Secret securely generated by the Group Manager and provided
   to CoAP endpoints upon their joining of the OSCORE group;
   countersignatures assure source authentication of exchanged CoAP
   messages, and hence prevent a group member to be used for subverting
   security in the whole group.

5.3.  6LoWPAN

   Editor Note, TBD: identify if multi-fragment multicast requests have
   a negative effect on security and, if so, advice here on trying to
   avoid such requests.  Also an attacker could use multi-fragment to
   occupy reassembly buffers of many routing 6LoWPAN nodes.

5.4.  Wi-Fi

   TBD: Wi-Fi specific security considerations; see also Section 5.3.1
   of [RFC7390].

5.5.  Monitoring

   TBD: see Section 5.4 of [RFC7390].

6.  IANA Considerations

   This document has no actions for IANA.

7.  References

Dijk, et al.             Expires January 9, 2020               [Page 20]
Internet-Draft        Group Communication for CoAP             July 2019

7.1.  Normative References

   [I-D.ietf-core-object-security]
              Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", draft-ietf-core-object-security-16 (work in
              progress), March 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-04 (work in progress),
              March 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <https://www.rfc-editor.org/info/rfc4944>.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <https://www.rfc-editor.org/info/rfc6690>.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <https://www.rfc-editor.org/info/rfc7049>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
              Application Protocol (CoAP)", RFC 7641,
              DOI 10.17487/RFC7641, September 2015,
              <https://www.rfc-editor.org/info/rfc7641>.

   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
              the Constrained Application Protocol (CoAP)", RFC 7959,
              DOI 10.17487/RFC7959, August 2016,
              <https://www.rfc-editor.org/info/rfc7959>.

Dijk, et al.             Expires January 9, 2020               [Page 21]
Internet-Draft        Group Communication for CoAP             July 2019

   [RFC8075]  Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
              E. Dijk, "Guidelines for Mapping Implementations: HTTP to
              the Constrained Application Protocol (CoAP)", RFC 8075,
              DOI 10.17487/RFC8075, February 2017,
              <https://www.rfc-editor.org/info/rfc8075>.

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,
              <https://www.rfc-editor.org/info/rfc8152>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              RFC 8323, DOI 10.17487/RFC8323, February 2018,
              <https://www.rfc-editor.org/info/rfc8323>.

7.2.  Informative References

   [Californium]
              Eclipse Foundation, "Eclipse Californium", March 2019,
              <https://github.com/eclipse/californium/tree/2.0.x/
              californium-core/src/main/java/org/eclipse/californium/
              core>.

   [Go-OCF]   Open Connectivity Foundation (OCF), "Implementation of
              CoAP Server & Client in Go", March 2019,
              <https://github.com/go-ocf/go-coap>.

   [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-01 (work in progress), March 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-24
              (work in progress), March 2019.

Dijk, et al.             Expires January 9, 2020               [Page 22]
Internet-Draft        Group Communication for CoAP             July 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-08 (work in
              progress), March 2019.

   [I-D.ietf-core-multipart-ct]
              Fossati, T., Hartke, K., and C. Bormann, "Multipart
              Content-Format for CoAP", draft-ietf-core-multipart-ct-03
              (work in progress), March 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-22 (work in progress), July 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-02 (work in progress), March 2019.

   [RFC7346]  Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
              DOI 10.17487/RFC7346, August 2014,
              <https://www.rfc-editor.org/info/rfc7346>.

   [RFC7390]  Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
              the Constrained Application Protocol (CoAP)", RFC 7390,
              DOI 10.17487/RFC7390, October 2014,
              <https://www.rfc-editor.org/info/rfc7390>.

   [RFC7967]  Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
              Bose, "Constrained Application Protocol (CoAP) Option for
              No Server Response", RFC 7967, DOI 10.17487/RFC7967,
              August 2016, <https://www.rfc-editor.org/info/rfc7967>.

Appendix A.  Use Cases

   To illustrate where and how CoAP-based group communication can be
   used, this section summarizes the most common use cases.  These use
   cases include both secured and non-secured CoAP usage.  Each
   subsection below covers one particular category of use cases for
   CoRE.  Within each category, a use case may cover multiple
   application areas such as home IoT, commercial building IoT (sensing
   and control), industrial IoT/control, or environmental sensing.

Dijk, et al.             Expires January 9, 2020               [Page 23]
Internet-Draft        Group Communication for CoAP             July 2019

A.1.  Discovery

   Discovery of physical devices in a network, or discovery of
   information entities hosted on network devices, are operations that
   are usually required in a system during the phases of setup or
   (re)configuration.  When a discovery use case involves devices that
   need to interact without having been configured previously with a
   common security context, unsecured CoAP communication is typically
   used.  Discovery may involve a request to a directory server, which
   provides services to aid clients in the discovery process.  One
   particular type of directory server is the CoRE Resource Directory
   [I-D.ietf-core-resource-directory]; and there may be other types of
   directories that can be used with CoAP.

A.1.1.  Distributed Device Discovery

   Device discovery is the discovery and identification of networked
   devices - optionally only devices of a particular class, type, model,
   or brand.  Group communication is used for distributed device
   discovery, if a central directory server is not used.  Typically in
   distributed device discovery, a multicast request is sent to a
   particular address (or address range) and multicast scope of
   interest, and any devices configured to be discoverable will respond
   back.  For the alternative solution of centralized device discovery a
   central directory server is accessed through unicast, in which case
   group communication is not needed.  This requires that the address of
   the central directory is either preconfigured in each device or
   configured during operation using a protocol.

   In CoAP, device discovery can be implemented by CoAP resource
   discovery requesting (GET) a particular resource that the sought
   device class, type, model or brand is known to respond to.  It can
   also be implemented using CoAP resource discovery (Section 7 of
   [RFC7252]) and the CoAP query interface defined in Section 4 of
   [RFC6690] to find these particular resources.  Also, a multicast GET
   request to /.well-known/core can be used to discover all CoAP
   devices.

A.1.2.  Distributed Service Discovery

   Service discovery is the discovery and identification of particular
   services hosted on network devices.  Services can be identified by
   one or more parameters such as ID, name, protocol, version and/or
   type.  Distributed service discovery involves group communication to
   reach individual devices hosting a particular service; with a central
   directory server not being used.

Dijk, et al.             Expires January 9, 2020               [Page 24]
Internet-Draft        Group Communication for CoAP             July 2019

   In CoAP, services are represented as resources and service discovery
   is implemented using resource discovery (Section 7 of [RFC7252]) and
   the CoAP query interface defined in Section 4 of [RFC6690].

A.1.3.  Directory Discovery

   This use case is a specific sub-case of Distributed Service Discovery
   (Appendix A.1.2), in which a device needs to identify the location of
   a Directory on the network to which it can e.g. register its own
   offered services, or to which it can perform queries to identify and
   locate other devices/services it needs to access on the network.
   Section 3.3 of [RFC7390] shows an example of discovering a CoRE
   Resource Directory using CoAP group communication.  As defined in
   [I-D.ietf-core-resource-directory], a resource directory is a web
   entity that stores information about web resources and implements
   REST interfaces for registration and lookup of those resources.  For
   example, a device can register itself to a resource directory to let
   it be found by other devices and/or applications.

A.2.  Operational Phase

   Operational phase use cases describe those operations that occur most
   frequently in a networked system, during its operational lifetime and
   regular operation.  Regular usage is when the applications on
   networked devices perform the tasks they were designed for and
   exchange of application-related data using group communication
   occurs.  Processes like system reconfiguration, group changes,
   system/device setup, extra group security changes, etc. are not part
   of regular operation.

A.2.1.  Actuator Group Control

   Group communication can be beneficial to control actuators that need
   to act in synchrony, as a group, with strict timing (latency)
   requirements.  Examples are office lighting, stage lighting, street
   lighting, or audio alert/Public Address systems.  Sections 3.4 and
   3.5 of [RFC7390] show examples of lighting control of a group of
   6LoWPAN-connected lights.

A.2.2.  Device Group Status Request

   To properly monitor the status of systems, there may be a need for
   ad-hoc, unplanned status updates.  Group communication can be used to
   quickly send out a request to a (potentially large) number of devices
   for specific information.  Each device then responds back with the
   requested data.  Those devices that did not respond to the request
   can optionally be polled again via reliable unicast communication to
   complete the dataset.  The device group may be defined e.g. as "all

Dijk, et al.             Expires January 9, 2020               [Page 25]
Internet-Draft        Group Communication for CoAP             July 2019

   temperature sensors on floor 3", or "all lights in wing B".  For
   example, it could be a status request for device temperature, most
   recent sensor event detected, firmware version, network load, and/or
   battery level.

A.2.3.  Network-wide Query

   In some cases a whole network or subnet of multiple IP devices needs
   to be queried for status or other information.  This is similar to
   the previous use case except that the device group is not defined in
   terms of its function/type but in terms of its network location.
   Technically this is also similar to distributed service discovery
   (Appendix A.1.2) where a query is processed by all devices on a
   network - except that the query is not about services offered by the
   device, but rather specific operational data is requested.

A.2.4.  Network-wide / Group Notification

   In some cases a whole network, or subnet of multiple IP devices, or a
   specific target group needs to be notified of a status change or
   other information.  This is similar to the previous two use cases
   except that the recipients are not expected to respond with some
   information.  Unreliable notification can be acceptable in some use
   cases, in which a recipient does not respond with a confirmation of
   having received the notification.  In such a case, the receiving CoAP
   server does not have to create a CoAP response.  If the sender needs
   confirmation of reception, the CoAP servers can be configured for
   that resource to respond with a 2.xx success status after processing
   a notification request successfully.

A.3.  Software Update

   Multicast can be useful to efficiently distribute new software
   (firmware, image, application, etc.) to a group of multiple devices.
   In this case, the group is defined in terms of device type: all
   devices in the target group are known to be capable of installing and
   running the new software.  The software is distributed as a series of
   smaller blocks that are collected by all devices and stored in
   memory.  All devices in the target group are usually responsible for
   integrity verification of the received software; which can be done
   per-block or for the entire software image once all blocks have been
   received.  Due to the inherent unreliability of CoAP multicast, there
   needs to be a backup mechanism (e.g. implemented using CoAP unicast)
   by which a device can individually request missing blocks of a whole
   software image/entity.  Prior to multicast software update, the group
   of recipients can be separately notified that there is new software
   available and coming, using the above network-wide or group
   notification.

Dijk, et al.             Expires January 9, 2020               [Page 26]
Internet-Draft        Group Communication for CoAP             July 2019

Acknowledgments

   The authors sincerely thank Thomas Fossati and Jim Schaad for their
   comments and feedback.

   The work on this document has been partly supported by VINNOVA and
   the Celtic-Next project CRITISEC.

Authors' Addresses

   Esko Dijk
   IoTconsultancy.nl
   -------
   Utrecht
   The Netherlands

   Email: esko.dijk@iotconsultancy.nl

   Chonggang Wang
   InterDigital
   1001 E Hector St, Suite 300
   Conshohocken  PA 19428
   United States

   Email: Chonggang.Wang@InterDigital.com

   Marco Tiloca
   RISE AB
   Isafjordsgatan 22
   Kista  SE-16440 Stockholm
   Sweden

   Email: marco.tiloca@ri.se

Dijk, et al.             Expires January 9, 2020               [Page 27]