LWIG Working Group                                               S. Keoh
Internet-Draft                                                  S. Kumar
Intended Status: Informational                         O. Garcia-Morchon
Expires: August 22, 2013                                Philips Research
                                                       February 18, 2013


          Securing the IP-based Internet of Things with DTLS
                      draft-keoh-lwig-dtls-iot-00


Abstract

   The IP-based Internet of Things (IoT) refers to the pervasive
   interaction of smart devices and people enabling new applications by
   means of IP protocols. Traditional IP protocols will be further
   complemented by 6LoWPAN and CoAP to make the IoT feasible on small
   devices. Security and privacy are a must for such an environment. Due
   to mobility, limited bandwidth, resource constraints, and new
   communication topologies, existing security solutions need to be
   adapted. We propose a security architecture for the IoT in order to
   provide network access control to smart devices, the management of
   keys and securing unicast/multicast communication. Devices are
   authenticated and granted network access by means of a pre-shared key
   (PSK) based security handshake protocol. The solution is based on
   Datagram Transport Layer Security (DTLS). Through the established
   secure channels, keying materials, operational and security
   parameters are distributed, enabling devices to derive session keys
   and group keys. The solution relies on the DTLS Record Layer for the
   protection of unicast and multicast data flows. We have prototyped
   and evaluated the security architecture. The DTLS architecture allows
   for easier interaction and interoperability with the Internet due to
   the extensive use of TLS. However, it exhibits performance issues
   constraining its deployment in some network topologies and hence
   would require further optimizations.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any



Keoh, et al.            Expires August 22, 2013                 [Page 1]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2013 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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Related Work and Background  . . . . . . . . . . . . . . . . .  5
   3 Use Cases & Problem Statement  . . . . . . . . . . . . . . . . .  6
     3.1 Problem Statement and Requirements . . . . . . . . . . . . .  6
     3.2 Threat model, Security Goals & Assumptions . . . . . . . . .  7
   4 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2 Secure Network Access  . . . . . . . . . . . . . . . . . . .  9
     4.3 Key Management . . . . . . . . . . . . . . . . . . . . . . . 10
       4.3.1 Management of unicast keys . . . . . . . . . . . . . . . 10
       4.3.2 Management of multicast keys . . . . . . . . . . . . . . 11
     4.4 Secure Uni- and Multicast Communication  . . . . . . . . . . 11
       4.4.1 Unicast Communication  . . . . . . . . . . . . . . . . . 12
       4.4.2 Multicast Communication  . . . . . . . . . . . . . . . . 12
   5 Implementation and Evaluation  . . . . . . . . . . . . . . . . . 12
     5.1 Prototype Implementation . . . . . . . . . . . . . . . . . . 12
     5.2 Memory consumption . . . . . . . . . . . . . . . . . . . . . 13
     5.3 Communication overhead . . . . . . . . . . . . . . . . . . . 14



Keoh, et al.            Expires August 22, 2013                 [Page 2]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


   6. Conclusions and future work . . . . . . . . . . . . . . . . . . 14
   7  Security Considerations . . . . . . . . . . . . . . . . . . . . 15
   8  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   10  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2  Informative References  . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17











































Keoh, et al.            Expires August 22, 2013                 [Page 3]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


