Internet DRAFT - draft-kumar-dice-multicast-security

draft-kumar-dice-multicast-security







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,
              <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 & 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]