DTLS-based Multicast Security in Constrained Environments
draft-keoh-dice-multicast-security-06

Abstract

The CoAP standard is fast emerging as a key protocol in the area of resource-constrained devices. Such IP-based systems are foreseen to be used for building and lighting control systems where devices interconnect with each other, forming, for example, low-power and lossy networks (LLNs). Both multicast and its security are key needs in these networks. This draft presents a method for securing IPv6 multicast communication based on the DTLS which is already supported for unicast communication for CoAP devices. This draft deals with the adaptation of the DTLS record layer to protect multicast group communication, assuming that all group members already have the group security association parameters in their possession. The adapted DTLS record layer provides message confidentiality, integrity and replay protection to group messages using the group keying material before sending the message via IPv6 multicast to the group.

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 http://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 November 06, 2014.

Copyright Notice

Copyright (c) 2014 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 (http://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
• 1.1. Terminology
• 1.2. Outline
• 2. Use Cases and Requirements
• 2.1. Group Communication Use Cases
• 2.2. Security Requirements
• 3. Overview of DTLS-based Secure Multicast
• 3.1. IP Multicast
• 3.2. Securing Multicast in Constrained Networks
• 4. Multicast Data Security
• 4.1. SecurityParameter derivation
• 4.2. Record layer adaptation
• 4.3. Sending Secure Multicast Messages
• 4.4. Receiving Secure Multicast Messages
• 4.5. Unicast Responses to Multicast Messages
• 4.6. Proxy Operation
• 5. IANA Considerations
• 6. Security Considerations
• 6.1. Group level security
• 6.2. Late joiners
• 6.3. Uniqueness of SenderIDs
• 6.4. Reduced sequence number space
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Appendix A. Change Log
• Authors' Addresses

1. Introduction

There is an increased use of wireless control networks in environmental monitoring, industrial automation, lighting controls and building management systems. This is mainly driven by the fact that the independence from physical control wires allows for freedom of placement, portability and for reducing the cost of installation as less cable placement and drilling are required. Consequently, there is an ever growing number of electronic devices, sensors and actuators that have become Internet connected, thus creating a trend towards the Internet-of-Things (IoT). These connected devices are equipped with communication capability that enables them to interact with each other as well as with the wider Internet services. However, the devices in such wireless control networks are characterized by power constraints (as these are usually battery-operated), have limited computational resources (low CPU clock, small RAM and flash storage) and often, the communication bandwidth is limited and unreliable (e.g., IEEE 802.15.4 radio). Hence, such wireless control networks are also known as Low-power and Lossy Networks (LLNs).

In addition to the usual device-to-device unicast communication that allow devices to directly interact with each other, group communication is an important feature in constrained environments. It is more effective in constrained environments to convey messages to a group of devices without requiring the sender to perform multiple time and energy consuming unicast transmissions to reach each individual group member. For example, in a building and lighting control system, the heating, ventilation, air-conditioning and lighting devices are often grouped according to the layout of the building, and control commands are issued simultaneously to a group of devices. Group communication is based on the Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] sent over IP- multicast [I-D.ietf-core-groupcomm].

Currently, CoAP messages are protected using Datagram Transport Layer Security (DTLS) [RFC6347]. However, DTLS is currently used to secure a connection between two endpoints and it cannot be used to protect multicast group communication. Group communication in constrained environments is equally important and should be secured as it is also vulnerable to the usual attacks over the air (eavesdropping, tampering, message forgery, replay, etc). There have been a lot of previous efforts in IETF to standardize mechanisms to secure multicast communication such as [RFC3830], [RFC4082], [RFC3740], [RFC4046], and [RFC4535]. However, these approaches are not necessarily suitable for constrained environments which have much more limited bandwidth and resources. For example, the MIKEY Architecture [RFC3830] is mainly designed to facilitate multimedia distribution, while TESLA [RFC4082] is proposed as a protocol for broadcast authentication of the source and not for protecting the confidentiality of multicast messages. [RFC3740] and [RFC4046] provide reference architectures for multicast security. [RFC4535] describes Group Secure Association Key Management Protocol (GSAKMP), a security framework for creating and managing cryptographic groups on a network which can be reused for key management in our context with any needed adaptation for constrained networks.