1  Introduction

   The IP-based Internet of Things (IoT) will enable smart and mobile
   devices equipped with sensing, acting, and wireless communication
   capabilities to interact and cooperate with each other in a pervasive
   way by means of IP connectivity. IP protocols play a key role in this
   vision since they allow for end-to-end connectivity using standard
   protocols ensuring that different smart devices can easily
   communicate with each other in an inexpensive way. Protocols such as
   IPv6, TCP and HTTP that are commonly used in traditional networks
   will be complemented by IPv6 over Low power Wireless Personal Area
   Networks (6LoWPAN) and Constrained Application Protocol (CoAP)
   currently in development in IETF.

   This allows smart and mobile devices used for various applications
   like healthcare monitoring, industrial automation and smart cities to
   be seamlessly connected to the Internet, thus creating a plethora of
   IoT applications. An example application is smart-metering, in which
   a smart-meter can communicate with consumer electronics and other
   devices in a building/household to retrieve and manage energy
   consumption. Additionally, a set of lighting devices could be
   controlled and managed efficiently by the smart-meter, e.g., dimming
   them down during peak energy periods by means of a multicast message.

   Security and privacy are mandatory requirements for the IP-based IoT
   in order to ensure its acceptance. The interaction between devices
   must be regulated in the sense that authorized devices joining a
   specific IoT network in a given location will be granted access to
   only certain resources provided by the IoT.

   To enable this, the IoT network has to:
      1. Authorize the joining of the smart device, such that it is
         provisioned and configured  with the corresponding operational
         parameters, thus providing "network access".
      2. Establish and derive pairwise keys, application session keys
         and multicast keys to enable devices to secure its
         communication links with each other, and for that, "key
         management" is needed.
      3. Devices should be able to communicate within the network,
         either securely pairwise or in a "secure multicast" group.

   In order to achieve these three security functionalities, there are
   several challenges: (i) no standard solution exists yet; (ii)
   mobility of smart devices should be accounted for; (iii) the solution
   needs to be applicable to large scale deployments; (iv) new
   communication patterns introduced in IoT such as multicast (beyond
   just end-to-end communication links), and thus, IP security protocols
   need to be adapted; and (v) the available resources (bandwidth,



Keoh, et al.            Expires August 22, 2013                 [Page 4]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


   memory, and CPU) are tightly constrained.

   Of course, the three research topics are not new, and indeed, some of
   them (e.g., key management or secure broadcast) have been extensively
   analyzed in the wireless sensor network literature during the last
   decade. However, the last step of applying those results to actual
   standards to get a working solution is still a missing and crucial
   step towards the success of the IP-based IoT. This work analyzes how
   this can be achieved.

   We present a security architecture for the IP-based IoT in order to
   explore how these functionalities can be achieved by adapting and
   extending IP security protocols. With this, our goal is to analyze
   the trade-offs regarding performance, security, and interoperability
   so that we obtain a solution that performs reliably, offers high
   security, and is as interoperable as possible with the standard
   Internet.

   The solution is based on Datagram Transport Layer Security (DTLS).
   Beyond the handshakes themselves, we explain how to use them to allow
   for secure network access, flexible key management as well as uni-
   and multicast operation. We use the DTLS handshake for network
   access. For key management we integrate with the Adapted Multimedia
   Internet KEYing (AMIKEY) protocol for efficient key management and
   generation of pairwise keys within an IoT network. Secure multicast
   operation is enabled through the direct use of DTLS record layer with
   the multicast keys to protect CoAP messages on top of IP multicast.

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].


2.  Related Work and Background

   The "Datagram Transport Layer Security (DTLS)" protocol [RFC4347] is
   a datagram-compatible adaption of TLS that runs on top of UDP. DTLS
   uses similar messages as defined in TLS including the DTLS handshake
   to establish a secure unicast link and the DTLS record layer to
   protect this link. The "DTLS handshake" supports different types of
   authentication mechanisms, e.g., using a pre-shared key, public-key
   certificates, and raw public-keys. DTLS is the mandatory standard for
   protection of CoAP [I-D.ietf-core-coap] messages. DTLS differs from
   TLS mainly in three aspects:
      (1) DTLS provides DoS protection through a stateless cookie
         exchange;



Keoh, et al.            Expires August 22, 2013                 [Page 5]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


      (2) DTLS adds functionality to ensure a reliable link during its
         handshake to solve UDP's inherent packet losses and reordering;
      (3) The record layer includes an explicit sequence number (again,
         due to the reordering issues in UDP) so that payload integrity
         and reply protection can be ensured.

   The Adapted Multimedia KEYing (AMIKEY) [I-D.alexander-roll-mikey] is
   used to provide keying material for securing uni- and multicast
   communications within constrained networks and devices. It is based
   on MIKEY, a Key Management Protocol intended for use in real-time
   applications [RFC3830]. For this purpose, AMIKEY provides different
   message exchanges that may be transported directly over UDP and TCP.
   Essentially, they can be integrated within other protocol like DTLS.
   Our solutions make use of AMIKEY's key derivation mechanism as we
   consider it to be efficient for constrained networks.


