DICE Working Group S. Kumar Internet-Draft Philips Research Intended status: Standards Track July 02, 2014 Expires: January 3, 2015 Group Communication Security for Low-Power and Lossy Networks (LLNs) draft-kumar-dice-groupcomm-security-00 Abstract CoAP unicast and group communication for low-power and lossy networks (LLNs) are foreseen to be used for building and lighting control systems. Although unicast CoAP communication mandates DTLS for security, no similar existing security mechanisms exist to secure CoAP group communication. The draft, DTLS multicast security [I-D.keoh-dice-multicast-security], proposes a solution based on reusing the DTLS record layer to also secure CoAP group communication. Although that solution has advantages in terms of code reuse, it does not ensure source authentication within the group. This draft presents alternative CoAP group communication security solutions based on public key cryptographic signatures to also ensure source authentication within the group. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 3, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Kumar Expires January 3, 2015 [Page 1]
Internet-Draft Group Communication Security for LLN July 2014 (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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Security Requirements . . . . . . . . . . . . . . . . . . . . 4 3. Overview for Secure Group Communication . . . . . . . . . . . 6 3.1. IP Multicast . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Abstract model for securing group communication . . . . . 7 3.2.1. Sending Secure Multicast Messages . . . . . . . . . . 8 3.2.2. Receiving Secure Multicast Messages . . . . . . . . . 9 4. Specific solutions for Group Communication Security . . . . . 10 4.1. CoAP based solution . . . . . . . . . . . . . . . . . . . 11 4.2. Shim layer solution . . . . . . . . . . . . . . . . . . . 11 4.3. Comparison between the solutions . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6.1. Group level confidentiality . . . . . . . . . . . . . . . 13 6.2. Late joiners . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Uniqueness of Sender IDs . . . . . . . . . . . . . . . . 13 6.4. Sequence number space . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction There is an increased use of wireless control networks in environmental monitoring, industrial automation, lighting controls and building management systems. Additionally these connected devices are equipped with IP communication capability that enables them to interact with each other as well as with the wider Internet services. However, the devices in such wireless control networks are characterized by power constraints (as these are usually battery- operated), have limited computational resources (low CPU clock, small RAM and flash storage) and often, the communication bandwidth is limited and unreliable (e.g., IEEE 802.15.4 radio). Hence, such wireless control networks are characterized as Low-power and Lossy Kumar Expires January 3, 2015 [Page 2]
Internet-Draft Group Communication Security for LLN July 2014 Networks (LLNs). The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] and 6LoWPAN [RFC4944] standards are fast emerging as key protocols for enabling IP connectivity in LLNs. In addition to the usual device-to-device unicast communication that allow devices to directly interact with each other, group communication is an important feature in these 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. Group communication for LLNs is based on the CoAP sent over IP- multicast [I-D.ietf-core-groupcomm]. Currently, unicast CoAP messages are protected using Datagram Transport Layer Security (DTLS) [RFC6347]. Although 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), there is no such similar security mechanisms defined. The DTLS Multicast draft [I-D.keoh-dice-multicast-security] proposes an approach to reuse DTLS as mandated in CoAP unicast to also support multicast security. It uses an adaptation of the DTLS record layer to protect multicast messages to be sent to the group, and thus providing "group level" confidentiality, integrity and replay protection to the CoAP group messages. Although that solution has different advantages like code reuse and transparency at the CoAP layer, it does not provide source authentication since all members of the group share a common key. This draft describes alternative solutions based on public-key cryptography (PKC) to ensure source authentication within the group and compare it with [I-D.keoh-dice-multicast-security] solution. 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 same terminology as in [I-D.keoh-dice-multicast-security]: o Group Controller: The entity that is responsible for creating a multicast group and establishing security associations among authorized group members. It is also responsible for renewing/ updating the multicast group keys. Kumar Expires January 3, 2015 [Page 3]
Internet-Draft Group Communication Security for LLN July 2014 o Sender: The Sender is an entity that sends data to the multicast group. In a 1-to-N multicast group only a single Sender is transmits data to the group. In an M-to-N multicast group (where M and N are not necessarily the same value), M group members are Senders. o Listener: The entity that receives multicast messages when listening to a specific multicast IP address. o Security Association (SA): A set of policy and cryptographic keys that provide security services to network traffic that matches that policy [RFC3740]. A Security Association usually contains the following attributes: * selectors, such as source and destination identifiers. * 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 (GSA): A bundling of security associations (SAs) that together define how a group communicates securely. [RFC3740] o Keying material: Data that is specified as part of the SA which is needed to establish and maintain a cryptographic security association, such as keys, key pairs, and IVs [RFC4949]. 1.2. Outline This draft is structured as follows: Section 2 list the security requirements to be achieved. Section 3 first presents the proposed group communication security at an abstract level. In Section 4, we present specific solutions based on the abstract solution, one based on directly adding security into CoAP and the other using a shim layer. We also compare these solutions to the the one proposed in [I-D.keoh-dice-multicast-security]. Section 6 presents the security considerations. 2. Security Requirements The "Miscellaneous CoAP Group Communication Topics" draft [I-D.dijk-core-groupcomm-misc] defines a set of security requirements for group communication in LLNs. In this section, we re-iterate and further classify the security requirements into those that are assumed to be fulfilled and those that need to be fulfilled by the Kumar Expires January 3, 2015 [Page 4]
Internet-Draft Group Communication Security for LLN July 2014 solution in this draft. These requirements are same as in [I-D.keoh-dice-multicast-security] with the additional requirement on source authentication within the group. The security requirements which are out-of-scope of this draft and assumed to be already fulfilled: a. Establishment of a GSA: A secure mechanism must be used to distribute keying materials, multicast security policies and security parameters to members of a multicast group. A GSA must be established by the group controller (which manages the multicast group) among the group members. The 6LoWPAN border router, a device in the LLN, or a remote server outside the LLN could play the role of the group controller. However, GSA establishment is outside the scope of this draft, and it is anticipated that an activity in IETF dedicated to the design of a generic key management scheme for the LLN will include this feature preferably based on [RFC3740], [RFC4046] and [RFC4535]. b. Multicast data security ciphersuite: All group members must use the same ciphersuite to protect the authenticity, integrity and confidentiality of multicast messages. The ciphersuite is part of the GSA. Typically authenticity is more important than confidentiality in LLNs. c. Forward security: Devices that leave the group should not have access to any future GSAs. This ensures that a past member device cannot continue to decrypt confidential data that is sent in the group. It also ensures that this device cannot send encrypted and/or integrity protected data after it leaves the group. The GSA update mechanism has to be defined as part of the key management scheme. d. Backward confidentiality: A new device joining the group should not have access to any old GSAs. This ensures that a new member device cannot decrypt data sent before it joins the group. The key management scheme should ensure that the GSA is updated to ensure backward confidentiality. The security requirements which need to be fulfilled by the solution described in this draft: a. Multicast communication topology: We consider both 1-to-N (one sender with multiple listeners) and M-to-N (multiple senders with multiple listeners) communication topologies. b. Multicast group size: The security solutions should support the typical group sizes that "Group Communication for CoAP" draft Kumar Expires January 3, 2015 [Page 5]
Internet-Draft Group Communication Security for LLN July 2014 [I-D.ietf-core-groupcomm] intends to support. Group size is the combination of the number of Senders and Listeners in a group with possible overlap (a Sender can also be a Listener but need not be always). In LLNs, the number of Senders is much smaller than the number of Listeners. c. Multicast data confidentiality: Multicast message should be encrypted within the group, as some group messages when sent in the clear could pose unforeseen privacy risks to the users of the system. d. Multicast data replay protection: It should not be possible to replay CoAP group messages out-of-order. e. Multicast data group level authentication and integrity: It should be possible to verify if the multicast message originated within the group and that messages have not been tampered by non- group members. f. Multicast data source authentication: Source authenticity is required if the group members are assumed to be untrusted and can tamper with the multicast messages. This can happen if nodes of the group can be easily compromised. Source authenticity helps to minimize the risk of any node compromise leading to the compromise of the whole multicast group. Source authenticity can be typically provided using public-key cryptography in which every multicast message is signed by the sender. 3. Overview for Secure Group Communication This section first describes how group communication based on the underlying IP multicast works and then describe the security solution at an abstract level. 3.1. IP Multicast Devices in the LLN are categorized into two roles, (1) Sender and (2) Listener. Any node in the LLN may have one of these roles, or both roles. The application(s) running on a device basically determine these roles by the function calls they execute on the IP stack of the device. In principle, a Sender or Listener does not require any prior access procedures or authentication to send or listen to a multicast message [RFC5374]. A sender to an IPv6 multicast group sets the destination of the packet to an IPv6 address that has been allocated for IPv6 multicast. A device becomes a Listener by "joining" to the specific IPv6 multicast group by registering with a network routing device, Kumar Expires January 3, 2015 [Page 6]
Internet-Draft Group Communication Security for LLN July 2014 signaling its intent to receive packets sent to that particular IPv6 multicast group. Figure 1 depicts a 1-to-N multicast communication and the roles of the nodes. Any device can in principle decide to listen to any IPv6 multicast address. This also means applications on the other devices do not know, or do not get notified, when new Listeners join the LLN. More details on the IPv6 multicast and CoAP group communication can be found in [I-D.ietf-core-groupcomm]. This draft does not intend to modify any of the underlying group communication or multicast routing protocols. ++++ |. | --| ++++ ++++ / ++|. | |A |---------| ++++ | | \ ++|B | ++++ \-----| | Sender ++++ Listeners Figure 1: The roles of nodes in a 1-to-N multicast communication topology 3.2. Abstract model for securing group communication 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 to add them to the new group. Additionally it distributes the GSA consisting of keying material, security policies, security parameters and ciphersuites using a standardized key management for LLN which is outside the scope of this draft. For the solution defined in this draft, the GSA should at least contain the following parameters: o Selectors: Kumar Expires January 3, 2015 [Page 7]
Internet-Draft Group Communication Security for LLN July 2014 * A "GSA context" identifier to allow Listeners to identify the GSA parameters being used by the Senders. * A unique "Sender ID" for each Sender. o Cryptographic ciphersuites: * PKC signature algorithm and its public parameters. * Symmetric-key encryption algorithm and mode of operation. * Symmetric-key Message Authentication Code (MAC) algorithm (can be combined with AEAD mode for encryption) o Cryptographic keys: * The individual PKC private-key at the Senders and all (PKC public-key, Sender ID) pairs at Listeners * Symmetric-key Encryption algorithm group key * Symmetric-key MAC algorithm group key (not needed if AEAD mode used for encryption) Additionally Senders and Listeners need to store additional "Security Parameters" that are updated when sending or receiving messages: o Senders: * Last used sequence number (initially set to zero). o Listeners: * For each Sender, the sequence number of the last received packet that passed authentication. 3.2.1. Sending Secure Multicast Messages Senders in the group secure a group communication message consisting of a payload header (e.g. CoAP header) and the payload, as per the following abstract rules to create the structure as shown Figure 2 : a. Attach Protocol ID: Identifies to Listener that group communication security is enabled and the version being used. b. Attach current GSA context: Identifies to Listener which cryptographic suites and keys are being used for securing the message. Kumar Expires January 3, 2015 [Page 8]
Internet-Draft Group Communication Security for LLN July 2014 c. Attach Sender ID: Identifies the Sender within the group which is needed for verifying the source of the message. d. Attach Sequence Number: Indicates the order of messages sent to prevent replay attacks. The Sender increments the Sequence Number stored in its "Security Parameters" and attaches it here. The "GSA context", "Sender ID" and "Sequence Number" together can be used to construct the nonce or IV if needed for the cryptographic mode of operation. The exact details on the construction can be defined during GSA establishment within the cryptographic suite. e. SIG: PKC signature for source authentication using the Sender's private key. The fields "Protocol ID", "GSA context", "Sender ID", "Sequence Number", "Payload header" and "Payload" are signed. f. Based on the GSA context (i.e. symmetric-key encryption algorithm is not NULL), then "Payload" and "SIG" are encrypted g. MAC: All fields are authenticated using the MAC algorithm. A MAC is performed in addition to the SIG to provide a basic Denial- of-Service protection from devices performing the more computationally intensive PKC verification operations on bogus messages from outside the group. If the MAC key is compromised, then a device observes that MAC verification succeeds while the SIG verification fails. It can then raise an alarm with its controller so that it can revoke and create a new MAC key for the whole group. +--------+---------+--------+----------+---------+---------+-----+-----+ |Protocol| GSA | Sender | Sequence | Payload | Payload | SIG | MAC | | ID | context | ID | Number | Header | | | | +--------+---------+--------+----------+---------+---------+-----+-----+ <---------------Private-key Signed fields-----------------------> <--Encrypted--> fields <------------------Symmetric-key MACed fields--------------------------> Figure 2: Abstract model for protection of group messages 3.2.2. Receiving Secure Multicast Messages When a Listener receives a protected group communication message, it verifies the message as per the following abstract rules: Kumar Expires January 3, 2015 [Page 9]
Internet-Draft Group Communication Security for LLN July 2014 a. Read Protocol ID: Identifies that group communication security is enabled and the version being used. b. Read GSA context: If the GSA context is known to the Listener, the rest of the message is verified and decrypted using the GSA cryptographic suites and keys. If the GSA context is not known to the Listener, the message is silently dropped. c. Read Sender ID: Identifies the Sender within the group based on which the Listener can lookup the appropriate PKC public-key and stored "Sequence Number" to be used for further processing. d. Read Sequence Number: Listener checks if the received "Sequence Number" is greater (or within a sliding window) of the stored last seen "Sequence Number" for this Sender. If not the packer is dropped. e. Verify MAC: Verify MAC based on the group key. If failure, then drop packet. f. Based on the GSA context (i.e. symmetric-key encryption algorithm is not NULL), decrypt the Payload and SIG fields. g. Verify SIG: Verify PKC signature for source authentication using the public-key for the Sender ID. * If success, the stored "Sequence Number" for the Sender is updated in the "Security Parameters". Furthermore the payload header and payload is sent to the application to be further processed. * If failure, drop the packet and inform controller about an inconsistency between a MAC verification success and SIG verification failure. This could indicate the compromise of the group key. 4. Specific solutions for Group Communication Security This section describes two specific alternative solutions to [I-D.keoh-dice-multicast-security] based on the abstract reference solution described in the previous section. The first alternative implements the solution directly into the CoAP message while the second solution is defined as a shim layer between the CoAP and UDP layer. The second solution can also be adapted to DTLS record layer if needed. Kumar Expires January 3, 2015 [Page 10]
Internet-Draft Group Communication Security for LLN July 2014 4.1. CoAP based solution In this solution, the security of group messages are diretly included inside the CoAP group message as shown in Figure 3. +--------+----------------------------------------------+ | | +--------+---------------------------------+ | | | | | +-------+-----------+---------+ | | | IP | | UDP | | CoAP | CoAP | CoAP | | | | header | | header | | Header| Options | Payload | | | | | | | | |[Security] | [SIG] | | | | | | | | |[ Header ] | [MAC] | | | | | | | +-------+-----------+---------+ | | | | +--------+---------------------------------+ | +--------+----------------------------------------------+ Figure 3: Group communication security within CoAP The "Protocol ID", "GSA context", "Sender ID" and "Sequence Number" are carried as additional options in Type-Length-Value (TLV) format within the CoAP Options field indicated as "Security Header" in Figure 3. (More details on the options, like class etc., needs to be further expanded in a newer version of the draft.) The PKC signature SIG is generated over the combined CoAP Header, CoAP Options and the original CoAP payload. This SIG is concatenated to the original CoAP payload, and these together can be further encrypted based on the ciphersuite defined in the GSA. Finally the MAC is computed over the CoAP Header, CoAP options and the new (encrypted) CoAP Payload and concatenated into the CoAP payload field. The creation of the secure group message by the Sender and verification by the Listener are same as described in the abstract model, except that the corresponding values need to be read from the correct locations within the CoAP Options and CoAP Payload. 4.2. Shim layer solution In this solution, the security of group messages closely matches the abstract model shown in Figure 2. The payload header are the original CoAP header and CoAP options field. The payload is the CoAP payload. The shim layer carries the rest of the headers; "Protocol ID", "GSA context", "Sender ID" and "Sequence Number" (indicated as "Security Header") as well as the SIG and MAC fields. The solution is as shown in Figure 4. Kumar Expires January 3, 2015 [Page 11]
Internet-Draft Group Communication Security for LLN July 2014 +------+---------------------------------------------------------------+ | | +------+----------------------------------------------------+ | | | | | +----------+---------Shim Layer------+-----+-----+ | | | | | | | +-------+--------+--------+ | | | | | IP | | UDP | |[Security]| CoAP | CoAP | CoAP | | | | | |header| |header| |[ Header ]| Header| Options| Payload| SIG | MAC | | | | | | | | +-------+--------+--------+ | | | | | | | | +----------+-------------------------+-----+-----+ | | | | +------+----------------------------------------------------+ | +------+---------------------------------------------------------------+ Figure 4: Group communication security with Shim Layer The creation of the secure group message by the Sender and verification by the receiver are same as described in the abstract model except for the different positioning of the fields. 4.3. Comparison between the solutions This is a first comparison between the solutions and needs to be further refined. The solutions described in this draft use more computationally intensive operations based on PKC for each and every individual message. This can be quite demanding on many cheap IoT devices which have strong memory and power constraints. Also compared to the solution in [I-D.keoh-dice-multicast-security], the current solutions require new code for securing group communication and cannot reuse parts of the existing code used to protect unicast communication. Furthermore the CoAP based solution requires changes in the CoAP layer and requires different handling for group messages compared to unicast communication. The Shim layer solution is transparent for the CoAP layer and can also be reused for other multicast protocols over UDP. The Shim layer solution, if needed, can also be adapted to DTLS record layer with some additional changes to the DTLS record format. 5. IANA Considerations This memo includes no request to IANA. Kumar Expires January 3, 2015 [Page 12]
Internet-Draft Group Communication Security for LLN July 2014 6. Security Considerations Some of the security issues that should be taken into consideration are discussed below. 6.1. Group level confidentiality This proposal uses a single group key to provide confidentiality of the communication within the group. This is a weak form of confidentiality and for most IoT scenarios where group commuication is used to send commands, this suffices. 6.2. Late joiners Listeners who are late joiners to a multicast group, do not know the current GSA context and Sequence Number being used by different Senders. When they receive a packet from a Sender with a random Sequence 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 as a additional Listener role in the multicast group can maintain the list of last seen Sequence Number of each sender. When late joiners sends a request to the group controller to join the multicast group, the group controller can send this list as part of the GSA. 6.3. Uniqueness of Sender IDs It is important that Sender IDs are unique to maintain the security properties. Since the group controller assigns the Sender IDs, it should ensure the uniqueness within the group. 6.4. Sequence number space The "Sequence Number" space should be defined large enough to avoid changing the GSA context often due to wrap over. The controller can create a new GSA context when Sequence Number approaches exhaustion. This should be done as part of the key management mechanism which is out-of-scope of this draft. 7. Acknowledgements The authors greatly acknowledge discussion, comments and feedback from Dee Denteneer, Peter van der Stok, Zach Shelby and Michael StJohns. Also thank Tanja Lange and Daniel J. Bernstein for the useful discussion and comments. Kumar Expires January 3, 2015 [Page 13]
Internet-Draft Group Communication Security for LLN July 2014 8. References 8.1. Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-18 (work in progress), June 2013. [I-D.ietf-core-groupcomm] Rahman, A. and E. Dijk, "Group Communication for CoAP", draft-ietf-core-groupcomm-19 (work in progress), June 2014. [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] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, July 2012. 8.2. Informative References [FIPS.180-2.2002] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, <http://csrc.nist.gov/publications/fips/fips180-2/ fips180-2.pdf>. [FIPS.197.2001] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>. Kumar Expires January 3, 2015 [Page 14]
Internet-Draft Group Communication Security for LLN July 2014 [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., Bormann, C., and S. Krco, "CoRE Resource Directory", draft-ietf-core-resource-directory-01 (work in progress), December 2013. [I-D.keoh-dice-multicast-security] Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A. Rahman, "DTLS-based Multicast Security in Constrained Environments", draft-keoh-dice-multicast-security-07 (work in progress), May 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.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. Kumar Expires January 3, 2015 [Page 15]
Internet-Draft Group Communication Security for LLN July 2014 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006. [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. Author's Address Sandeep S. Kumar Philips Research High Tech Campus 34 Eindhoven 5656 AE NL Email: sandeep.kumar@philips.com Kumar Expires January 3, 2015 [Page 16]