This draft describes an approach to use DTLS as mandated in CoAP unicast to also support multicast security. We will assume that all devices in the group already have a group security association parameters based on a key management mechanism which is outside the scope of this draft. This draft focuses primarily on the adaptation of the DTLS record layer to protect multicast messages to be sent to the group, and thus providing confidentiality, integrity and replay protection to the CoAP group messages.

Lastly, even though this draft is written from the perspective of securing CoAP based group communication, it is important to note that DTLS is a powerful and flexible security protocol. Thus use of DTLS-based multicast for application layer protocols other than CoAP are possible as long as they follow the approach outlined in this draft.

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

This specification uses the following terminology:

• Group Controller: The entity that is responsible for creating a multicast group and establishing security associations among authorized group members. It is also responsible for renewing/updating the multicast group keys.
• Sender: The Sender is an entity that sends data to the multicast group. In a 1-to-N multicast group only a single sender is authorized to transmit data to the group. In an M-to-N multicast group (where M and N are not necessarily the same value), M group members are authorized to be senders.
• Listener: The entity that receives multicast messages when listening to a multicast IP address.
• Security Association (SA): A set of policy and cryptographic keys that provide security services to network traffic that matches that policy [RFC3740]. A Security Association usually contains the following attributes:
  • selectors, such as source and destination transport addresses.
  • properties, such as identities.
  • cryptographic policy, such as the algorithms, modes, key lifetimes, and key lengths used for authentication or confidentiality.
  • keying material for authentication, encryption and signing.
• Group Security Association (GSA): A bundling of security associations (SAs) that together define how a group communicates securely. [RFC3740]
• Keying material: Data that is specified as part of the SA which is needed to establish and maintain a cryptographic security association, such as keys, key pairs, and IVs [RFC4949].

1.2. Outline

This draft is structured as follows: Section 2 motivates the proposed solution with group communication use cases in LLNs and derives a set of requirements. Section 3 provides an overview of the proposed DTLS-based multicast security assuming that all devices in the group already have a group security association parameters in their possession. In Section 4, we describe the details of the adaptation of DTLS record layer for confidentiality and integrity protection of the multicast messages. Section 6 presents the security considerations.

2. Use Cases and Requirements

This section defines the use cases for group communication in LLNs and specifies a set of security requirements for these use cases.

2.1. Group Communication Use Cases

The "Group Communication for CoAP" draft [I-D.ietf-core-groupcomm] provides the necessary background for multicast based CoAP communication in constrained environments (e.g. LLNs). and the interested reader is encouraged to first read this document to understand the non-security related details. This document also lists a few multicast group communication uses cases with detailed descriptions and some are listed here briefly:

1. Lighting control: enabling synchronous operation of a group of 6LoWPAN [RFC4944] [RFC6282] connected lights in a room/floor/building. This ensures that the light preset like on/off/dim-level of a large group of luminaries are changed at the same time, hence providing a visual synchronicity of light effects to the user.
2. Parameter update: configuration settings of a group of similar devices are updated simultaneously and efficiently.
3. Device and Service discovery: information about the devices in the local network and their capabilities can be queried and requested using multicast, e.g. by a commissioning device. The responses are sent back in unicast.

Elaborating on one of the main use cases that this document addresses, Lighting control, consider a building equipped with 6LoWPAN IP-connected lighting devices, switches, and 6LoWPAN border routers; the devices are organized in groups according to their physical location in the building, e.g., lighting devices and switches in a room/floor can be configured as a single multicast group. The switches are then used to control the lighting devices in the group by sending on/off/dimming commands to all lighting devices in the group. 6LoWPAN border routers that are connected to an IPv6 network backbone (which is also multicast enabled) are used to interconnect 6LoWPANs in the building. Consequently, this would also enable multicast groups to be formed across different physical subnets (which may be individually protected with L2 security). In such a multicast group, group messages can traverse from one physical subnet to another physical subnet through a IPv6 backbone which may not be protected. Additionally, other non-lighting devices (like window blind controls) may share the physical subnet for networking.

2.2. Security Requirements