3 Use Cases & Problem Statement

   Our work targets an "IoT network" running 6LoWPAN/CoAP over multiple
   hops with both uni- and multicast links, i.e. typical edge networks
   in the IoT. Devices in the "IoT network" are mobile or stationary and
   exhibit tight processing, memory and bandwidth constraints. The "IoT
   network" is connected to the public Internet through a number of
   6LoWPAN border routers (6LBR). Further, we consider a centrally
   managed scenario in which the devices and services in each "IoT
   network" are managed by a "domain manager". The "domain manager"
   could be located within the "IoT network" or in the public Internet.
   The "domain manager" along with the "IoT networks" it manages is
   denoted as the "IoT domain". We consider as a concrete example of
   such a scenario a smart building. Smart devices within the building
   (e.g., window blinds, lighting devices) form several multi-hop IoT
   networks connected to a remote building management system via some
   border routers.

3.1 Problem Statement and Requirements

   We consider an IoT domain with many devices that dynamically join the
   network, then provide or request a certain service and finally leave
   the network. These services are provided or requested using either
   unicast (e.g., switching on the heater) or multicast group
   communication (e.g., switching on all lights in a room). We identify
   three main problems that currently lack a standardized solution for
   IoT networks:

       o Network access -- A new joining device must only be able to
         communicate in a secure IoT network after securely joining the
         IoT network and receiving all necessary access parameters,



Keoh, et al.            Expires August 22, 2013                 [Page 6]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


         e.g., commissioning a new lighting bulb into the building
         network.

         The multi-hop nature of IoT networks leads to a key challenge
         here since a joining device and the domain manager cannot reach
         each other by means of regular IP routing so that specific
         approaches are needed.

         Similarly, devices that leave the IoT network should not be
         able to access the network with previous access parameters.

       o Key management -- A lightweight mechanism to derive and manage
         different keys to secure interactions in the IoT domain is
         required, e.g., different pairwise, group, and network keys.

       o Secure uni- and multicast communication -- A secure transport
         protocol is needed to protect the communication in the IoT
         domain.

         This includes both unicast and multicast links, protected using
         the derived keys, e.g., preserving the integrity and
         confidentiality of the exchanged commands.

   Additional requirements are that the solutions need to be scalable
   for an IoT domain with several hundreds or thousands of resource
   constrained devices and be based on standard IP protocols for easier
   interaction and interoperability with the Internet. In this work, we
   provide a solution to these three problems based on a smart
   combination of DTLS and AMIKEY with only minimal modifications.

3.2 Threat model, Security Goals & Assumptions

   We assume the Internet Threat Model [RFC3552] in which a malicious
   adversary can read and forge network traffic between devices at any
   point during transmission, but assume that devices themselves are
   secure. In many IoT application areas the network is indeed untrusted
   (e.g., wireless communications in public places, large factories,
   office buildings). Security of the end devices is important to create
   a secure IoT scenario, however device security is not within the
   scope of this draft. The Internet Threat Model is thus a reasonable
   choice in our context.

   We further identify the following threats in an IoT domain and the
   corresponding security goals:
       o Secure Network Access -- Attackers can perform network attacks,
         e.g., flooding the network and using the network for other
         communication purposes. To this end, only devices that have
         been authenticated and authorized through a secure network



Keoh, et al.            Expires August 22, 2013                 [Page 7]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


         access process should be allowed to communicate within the
         network.

       o Key Management -- Attackers can attempt to compromise the
         keying materials, pairwise keys, or multicast group keys by
         exploiting the vulnerability on the devices. Therefore, secure
         key derivation and key update mechanisms are required to manage
         all cryptographic keys. Similarly, compromising the derived
         keys does not enable the attackers to obtain information about
         the keying materials.

         o Secure Uni- and Multicast -- The adversary can maliciously
         modify either unicast or multicast traffic in the IoT network.
         Additionally, the adversary can eavesdrop on the data exchanged
         within an IoT domain. For unicast, two communicating parties
         must establish a pairwise key to secure the confidentiality,
         integrity and authenticity of the information exchanged.
         Multicast communication is protected using a group key, thus
         only allowing authenticated and authorized group members to
         send messages to a multicast group. We assume that the
         multicast group members can trust each other since they are
         authenticated and authorized by the domain manager. Therefore,
         we do not additionally require source authentication in the
         messages as will be detailed further later on. If a device
         leaves a multicast group, it must not be able to rejoin and
         send messages to the group later on.

   Due to the resource constrained devices in the IoT network, our
   proposed security architecture is based on the assumption that a
   device has been configured with a PSK that is known "a priori" to the
   domain manager of the IoT domain it wants to join. This assumption is
   reasonable since a PSK could be embedded and registered during the
   manufacturing process of a device and the domain manager can retrieve
   it from a central server. If more powerful devices are available, our
   secure network access can be easily updated to work with public-key
   cryptography.

