DICE Working Group M. Tiloca Internet-Draft S. Raza Intended Status: Standards Track SICS Swedish ICT AB Expires: April 16, 2016 K. Nikitin EPFL S. Kumar Philips Research October 14, 2015 Secure Two-Way DTLS-Based Group Communication in the IoT draft-tiloca-dice-secure-groupcomm-00 Abstract CoAP has emerged as the de-facto IoT standard for communication involving resource-constrained devices composing Low-power and Lossy Networks (LLNs). CoAP mandates the adoption of the DTLS protocol to secure unicast communication. However, in several IoT application scenarios involving a group of multiple devices, the adoption of CoAP multicast communication through IPv6 results in a number of advantages, especially in terms of performance and scalability. Yet, CoAP does not specify how to secure multicast group communication in an interoperable way. This draft presents a method to secure communication in a multicast group, through an adaptation of the DTLS record layer. In particular, group members rely on the same group keying material in order to secure both request messages sent via multicast and possible unicast messages sent as response. Since the group keying material is provided upon joining the group, all group members are not required to perform any DTLS handshake with each other. The proposed method makes it possible to provide either group authentication or source authentication of secured messages. 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." Tiloca Expires April 16, 2016 [Page 1] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 This Internet-Draft will expire on April 16, 2016. Copyright and License 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 6 2.1 Group Communication Use Cases . . . . . . . . . . . . . . . 6 2.2 Security Requirements . . . . . . . . . . . . . . . . . . . 8 3. Overview of DTLS-based Secure Multicast . . . . . . . . . . . . 10 3.1 IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Two-way Secure Group Communication . . . . . . . . . . . . . 12 4. Security Data Structures . . . . . . . . . . . . . . . . . . . 13 4.1 Group Security Association . . . . . . . . . . . . . . . . . 13 4.2 Security parameter structure . . . . . . . . . . . . . . . . 15 4.3 Connection states . . . . . . . . . . . . . . . . . . . . . 16 5. Secure multicast messages . . . . . . . . . . . . . . . . . . . 18 5.1 On truncating the sequence number field . . . . . . . . . . 18 5.2 Sending secure group request messages . . . . . . . . . . . 19 5.3 Receiving secure group request messages . . . . . . . . . . 20 6. Secure unicast responses to multicast messages . . . . . . . . 21 6.1 Derivation of listener individual keying material . . . . . 22 6.2 Sending secure group response messages . . . . . . . . . . . 24 6.3 Receiving secure group response messages . . . . . . . . . . 25 7. Revocation and redistribution of group security material . . . 26 7.1 Periodical rekeying. . . . . . . . . . . . . . . . . . . . . 27 7.2 Join rekeying. . . . . . . . . . . . . . . . . . . . . . . . 28 7.3 Leave rekeying. . . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 29 9.1 Group-level security . . . . . . . . . . . . . . . . . . . . 29 9.2 Prevention of attacks based on IP spoofing . . . . . . . . . 30 Tiloca Expires April 16, 2016 [Page 2] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 9.3 Nonce reuse in authenticated encryption . . . . . . . . . . 30 9.4 Late joining nodes . . . . . . . . . . . . . . . . . . . . . 31 9.5 Uniqueness of SenderIDs . . . . . . . . . . . . . . . . . . 31 9.6 Same GroupID in different multicast groups . . . . . . . . . 32 9.7 Reduced sequence number space . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.1 Normative References . . . . . . . . . . . . . . . . . . . 32 10.2 Informative References . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 1 Introduction Nowadays it is possible to connect the physical and cyber world by embedding a tiny computer, with limited storage and communication capabilities, in everyday physical objects. The resultant smart objects can be connected not only with each other in Low-Power and Lossy Networks (LLNs), but also with the Internet, so actively taking part to the Internet of Things (IoT). In the IoT, smart objects can interact with each other through different communication paradigms, namely one-to-one, one-to-many, and many-to-many. Besides, different communication and networking protocols are standardized to enable interactions between smart objects. For instance, 6LoWPAN [RFC6282] enables IP capabilities, RPL [RFC6550] enables routing capabilities, and CoAP [RFC7252] enables web capabilities. In particular, CoAP has become the de-facto web standard for the IoT, and mandates the adoption of the DTLS protocol [RFC6347] to provide secure communication, if requested. More recently, [RFC7390] has enabled group communication for CoAP, highlighting various use cases where smart objects benefit from a group communication model. There are multiple use cases where secure group communication is highly convenient or even inevitable, such as lightening control, integrated building control, software and firmware updates, parameter and configuration updates, commissioning of 6LoWPAN networks, and emergency broadcasts. While in several real-world IoT deployments such use cases require security as well, CoAP does not currently specify how to secure multicast group communication. Since DTLS is the mandated security protocol for unicast communication in the IoT, it makes particular sense to extend DTLS in order to enable secure multicast communication among smart objects. Although IPsec multicast [RFC5374] is a possible alternative, it would require to adopt additional heavyweight security protocols such as IPsec [RFC4301][RFC6040] and likely even IKEv2 [RFC7296]. Moreover, since unicast communication in the IoT is supposed to be protected through DTLS, switching to a full adoption of solutions based on IPsec becomes even less convenient and practical. Tiloca Expires April 16, 2016 [Page 3] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 There were previous attempts to enable secure DTLS-based group communication [I-D.keoh-dice-multicast-security-08][I-D.kumar-dice- multicast-security-00] for CoAP. However, they were questioned due to a number of reasons. First, more relevant use uses cases were expected to be provided and more strongly motivated. Second, since group authentication may be not enough for many use cases, source authentication was pointed out as a fundamental option to be available. Third, the initial lack of protection for group response messages was covered by adopting traditional DTLS unicast session. This is prone to practical issues and can result in performance degradation, especially on large scale, dynamic, groups. Following the discussions around previous proposals, there is a consensus that secure group communication is indeed necessary and desirable, but specific methods proposed so far to achieve it were questioned. In this draft, we propose an approach providing secure two-way DTLS- based group communication in the IoT, overcoming the limitations of previous proposals. This draft particularly focuses on the following goals: i) avoiding the need to implement multiple security protocols, by extending the DTLS record layer; ii) protecting multicast request messages as well as related unicast response messages in the group; iii) making it possible to ensure source or group authentication of both group request messages and group response messages; and iv) avoiding any DTLS handshake to enable secure group communication. 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: o Keying material: Data that is necessary to establish and maintain a cryptographic security association. This includes, for instance, keys, key pairs, and IVs [RFC4949]. o Security Association (SA): Set of policies and cryptographic keying material that together provide security services to network traffic matching this policy [RFC3740]. In this draft, a Security Association includes, together with possible additional ones, the following attributes: * selectors, e.g. source and destination transport addresses; * properties, such as identities of involved entities; * cryptographic policy, e.g. the algorithms, modes, key Tiloca Expires April 16, 2016 [Page 4] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 lifetimes, and key lengths used for the authentication or confidentiality processes; * keying material used for the authentication, encryption and signing processes. o Group Security Association: A bundling of security associations (SAs) that together define how members of a multicast group communicate securely [RFC3740]. o Group Controller (GC): Entity responsible for creating a multicast group, establishing security associations among authorized group members, and managing the joining of new group members. This entity may also be responsible for renewing/updating multicast group keys and related policies, i.e. act as group key manager. The GC is not required to be an actual member of the multicast group and to take part in the group communication. o Sender: Entity in a multicast group that sends data as multicast messages to the 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. o Listener: Entity in a multicast group that receives multicast messages when listening to the multicast IPv6 address associated to the multicast group. A listener MAY reply back, by sending a unicast response message to the sender which has sent the multicast message. o Group request: Multicast message sent by a sender in the group to all listeners in the group through multicast IPv6. o Group response: Unicast message sent back by a listener node in the group as a response to a group request received by a sender. o Group authentication: Evidence that a received message originated from some member of this group. This provides assurances that the message was not tampered with by an adversary outside this group, but does not pinpoint and/or assure what specific entity in the group originated the message. o Source authentication: Evidence that a received message originated from a specifically identified group member. This provides assurances that the message was not tampered with by any other group member or an adversary outside this group. 1.2 Outline Tiloca Expires April 16, 2016 [Page 5] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 The remainder of this draft is organized as follows. Section 2 describes some relevant group communication use cases in the IoT and identifies a set of security requirements. Section 3 overviews the proposed two-way DTLS-based secure group communication, assuming that the group members already have in their possession everything required to fully operate. Section 4 presents the security data structures referred throughout this draft. Then, Sections 5 and 6 describe the details of the adaptation of the DTLS record layer, to secure multicast request messages and unicast reply messages, respectively. Section 7 discusses considerations related to the revocation and redistribution of security material in the multicast group. Section 9 presents the security considerations. 2. Use Cases and Requirements This section introduces some use cases for group communication in the IoT and identifies a set of related security requirements. 2.1 Group Communication Use Cases "Group Communication for CoAP" [RFC7390] provides the necessary background for multicast-based CoAP communication, with particular reference to low-power and lossy networks (LLNs) and resource constrained devices. 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 use cases with detailed descriptions. a. Lighting control: consider a building equipped with 6LoWPAN [RFC4944][RFC6282] IP-connected lighting devices, switches, and 6LoWPAN border routers. The devices are organized into groups according to their physical location in the building. For instance, lighting devices and switches in a room or corridor can be configured as members of a single multicast group. Switches are then used to control the lighting devices, by sending on/off/dimming commands to all lighting devices in a group. 6LoWPAN border routers that are connected to an IPv6 network backbone (which is also multicast-enabled) are used to interconnect 6LoWPAN routers 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 communication 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. Devices may reply back to the switches that issue on/off/dimming commands, in order to Tiloca Expires April 16, 2016 [Page 6] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 report about the execution of the requested operation (e.g. OK, failure, error) and their current operational status. b. Integrated building control: enabling Building Automation and Control Systems (BACSs) to control multiple heating, ventilation and air-conditioning units to pre-defined presets. Controlled units can be organized into multicast groups in order to reflect their physical position in the building, e.g. devices in the same room can be configured as members of a single multicast group. Furthermore, controlled units are expected to possibly reply back to the BACS issuing control commands, in order to report about the execution of the requested operation (e.g. OK, failure, error) and their current operational status. c. Software and firmware updates: software and firmware updates often comprise quite a large amount of data. Therefore, it can overload an LLN that is otherwise typically used to deal with only small amounts of data, on an infrequent base. Rather than sending software and firmware updates as unicast messages to each individual device, multicasting such updated data to a larger group of devices at once displays a number of benefits. For instance, it can significantly reduce the network load and decrease the overall time latency for propagating this data to all devices. Even if the complete whole update process itself is secured, securing the individual messages is important, in case updates consist of relatively large amounts of data. In fact, checking individual received data piecemeal for tampering avoids that devices store large amounts of partially corrupted data and that they detect tampering hereof only after all data has been received. Devices receiving software and firmware updates are expected to possibly reply back, in order to provide a feedback about the execution of the update operation (e.g. OK, failure, error) and their current operational status. d. Parameter and configuration update: by means of multicast communication, it is possible to update the settings of a group of similar devices, both simultaneously and efficiently. Possible parameters are related, for instance, to network load management or network access controls. Devices receiving parameter and configuration updates are expected to possibly reply back, to provide a feedback about the execution of the update operation (e.g. OK, failure, error) and their current operational status. e. Commissioning of LLNs systems: a commissioning device is responsible for querying all devices in the local network or a selected subset of them, in order to discover their presence, and be aware of their capabilities, default configuration, and operating conditions. Queried devices displaying similarities in Tiloca Expires April 16, 2016 [Page 7] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 their capabilities and features, or sharing a common physical location can be configured as members of a single multicast group. Queried devices are expected to reply back to the commissioning device, in order to notify their presence, and provide the requested information and their current operational status. f. Emergency broadcast: a particular emergency related information (e.g. natural disaster) is generated and broadcast by an emergency notifier, and relayed to multiple devices. The latters may reply back to the emergency notifier, in order to provide their feedback and local information related to the ongoing emergency. 2.2 Security Requirements The following security requirements are out of the scope of this draft and are assumed to be already fulfilled: a. Establishment of a GSA: A secure mechanism must be used to distribute keying material, 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 network, or a remote server outside the 6LoWPAN network, could play the role of the Group Controller. However, the GSA establishment is out of 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][RFC4535]. b. Multicast data security ciphersuite: All group members MUST agree on a ciphersuite to provide authenticity, integrity and confidentiality of messages in the multicast group. The ciphersuite is specified as part of the GSA. Typically, authenticity is more important than confidentiality in LLNs. Therefore, the approach described in this draft MUST support at least ciphersuites with MAC only (NULL encryption) and AEAD [RFC5116] ciphersuites. Other ciphersuites defined for data record security in DTLS SHOULD also be preferably supported. c. Backward security: A new device joining the multicast group should not have access to any old GSAs used before its joining. This ensures that a new group member is not able to decrypt confidential data sent before it has joined the group. The adopted key management scheme should ensure that the GSA is updated to ensure backward confidentiality. The actual mechanism to update the GSA and renew the group keying material upon a group member's joining has to be defined as part of the group key management scheme. Tiloca Expires April 16, 2016 [Page 8] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 d. Forward security: Entities that leave the multicast group should not have access to any future GSAs or message exchanged within the group after their leaving. This ensures that a former group member is not able to decrypt confidential data sent within the group anymore. Also, it ensures that a former member is not able to send encrypted and/or integrity protected messages to the group anymore. The actual mechanism to update the GSA and renew the group keying material upon a group member's leaving has to be defined as part of the group key management scheme. The following security requirements need to be fulfilled by the approach described in this draft: a. Multicast communication topology: This draft considers both 1-to-N (one sender and multiple listeners) and M-to-N (multiple senders and 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 instance, in the lighting control use case, switches are the only entities responsible for sending commands to a group of lighting devices. In more advanced lighting control use cases, a M-to-N communication topology would be required, for instance in case multiple sensors (presence or day-light) are responsible to trigger events to a group of lighting devices. b. Multicast group size: Security solutions for group communication SHOULD be able to adequately support different, possibly large, group sizes. Group size is the combination of the number of senders and listeners in a multicast group, with possible overlap (i.e. a sender MAY also be a listener at the same time). In the use cases mentioned in this draft, the number of senders (normally the controlling devices) is much smaller than the number of listeners (i.e. the controlled devices). A security solution for group communication that supports 1 to 50 senders would be able to properly cover the group sizes required for most use cases that are relevant for this draft. The total number of group members is expected to be in the range of 2 to 100 devices. Groups larger than that SHOULD be divided into smaller independent multicast groups, e.g. by grouping lights in a building on a per floor basis. c. Data replay protection: It MUST NOT be possible to replay a group request message or group response message, which would disrupt the correct communication in the group and the activity of group members. d. Group-level data confidentiality: Messages sent within the multicast group SHOULD be encrypted. In fact, some control Tiloca Expires April 16, 2016 [Page 9] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 commands and/or associated responses could pose unforeseen security and privacy risks to the system users, when sent as plaintext. In particular, data confidentiality MAY be required if privacy sensitive data is exchanged in the group. This draft considers group-level data confidentiality since messages are encrypted at a group level, i.e. in such a way that they can be decrypted by any member of the multicast group, but not by an external adversary or other external entities. e. Data authentication: Messages sent within the multicast group SHOULD be authenticated. That is, it is essential to ensure that a message is originated by a generic member of the group (group- level data authentication) or a specific member of the group (source-level data authentication). The approach proposed in this draft makes it possible to provide group-level data authentication or source-level data authentication, both for group requests originated by sender nodes and group responses originated by listener nodes. In case group-level data authentication is considered, it is assumed that all group members are trusted not to tamper with the messages sent within the group, and the common group keying material is used to authenticate messages. In case source-level data authentication is considered, messages are signed by their respective originator group member by means of public-key cryptography. f. Data integrity: Messages sent within the multicast group SHOULD be integrity protected. That is, it is essential to ensure that a message has not been tampered with by an external adversary or other external entities which are not group members. Data integrity is provided through the same means used to provide data authentication. 3. Overview of DTLS-based Secure Multicast This draft describes how to adapt the DTLS protocol to secure group communication. To this end, we propose an extension of DTLS, based on minimal adaptation to the DTLS record layer [RFC6347]. Reusing the DTLS protocol for different purposes can guarantee the required level of security, while avoiding the need to implement multiple security protocols. This is especially beneficial when the target deployment consists of embedded, resource-constrained, devices. DTLS has been selected as the default, must-implement, security protocol for securing communication relying on the CoAP protocol [RFC7252]. Therefore, it is desirable that DTLS is also accordingly extended to secure CoAP-based group communication [RFC7390]. Nevertheless, the DTLS extension described in this draft does not imply the usage of the CoAP protocol. That is, different protocols Tiloca Expires April 16, 2016 [Page 10] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 can be adopted at the application level, provided that they support the presence of DTLS. This section first presents group communication based on IPv6 multicast, and then overviews a possible adaptation of DTLS to secure group communication. In particular, the proposed approach makes it possible to secure group request sent by senders as multicast messages and related group responses sent back by listeners as unicast messages. Also, it makes it possible to provide source authenticity of group messages, both for group requests and group responses. Finally, unless otherwise necessary to establish further specific secure sessions, the proposed approach does not require to perform any DTLS handshake between group members. 3.1 IPv6 Multicast Group members are categorized into two possible roles, namely sender and listener. Any group member may have one of these roles, or both roles. The application(s) running on a group member is supposed to determine these roles, depending on the intended interactions with the communication stack. 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 |---------| ++++ | | \ ++|B | ++++ \-----| | Sender ++++ Listeners Figure 1: Example of a 1-to-N multicast communication 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. This in turn requires the joining device to register with a network routing device, signaling the intent to receive packets sent to that particular IPv6 multicast group. Figure 1 depicts an example of 1-to-N multicast communication and the roles of the group members. In principle, any device can decide to listen to any IPv6 multicast address. This also means that applications on the other group members do not know, or do not get notified, when new listeners join the multicast group. More details on the IPv6 multicast and CoAP group communication can be found in [RFC7390]. Tiloca Expires April 16, 2016 [Page 11] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 This draft does not intend to modify any of the underlying group communication or multicast routing protocols. 3.2 Two-way Secure Group Communication This draft assumes the presence of a group controller (GC), i.e. a dedicated entity that creates and manages the multicast group. The group controller may be hosted by a remote server or be a border router. In some cases, devices that intend to join the multicast group may be configured by means of a commissioning tool that mediates the communication between them and the group controller. Devices can discover the group controller by 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 devices to add them to the group. Additionally it provides them with the GSA, consisting of the keying material, security policies, security parameters and ciphersuites. To this end, the group controller relies on standardized key management mechanisms which are out of the scope of this draft. Additional ciphersuites may need to be defined to convey the bulk cipher algorithm, MAC algorithm and key lengths within the key management protocol. A sender in the multicast group encrypts and authenticates a group request multicast message by using the group keying material to process the DTLS record. Then, the group request is passed down to the lower layer of the IP protocol stack for transmission to the multicast address as depicted in Figure 2. Upon receiving the group request, the listeners use the multicast IP destination address and port number (i.e., Multicast identifier) to look up the GSA associated to that group connection. The received group request is then decrypted and its authenticity is verified. More details about how group requests are processed in the multicast group are provided in Section 5. A listener MAY reply back to the sender that originated the group response, by means of a unicast group response message. The listener secures the group response by means of individual keying material derived from the group keying material in the GSA and used to process the DTLS record. Then, the group response is passed down to the lower layer of the IP protocol stack for transmission to the unicast address of the sender, as depicted in Figure 2. Upon receiving the group response, the sender considers the group keying material in the GSA, and uses it to derive the individual keying material associated to the listener that has sent the group response. The received group response is then decrypted and its authenticity is verified. More details about how group responses are processed in the multicast group are provided in Section 6. Tiloca Expires April 16, 2016 [Page 12] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 +--------+-------------------------------------------------+ | | +--------+------------------------------------+ | | | | | +-------------+------------------+ | | | | | | | | +--------------+ | | | | IP | | UDP | | DTLS Record | | Group | | | | | header | | header | | Header | | message | | | | | | | | | | +--------------+ | | | | | | | +-------------+------------------+ | | | | +--------+------------------------------------+ | +--------+-------------------------------------------------+ Figure 2: A message protected using the group DTLS Record Layer While assuring two-way secure communication within the multicast group, the approach described in this draft also displays the following benefits. First, the commonly shared group keying material makes it possible to avoid the performance of DTLS handshakes altogether, unless otherwise necessary to establish pairwise secure sessions among group members. As a consequence, it does not substantially affect performance of group members (especially if senders), with further benefits in terms of network readiness and availability. Second, senders can remain unaware of current and future listener nodes in the multicast group. Third, listener nodes are able to securely reply back to sender nodes, without performing a DTLS handshake first. This is aligned with the guidelines for CoAP group communication [RFC7252], according to which the endpoint acting as the CoAP client (i.e. the sender node) SHOULD also act as the DTLS client (i.e. start the DTLS handshake). 4. Security Data Structures This section overviews the security data structures referred by the approach proposed in this draft. In particular, Section 4.1 discusses the Group Security Association (GSA) owned by all members of the multicast group. Then, Section 4.2 overviews the security parameter structure. Finally, Section 4.3 discusses the connection states referred by senders or listeners in the multicast group. 4.1 Group Security Association The GSA contains the following elements. Some of them can be not set or not relevant, as explained below. Every node owns the GSA of each multicast group where it is a member. GroupID SenderID CipherSuite client write IV Tiloca Expires April 16, 2016 [Page 13] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 server write IV client write encryption key server write encryption key client write MAC key server write MAC key source_authentication Member Private Key {SenderID1, SenderID1 Public Key} {SenderID2, SenderID2 Public Key} ... {Listener1 IP address, Listener1 Public Key} {Listener2 IP address, Listener2 Public Key} ... a. The GroupID has the same value for all the group members, and practically represents a short alias for the multicast IP address associated to the multicast group. In the approach described in this draft, the GroupID assumes a value in the range between 0 and 255 included. b. The SenderID value is relevant only for group members configured (also) as senders, and is provided by the GC upon joining the group. A SenderID value MUST be unique within the multicast group at any time, i.e. the multicast group MUST NOT include more than one member configured (also) as sender and associated to a given SenderID value. In the approach described in this draft, a SenderID assumes a value in the range between 0 and 255 included. The GC provides a list of active sender nodes and their respective SenderID to all the listener nodes in the multicast group. c. The GC chooses a CipherSuite which is specified in the GSA of all the members of the multicast group. If the flag source_authenticity is set to TRUE, CipherSuite MUST support source authentication based on public key cryptography. All the members of the multicast group MUST support the CipherSuite specified in the GSA. d. The same group keying material client write IV, server write IV, client write encryption key, server write encryption key, client write MAC key and server write MAC key is derived for all members of the multicast group. To this end, all group members consider the security parameters master_secret[48], client_random[32] and server_random[32] in Section 4.2, and rely on the PRF function defined in Section 6.3 of [RFC5246] to derive the group keying material. Every listener node, before processing its first group response message addressed to a given sender node, derives additional individual keying material and stores it separately (see Section 6). From then on, the listener node considers this Tiloca Expires April 16, 2016 [Page 14] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 individual keying material as the client write encryption key and client write MAC key used when securing outgoing group response messages addressed to that sender node (see Section 6). That is, the client write encryption key and client write MAC key in the GSA on the listener nodes are not affected. When receiving a group request message from that listener node for the first time, that sender node derives the same individual keying material in order to process incoming group response messages from that sender node (see Section 6), and stores it separately. That is, the client write encryption key and client write MAC key in the GSA on the sender nodes are not affected. e. The source_authentication flag is set to TRUE if it is required to provide source authentication of all multicast group request messages sent by all sender nodes and all unicast group response messages sent by all listener nodes. Conversely, the source_authentication is set to FALSE if it is required to provide only group authentication to all multicast group request messages sent by all sender nodes and all unicast group response messages sent by all listener nodes. f. If the source_authentication flag is set to TRUE, every member of the multicast group stores its own asymmetric private key in the Member Private Key field. Conversely, if the source_authentication flag is set to FALSE, the Member Private Key field is neither set nor relevant on any member of the multicast group. g. If the source_authentication flag is set to TRUE, every listener node stores the public key of each sender node in the multicast group, together with the respective SenderID. In principle, listener nodes can be provided with the senders' public keys upon joining the group. As an alternative, a listener node can ask a trusted Certification Authority for a sender's public key, upon receiving a multicast group request message from that sender node for the first time. More details about the retrieval and verification of senders' public keys are out of the scope of this draft. h. If the source_authentication flag is set to TRUE, every sender node stores the public key of each listener node in the multicast group, together with the respective IP address. In principle, sender nodes can ask a trusted Certification Authority for a listener's public key, upon receiving a unicast group response message from that listener node for the first time. More details about the retrieval and verification of senders' public keys are out of the scope of this draft. 4.2 Security parameter structure Tiloca Expires April 16, 2016 [Page 15] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 The Group Controller provides the following security parameter structure to all members of the multicast group, upon their joining. This structure reflects the definition in [RFC5246], with three additional fields in order to provide source authentication in the group, if required. 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; SignatureAlgorithm signature_algorithm; uint8 signature_key_length; uint8 signature_length; CompressionMethod compression_algorithm; opaque master_secret[48]; opaque client_random[32]; opaque server_random[32]; } SecurityParameters; a. SecurityParameters.entity is set to ConnectionEnd.server for sender nodes and ConnectionEnd.client for listener nodes. b. The parameters bulk_cipher_algorithm, cipher_type, enc_key_length, block_length, fixed_iv_length, record_iv_length, mac_algorithm, mac_length, mac_key_length, signature_algorithm, signature_key_length and signature_length are set to the same value for all the members in the multicast group, based on the ciphersuite specified in the GSA. In particular, the parameters signature_algorithm, signature_key_length and signature_length are set only if the flag source_authentication in the GSA is set to TRUE. Also, the parameters mac_algorithm, mac_length and mac_key_length are set only if the flag source_authentication in the GSA is set to FALSE and the ciphersuite specified in the GSA supports message authenticity. c. The parameters prf_algorithm, compression_algorithm, master_secret[48], client_random[32], and server_random[32] are set to the same value for all the members in the multicast group. 4.3 Connection states Tiloca Expires April 16, 2016 [Page 16] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 The group connection states are instantiated on the group members based on their role(s) in the group, according to the following rules. A group member configured as sender instantiates the following group connection states: o One write group connection state, instantiated during the sender node's initialization and referred while sending multicast group request messages. This group connection state contains an Epoch value and a Sequence Number value which is incremented for each DTLS record sent as part of an outgoing multicast group request message. The first of such DTLS records has 0 as Sequence Number value. o One read group connection state for each listener node in the multicast group. This kind of group connection state is instantiated upon receiving a unicast group response message from the associated listener node for the first time. Then, it is referred when receiving any further unicast group response message from the associated listener node. This group connection state contains an Epoch value and a Sequence Number value, which is updated according to the DTLS anti-replay mechanism, upon receiving a valid unicast group response message from the associated listener node. The Sequence Number value is initialized to 0. Also, the group connection state contains additional individual keying material related to the associated listener node, generated and used as described in Section 6. A group member configured as listener instantiates the following group connection states: o One write group connection state for each sender node in the multicast group, referred while sending unicast group response messages to the associated sender. This kind of group connection state is instantiated upon sending a unicast group response message to the associated sender node for the first time. Then, it is referred when sending any further unicast group response message to the associated sender node. This group connection state contains an Epoch value and a Sequence Number value which is incremented for each DTLS record sent as part of an outgoing unicast group response message to the associated sender node. The first of such DTLS records has 0 as Sequence Number value. Also, this write group connection state contains additional individual keying material related to the associated sender node, generated and used as described in Section 6. o One read group connection state for each sender node in the Tiloca Expires April 16, 2016 [Page 17] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 multicast group. This kind of group connection state is instantiated upon receiving a multicast group request message from the associated sender node for the first time. Then, it is referred when receiving any further multicast group request message from the associated sender node. This group connection state contains an Epoch value and a Sequence Number value, which is updated according to the DTLS anti-replay mechanism, upon receiving a valid multicast group request message from the associated sender node. The Sequence Number value is initialized to 0. 5. Secure multicast messages This section describes the adaptation of the DTLS Record layer to enable multiple sender nodes in the group to securely send multicast group request messages. +---------+---------+--------+--------+------------+--------+ | 1 Byte | 2 Byte | 2 Byte | 1 Byte | 5 Byte | 2 Byte | +---------+---------+--------+--------+------------+--------+ | Content | Version | Epoch | Sender | Trunc_seq_ | Length | | Type | Ma | Mi | | ID | number | | +---------+---------+--------+--------+------------+--------+ Figure 3: Adapted DTLS record header for multicast group requests Figure 3 shows the adapted DTLS record layer header, used when a sender node transmits a multicast group request message. The existing DTLS record layer header is adapted in such a way that the 6-octet Sequence_number field is split into a 1-octet SenderID field and a 5- octet "truncated" Trunc_seq_number field. The epoch is fixed and provided to the group members by the GC upon joining the multicast group. The Trunc_seq_number is initialized to 0 and is increased by one each time the sender node sends a new DTLS record, as part of a multicast group request message. The group request message is secured by the source sender node as described in Section 5.2, and processed by the recipient listener nodes as described in Section 5.3. 5.1 On truncating the sequence number field The rationale for having the Trunc_seq_number field together with the SenderID field is as follows. In the presence of multiple sender nodes in the multicast group, the sequence number values used by sender nodes need to be synchronized to avoid their reuse. Otherwise, multicast group request messages sent by different sender nodes may get discarded as replayed messages by the recipient listener nodes. Moreover, since all the sender nodes refer to the same group keying material, this would also result in Tiloca Expires April 16, 2016 [Page 18] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 nonce reuse in AEAD cipher suites like AES-CCM [RFC6655] and AES-GCM [RFC5288]. In particular, nonce reuse can completely break the security of these cipher suites. In fact, according to the AES-CCM specification for TLS [RFC6655], the CCMNonce is a combination of a salt value and the message sequence number, that is struct { opaque salt[4]; opaque nonce_explicit[8]; } CCMNonce; More in detail, the salt is the "client write IV" (when the client is sending) or the "server write IV" (when the server is sending). Besides, [RFC6655] states that the value of the nonce_explicit MUST be distinct for each distinct invocation of the CCM encrypt function for any fixed key. When the nonce_explicit is equal to the sequence number of the TLS packets, the CCMNonce has the following structure. 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; In DTLS, the 64-bit sequence number is composed of the 16-bit epoch value concatenated with the 48-bit sequence number value included in the DTLS record header. Therefore, in order to prevent that the CCMNonce is reused, either all the sender nodes in the multicast group are synchronized with each other, or separate non-overlapping sequence number spaces have to be created for each sender node. Synchronization between sender nodes is particularly difficult to achieve, especially among constrained devices and in LLNs. Therefore, this draft considers the second approach and separates the sequence number spaces by embedding a unique sender identifier, namely SenderID, in the sequence number, as suggested in [RFC5288]. It follows that the GC is also required to assign a unique SenderID to each device in the multicast group which is configured as sender. The GC provides a list of active sender nodes and their SenderID to all listener nodes in the multicast group. 5.2 Sending secure group request messages In order to send a DTLS record as part of a secure multicast group request message, a sender node proceeds as follows. Tiloca Expires April 16, 2016 [Page 19] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 1. The sender node determines the right GSA and write group connection state, based on the multicast IP destination address and destination port number. 2. The sender node includes its own SenderID in the SenderID field of the adapted header of the DTLS record. 3. The sender node considers the epoch and truncated sequence number values from the write group connection state. These values are used to fill the Epoch and Trunc_seq_number fields of the adapted header of the DTLS record. The first record sent to the multicast group has truncated sequence number 0. 4. The sender node processes the DTLS record according to the CipherSuite specified in the GSA. In particular, if the source_authentication flag in the GSA is set to TRUE, the DTLS record is signed using the sender's private key, and the signature is appended to the DTLS record payload. Otherwise, if the CipherSuite provides only group authentication, the server write MAC key and server write IV stored in the GSA are used to authenticate the DTLS record. Finally, if the CipherSuite provides confidentiality, the server write encryption key and server write IV stored in the GSA are used to encrypt the DTLS record. 5. The sender node passes the DTLS record down to UDP and IP layers for transmission on the multicast IP destination address and port number associated to the multicast group. 6. The sender node updates the truncated sequence number in its own write group connection state, incrementing its value by 1. 5.3 Receiving secure group request messages Upon receiving a DTLS record as part of a secure multicast group request message, a listener node proceeds as follows. 1. The listener node determines the right GSA, based on the multicast IP destination address and destination port number. 2. The listener node considers the multicast IP destination address and destination port number as well as the SenderID specified in the adapted header of the DTLS record, in order to determine the right read group connection state. This is different from the standard DTLS logic, according to which the current "client read" connection state is bound to the IP source address and port number. If this is the first group request message ever received from that sender node in the multicast group, the listener node instantiates a read group connection state associated to that Tiloca Expires April 16, 2016 [Page 20] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 sender node. 3. The listener node checks the freshness of the received DTLS record, comparing the values conveyed in the Epoch and Trunc_seq_number fields with the values of the epoch and truncated sequence number stored in the selected read group connection state. The listener node MUST ensure that the retrieved epoch value coincides with the stored value, and that the retrieved truncated sequence number value coincides with the stored value. Otherwise, the DTLS record SHOULD be discarded. Alternatively, a mechanism based on a sliding window MAY be adopted to accept genuine out-of-order DTLS records. 4. The listener node processes the DTLS record according to the CipherSuite specified in the GSA. If the CipherSuite provides confidentiality, the server write encryption key and server write IV stored in the GSA are used to decrypt the DTLS record. Then, if the source_authentication flag in the GSA is set to TRUE, the listener node checks the authenticity of the DTLS record using the sender's public key, identified by means of the SenderID conveyed in the record header. Otherwise, if the CipherSuite provides only group authentication, the server write MAC key and server write IV stored in the GSA are used to check the authenticity of the DTLS record. 5. Once the freshness and authenticity of the DTLS record have been verified, the listener node passes the DTLS record to the higher level protocols. 6. The listener node updates the value of the truncated sequence number in the selected read group connection state. 6. Secure unicast responses to multicast messages This section describes the adaptation of the DTLS Record layer to enable listener nodes in the multicast group to securely send unicast group response messages, as a reply to a multicast group request message received from a sender node. Unless otherwise necessary to fulfill further application requirements, the listener nodes are not required to perform any DTLS handshake with other members of the multicast group. Figure 4 shows the adapted DTLS record layer header, used when a listener node transmits a unicast group response message. The existing DTLS record layer header is adapted in such a way that the 6-octet Sequence_number field is split into a 1-octet GroupID field and a 5-octet "truncated" Trunc_seq_number field. The epoch is fixed and provided to the group members by the GC upon joining the Tiloca Expires April 16, 2016 [Page 21] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 multicast group. The Trunc_seq_number is initialized to 0 and is increased by one each time the listener node sends a new DTLS record, as part of a unicast group response message addressed to the same sender node. +---------+---------+--------+--------+------------+--------+ | 1 Byte | 2 Byte | 2 Byte | 1 Byte | 5 Byte | 2 Byte | +---------+---------+--------+--------+------------+--------+ | Content | Version | Epoch | Group | Trunc_seq_ | Length | | Type | Ma | Mi | | ID | number | | +---------+---------+--------+--------+------------+--------+ Figure 4: Adapted DTLS record header for unicast group responses The rationale for having the Trunc_seq_number field together with the GroupID field is as follows. The GroupID field allows a sender node to correctly "interpret" a unicast group response message as a reply to a multicast group request message that it has previously sent to that multicast group. Practically, the GroupID field allows a sender node to correctly determine the correct GSA to be considered. Also, together with the IP source address of a unicast group response message, the GroupID field allows a sender node to correctly determine the correct read group connection state to be considered, i.e. the one referred to the correct listener node. The case where a sender node is configured as sender in different multicast groups having the same GroupID is discussed in Section 9.6. Potentially, the same issues discussed in Section 5.1 about the reuse of nonce values can arise. In fact, all listener nodes in the multicast group refer to the same GroupID, and it is possible that their truncated sequence number values become synchronized with each other. In order to preserve secure communication within the multicast group, listener nodes derive additional individual keying material which is used to process outgoing unicast group response messages. The same individual keying material is derived by sender nodes and used to process incoming unicast group response messages. This is described in detail in Section 6.1, while further related security considerations are provided in Sections 9.2 and 9.3. Group response messages are secured by a source listener node as described in Section 6.2, and processed by the recipient sender node as described in Section 6.3. 6.1 Derivation of listener individual keying material Before sending its first unicast group response message to a given sender node in the multicast group, a listener node computes additional individual keying material, and stores it in the write group connection state associated to that sender node and the same group's communication, as detailed below. From then on, the listener Tiloca Expires April 16, 2016 [Page 22] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 node considers that individual keying material to process all its outgoing unicast group response messages addressed to that specific recipient sender node. Similarly, upon receiving the first group response message from that listener node in the multicast group, the sender node computes the same individual keying material, and stores it in the read group connection state associated to that listener node and the same group's communication. From then on, the sender node considers that individual keying material to process all the incoming unicast group response messages received from that listener node and related to that group's communication. The individual keying material is computed according to the same data expansion scheme referred by DTLS and described in Section 6.3 of [RFC5246]. The invoked procedure considers as input the client write key and server write key originally stored in the GSA, the IP address associated to the listener node, and the SenderID associated to the sender node. In particular, the following procedure is performed key_block = PRF(client write key + server write key, "key derivation", listener IP address + SenderID); until enough output has been generated. Specifically, the procedure stops when an amount of bytes equal to SecurityParameters.mac_key_length plus SecurityParameters.enc_key_length has been generated. Then, the individual keying material is extracted as follows. The first SecurityParameters.mac_key_length bytes of the key_block output are considered as the client write MAC key to be used for unicast responses sent by that listener node to that sender node. That is, the listener node stores it as the individual client write MAC key in the write group connection state associated to that sender node and the same group's communication. Instead, the sender node stores it as the individual client write MAC key in the read group connection state associated to that listener node and the same group's communication. Then, the following SecurityParameters.enc_key_length of the key_block output are considered as the client write encryption key to be used for unicast responses sent by that listener node to that sender node. That is, the listener node stores it as the individual client write encryption key in the write group connection state associated to that sender node and the same group's communication. Instead, the sender node stores it as the individual client write encryption key in the read group connection state associated to that Tiloca Expires April 16, 2016 [Page 23] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 listener node and the same group's communication. 6.2 Sending secure group response messages In order to send a DTLS record as part of a secure unicast group response message, a listener node proceeds as follows. If it has previously established a traditional unicast DTLS session with the sender node to be replied to, the listener node MUST refer to that DTLS session to securely reply to the sender node. In such a case, the listener node is not required to maintain a write group connection state associated to that sender node and that group's communication. Otherwise, the listener node performs the following steps. 1. The listener node determines the right GSA, based on the multicast IP destination address and destination port number of the multicast group request message it has received and wants to reply to. 2. If this is its first group response message ever sent to that sender node in the multicast group, the listener node instantiates a write group connection state associated to that sender node. Then, the listener node derives the necessary individual keying material and stores it in the write group connection state, as described in Section 6.1. Otherwise, the listener node determines the right write group connection state based on the unicast IP destination address and destination port number of the sender node to be replied to. The IP destination address is the one previously retrieved as IP source address from the multicast group request message. The destination port number is the one previously retrieved as source port number from the multicast group request message. 3. The listener node retrieves the GroupID from the GSA and includes it in the GroupID field of the adapted header of the DTLS record. 4. The listener node considers the epoch and truncated sequence number values from the selected write group connection state. These values are used to fill the Epoch and Trunc_seq_number fields of the adapted header of the DTLS record. The first record sent to the recipient sender node has truncated sequence number 0. 5. The listener node processes the DTLS record according to the CipherSuite specified in the GSA. In particular, if the source_authentication flag in the GSA is set to TRUE, the DTLS record is signed using the listener's private key, and the signature is appended to the DTLS record payload. Otherwise, if the CipherSuite provides only group authentication, the individual Tiloca Expires April 16, 2016 [Page 24] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 client write MAC key stored in the selected write group connection state and the client write IV stored in the GSA are used in order to authenticate the DTLS record. Finally, if the CipherSuite provides confidentiality, the individual client write encryption key stored in the selected write group connection state and the client write IV stored in the GSA are used to encrypt the DTLS record. 6. The listener node passes the DTLS record down to UDP and IP layers for transmission on the unicast IP destination address and port number of the sender to be replied to. The IP destination address is the one previously retrieved as IP source address from the multicast group request message. The destination port number is the one previously retrieved as source port number from the multicast group request message. 7. The listener node updates the truncated sequence number in the selected write group connection state, incrementing its value by 1. 6.3 Receiving secure group response messages Upon receiving a DTLS record as part of a secure unicast group response message, a sender node proceeds as follows. A node in the multicast group MUST consider invalid and discard any received group response message, in case it is not configured as sender node. 1. The sender node checks if a unicast DTLS session has been previously opened with the source listener node, based on the IP source address and port number of the received group response message. In case of positive match, the sender node MUST process the received message according to the traditional DTLS protocol [RFC6347]. Note that, in such a case, the sender node is not required to maintain a read group connection state associated to that listener node and that group's communication. Conversely, in case of negative match, the sender node does not yet consider the received message to be invalid, and moves to step 2. 2. The sender node parses the DTLS record header according to the format shown in Figure 4, and determines the right GSA, based on the retrieved GroupID. In case the sender node is configured as sender in different multicast subgroups having the same GroupID, the right GSA can be determined as discussed in Section 9.6. If no GSA associated to that GroupID can be found, the sender node MUST discard the received message. Otherwise, the sender node moves to step 3. 3. If this is the first unicast group response message ever received Tiloca Expires April 16, 2016 [Page 25] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 from that listener node in the multicast group, the sender node instantiates a read group connection state associated to that listener node. Then, the sender node derives the necessary individual keying material and stores it in that read group connection state, as described in Section 6.1. Otherwise, the sender node considers the retrieved GroupID and the IP source address of the listener node, in order to determine the right read group connection state. 4. The sender node checks the freshness of the received DTLS record, comparing the values conveyed in the Epoch and Trunc_seq_number fields with the values of the epoch and truncated sequence number stored in the selected read group connection state. The sender node MUST ensure that the retrieved epoch value coincides with the stored value, and that the retrieved truncated sequence number value coincides with the stored value. Otherwise, the DTLS record SHOULD be discarded. Alternatively, a mechanism based on a sliding window MAY be adopted to accept genuine out-of-order DTLS records. 5. The sender node processes the DTLS record according to the CipherSuite specified in the GSA. If the CipherSuite provides confidentiality, the sender node decrypts the DTLS record using the individual client write encryption key stored in the selected read group connection state and the client write IV stored in the GSA. Then, if the source_authentication flag in the GSA is set to TRUE, the sender node checks the authenticity of the DTLS record using the listener's public key, identified by means of the listener IP address. Otherwise, if the CipherSuite provides only group authentication, the sender node checks the authenticity of the DTLS record using the individual client write MAC key stored in the selected read group connection state and the client write IV stored in the GSA. 6. Once the freshness and authenticity of the DTLS record have been verified, the sender node passes the DTLS record to the higher level protocols. 7. The sender node updates the value of the truncated sequence number in the selected read group connection state. 7. Revocation and redistribution of group security material The approach for secure group communication presented in this draft SHOULD rely on additional mechanisms aimed at securely distributing, revoking, and renewing keying material, multicast security policies, and security parameters used in the group. In addition, the GC is intended as primarily responsible for providing the GSA to the group members. The establishment of the GSA will be part of a future IETF Tiloca Expires April 16, 2016 [Page 26] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 activity dedicated to the design of a generic key management scheme, preferably based on requirements and recommendations defined in [RFC3740][RFC4046][RFC4535]. Nevertheless, in this section we suggest a possible way to renew the group security material (rekeying) and provide the current GSA to new group members upon their joining. In particular, we consider the GC to be an additional member of the multicast group, and to be configured as a sender node. As specified in [RFC5246], the group keying material included in the GSA is computed from the Security Parameters master_secret, client_random and server_random. in particular, the master_secret is computed by means of a pre_master_secret value, and the Security Parameters client_random and server_random. Hence, a group keying material renewal can be practically performed by securely providing the group members with a new pre_master_secret value. Upon receiving it, the group members use it to compute the new master_secret to be stored in the SecurityParameters structure. Finally, they use the new master_secret to compute the new group keying material to be stored in the GSA, as well as the individual keying material to be stored in the write group connection states on the listener nodes and in the read group connection states on the sender nodes. All the other Security Parameters and keying material in the GSA remain unchanged. In order to assure that rekeying messages are actually sent by the GC, it is required that source authentication is enabled in the multicast group, i.e. the source_authentication flag in the GSA is set to TRUE. As an alternative, the GC can determine the random field of the new pre_master_secret as the next element of a pre-computed reversed hash chain, an authentication mechanism derived from Lamport's one-time password [LAMPORT:1981]. The advantage of this approach is that the most recently released element in the chain can be efficiently authenticated by computing its hash, and verifying that the result is equal to the previously released element in the chain. Therefore, upon creating the multicast group, it is sufficient that the GC provides all members with the head element of the hash chain in an authenticated way, e.g. off-line or through a predefined point-to-point authenticated channel. Then, all other chain elements can be automatically and efficiently authenticated by group members. Furthermore, this approach does not require to configure the GC as an actual member of the group. What follows is a brief overview of the key management operations expected on a regular basis (Section 7.1), and upon a new member's joining (Section 7.2) or a group member's leaving (Section 7.3). 7.1 Periodical rekeying. The group keying material SHOULD be renewed in a periodical fashion, Tiloca Expires April 16, 2016 [Page 27] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 in order to discourage an external adversary from breaking the secure communication in the group through exhaustive key search or traffic analysis. Periodical rekeying is effective as long as the group has not been compromised, i.e. no group members are under the adversary's control. Furthermore, the amount of time between two consecutive occurrences of periodical rekeying SHOULD be appropriately defined, taking into account the specific application requirements, and the expected level of threat the group is exposed to. Obviously, the more frequently the periodical rekeying is performed, the less the damage due to possibly compromised group keying material. Practically, the GC can periodically broadcast a new securely generated pre_master_secret to group members. For instance, this can be done by broadcasting a single DTLS multicast message, protected by means of the current server write parameters in the GSA, as any other multicast group request message transmitted to the group. Upon receiving it, all group members rely on the new pre_master_secret to update the master_secret in the SecurityParameters structure. After that, all group members can update the group security material stored in their GSA, as well as the individual keying material stored in the write group connection states on the listener nodes and in the read group connection states on the sender nodes. 7.2 Join rekeying. Upon a new node joining the group, it is required to assure backward security, whose importance has been explicitly stressed in [RFC4046]. In particular, the joining node must not be able to access any group communication which took place before its joining. As a first step, currently present group members are rekeyed according to the same procedure described above for periodical rekeying. After that, the GC provides the updated GSA to the joining node, which can then complete the join process. The GC is required to provide the joining node with the GSA through a secure communication channel. As a possible approach, upon contacting the Resource Directory service to gain knowledge of the GC address, the joining node could retrieve a public certificate associated to the GC, use the retrieved public key to establish a secure channel with the GC, and securely obtain the GSA. As an alternative, the joining node can establish a DTLS session with the GC, and receive the GSA as a sequence of protected DTLS records. 7.3 Leave rekeying. A group member may voluntarily leave the group (i.e. its mission is concluded or its membership is expired), or it may be forced to leave (e.g. if it has been found to be compromised or it is suspected so). In such a case, remaining group members have to be securely provided with updated group keying material, in order to assure forward Tiloca Expires April 16, 2016 [Page 28] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 security, whose importance has been explicitly stressed in [RFC4046]. Specifically, the leaving node must not be able to access group communication which takes place after its departure from the group. At the same time, the leaving node must be prevented from taking part in the rekeying process itself, i.e. from accessing the new security material during its distribution. Since the leaving node is aware of the current group keying material, the latter can not be used to securely distribute a new pre_master_secret to the remaining nodes. As a first easy approach, the GC can establish a different pairwise symmetric key with every member of the group upon their joining. Then, upon a node's leaving, the GC could rely on such pairwise keys to distribute a new pre_master_secret to all the remaining nodes, in a one-to-one fashion. However, such a unicast approach lacks of efficiency, as it requires a number of rekeying messages which linearly grows with the number of nodes in the group, hence not scaling well with the group size. As an alternative, it is possible to rely on specific application level schemes for group key management, which result to be more efficient and display high scalability with the number of nodes in the group. 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations This document describes an adaptation of DTLS 1.2 to support multicast group communication; therefore, most of the security considerations are the same as those of DTLS 1.2 [RFC6347] and TLS 1.2 [RFC5246] described in Appendices D, E, and F. Besides, security issues specifically related to the revocation and redistribution of security material are discussed in Section 7. Further security issues to be taken into consideration are discussed below. 9.1 Group-level security The approach described in this draft relies on commonly shared group security material to protect communication within the group. Unless source authentication is adopted, this requires that all group members are trusted, e.g. they do not forge messages in order to make them appear as sent by a different member of the group. In many use case, the devices in a multicast group belong to a common authority and are configured by a commissioner. For instance, in a professional lighting scenario, the roles of the sender and listener nodes are configured by the lighting commissioner, and devices follow those roles. In case group members can not be trusted to this extent, it is possible to provide source authenticity through digital signature, as described in Sections 5 and 6. Tiloca Expires April 16, 2016 [Page 29] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 Furthermore, encryption and authentication operations rely on a nonce value in order to randomize the process. With reference to a listener node which secures a unicast response message, it composes the nonce as the sequence of i) the client write IV from the GSA; and ii) the concatenation of epoch, GroupID, and Trunc_seq_number, namely explicit nonce, that are going to be included in the response DTLS header. On one hand, the client write IV and the GroupID are the same for all the listeners in the group. On the other hand, it is possible that multiple listeners are synchronized with each other as to the epoch and Trunc_seq_number they use to reply to a given multicast message from a sender node. In this case, all such listeners consider the same explicit nonce. Sections 9.2 and 9.3 discuss that reuse of explicit nonce does not represent a problem, since individual security material associated to listener nodes is derived on the listener and sender side. Finally, the presented approach SHOULD take into consideration the risk of compromise of group members. As a first thing, the risk of compromise is reduced when multicast groups are deployed in physically secured locations, like lighting inside office buildings. Secondly, the adoption of key management schemes for secure revocation and renewal of group security material SHOULD be considered, as discussed in Section 7. 9.2 Prevention of attacks based on IP spoofing The approach described in this draft makes it possible that all the listener nodes in the multicast group use different individual pairs (see Section 6). It follows that, when securing a unicast group response message, two listener nodes that rely on the same explicit nonce actually use different keying material and hence produce two different secured group response messages. This makes it possible to prevent an active attack when an external adversary injects fake group response messages by spoofing the IP source address of a given listener node. Furthermore, every listener node derives an individual pair separately for each sender node in the group (see Section 6.1). This makes it possible to prevent an active attack when an external adversary intercepts a unicast group response message sent to a given sender node, and then replays it to a different sender node by spoofing the IP destination address. 9.3 Nonce reuse in authenticated encryption DTLS makes it possible to use Authenticated Encryption with Tiloca Expires April 16, 2016 [Page 30] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 Associated Data (AEAD) ciphers, such as AES_CCM [RFC6655] or AES_GCM [RFC5288]. These ciphers require only one key to be used to secure a message, i.e. listeners would rely only on the client write encryption key, without using the client write MAC key. In this case, the possible reuse of the same explicit nonce by different listener nodes discussed in Section 9.1 is not a problem, thanks to the derivation of different individual client write encryption keys for each listener node (see Section 6). This has two major consequences. First, it makes it possible to still comply with the requirement of [RFC6655] and [RFC5288], according to which each value of the explicit nonce MUST be distinct for each distinct invocation of the encrypt function for any fixed key. Second, it prevents an adversary from solving underlying keyed hash so making subsequent forgeries trivial, and from choosing IVs to produce colliding counters. It follows that any degradation of the provided security level due to a possible nonce reuse is prevented. 9.4 Late joining nodes Upon joining the multicast group when the system is fully operative, listener nodes are not aware of the current epoch and Trunc_seq_number being used by different sender nodes. This means that, when such listener nodes receive a multicast message from a sender node, they are not able to verify if the message is fresh and has not been replayed by an adversary. In order to address this issue, we can rely on techniques similar to AERO [I-D.mcgrew-aero], i.e., upon receiving the first message from a particular sender node, late joining listener nodes initialize their last seen epoch and Trunc_seq_number in their read group connection state associated to that sender node. However, after that they drop such a message, without delivering it to the application layer. This provides a reference point to identify if future messages are fresher than the last one seen. As an alternative, the GC can be an additional member of the multicast group and be configured as a listener node. Then, it can maintain the epoch and Trunc_seq_number of each sender node in the multicast group. When late joiners send a request to the GC to join the multicast group, the GC can provide them with the list of epoch and Trunc_seq_number values to be stored in the read group connection states associated to the appropriate senders. 9.5 Uniqueness of SenderIDs As discussed in Section 5, it is important that SenderIDs are unique within a multicast group, in order to preserve the security properties of the DTLS record layer messages, especially the freshness of nonce values. Hence, in case two or more sender nodes are configured with the same SenderID, it becomes necessary to Tiloca Expires April 16, 2016 [Page 31] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 explicitly avoid the related security weakness and prevent nonce reuse. To this end, a possible mechanism consists in all sender nodes in the multicast group acting also as listener nodes. This allows a sender node S1 that receives a message with the same SenderID in the DTLS header from a different sender node S2 to become aware of the SenderID conflict. Then, S1 can notify the GC about the SenderID conflict through a secure channel. The GC can then provide a different SenderID to either one of the two sender nodes or both of them. 9.6 Same GroupID in different multicast groups In general, every multicast group is managed by a different GC, which is responsible to determine the associated GroupID to be used within the group. Then, it is possible that a node is configured as sender in different multicast groups at the same time, and such multicast groups are identified by the same, ambiguous, GroupID value. In such a case, upon receiving a unicast group response message as a reply to a multicast group request message, such sender nodes would not be able to determine to which group communication such group response message refers to, i.e. which GSA and read group connection state has to be considered to process the received group response message. In order to overcome this issue, sender nodes can identify the right GSA and read group connection state to be considered by means of the extended tuple from the DTLS, UDP and IP headers in the group response message. This relies on the practical assumption that, if a sender node belongs to different multicast groups at the same time, it actually takes part in each group's communication through a different application or application instance, each one of which refers to a different port number. 9.7 Reduced sequence number space In the approach described in this draft, the DTLS record layer sequence_number is truncated from 6 octets to 5 octets. This results in a reduction of the sequence_number space, which SHOULD be taken into account to ensure that the epoch value is incremented before the Trunc_seq_number wraps around. A sender node, or the GC as an alternative, can send a ChangeCipherSpec message to the whole multicast group whenever the Trunc_seq_number has been exhausted, in order that the epoch value is increased by all group members. This SHOULD be done as part of the key management scheme adopted within the group, which is out of scope for this draft. 10. References 10.1 Normative References Tiloca Expires April 16, 2016 [Page 32] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 [I-D.keoh-dice-multicast-security-08] Keoh, S., Kumar, S., Dijk, E., and A. Rahman, "DTLS-based Multicast Security in Constrained Environments", draft- keoh-dice-multicast-security-08 (work in progress), July 2014. [I-D.kumar-dice-multicast-security-00] Kumar, S., and R. Struik, "Transport-layer Multicast Security for Low-Power and Lossy Networks (LLNs)", draft- kumar-dice-multicast-security-00 (work in progress), March 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008. [RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008. [RFC6347] Rescorla, E., and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6655] Bailey, D., and D. McGrew, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, July 2012. [RFC7252] Shelby Z., Hartke K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. 10.2 Informative References [LAMPORT:1981] Lamport, L., Password authentication with insecure communication. Communications of the ACM, 24(11):770-772, November 1981. [I-D.mcgrew-aero] McGrew, D., and J. Foley, "Authenticated Encryption with Replay prOtection (AERO)", draft-mcgrew-aero-01 (work in progress), February 2014. [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., and P. van der Stok, Tiloca Expires April 16, 2016 [Page 33] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 "CoRE Resource Directory", draft-ietf-core-resource- directory-04 (work in progress), July 2015. [I-D.vanderstok-core-dna] Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, Naming, and Addressing", draft-vanderstok-core-dna-02 (work in progress), July 2012. [RFC3740] Hardjono, T., and B. Weis, "The Multicast GroupSecurity Architecture", RFC 3740, March 2004. [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005. [RFC4301] Kent, S., and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008. [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010. [RFC6282] Hui, J., and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011. [RFC6550] Winter T., Thubert P., Brandt A., Hui J., Kelsey R., Levis P., Pister K., Struik R., Vasseur JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. [RFC6763] Cheshire, S., and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. Tiloca Expires April 16, 2016 [Page 34] INTERNET DRAFT Multicast-DTLS-for-the-IoT October 14, 2015 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7296, October 2014. [RFC7390] Rahman., A., and E. Dijk, "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, October 2014. Authors' Addresses Marco Tiloca SICS Swedish ICT AB Isafjordsgatan 22, 16440 Kista Sweden Email: marco@sics.se Shahid Raza SICS Swedish ICT AB Isafjordsgatan 22, 16440 Kista Sweden Email: shahid@sics.se Kirill Nikitin School of Computer and Communication Sciences, EPFL EDOC-IC INN 134, Station 14, 1015 Lausanne Switzerland Email: kirill.nikitin@epfl.ch Sandeep S. Kumar Philips Research High Tech Campus 34, Eindhoven 5656 AE The Netherlands Email: sandeep.kumar@philips.com Tiloca Expires April 16, 2016 [Page 35]