Transport-layer Multicast Security for Low-Power and Lossy Networks (LLNs)
draft-kumar-dice-multicast-security-00

Abstract

CoAP and 6LoWPAN are fast emerging as the de-facto protocol standards in the area of resource-constrained devices forming Low-power and Lossy Networks (LLNs). Unicast communication in such networks are secured at the transport layer using DTLS, as mandated by CoAP. For various applications, IP multicast-based group communications in such networks provide clear advantages. However, at this point, CoAP does not specify how to secure group communications in an interoperable way. This draft specifies two methods for securing CoAP-based group communication at the transport layer and targets deployment scenarios that may require group authentication, respectively source authentication. The specification leverages the fact that DTLS is already used as the mechanism of choice to secure unicast communications and allows group communications security to be implemented as an extension of DTLS record layer processing, thereby minimizing incremental implementation cost.

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 September 10, 2015.

Copyright Notice

Copyright (c) 2015 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
• 2.1. Group Communication Use Cases
• 2.2. Security Requirements
• 3. Overview of Transport level Secure Multicast
• 3.1. Setting up Group Security Association
• 3.2. Group Communication packets
• 4. Group-level Data Authenticity
• 4.1. Group message format
• 4.2. Group message processing
• 4.2.1. Sending Secure Multicast Messages
• 4.2.2. Receiving Secure Multicast Messages
• 5. Source-level Data Authenticity
• 5.1. Group message format
• 5.2. Group message processing
• 5.2.1. Sending Secure Multicast Messages
• 5.2.2. Receiving Secure Multicast Messages
• 6. Security Considerations
• 6.1. Late joiners
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

There is an ever growing number of electronic devices, sensors and actuators that have become wireless and Internet connected, thus creating a trend towards the Internet-of-Things (IoT). These connected devices are equipped with communication capability based on CoAP [RFC7252] and 6LoWPAN [RFC6347] standards that enables them to interact with each other as well as with the wider Internet services. However, the devices in such wireless 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 would allow devices to interact with each other, group communication is an important feature in LLNs. It is more effective in LLNs 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 lighting control system, 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 for LLNs is based on the CoAP sent over IP- multicast [RFC7390].