The "Miscellaneous CoAP Group Communication Topics" draft [I-D.dijk-core-groupcomm-misc] already defines a set of security requirements for CoAP group communications We re-iterate and further describe those security requirements in this section with respect to the use cases:

1. Multicast communication topology: We consider both 1-to-N (one sender with multiple listeners) and M-to-N (multiple senders with multiple listeners) communication topologies. The 1-to-N communication topology is the simplest group communication scenario that would serve the needs of a typical LLN. For example, in the simple lighting control use case, the switch is the only entity that is responsible for sending control commands to a group of lighting devices. In more advanced lighting control use cases, a N-to-M communication topology would be required, for example if multiple sensors (presence or day-light) are responsible to trigger events to a group of lighting devices.
2. Multicast group size: The security solutions should support the typical group sizes that "Group Communication for CoAP" draft [I-D.ietf-core-groupcomm] intends to support. Group size is the combination of the number of Senders and Listeners in a group with possible overlap (a Sender can also be a Listener but need not be always). In LLN use cases mentioned in the document, the number of Senders (normally the controlling devices) is much smaller than the number of Listeners (the controlled devices). A security solution that supports 1 to 50 Senders would cover the group sizes required for most use cases that are relevant for this document. The total number of group devices must be in the range of 2 to 100 devices. Groups larger than these should be divided into smaller independent multicast groups such as grouping lights of a building per floor.
3. Establishment of a GSA: A secure mechanism must be used to distribute keying materials, multicast security policies and security parameters to members of a multicast group. A GSA must be established by the group controller (which manages the multicast group) among the group members. The 6LoWPAN border router, a device in the 6LoWPAN, or a remote server outside the 6LoWPAN could play the role of the group controller. However, GSA establishment is outside the scope of this draft, and it is anticipated that an activity in IETF dedicated to the design of a generic key management scheme for the LLN will include this feature preferably based on [RFC3740], [RFC4046] and [RFC4535].
4. Multicast data confidentiality: Multicast message should be encrypted, as some control commands when sent in the clear could pose unforeseen privacy risks to the users of the system.
5. Multicast data replay protection: It must not be possible to replay a multicast message as this would disrupt the operation of the group communication.
6. Multicast data group authentication and integrity: It is essential to ensure that a multicast message originated from a member of the group and that messages have not been tampered with by attackers who are not members. The multicast group key which is known to all group members is used to provide authenticity to the multicast messages (e.g., using a Message Authentication Code, MAC). This assumes that all other group members are trusted not to tamper with the multicast message.
7. Multicast data security ciphersuite: All group members must use the same ciphersuite to protect the authenticity, integrity and confidentiality of multicast messages. The ciphersuite is part of the GSA. Typically authenticity is more important than confidentiality in LLNs. Therefore the proposed multicast data security protocol must support at least ciphersuites with MAC only (NULL encryption) and AEAD [RFC5116] ciphersuites. Other ciphersuites that are defined for data record security in DTLS should also be preferably supported.
8. Multicast data source authentication: Source authenticity is required if the group members are assumed to be untrusted and can tamper with the multicast messages. This can happen if nodes of the group can be easily compromised. Source authenticity helps to minimize the risk of any node compromise leading to the compromise of the whole multicast group. Source authenticity can be typically provided using public-key cryptography in which every multicast message is signed by the sender. Alternatively, a lightweight broadcast authentication, i.e., TESLA [RFC4082] can be deployed, however it requires devices in the multicast group to have a trusted clock and have the ability to loosely synchronize their clocks with the sender. Source authenticity mechanisms should be preferably defined at the application layer. The transport layer group level security can provide an additional layer of security for the source authenticity mechanism against DoS attacks. However, even with source authenticity the risk still remains that compromise of a sender can still compromise the whole group.
9. Forward security: Devices that leave the group should not have access to any future GSAs. This ensures that a past member device cannot continue to decrypt confidential data that is sent in the group. It also ensures that this device cannot send encrypted and/or integrity protected data after it leaves the group. The GSA update mechanism has to be defined as part of the key management scheme.
10. Backward confidentiality: A new device joining the group should not have access to any old GSAs. This ensures that a new member device cannot decrypt data sent before it joins the group. The key management scheme should ensure that the GSA is updated to ensure backward confidentiality.

