DICE Working Group S. Kumar Internet-Draft Philips Research Intended status: Standards Track R. Struik Expires: September 10, 2015 Struik Security Consultancy March 09, 2015 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. Kumar & Struik Expires September 10, 2015 [Page 1] Internet-Draft Transport-layer Multicast Security for LLNs March 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Group Communication Use Cases . . . . . . . . . . . . . . 5 2.2. Security Requirements . . . . . . . . . . . . . . . . . . 6 3. Overview of Transport level Secure Multicast . . . . . . . . 7 3.1. Setting up Group Security Association . . . . . . . . . . 8 3.2. Group Communication packets . . . . . . . . . . . . . . . 8 4. Group-level Data Authenticity . . . . . . . . . . . . . . . . 9 4.1. Group message format . . . . . . . . . . . . . . . . . . 11 4.2. Group message processing . . . . . . . . . . . . . . . . 11 4.2.1. Sending Secure Multicast Messages . . . . . . . . . . 11 4.2.2. Receiving Secure Multicast Messages . . . . . . . . . 12 5. Source-level Data Authenticity . . . . . . . . . . . . . . . 12 5.1. Group message format . . . . . . . . . . . . . . . . . . 14 5.2. Group message processing . . . . . . . . . . . . . . . . 15 5.2.1. Sending Secure Multicast Messages . . . . . . . . . . 15 5.2.2. Receiving Secure Multicast Messages . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6.1. Late joiners . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Kumar & Struik Expires September 10, 2015 [Page 2] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 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]. Kumar & Struik Expires September 10, 2015 [Page 3] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 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: o 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. o 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. o Listener: Entity that receives multicast messages when listening to a multicast IP address. o 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. o Group Security Association: A bundling of security associations (SAs) that together define how a group communicates securely [RFC3740]. o 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]. Kumar & Struik Expires September 10, 2015 [Page 4] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 o 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. o 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. a. 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 Kumar & Struik Expires September 10, 2015 [Page 5] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 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. b. Integrated Building control: enabling Building Automation and Control Systems to control multiple heating, ventilation and air- conditioning units to pre-defined presets. c. 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. d. 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 e. Commissioning of LLN systems: querying information about the devices in the local network and their capabilities, e.g., by a commissioning device. f. 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: a. 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 Kumar & Struik Expires September 10, 2015 [Page 6] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 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. b. 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. c. 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). d. 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. Kumar & Struik Expires September 10, 2015 [Page 7] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 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 | | | | | | | | | | +--------------+ | | | | | | | +--------------------------------+ | | | | +---------------------------------------------+ | +--------+-+---------------------------------------------+-+ Figure 1: Sending a multicast message protected using DTLS Record Layer The listeners when receiving the message, use the multicast IPv6 destination address and port (i.e., multicast group identifier) to derive the corresponding GSA needed for that group connection. The Kumar & Struik Expires September 10, 2015 [Page 8] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 received message's authenticity is verified and/or decrypted using the keying material for that connection and the security header. 4. Group-level Data Authenticity This section describes in detail the group level authenticity mechanism for transport level secure group messages. We assume that group membership has been configured by the group controller as described in Section 3.1 , and all member devices in the group have the GSA. The group-level authentication GSA contains the following elements: CipherSuite server write MAC key server write encryption key server write IV SenderID The group controller chooses a CipherSuite for the GSA based on knowledge that all devices in the group support the specific CipherSuite. Based on the CipherSuite selected, one or more of the other elements may be empty. For example, if only using authenticity only ciphersuite, the encryption key and IV is not sent, similarly if an AEAD ciphersuite is used then MAC key is not sent. The SenderID is only sent to devices which are senders in the group The GSA is used to instantiate the needed elements of the "SecurityParameters" structure (shown below) as defined in [RFC5246] for all devices. Kumar & Struik Expires September 10, 2015 [Page 9] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 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; a. SecurityParameters.entity is set to ConnectionEnd.server for senders and ConnectionEnd.client for listeners. b. bulk_cipher_algorithm, cipher_type, enc_key_length, block_length, fixed_iv_length, record_iv_length, mac_algorithm, mac_length, and mac_key_length is set based on the ciphersuite present in the GSA. c. cipher_type is CipherType.aead (if confidentiality is needed) d. enc_key_length, block_length are sent in the GSA. e. prf_algorithm, compression_algorithm, master_secret[48], client_random[32], and server_random[32] are not used and therefore not set. The current read and write states are then instantiated for all group members based on the keying material in the GSA and according to their roles: a. Listeners (ConnectionEnd.client) directly use "server write" parameters in the GSA for instantiating the current read state. The write state is not instantiated and not used. b. Senders (ConnectionEnd.server) first pass each of the "server write" parameters in the GSA through a function output=F(SenderID, input) [Note: F needs to be defined later]. The output is then used for instantiating the current write state. Kumar & Struik Expires September 10, 2015 [Page 10] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 If a device is both a sender and listener, then the read and write states are both instantiated as above. Additionally each connection state contains the epoch (set to zero) and sequence number which is incremented for each record sent; the first record sent has the sequence number 0. 4.1. Group message format To reuse the DTLS implementation for group message processing, the DTLS Records are used to send messages in the group. The following Figure 2 illustrates the structure of the DTLS record layer header, the epoch and seq_number are used to ensure message freshness and to detect message replays. +---------+---------+--------+--------+--------+------------+-------+ | 1 Byte | 2 Byte | 2 Byte | 6 Byte | 2 Byte | | | +---------+---------+--------+--------+--------+------------+-------+ | Content | Version | epoch | seq_ | Length | Ciphertext | MAC | | Type | Ma | Mi | | number | | (Enc) | (Enc) | +---------+---------+--------+--------+--------+------------+-------+ Figure 2: The DTLS record layer header to transport group-level authenticated messages The same packet structure is used to transport group messages with the Content Type set to ContentType.application_data, the version set to DTLS version 1.2 (mandated by CoAP) which uses the version {254, 253}, epoch is fixed for all devices by the controller and the seq_number based on current connection state. The seq_number is increased by one whenever the sender sends a new group message in the record. Finally, the message is protected (encrypted and authenticated with a MAC) using the session keys in the "server write" parameters. 4.2. Group message processing 4.2.1. Sending Secure Multicast Messages Senders in the multicast group when sending a CoAP group message from the application, create the DTLS record payload based on the "server write" parameters. It also manages its own epoch and seq_number in the "server write" connection state; the first record sent has the seq_number 0. After creating the DTLS record, the seq_number is incremented in the "server write" connection state. The DTLS record Kumar & Struik Expires September 10, 2015 [Page 11] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 is then passed down to UDP and IPv6 layer for transmission on the multicast IPv6 destination address and port. 4.2.2. Receiving Secure Multicast Messages When a listeners receives a protected multicast message from the sender, it looks up the corresponding "client read" connection state based on the multicast IP destination and port of the connection. This is different from standard DTLS logic in that the current "client read" connection state is bound to the source IP address and port. Listener devices in a multiple senders multicast group, need to store multiple "client read" connection states for the different senders linked to the Source IP addresses. The keying material is same for all senders however tracking the epoch and the seq_number of the last received packets needs to be kept different for different senders. The listeners first perform a "server write" keys lookup by using the multicast IPv6 destination address and port of the packet. Then the key is passed through the same F function described above to get specific keys for the particular sender. The listeners decrypt and check the MAC of the message using this key. This guarantees that no one without access to the GSA has spoofed the message. Subsequently, the listeners retrieve the "client read" connection state which contains the last stored epoch and seq_number of the sender, which is used to check the freshness of the message received. The listeners must ensure that the epoch is the same and seq_number in the message received is at least equal to the stored value, otherwise the message is discarded. Alternatively a windowing mechanism can be used to accept genuine out-of-order packets. Once the authenticity and freshness of the message have been checked, the listeners can pass the message to the higher layer protocols. The seq_number in the corresponding "client read" connection state are updated as well. 5. Source-level Data Authenticity This section describes in detail the source level authenticity mechanism based on public-key cryptography for transport level secure group messages. We assume that group membership has been configured by the group controller as described in Section 3.1 , and all member devices in the group have the GSA. The source-level authentication GSA contains the following elements: a. For Senders: Kumar & Struik Expires September 10, 2015 [Page 12] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 CipherSuite {SenderID, SenderID Private Key} server write encryption key server write IV b. For Listeners: CipherSuite {SenderID1, SenderID1 Public Key} {SenderID2, SenderID2 Public Key} {SenderID3, SenderID3 Public Key} ... server write encryption key server write IV The group controller chooses a CipherSuite for the GSA for all devices based on knowledge that all devices in the group support the specific CipherSuite. Based on the CipherSuite selected, one or more of the other elements may be empty. For example, if only authenticity is needed then the encryption key and IV is not sent. The GSA is used to instantiate the needed elements of the "SecurityParameters" structure (shown below) as defined in [RFC5246] for all devices. 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; Kumar & Struik Expires September 10, 2015 [Page 13] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 a. SecurityParameters.entity is set to ConnectionEnd.server for senders and ConnectionEnd.client for listeners. b. bulk_cipher_algorithm, cipher_type, enc_key_length, block_length, fixed_iv_length, and record_iv_length is set based on the ciphersuite present in the GSA. c. mac_algorithm, mac_length, and mac_key_length are set different to DTLS since we use public key algorithms. The mac here therefore is a public-key based signature. d. enc_key_length, block_length are sent in the GSA if encryption is needed. e. prf_algorithm, compression_algorithm, master_secret[48], client_random[32], and server_random[32] are not used and therefore not set. The current read and write states are then instantiated for all group members based on the keying material in the GSA and according to their roles: a. Listeners (ConnectionEnd.client) use the SenderID's public keys for instantiating the current read state for different senders. If confidentiality is needed, the "server write" parameters in the GSA is also added to the current read state. The write state is not instantiated and not used. b. Senders (ConnectionEnd.server) use the SenderID private key to instantiate the current write state. If confidentiality is used, first pass each of the "server write" parameters in the GSA through a function output=F(SenderID, input) [Note: F needs to be defined later.]. If a device is both a sender and listener, then the read and write states are both instantiated as above. Additionally each connection state contains the epoch (set to zero) and sequence number which is incremented for each record sent; the first record sent has the sequence number 0. 5.1. Group message format To reuse the DTLS implementation for group message processing, the DTLS Records are used to send messages in the group with minor changes. Kumar & Struik Expires September 10, 2015 [Page 14] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 The following Figure 2 illustrates the structure of the DTLS record layer header, the epoch and seq_number are used to ensure message freshness and to detect message replays. +---------+---------+--------+--------+--------+------------+-------+ | 1 Byte | 2 Byte | 2 Byte | 6 Byte | 2 Byte | | | +----------------------------------------------------------------+--+ | Content | Version | epoch | seq_ | Length | Ciphertext | Sig- | | Type | Ma + Mi | | number | | (if enc) | nature| +---------+----+----+--------+--------+--------+------------+-------+ Figure 3: The DTLS record layer header to transport source-level authenticity messages The same packet structure is used to transport group messages with the Content Type set to ContentType.application_data, the version set to DTLS version 1.2 (mandated by CoAP) which uses the version {254, 253}, epoch is fixed for all devices by the controller and the seq_number based on current connection state. The seq_number is increased by one whenever the sender sends a new group message in the record. Finally, the message is signed using the SenderID private key and added to the signature field. If confidentiality is needed then data is encrypted using the session keys in the "server write" parameters. 5.2. Group message processing 5.2.1. Sending Secure Multicast Messages Senders in the multicast group when sending a CoAP group message from the application, create the DTLS record payload based on the current write connection state, i.e. the data (along with the headers) is signed using the private key and if confidentiality is needed, the server write parameters are used to encrypt the data. It also manages its own epoch and seq_number in the current write connection state; the first record sent has the seq_number 0. After creating the DTLS record, the seq_number is incremented in the "server write" connection state. The DTLS record is then passed down to UDP and IPv6 layer for transmission on the multicast IPv6 destination address and port. Kumar & Struik Expires September 10, 2015 [Page 15] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 5.2.2. Receiving Secure Multicast Messages When a listeners receives a protected multicast message from the sender, it looks up the corresponding "client read" connection state based on the source address, source port, multicast IP destination and destination port of the connection. This is different from standard DTLS logic in that the current "client read" connection state is bound only to the source IP address and source port. Listener devices in a multiple senders multicast group, need to store multiple "client read" connection states for the different senders linked to the source IP addresses. Each of these connection states contain the public key of the corresponding sender. Further tracking the epoch and the seq_number of the last received packets needs to be kept different for different senders. The listeners first perform a public key lookup by retrieving the "client read" connection state using the source address, source port, multicast IPv6 destination address and port of the packet. The listeners verifies the signature of the message using this public key. This guarantees that no one without access to the GSA for the specific device has spoofed the message. Subsequently, the listeners retrieve from the "client read" connection state the last stored epoch and seq_number of the sender, which is used to check the freshness of the message received. The listeners must ensure that the epoch is the same and seq_number in the message received is higher than the stored value, otherwise the message is discarded. Alternatively a windowing mechanism can be used to accept genuine out-of-order packets. Once the authenticity and freshness of the message have been checked, the listeners can pass the message to the higher layer protocols. The the seq_number in the corresponding "client read" connection state are updated as well. 6. Security Considerations Some of the security issues that should be taken into consideration are discussed below. 6.1. Late joiners Listeners who are late joiners to a multicast group, do not know the current epoch and seq_number being used by different senders. When they receive a packet from a sender with a random seq_number in it, it is impossible for the listener to verify if the packet is fresh and has not been replayed by an attacker. To overcome this late joiner security issue, the group controller which can act as a listener in the multicast group can maintain the epoch and seq_number of each sender. When late joiners send a request to the group Kumar & Struik Expires September 10, 2015 [Page 16] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 controller to join the multicast group, the group controller can send the list of epoch and seq_numbers to the late joiner. 7. Acknowledgements 8. References 8.1. Normative References [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] McGrew, D. and D. Bailey, "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. [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, October 2014. 8.2. Informative References [FIPS.180-2.2002] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, . [FIPS.197.2001] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, . Kumar & Struik Expires September 10, 2015 [Page 17] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 [I-D.dijk-core-groupcomm-misc] Dijk, E. and A. Rahman, "Miscellaneous CoAP Group Communication Topics", draft-dijk-core-groupcomm-misc-06 (work in progress), June 2014. [I-D.ietf-core-resource-directory] Shelby, Z. and C. Bormann, "CoRE Resource Directory", draft-ietf-core-resource-directory-02 (work in progress), November 2014. [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.mglt-dice-ipsec-for-application-payload] Migault, D. and C. Bormann, "IPsec/ESP for Application Payload", draft-mglt-dice-ipsec-for-application-payload-00 (work in progress), July 2014. [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. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005. [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005. [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006. Kumar & Struik Expires September 10, 2015 [Page 18] Internet-Draft Transport-layer Multicast Security for LLNs March 2015 [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)", RFC 4785, January 2007. [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. [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. Authors' Addresses Sandeep S. Kumar Philips Research High Tech Campus 34 Eindhoven 5656 AE The Netherlands Email: ietf.author@sandeep-kumar.org Rene Struik Struik Security Consultancy Email: rstruik.ext@gmail.com Kumar & Struik Expires September 10, 2015 [Page 19]