Currently, CoAP messages are protected using Datagram Transport Layer Security (DTLS) [RFC6347]. However, DTLS is mainly used to secure a connection between two endpoints and it cannot be used to protect multicast group communication. Group communication in LLNs 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.). Although there have been a lot of efforts in IETF to standardize mechanisms to secure multicast communication [RFC3830] [RFC4082] [RFC3740] [RFC4046] [RFC4535], they are not necessarily suitable for LLNs 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 with good time synchronization. [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 LLNs.

An existing IP multicast security protocol could be used after profiling as shown in [I-D.mglt-dice-ipsec-for-application-payload]. However since DTLS is already mandated for CoAP unicast, this would require an additional security protocol to be implemented on constrained devices. This draft describes an alternative transport layer approach by reusing already available functionalities in DTLS. This allows CoAP group communication security to be implemented with minimal additional resources as an extension to the DTLS record layer processing.

1.1. Terminology

This specification uses the following terminology:

• Group Controller: Entity responsible for creating a multicast group and establishing security associations among authorized group members. This entity is also responsible for renewing/updating multicast group keys and related policies.
• Sender: Entity that sends data to the multicast group. In a 1-to-N multicast group, only a single sender transmits data to the group; in an M-to-N multicast group (where M and N do not necessarily have the same value), M group members are senders.
• Listener: Entity that receives multicast messages when listening to a multicast IP address.
• Security Association (SA): Set of policies and cryptographic keying material that together provide security services to network traffic matching this policy [RFC3740]. Here, a Security Association usually includes 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: A bundling of security associations (SAs) that together define how a group communicates securely [RFC3740].
• Keying material: Data specified as part of the SA that is necessary to establish and maintain a cryptographic security association, such as keys, key pairs, and IVs [RFC4949].
• Group authentication: Evidence that a received group message originated from some member of this group. This provides assurances that this message was not tampered with by an adversary outside this group, but does not pinpoint who precisely in the group originated this message.
• Source authentication: Evidence that a received group message originated from a specifically identified group member. This provides assurances that this message was not tampered with by any other group member or an adversary outside this group.

1.2. Outline

The remainder of this draft is organized as follows. Section 2 provides use cases for group communications with LLNs. Section 3 provides an overview of transport layer secure multicasting, while Section 4 and Section 5 provide the detailed specifications for securing multicast messaging providing for group authentication and source authentication, respectively.

2. Use Cases

This section introduces some use cases for group communications in LLNs and identifies a set of security requirements for these use cases.

2.1. Group Communication Use Cases

"Group Communication for CoAP" [RFC7390] provides the necessary background for multicast-based CoAP communication in 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 group communication uses cases with detailed descriptions.

1. 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 or corridor 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 logical multicast groups to be formed even if devices in the lighting group may be physically in different subnets (e.g. on wired and wireless networks). Group communications enables synchronous operation of a group of 6LoWPAN connected lights ensuring that the light preset (e.g. dimming level or color) of a large group of luminaires are changed at the same perceived time. This is especially useful for providing a visual synchronicity of light effects to the user.
2. Integrated Building control: enabling Building Automation and Control Systems to control multiple heating, ventilation and air-conditioning units to pre-defined presets.
3. Software and Firmware updates: software and firmware updates often comprise quite a large amount of data and can, thereby, overload an LLN that is otherwise typically used to communicate only small amounts of data infrequently. Multicasting such updated data to a larger group of devices at once, rather than sending this as unicast messages to each individual device in turn, can significantly reduce the network load and may also decrease the overall time latency for propagating this data to all devices. With updates of relatively large amounts of data, securing the individual messages is important, even if the complete update itself is secured as a whole, since checking individual received data piecemeal for tampering avoids that devices store large amounts of partially corrupted data and may detect tampering hereof only after all data has been received.
4. Parameter and Configuration update: settings of a group of similar devices are updated simultaneously and efficiently. Parameters could be, for example, network load management or network access controls
5. Commissioning of LLN systems: querying information about the devices in the local network and their capabilities, e.g., by a commissioning device.
6. Emergency broadcast: a particular emergency related information (e.g. natural disaster) is relayed to multiple devices.

2.2. Security Requirements

"Group Communications for CoAP" [RFC7390] already defines a set of security requirements for group communication in LLNs. We re-iterate and further describe those security requirements in this section with respect to the use cases:

1. Group 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 a simple lighting control use case, a switch would be the only entity that is responsible for sending control commands to a group of lighting devices. In more advanced lighting control use cases, an M-to-N 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. Group-level data confidentiality: Data confidentiality may be required if privacy sensitive data is exchanged in the group. Confidentiality is only required at the group level since any member of the group can decrypt the message.
3. Group-level authentication and integrity: In certain use cases, it is sufficient to ensure the weaker group-level authentication of group messages. Such cases include M-to-N communication topology where M senders all perform similar roles and where M is of approximately the same size as group size N. Group-level authentication is achieved by a single group key that is known to all group members and used to provide authenticity to the group messages (e.g., using a Message Authentication Code, MAC).
4. Source-level authentication: Certain use-cases require a stronger source-level authentication of group messages. This is especially needed in M-to-N communication topology, where M is closer to 1. Source authentication can be provided using public-key cryptography in which every group message is signed by its sender.

3. Overview of Transport level Secure Multicast

The IETF CoRE WG has selected DTLS [RFC6347] as the default must-implement security protocol for securing CoAP unicast traffic. The goal of this draft is to secure CoAP Group communication with minimal additional overhead on resource-constrained embedded devices. We propose to reuse some of the functionalities of DTLS such that a transport-layer multicast security solution can be implemented by extending the DTLS implementation (that already exists on these devices) with minimal adaptation.

We first give a general overview of how the transport-layer multicast security can be implemented and then provide two variations: one for group authentication and the other for source authentication.

3.1. Setting up Group Security Association

A group controller in an LLN creates a multicast group. The group controller may be hosted by a remote server, or a border router that creates a new group over the network. In some cases, devices may be configured using a commissioning tool that mediates the communication between the devices and the group controller. The controller in the network can be discovered by the devices using various methods defined in [I-D.vanderstok-core-dna] such as DNS-SD [RFC6763] and Resource Directory [I-D.ietf-core-resource-directory]. The group controller communicates with individual device in unicast to add them to the new group. This configuration can be done as unicast CoAP based messages sent over a DTLS secured link. The CoAP resource on the devices that is used to configure the group [RFC7390]can also be used to configure the devices with the Group Security Association (GSA) consisting of keying material, security policies security parameters and ciphersuites. [Note: The details of the CoAP based configuration needs further elaboration in a new revision.]

3.2. Group Communication packets

Senders in the group can authenticate and/or encrypt the CoAP group messages using the keying material in the GSA. The authenticated and/or encrypted message contains a security header which includes a replay counter. This is passed down to the lower layer of the IPv6 protocol stack for transmission to the multicast address as depicted in Figure 1.

						
+--------+-+---------------------------------------------+-+
|        | +---------------------------------------------+ |
|        | |        | +--------------------------------+ | |
|        | |        | |             | +--------------+ | | |
|   IP   | |   UDP  | |  Security   | |   multicast  | | | |
| header | | header | |   Header    | |    message   | | | |
|        | |        | |             | +--------------+ | | |
|        | |        | +--------------------------------+ | |
|        | +---------------------------------------------+ |
+--------+-+---------------------------------------------+-+

							
	CipherSuite
	server write MAC key	
	server write encryption key	
	server write IV 
	SenderID	

	
	struct {
		  ConnectionEnd          entity;
		  PRFAlgorithm           prf_algorithm;
		  BulkCipherAlgorithm    bulk_cipher_algorithm;
		  CipherType             cipher_type;
		  uint8                  enc_key_length;
		  uint8                  block_length;
		  uint8                  fixed_iv_length;
		  uint8                  record_iv_length;
		  MACAlgorithm           mac_algorithm;
		  uint8                  mac_length;
		  uint8                  mac_key_length;
		  CompressionMethod      compression_algorithm;
		  opaque                 master_secret[48];
		  opaque                 client_random[32];
		  opaque                 server_random[32];
	} SecurityParameters;
		

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

							
	CipherSuite
	{SenderID, SenderID Private Key}  
	server write encryption key	
	server write IV 
	

							
	CipherSuite
	{SenderID1, SenderID1 Public Key} 
	{SenderID2, SenderID2 Public Key}
	{SenderID3, SenderID3 Public Key}
	...
	server write encryption key	
	server write IV 

	
	struct {
		  ConnectionEnd          entity;
		  PRFAlgorithm           prf_algorithm;
		  BulkCipherAlgorithm    bulk_cipher_algorithm;
		  CipherType             cipher_type;
		  uint8                  enc_key_length;
		  uint8                  block_length;
		  uint8                  fixed_iv_length;
		  uint8                  record_iv_length;
		  MACAlgorithm           mac_algorithm;
		  uint8                  mac_length;
		  uint8                  mac_key_length;
		  CompressionMethod      compression_algorithm;
		  opaque                 master_secret[48];
		  opaque                 client_random[32];
		  opaque                 server_random[32];
	} SecurityParameters;
		

						
+---------+---------+--------+--------+--------+------------+-------+
| 1 Byte  | 2 Byte  | 2 Byte | 6 Byte | 2 Byte |            |       |
+----------------------------------------------------------------+--+
| Content | Version | epoch  |  seq_  | Length | Ciphertext | Sig-  |
|   Type  | Ma + Mi |        | number |        |  (if enc)  | nature|
+---------+----+----+--------+--------+--------+------------+-------+