4 Design

   In this section, we detail the design of our solution to the three
   problems (i) secure network access, (ii) key management, and (iii)
   uni- and multicast communication as identified in Section 3.1. The
   solution is mainly built on DTLS and AMIKEY.


4.1 Overview

   The first phase accounts for "secure network access". In our



Keoh, et al.            Expires August 22, 2013                 [Page 8]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


   architecture, the network is protected at link layer by means of a
   symmetric-key (L2 key), which is unknown to the joining device "a
   priori". Using its link local address, the joining device
   authenticates itself to the domain manager of the IoT domain by means
   of an initial handshake (DTLS) that is based on a PSK. The PSK is
   assumed to have been pre-configured in the device (cf. Section 3.2).
   On success, the domain manager issues access parameters (L2 key) that
   would allow the joining device to access the secured IoT network and
   to receive a routable IPv6 address. As the link local address only
   enables one hop communication, this poses a key challenge in multi-
   hop networks in that the domain manager cannot be reached directly.
   In the proposed solution, this issue is dealt with by means of a
   relay device, e.g. as was done in the PANA protocol by means of the
   PANA relay element [RFC6345].

   The second phase deals with "key management". The joining device is
   provided with keying material to interact with other devices either
   in pairs or groups. For pairwise key generation, two communicating
   devices that wish to interact with each other can derive a pairwise
   key based on their identities, e.g., using a polynomial scheme
   [Blundo-polynomial]. For group key generation, we assume that the
   domain manager controls the multicast groups. A joining device that
   wishes to participate in a multicast group indicates this to the
   domain manager during the initial handshake, and if authorized,
   receives the required multicast group keys from the domain manager.

   Neither pairwise nor group keys are used directly, instead they serve
   as root keying material in the MIKEY key derivation mechanism in
   order to derive fresh purpose-specific session keys for any pair or
   group of devices in the IoT network. The protocol framework for
   requesting and managing these purpose-specific keys is based on the
   lightweight MIKEY-extension called AMIKEY [I-D.alexander-roll-mikey].

   The final phase, "secure uni- and multicast", is achieved by using
   CoAP carried over the DTLS record layer. The pairwise or group keys
   derived in the key management phase are used to protect the
   communication links.

4.2 Secure Network Access

   We describe the details of the initial DTLS based handshakes as well
   as how multi-hop environments are handled.

   IETF CoRE working group defines DTLS for securing the transport of
   messages in an IoT domain. In this approach, the DTLS handshake
   protocol is used during the secure network access phase. The DTLS
   might be based on public-key certificates or raw public-keys as
   specified in CoAP. Our design uses DTLS-PSK [RFC4279], because it



Keoh, et al.            Expires August 22, 2013                 [Page 9]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


   incurs less overhead and reduces the number of exchanged messages. We
   now describe how DTLS-PSK is used in a single- and multi-hop
   scenario.

         Single-hop: In this case, the joining device can be
         authenticated with the domain manager by performing the DTLS
         handshake based on the PSK and relying on the link-local
         address. Once the device has been authenticated and authorized
         for the network, the established DTLS secure channel between
         the domain manager and the joining device is used to issue the
         L2 key to the device. DTLS-PSK provides resiliency against
         Denial-of-Service attacks through a cookie mechanism.

         Multi-hop: DTLS runs on UDP but communication is limited to a
         single hop due to the link local address. To deal with this, a
         relay device is responsible for forwarding the messages by
         using a mapping between the link local address of the joining
         device and the relay's IP address. The relaying logic consists
         of changing the link local address of the joining device with
         the relay device's IP address, in a similar way as done in PANA
         relay element [6345]. This indeed allows for the provisioning
         of L2 key to the joining device so that it can later receive
         its IP address through the neighbor discovery protocol [6775].
         However, note that the DTLS channel established during the
         handshake is bound to the relay's IP address and not the new IP
         address of the joining device. Hence, if the device were to
         communicate with the domain manager again, it would have to
         redo the DTLS handshake using its new IP address. This means
         that the DTLS channel established during network access is
         transient and it is closed by the relay device once the
         handshake is finished.