3. Overview of DTLS-based Secure Multicast

The goal of this draft is to secure CoAP Group communication by extending the use of the DTLS security protocol to allow for the use of DTLS record layer with minimal adaptation. The IETF CoRE WG has selected DTLS [RFC6347] as the default must-implement security protocol for securing CoAP, therefore it is desirable that DTLS be extended to facilitate CoAP-based group communication. Reusing DTLS for different purposes while guaranteeing the required security properties can avoid the need to implement multiple security protocols and this is especially beneficial when the target deployment consists of resource-constrained embedded devices. This section first describes group communication based on IP multicast, and subsequently sketches a solution for securing group communication using DTLS.

3.1. IP Multicast

Devices in the network (e.g. LLN) are categorized into two roles, (1) sender and (2) listener. Any node may have one of these roles, or both roles. The application(s) running on a device basically determine these roles by the function calls they execute on the IP stack of the device.

In principle, a sender or listener does not require any prior access procedures or authentication to send or listen to a multicast message [RFC5374]. A sender to an IPv6 multicast group sets the destination of the packet to an IPv6 address that has been allocated for IPv6 multicast. A device becomes a listener by "joining" to the specific IPv6 multicast group by registering with a network routing device, signaling its intent to receive packets sent to that particular IPv6 multicast group. Figure 1 depicts a 1-to-N multicast communication and the roles of the nodes. Any device can in principle decide to listen to any IPv6 multicast address. This also means applications on the other devices do not know, or do not get notified, when new listeners join the network. More details on the IPv6 multicast and CoAP group communication can be found in [I-D.ietf-core-groupcomm]. This draft does not intend to modify any of the underlying group communication or multicast routing protocols.

						

               ++++
               |. |
             --| ++++
    ++++    /  ++|. |
    |A |---------| ++++
    |  |    \    ++|B |
    ++++     \-----|  |
   Sender          ++++
                 Listeners

						
	Ciphersuite MTS_WITH_AES_128_CCM_8 = {TBD1, TBD2}
	Ciphersuite MTS_WITH_NULL_SHA256   = {TBD3, TBD4}

						
+--------+-------------------------------------------------+
|        | +--------+------------------------------------+ |
|        | |        | +-------------+------------------+ | |
|        | |        | |             | +--------------+ | | |
|   IP   | |   UDP  | | DTLS Record | |   multicast  | | | |
| header | | header | |    Header   | |    message   | | | |
|        | |        | |             | +--------------+ | | |
|        | |        | +-------------+------------------+ | |
|        | +--------+------------------------------------+ |
+--------+-------------------------------------------------+

					
	client write MAC key
	server write MAC key
	client write encryption key
	server write encryption key
	client write IV
	server write IV
		

						
+---------+---------+--------+--------+--------+------------+-------+
| 1 Byte  | 2 Byte  | 2 Byte | 6 Byte | 2 Byte |            |       |
+---------+---------+--------+--------+--------+------------+-------+
| Content | Version | epoch  |  seq_  | Length | Ciphertext |  MAC  |
|   Type  | Ma | Mi |        | number |        |   (Enc)    | (Enc) |
+---------+---------+--------+--------+--------+------------+-------+

							
	struct {
   		opaque salt[4];
   		opaque nonce_explicit[8];
   	} CCMNonce;

							
	struct {
   		uint32 client_write_IV; // low order 32-bits
   		uint64 seq_num;         // TLS sequence number
   	} CCMClientNonce.

   	struct {
   		uint32 server_write_IV; // low order 32-bits
   		uint64 seq_num; 		// TLS sequence number
   	} CCMServerNonce.

							
   +---------+---------+--------+--------+-----------+--------+
   | 1 Byte  | 2 Byte  | 2 Byte | 1 Byte | 5 Byte    | 2 Byte |
   +---------+---------+--------+--------+-----------+--------+
   | Content | Version | Epoch  | Sender | trunc_seq_| Length |
   |   Type  | Ma | Mi |        |   ID   | number    |        |
   +---------+---------+--------+--------+-----------+--------+