Internet DRAFT - draft-kumar-dice-groupcomm-security

draft-kumar-dice-groupcomm-security







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]