4.3 Key Management

   This section describes the details of key management for unicast and
   group communication. The goal of this phase is to set up an AMIKEY
   crypto-session bundle (CSB) for unicast as well as group
   communication. A CSB is built from some root keying material (the TEK
   Generation Key (TGK)) and some random bits ("RAND"). AMIKEY then
   defines a lightweight mechanism for the derivation and management of
   fresh purpose-specific keys, called Traffic Encryption Keys (TEKs),
   that are used to secure the communication links. We now explain, for
   both the unicast and multicast case, how the root keying material,
   i.e the TGK, is obtained, how the CSB is negotiated and set up, and
   finally how TEKs are requested and generated.

4.3.1 Management of unicast keys




Keoh, et al.            Expires August 22, 2013                [Page 10]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


   DTLS runs on the transport layer, and thus we can use it directly to
   protect the applications. The polynomial shares are used in this case
   to provide for fast pairwise key agreement between any pair of
   devices in the IoT domain. This pairwise key serves as the PSK in
   DTLS-PSK [RFC4279] enabling any two applications running on the
   devices to derive a session key. In detail:
      1. Two applications running on the devices "D1" and "D2" start a
         DTLS-PSK handshake. They exchange their identities ID_D1 and
         ID_D2 as extensions to the first two handshake messages, the
         "ClientHello" and "ServerHello".
      2. Both devices then generate a pairwise key, e.g., if a
         polynomial scheme is used, they use their polynomial shares and
         their respective identities to arrive on a pairwise key:
         K(D1,D2) = F(ID_D1, ID_D2) = F(ID_D2, ID_D1).
      3. The derived key K(D1,D2) is used as the PSK to complete the
         DTLS-PSK handshake. This PSK can be regarded as the TGK.
      4. The result of the DTLS-PSK handshake is a session key used to
         protect the communication link between the two applications on
         both devices.

4.3.2 Management of multicast keys

   The joining device first indicates during the network access phase
   that it wishes to join a certain multicast group by adding a request
   with the group id in the extension part of the "ClientHello". The
   domain manager then issues the multicast group keys to the device, if
   it has been authorized to join. It is carried as payload over DTLS
   record layer after the initial handshake has finished. Two new
   "Content Types" for the DTLS header have been defined for this
   purpose to distinguish between the DTLS protected application data
   and key management data. They are the necessary parameters to set up
   a CSB, i.e. (1) "Master Key Data" (e.g., the TGK) and (2) "Security
   Parameters Data" (e.g., the "RAND" values). The fresh TEKs can then
   be derived from the CSB by every group member for secure group
   communication.

   When a device leaves a group, the domain manager deletes it from the
   list of authenticated nodes, increases the TEK_ID and starts a new
   TEK derivation process. The parameters required for generation of the
   fresh TEK are encrypted so that the leaving device cannot derive the
   new TEK and cannot rejoin without re-authorization.

4.4 Secure Uni- and Multicast Communication

   Once the pairwise session keys or multicast group session key has
   been derived, a secure channel can be created to transport data (CoAP
   messages) between the devices in the IoT network. For this we rely on
   the DTLS record-layer to create a secure transport layer for CoAP.



Keoh, et al.            Expires August 22, 2013                [Page 11]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


   For unicast communication with DTLS based key management this is
   straightforward (standard DTLS).

   For multicast communication, the combination of our proposed
   handshake protocols with the usage of DTLS record-layer for multicast
   security is based on [I-D.keoh-multicast-security].

4.4.1 Unicast Communication

   Any pair of devices in the IoT domain that wish to communicate with
   each other, establish a CSB and derive a fresh unicast TEK through
   DTLS as described in Section 4.3.1. The TEK is used in the DTLS
   record layer (based on AES-CCM) to protect the message exchange
   between two applications. AES-CCM [RFC3610] is an AES mode of
   operation that defines the use of AES-CBC for MAC generation with
   AES-CTR for encryption. The CCM counter (corresponding to the DTLS
   epoch and sequence number fields) are initialized to 0 upon TEK
   establishment and used in the nonce construction in a standard way.

4.4.2 Multicast Communication

   Our multicast solution relies on IP multicast (i.e., an IP multicast
   address) for routing purposes and adds a security layer on top. To
   protect the communication, a group of devices establishes a multicast
   CSB and fresh TEKs using DTLS as described in Section 4.3.2. The TEK
   is then used to protect CoAP messages transported over the DTLS
   record layer in AES-CCM mode and routed via IP-multicast. Each device
   in the group uses a CCM nonce composed of a fixed common part (the
   content type from the DTLS record layer and the group identifier) and
   a variable part (the epoch and sequence number fields in the DTLS
   record layer). This ensures a unique nonce for each message [RFC3610]
   in the context of a same key.

5 Implementation and Evaluation

   This section describes the prototype of our security solution and
   evaluates the memory and communication overheads.

5.1 Prototype Implementation

   The prototype is written in C and run as an application on Contiki OS
   2.5 [Dunkels-contiki], an event-driven open source operating system
   for constrained devices. They were tested in the Cooja simulator and
   then ported to run on Redbee Econotag hardware, which features a 32-
   bit CPU, 128 KB of ROM, 128 KB of RAM, and an IEEE 802.15.4 enabled-
   radio with an AES hardware coprocessor. Both prototypes comprise all
   necessary functionality to adapt to the roles as domain manager or
   joining device.



Keoh, et al.            Expires August 22, 2013                [Page 12]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


   The prototype of our DTLS-based solution is based on the "tinydtls"
   [Bergmann-Tinydtls] library and includes most of the extensions
   defined in Section 4 as follows:

         (1) We disabled the cookie mechanism in order to fit messages
         to the available packet sizes and reduce the total number of
         messages of the DTLS handshake.

         (2) We used separate delivery instead of flight grouping of
         messages and redesigned the retransmission mechanism
         accordingly.

         (3) We modified the "tinydtls" AES-CCM module to use the AES
         hardware coprocessor.

         (4) the relay node functionality has not been included yet.

         (5) We expanded the DTLS state machine with the necessary
         additions for our key management solution.

   The following subsections further analyze the memory and
   communication overhead of the solution in a single-hop scenario.

5.2 Memory consumption

   Table 1 presents the codesize and memory consumption of the prototype
   differentiating (i) the state machine for the handshake, (ii) the
   cryptographic primitives, (iii) the key management functionality and
   (iv) the DTLS record layer mechanism as the pillar of secure
   multicast communications.

         +----------------------+-----------------+
         |                      |      DTLS       |
         |                      +--------+--------+
         |                      |  ROM   |  RAM   |
         +----------------------+--------+--------+
         | State Machine        |  8.15  |   1.9  |
         | Cryptography         |   3.3  |   1.5  |
         | Key Management       |   1.0  |   0.0  |
         | DTLS Record Layer    |   3.7  |   0.5  |
         +----------------------+--------+--------+
         | TOTAL                |  16.15 |   3.9  |
         +----------------------+--------+--------+
             Table 1: Memory Requirements in KB

   The DTLS approach appears to incur large memory footprint both in ROM
   and RAM for two reasons. First, DTLS handshake defines many message
   types and this adds more complexity to its corresponding state



Keoh, et al.            Expires August 22, 2013                [Page 13]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


   machine. The logic for message re-ordering and retransmission also
   contribute to the complexity of the DTLS state machine. Second, DTLS
   defines the use of SHA2-based crypto suites which is not available
   from the hardware crypto co-processor.

5.3 Communication overhead

   We evaluate the communication overhead of the proposed solution, in
   the context of "network access" and multicast "key management". In
   particular, we examine the message overhead and the number of
   exchanged bytes under ideal condition without any packet loss in a
   single-hop scenario, i.e., domain manager and a joining device are in
   communication range.

   Table 2 summarizes the required number of round trips, number of
   messages and the total exchanged bytes for the DTLS-based handshake
   carried out in ideal conditions, i.e., in a network without packet
   losses. DTLS handshake is considered complex as it involves the
   exchange of 12 messages to complete the handshake. Further, DTLS runs
   on top the transport layer, i.e., UDP, and hence this directly
   increases the overhead due to lower layer per-packet protocol
   headers.

         +-------------------------------+--------+
         |                               |  DTLS  |
         +-------------------------------+--------+
         | No. of Message                |    12  |
         | No. of round trips            |     4  |
         +-------------------------------+--------+
         | 802.15.4 headers              |  168B  |
         | 6LowPAN headers               |  480B  |
         | UDP headers                   |   96B  |
         | Application                   |  487B  |
         +-------------------------------+--------+
         | TOTAL                         | 1231B  |
         +-------------------------------+--------+
         Table 2: Communication overhead for Network
                  Access and Multicast Key Management

6. Conclusions and future work

   This work described approaches to secure the IP-based Internet of
   Things using DTLS with focus on (i) secure network access, (ii) key
   management, and (iii) secure uni- and multicast communication. Apart
   from secure unicast communication with DTLS, there are no standard IP
   solutions in IETF for these unavoidable problems when deploying an
   IoT network. We have shown that the existing IP-based security
   protocol, i.e., DTLS can be used and adapted to cater for low



Keoh, et al.            Expires August 22, 2013                [Page 14]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


   resource devices (bandwidth, memory and CPU) and new communication
   patterns such as multicast and multi-hop network access.

   As a proof of concept, we implemented the an architecture based on
   DTLS over Contiki OS running on a Redbee Econotag. Our work has shown
   that the re-use of the existing standardized DTLS protocol to solve
   these problems with a compromise in efficiency is feasible. We hope
   that our work provides valuable protocol designs and evaluation
   results (with their pros and cons) which can provide the much needed
   direction for the standardization effort in IETF to ensure best
   solutions are adopted.


7  Security Considerations

   This document discusses various design aspects for of DTLS
   implementations.  As such this document, in entirety, concerns
   security.


8  IANA Considerations

   tbd

9.  Acknowledgements

   The authors greatly acknowledge discussion, comments and feedback
   from Dee Denteneer and Jan Henrik Ziegeldorf. We also appreciate the
   prototyping and implementation efforts by Pedro Moreno-Sanchez and
   Francisco Vidal-Meca who worked as an intern at Philips Research.

10  References

10.1  Normative References

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
              August 2004.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552, July
              2003.

   [RFC4279]  Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key
              Ciphersuites for Transport Layer Security (TLS)",



Keoh, et al.            Expires August 22, 2013                [Page 15]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


              RFC 4279, December 2005.

   [RFC3610]  Whiting, D., Housley, R., and N. Ferguson, "Counter with
              CBC-MAC (CCM)", RFC 3610, September 2003.


9.2  Informative References

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)", draft-ietf-
              core-coap-12 (work in progress), October 2012.

   [I-D.alexander-roll-mikey]
              Alexander, R., and Tsao, T. "Adapted Multimedia Internet
              KEYing (AMIKEY): An extension of Multimedia      Internet
              KEYing (MIKEY) Methods for Generic LLN Environments",
              draft-alexander-roll-mikey-lln-key-mgmt-04 (work-in-
              progress), September 2012.

   [Blundo-polynomial]
              Blundo, C., De Santis, A., Herzberg, A., Kutten, S.,
              Vaccaro, U., and Yung, M. "Perfectly-Secure Key
              Distribution for Dynamic Conferences", Advances in
              Cryptology (CRYPTO'92), 1993.

   [RFC6345]  Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and
              Yegin, A. "Protocol for Carrying Authentication for
              Network Access (PANA) Relay Element", RFC 6345, August
              2011.

   [RFC6775]  Shelby, Z., Chakrabarti, S., Nordmark, E., and Bormann, C.
              "Neighbor Discovery Optimization for IPv6 over Low-Power
              Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
              November 2012.

   [I-D.keoh-multicast-security]
              Keoh, S., Garcia-Morchon, O., and Kumar, S. "DTLS-based
              Multicast Security for Low-Power and Lossy Networks
              (LLNs)" (work-in-progress), October 2012.

   [Dunkels-Contiki]
              Dunkels, A., Gronvall, B., and Voigt, T. "Contiki - A
              Lightweight and Flexible Operating System for Tiny
              Networked Sensors", In Proceedings of the 29th Annual IEEE
              International Conference on Local Computer Networks, IEEE,
              2004.




Keoh, et al.            Expires August 22, 2013                [Page 16]


Internet-Draft           Securing IoT with DTLS        February 18, 2013


   [Bergmann-Tinydtls] Bergmann, O. "TinyDTLS - A Basic DTLS Server
              Template", http://tinydtls.sourceforge.net, 2012.



Authors' Addresses


   Sye Loong Keoh
   Philips Research
   High Tech Campus 34
   Eindhoven 5656 AE
   NL

   Email: sye.loong.keoh@philips.com

   Sandeep S. Kumar
   Philips Research
   High Tech Campus 34
   Eindhoven 5656 AE
   NL

   Email: sandeep.kumar@philips.com

   Oscar Garcia-Morchon
   Philips Research
   High Tech Campus 34
   Eindhoven 5656 AE
   NL

   Email: oscar.garcia@philips.com




















Keoh, et al.            Expires August 22, 2013                [Page 17]