[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 draft-irtf-t2trg-iot-seccons

CoRE                                                   O. Garcia-Morchon
Internet-Draft                                                   S. Keoh
Intended status: Informational                                  S. Kumar
Expires: September 15, 2011                             Philips Research
                                                               R. Hummen
                                                             RWTH Aachen
                                                               R. Struik
                                                      Struik Consultancy
                                                          March 14, 2011


       Security Considerations in the IP-based Internet of Things
                     draft-garcia-core-security-01

Abstract

   A direct interpretation of the Internet of Things concept refers to
   the usage of standard Internet protocols to allow for human-to-thing
   or thing-to-thing communication.  Although the security needs are
   well-recognized, it is still not fully clear how existing IP-based
   security protocols can be applied to this new setting.  This
   Internet-Draft first provides an overview of security architecture,
   its deployment model and general security needs in the context of the
   lifecycle of a thing.  Then, it presents challenges and requirements
   for the successful roll-out of new applications and usage of standard
   IP-based security protocols when applied to get a functional Internet
   of Things.

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 15, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the



Garcia-Morchon, et al.  Expires September 15, 2011              [Page 1]


Internet-Draft     Security Considerations for the IoT        March 2011


   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.  Conventions and Terminology Used in this Document  . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  The Thing Lifecycle and Architectural Considerations . . . . .  4
     3.1.  Security Aspects . . . . . . . . . . . . . . . . . . . . .  5
   4.  State of the Art . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  IP-based Security Solutions  . . . . . . . . . . . . . . .  8
     4.2.  Wireless Sensor Network Security and Beyond  . . . . . . . 10
   5.  Challenges for a Secure Internet of Things . . . . . . . . . . 11
     5.1.  Constraints and Heterogeneous Communication  . . . . . . . 11
       5.1.1.  Tight Resource Constraints . . . . . . . . . . . . . . 11
       5.1.2.  Denial-of-Service Resistance . . . . . . . . . . . . . 13
       5.1.3.  Protocol Translation and End-to-End Security . . . . . 13
     5.2.  Bootstrapping of a Security Domain . . . . . . . . . . . . 15
       5.2.1.  Distributed vs. Centralized Architecture and
               Operation  . . . . . . . . . . . . . . . . . . . . . . 15
       5.2.2.  Bootstrapping a thing's identity and keying
               materials  . . . . . . . . . . . . . . . . . . . . . . 16
       5.2.3.  Privacy-aware Identification . . . . . . . . . . . . . 17
     5.3.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . 18
       5.3.1.  End-to-End Security  . . . . . . . . . . . . . . . . . 18
       5.3.2.  Group Membership and Security  . . . . . . . . . . . . 19
       5.3.3.  Mobility and IP Network Dynamics . . . . . . . . . . . 19
   6.  Next Steps towards a Flexible and Secure Internet of Things  . 20
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26








Garcia-Morchon, et al.  Expires September 15, 2011              [Page 2]


Internet-Draft     Security Considerations for the IoT        March 2011


1.  Conventions and Terminology Used in this Document

   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 "Key words for use in
   RFCs to Indicate Requirement Levels" [RFC2119].


2.  Introduction

   The Internet of Things (IoT) denotes the interconnection of highly
   heterogeneous networked entities and networks following a number of
   communication patterns such as: human-to-human (H2H), human-to-thing
   (H2T), thing-to-thing (T2T), or thing-to-things (T2Ts).  The term IoT
   was first coined by the Auto-ID center [AUTO-ID] in 1999.  Since
   then, the development of the underlying concepts has ever increased
   its pace.  Nowadays, the IoT presents a strong focus of research with
   various initiatives working on the (re)design, application, and usage
   of standard Internet technology in the IoT.

   The introduction of IPv6 and web services as fundamental building
   blocks for IoT applications [ID-KIM] promises to bring a number of
   basic advantages including: (i) a homogeneous protocol ecosystem that
   allows simple integration with Internet hosts; (ii) simplified
   development of very different appliances; (iii) an unified interface
   for applications, removing the need for application-level proxies.
   Such features greatly simplify the deployment of the envisioned
   scenarios ranging from building automation to production environments
   to personal area networks, in which very different things such as a
   temperature sensor, a luminaire, or an RFID tag might interact with
   each other, with a human carrying a smart phone, or with backend
   services.

   This Internet Draft presents an overview of the security aspects of
   the envisioned all-IP architecture as well as of the lifecycle of an
   IoT device, a thing, within this architecture.  In particular, we
   review the most pressing aspects and functionalities that are
   required for a secure all-IP solution.

   With this, this Internet-Draft pursues several goals.  First, we aim
   at presenting a comprehensive view of the interactions and
   relationships between an IoT application and security.  Second, we
   aim at describing challenges for a secure IoT in the specific context
   of the lifecycle of a resource-constrained device.  The final goal of
   this draft is to discuss the next steps towards a secure IoT.

   The rest of the Internet-Draft is organized as follows.  Section 3
   depicts the lifecycle of a thing and gives general definitions for



Garcia-Morchon, et al.  Expires September 15, 2011              [Page 3]


Internet-Draft     Security Considerations for the IoT        March 2011


   the main security aspects within the IoT domain.  In Section 4, we
   review existing protocols and work done in the area of security for
   wireless sensor networks.  Section 5 identifies general challenges
   and needs for an IoT security protocol design and discusses existing
   protocols and protocol proposals against the identified requirements.
   Section 6 summarizes concrete steps towards a secure Internet of
   Things.  Section 7 includes final remarks and conclusions.


3.  The Thing Lifecycle and Architectural Considerations

   We consider the installation of a Building Automation and Control
   (BAC) system to illustrate the lifecycle of a thing in a BAC
   scenario.  A BAC system consists of a network of interconnected nodes
   that perform various functions in the domains of HVAC (Heating,
   Ventilating, and Air Conditioning), lighting, safety etc.  The nodes
   vary in functionality and a majority of them represent resource
   constrained devices such as sensors and luminaries.  Some devices may
   also be battery operated or battery-less nodes, demanding for a focus
   on low energy consumption and on sleeping devices.

   In our example, the life of a thing starts when it is manufactured.
   Due to the different application areas (i.e., HVAC, lighting, safety)
   nodes are tailored to a specific task.  It is therefore unlikely that
   one single manufacturer will create all nodes in a building.  Hence,
   interoperability as well as trust bootstrapping between nodes of
   different vendors is important.  The thing is later installed and
   commissioned within a network by an installer during the
   bootstrapping phase.  Specifically, the device identity and the
   secret keys used during normal operation are provided to the device
   during this phase.  Different subcontractors may install different
   IoT devices for different purposes.  Furthermore, the installation
   and bootstrapping procedures may not be a defined event but may
   stretch over an extended period of time.  After being bootstrapped,
   the device and the system of things are in operational mode and run
   the functions of the BAC system.  During this operational phase, the
   device is under the control of the system owner.  For devices with
   lifetimes spanning several years, occasional maintenance cycles may
   be required.  During each maintenance phase, the software on the
   device can be upgraded or applications running on the device can be
   reconfigured.  The maintenance tasks can thereby be performed either
   locally or from a backend system.  Depending on the operational
   changes of the device, it may be required to re-bootstrap at the end
   of a maintenance cycle.  The device continues to loop through the
   operational phase and the eventual maintenance phase until the device
   is decommissioned at the end of its lifecycle.  However, the end-of-
   life of a device does not necessarily mean that it is defective but
   rather denotes a need to replace and upgrade the network to next-



Garcia-Morchon, et al.  Expires September 15, 2011              [Page 4]


Internet-Draft     Security Considerations for the IoT        March 2011


   generation devices in order to provide additional functionality.
   Therefore the device can be removed and re-commissioned to be used in
   a different network under a different owner by starting the lifecycle
   over again.  Figure 1 shows the generic lifecycle of a thing.  This
   generic lifecycle is also applicable for IoT scenarios other than BAC
   systems.

   At present, BAC systems use legacy building control standards such as
   BACNet [BACNET] or DALI [DALI] with independent networks for each
   subsystem (HVAC, lighting, etc.).  However, this separation of
   functionality adds further complexity and costs to the configuration
   and maintenance of the different networks within the same building.
   As a result, more recent building control networks employ IP-based
   standards allowing seamless control over the various nodes with a
   single management system.  While allowing for easier integration,
   this shift towards IP-based standards results in new requirements
   regarding the implementation of IP security protocols on constrained
   devices and the bootstrapping of security keys for devices across
   multiple manufacturers.

    _Manufactured           _SW update          _Decommissioned
   /                       /                   /
   |   _Installed          |   _ Application   |   _Removed &
   |  /                    |  / reconfigured   |  /  replaced
   |  |   _Commissioned    |  |                |  |
   |  |  /                 |  |                |  |   _Reownership &
   |  |  |    _Application |  |   _Application |  |  / recommissioned
   |  |  |   /   running   |  |  / running     |  |  |
   |  |  |   |             |  |  |             |  |  |             \\
   +##+##+###+#############+##+##+#############+##+##+##############>>>
       \/  \______________/ \/  \_____________/ \___/         time //
       /           /         \          \          \
   Bootstrapping  /      Maintenance &   \     Maintenance &
                 /      re-bootstrapping  \   re-bootstrapping
           Operational                Operational

            The lifecycle of a thing in the Internet of Things.

                                 Figure 1

3.1.  Security Aspects

   The term security subsumes a wide range of different concepts.  In
   the first place, it refers to the basic provision of security
   services including confidentiality, authentication, integrity,
   authorization, non-repudiation, and availability, and some augmented
   services, such as duplicate detection and detection of stale packets
   (timeliness).  These security services can be implemented by a



Garcia-Morchon, et al.  Expires September 15, 2011              [Page 5]


Internet-Draft     Security Considerations for the IoT        March 2011


   combination of cryptographic mechanisms, such as block ciphers, hash
   functions, or signature algorithms, and non-cryptographic mechanisms,
   which implement authorization and other security policy enforcement
   aspects.  For each of the cryptographic mechanisms, a solid key
   management infrastructure is fundamental to handling the required
   cryptographic keys, whereas for security policy enforcement, one
   needs to properly codify authorizations as a function of device roles
   and a security policy engine that implements these authorization
   checks and that can implement changes hereto throughout the system's
   lifecycle.

   In the context of the IoT, however, the security must not only focus
   on the required security services, but also how these are realized in
   the overall system and how the security functionalities are executed.
   To this end, we use the following terminology to analyze and classify
   security aspects in the IoT:

   1   The security architecture refers to the system elements involved
       in the management of the security relationships between things
       and the way these security interactions are handled (e.g.,
       centralized or distributed) during the lifecycle of a thing.

   2   The security model of a node describes how the security
       parameters, processes, and applications are managed in a thing.
       This includes aspects such as process separation, secure storage
       of keying materials, etc.

   3   Security bootstrapping denotes the process by which a thing
       securely joins the IoT at a given location and point in time.
       Bootstrapping includes the authentication and authorization of a
       device as well as the transfer of security parameters allowing
       for its trusted operation in a given network.

   4   Network security describes the mechanisms applied within a
       network to ensure trusted operation of the IoT.  Specifically, it
       prevents attackers from endangering or modifying the expected
       operation of networked things.  Network security can include a
       number of mechanisms ranging from secure routing to data link
       layer and network layer security.

   5   Application security guarantees that only trusted instances of an
       application running in the IoT can communicate with each other,
       while illegitimate instances cannot interfere.








Garcia-Morchon, et al.  Expires September 15, 2011              [Page 6]


Internet-Draft     Security Considerations for the IoT        March 2011


              ..........................
              :           +-----------+:
              :       *+*>|Application|*****
              :       *|  +-----------+:   *
              :       *|  +-----------+:   *
              :       *|->| Transport |:   *
              :    * _*|  +-----------+:   *
              :    *|  |  +-----------+:   *
              :    *|  |->|  Network  |:   *
              :    *|  |  +-----------+:   *
              :    *|  |  +-----------+:   *    *** Bootstrapping
              :    *|  +->|     L2    |:   *    ~~~ Application Security
              :    *|     +-----------+:   *
              :+--------+              :   *
              :|Security| Configuration:   *
              :|Service |   Entity     :   *
              :+--------+              :   *
              :........................:   *
                                           *
  .........................                *  .........................
  :+--------+             :                *  :             +--------+:
  :|Security|   Node B    :                *  :   Node A    |Security|:
  :|Service |             :                *  :             |Service |:
  :+--------+             :                *  :             +--------+:
  :    |     +-----------+:                *  :+-----------+     |*   :
  :    |  +->|Application|:                ****|Application|<*+* |*   :
  :    |  |  +-----------+:                   :+-----------+  |* |*   :
  :    |  |  +-----------+:                   :+-----------+  |* |*   :
  :    |  |->| Transport |~~~~~~~~~~~~~~~~~~~~~| Transport |<-|* |*   :
  :    |__|  +-----------+: ................. :+-----------+  |*_|*   :
  :       |  +-----------+: : +-----------+ : :+-----------+  | *     :
  :       |->|  Network  |: : |  Network  | : :|  Network  |<-|       :
  :       |  +-----------+: : +-----------+ : :+-----------+  |       :
  :       |  +-----------+: : +-----------+ : :+-----------+  |       :
  :       +->|     L2    |: : |     L2    | : :|     L2    |<-+       :
  :          +-----------+: : +-----------+ : :+-----------+          :
  :.......................: :...............: :.......................:
                     Overview of Security Mechanisms.

                                 Figure 2

   We now discuss an exemplary security architecture relying on a
   configuration entity for the management of the system with regard to
   the introduced security aspects (see Figure 2).  Inspired by the
   security framework for routing over low power and lossy network
   [ID-Tsao], we show an example of security model and illustrates how
   different security concepts and the lifecycle phases map to the
   Internet communication stack.  Assume a centralized architecture in



Garcia-Morchon, et al.  Expires September 15, 2011              [Page 7]


Internet-Draft     Security Considerations for the IoT        March 2011


   which a configuration entity stores and manages the identities of the
   things associated with the system along with their cryptographic
   keys.  During the bootstrapping phase, each thing executes the
   bootstrapping protocol with the configuration entity, thus obtaining
   the required device identities and the keying material.  The security
   service on a thing in turn stores the received keying material for
   the network layer and application security mechanisms for secure
   communication.  Things can then securely communicate with each other
   during their operational phase by means of the employed network and
   application security mechanisms.


4.  State of the Art

   Nowadays, there exists a multitude of control protocols for the IoT.
   For BAC systems, the ZigBee standard [ZB], BACNet [BACNET], or DALI
   [DALI] play key roles.  Recent trends, however, focus on an all-IP
   approach for system control.

   In this setting, a number of IETF working groups are designing new
   protocols for resource constrained networks of smart things.  The
   6LoWPAN working group [WG-6LoWPAN] concentrates on the definition of
   methods and protocols for the efficient transmission and adaptation
   of IPv6 packets over IEEE 802.15.4 networks [RFC4944].  The CoRE
   working group [WG-CoRE] provides a framework for resource-oriented
   applications intended to run on constrained IP network (6LoWPAN).
   One of its main tasks is the definition of a lightweight version of
   the HTTP protocol, the Constrained Application Protocol (CoAP)
   [ID-CoAP], that runs over UDP and enables efficient application-level
   communication for things.

4.1.  IP-based Security Solutions

   In the context of the IP-based IoT solutions, consideration of TCP/IP
   security protocols is important as these protocols are designed to
   fit the IP network ideology and technology.  While a wide range of
   specialized as well as general-purpose key exchange and security
   solutions exist for the Internet domain, we discuss a number of
   protocols and procedures that have been recently discussed in the
   context of the above working groups.  The considered protocols are
   IKEv2/IPsec [RFC4306], TLS/SSL [RFC5246], DTLS [RFC5238], HIP
   [RFC5201][ID-Moskowitz], PANA [RFC5191], and EAP [RFC3748] in this
   Internet-Draft.  Application layer solutions such as SSH [RFC4251]
   also exist, however, these are currently not considered.  Figure 3
   depicts the relationships between the discussed protocols in the
   context of the security terminology introduced in Section 3.1.





Garcia-Morchon, et al.  Expires September 15, 2011              [Page 8]


Internet-Draft     Security Considerations for the IoT        March 2011


             ..........................
             :           +-----------+:
             :       *+*>|Application|*****     *** Bootstrapping
             :       *|  +-----------+:   *     ### Application Security
             :       *|  +-----------+:   *     === Network security
             :       *|->| Transport |:   *
             :    * _*|  +-----------+:   *
             :    *|  |  +-----------+:   *
             :    *|  |->|  Network  |:   *--> -PANA/EAP
             :    *|  |  +-----------+:   *    -HIP
             :    *|  |  +-----------+:   *
             :    *|  +->|     L2    |:   *     ## DTLS
             :    *|     +-----------+:   *     ##
             :+--------+              :   *
             :|Security| Configuration:   *     [] HIP,IKEv2
             :|Service |   Entity     :   *     [] ESP/AH
             :+--------+              :   *
             :........................:   *
                                          *
 .........................                *    .........................
 :+--------+             :                *    :             +--------+:
 :|Security|   Node B    :                *    :   Node A    |Security|:
 :|Service |             :                *    :             |Service |:
 :+--------+             :     Secure     *    :             +--------+:
 :    |     +-----------+:     routing    *    :+-----------+     |*   :
 :    |  +->|Application|:    framework   ******|Application|<*+* |*   :
 :    |  |  +----##-----+:        |            :+----##-----+  |* |*   :
 :    |  |  +----##-----+:        |            :+----##-----+  |* |*   :
 :    |  |->| Transport |#########|#############| Transport |<-|* |*   :
 :    |__|  +----[]-----+:  ......|..........  :+----[]-----+  |*_|*   :
 :       |  +====[]=====+=====+===========+=====+====[]=====+  | *     :
 :       |->|| Network  |:  : |  Network  | :  :|  Network ||<-|       :
 :       |  +|----------+:  : +-----------+ :  :+----------|+  |       :
 :       |  +|----------+:  : +-----------+ :  :+----------|+  |       :
 :       +->||    L2    |:  : |     L2    | :  :|     L2   ||<-+       :
 :          +===========+=====+===========+=====+===========+          :
 :.......................:  :...............:  :.......................:
            Relationships between IP-based security protocols.

                                 Figure 3

   The Internet Key Exchange (IKEv2)/IPsec and the Host Identity
   protocol (HIP) reside at or above the network layer in the OSI model.
   Both protocols are able to perform an authenticated key exchange and
   set up the IPsec transforms for secure payload delivery.  Currently,
   there are also ongoing efforts to create a HIP variant coined Diet
   HIP [ID-HIP] that takes lossy low-power networks into account at the
   authentication and key exchange level.



Garcia-Morchon, et al.  Expires September 15, 2011              [Page 9]


Internet-Draft     Security Considerations for the IoT        March 2011


   Transport Layer Security (TLS) and its datagram-oriented variant DTLS
   secure transport-layer connections.  TLS provides security for TCP
   and requires a reliable transport, while DTLS secures and uses
   datagram-oriented protocols such as UDP.  Both protocols are
   intentionally kept similar and share the same ideology and cipher
   suites.

   The Extensible Authentication Protocol (EAP) is an authentication
   framework supporting multiple authentication methods.  EAP runs
   directly over the data link layer and, thus, does not require the
   deployment of IP.  It supports duplicate detection and
   retransmission, but does not allow for packet fragmentation.  The
   Protocol for Carrying Authentication for Network Access (PANA) is a
   network-layer transport for EAP that enables network access
   authentication between clients and the network infrastructure.  In
   EAP terms, PANA is a UDP-based EAP lower layer that runs between the
   EAP peer and the EAP authenticator.

4.2.  Wireless Sensor Network Security and Beyond

   A variety of key agreement and privacy protection protocols that are
   tailored to IoT scenarios have been introduced in the literature.
   For instance, random key pre-distribution schemes [PROC-Chan] or more
   centralized solutions, such as SPINS [JOURNAL-Perrig], have been
   proposed for key establishment in wireless sensor networks.  The
   ZigBee standard [ZB] for sensor networks defines a security
   architecture based on an online trust center that is in charge of
   handling the security relationships within a ZigBee network.
   Personal privacy in ubiquitous computing has been studied
   extensively, e.g., in [THESIS-Langheinrich].  Due to resource
   constraints and the specialization to meet specific requirements,
   these solutions often implement a collapsed cross layer optimized
   communication stack (e.g., without task-specific network layers and
   layered packet headers).  Consequently, they cannot directly be
   adapted to the requirements of the Internet due to the nature of
   their design.

   Despite important steps done by, e.g., Gupta et al.  [PROC-Gupta], to
   show the feasibility of an end-to-end standard security architecture
   for the embedded Internet, the Internet and the IoT domain still do
   not fit together easily.  This is mainly due to the fact that IoT
   security solutions are often tailored to the specific scenario
   requirements without considering interoperability with Internet
   protocols.  On the other hand, the direct use of existing Internet
   security protocols in the IoT might lead to inefficient or insecure
   operation as we show in our discussion below.





Garcia-Morchon, et al.  Expires September 15, 2011             [Page 10]


Internet-Draft     Security Considerations for the IoT        March 2011


5.  Challenges for a Secure Internet of Things

   In this section, we take a closer look at the various security
   challenges in the operational and technical features of the IoT and
   then discuss how existing Internet security protocols cope with these
   technical and conceptual challenges through the lifecycle of a thing.
   Table 1 summarizes which requirements need to be met in the lifecycle
   phases as well as the considered protocols.  The structure of this
   section follows the structure of the table.  This discussion should
   neither be understood as a comprehensive evaluation of all protocols,
   nor can it cover all possible aspects of IoT security.  Yet, it aims
   at showing concrete limitations of existing Internet security
   protocols in some areas rather than giving an abstract discussion
   about general properties of the protocols.  In this regard, the
   discussion handles issues that are most important from the authors'
   perspectives.

5.1.  Constraints and Heterogeneous Communication

   Coupling resource constrained networks and the powerful Internet is a
   challenge because the resulting heterogeneity of both networks
   complicates protocol design and system operation.  In the following
   we briefly discuss the resource constraints of IoT devices and the
   consequences for the use of Internet Protocols in the IoT domain.

5.1.1.  Tight Resource Constraints

   The IoT is a resource-constrained network that relies on lossy and
   low-bandwidth channels for communication between small nodes,
   regarding CPU, memory, and energy budget.  These characteristics
   directly impact the threats to and the design of security protocols
   for the IoT domain.  First, the use of small packets, e.g., IEEE
   802.15.4 supports 127-byte sized packets at the physical layer, may
   result in fragmentation of larger packets of security protocols.
   This may open new attack vectors for state exhaustion DoS attacks,
   which is especially tragic, e.g., if the fragmentation is caused by
   large key exchange messages of security protocols.  Moreover, packet
   fragmentation commonly downgrades the overall system performance due
   to fragment losses and the need for retransmissions.  For instance,
   fate-sharing packet flight as implemented by DTLS might aggravate the
   resulting performance loss.










Garcia-Morchon, et al.  Expires September 15, 2011             [Page 11]


Internet-Draft     Security Considerations for the IoT        March 2011


              +--------------------------------------------------------+
              | Bootstrapping phase        | Operational Phase         |
 +------------+--------------------------------------------------------+
 |            |Incremental deployment      |End-to-End security        |
 |Requirements|Identity and key management |Mobility support           |
 |            |Privacy-aware identification|Group membership management|
 |            |Group creation              |                           |
 +------------+--------------------------------------------------------+
 |            |IKEv2                       |IKEv2/MOBIKE               |
 |Protocols   |TLS/DTLS                    |TLS/DTLS                   |
 |            |HIP/Diet-HIP                |HIP/Diet-HIP               |
 |            |PANA/EAP                    |                           |
 +---------------------------------------------------------------------+

            Relationships between IP-based security protocols.

                                 Figure 4

   The size and number of messages should be minimized to reduce memory
   requirements and optimize bandwidth usage.  In this context, layered
   approaches involving a number of protocols might lead to worse
   performance in resource-constrained devices since they combine the
   headers of the different protocols.  In some settings, protocol
   negotiation can increase the number of exchanged messages.  To
   improve performance during basic procedures such as, e.g.,
   bootstrapping, it might be a good strategy to perform those
   procedures at a lower layer.  This involves le

   Small CPUs and scarce memory limit the usage of resource-expensive
   cryptoprimitives such as public-key cryptography as used in most
   Internet security standards.  This is especially true, if the basic
   cryptoblocks need to be frequently used or the underlying application
   demands a low delay.

   Independently from the development in the IoT domain, all discussed
   security protocols show efforts to reduce the cryptographic cost of
   the required public-key-based key exchanges and signatures with
   ECC[RFC5246][RFC5903][ID-Moskowitz][ID-HIP].  Moreover, all protocols
   have been revised in the last years to enable crypto agility, making
   cryptographic primitives interchangeable.  Diet HIP takes the
   reduction of the cryptographic load one step further by focusing on
   cryptographic primitives that are to be expected to be enabled in
   hardware on IEEE 802.15.4 compliant devices.  For example, Diet HIP
   does not require cryptographic hash functions but uses a CMAC [NIST]
   based mechanism, which can directly use the AES hardware available in
   standard sensor platforms.  However, these improvements are only a
   first step in reducing the computation and communication overhead of
   Internet protocols.  The question remains if other approaches can be



Garcia-Morchon, et al.  Expires September 15, 2011             [Page 12]


Internet-Draft     Security Considerations for the IoT        March 2011


   applied to leverage key agreement in these heavily resource-
   constrained environments.

   A further fundamental need refers to the limited energy budget
   available to IoT nodes.  Careful protocol (re)design and usage is
   required to reduce not only the energy consumption during normal
   operation, but also under DoS attacks.  Since the energy consumption
   of IoT devices differs from other device classes, judgments on the
   energy consumption of a particular protocol cannot be made without
   tailor-made IoT implementations.

5.1.2.  Denial-of-Service Resistance

   The tight memory and processing constraints of things naturally
   alleviate resource exhaustion attacks.  Especially in unattended T2T
   communication, such attacks are difficult to notice before the
   service becomes unavailable (e.g., because of battery or memory
   exhaustion).  As a DoS countermeasure, DTLS, IKEv2, HIP, and Diet HIP
   implement return routability checks based on a cookie mechanism to
   delay the establishment of state at the responding host until the
   address of the initiating host is verified.  The effectiveness of
   these defenses strongly depends on the routing topology of the
   network.  Return routability checks are particularly effective if
   hosts cannot receive packets addressed to other hosts and if IP
   addresses present meaningful information as is the case in today's
   Internet.  However, they are less effective in broadcast media or
   when attackers can influence the routing and addressing of hosts
   (e.g., if hosts contribute to the routing infrastructure in ad-hoc
   networks and meshes).

   In addition, HIP implements a puzzle mechanism that can force the
   initiator of a connection (and potential attacker) to solve
   cryptographic puzzles with variable difficulties.  Puzzle-based
   defense mechanisms are less dependent on the network topology but
   perform poorly if CPU resources in the network are heterogeneous
   (e.g., if a powerful Internet host attacks a thing).  Increasing the
   puzzle difficulty under attack conditions can easily lead to
   situations, where a powerful attacker can still solve the puzzle
   while weak IoT clients cannot and are excluded from communicating
   with the victim.  Still, puzzle-based approaches are a viable option
   for sheltering IoT devices against unintended overload caused by
   misconfigured or malfunctioning things.

5.1.3.  Protocol Translation and End-to-End Security

   Even though 6LoWPAN and CoAP progress towards reducing the gap
   between Internet protocols and the IoT, they do not target protocol
   specifications that are identical to their Internet pendants due to



Garcia-Morchon, et al.  Expires September 15, 2011             [Page 13]


Internet-Draft     Security Considerations for the IoT        March 2011


   performance reasons.  Hence, more or less subtle differences between
   IoT protocols and Internet protocols will remain.  While these
   differences can easily be bridged with protocol translators at
   gateways, they become major obstacles if end-to-end security measures
   between IoT devices and Internet hosts are used.

   Cryptographic payload processing applies message authentication codes
   or encryption to packets.  These protection methods render the
   protected parts of the packets immutable as rewriting is either not
   possible because a) the relevant information is encrypted and
   inaccessible to the gateway or b) rewriting integrity-protected parts
   of the packet would invalidate the end-to-end integrity protection.

   There are essentially four solutions for this problem:

   1   Sharing symmetric keys with gateways enables gateways to
       transform (e.g., de-compress, convert, etc.) packets and re-apply
       the security measures after transformation.  This method abandons
       end-to-end security and is only applicable to simple scenarios
       with a rudimentary security model.

   2   Reusing the Internet wire format in the IoT makes conversion
       between IoT and Internet protocols unnecessary.  However, it
       leads to poor performance because IoT specific optimizations
       (e.g., stateful or stateless compression) are not possible.

   3   Selectively protecting vital and immutable packet parts with a
       MAC or with encryption requires a careful balance between
       performance and security.  Otherwise, this approach will either
       result in poor performance (protect as much as possible) or poor
       security (compress and transform as much as possible).

   4   Message authentication codes that sustain transformation can be
       realized by considering the order of transformation and
       protection (e.g., by creating a signature before compression so
       that the gateway can decompress the packet without recalculating
       the signature).  This enables IoT specific optimizations but is
       more complex and may require application-specific transformations
       before security is applied.  Moreover, it cannot be used with
       encrypted data because the lack of cleartext prevents gateways
       from transforming packets.

   To the best of our knowledge, none of the mentioned security
   protocols provides a fully customizable solution in this problem
   space.  In fact, they usually offer an end-to-end secured connection.
   An exception is the usage layered approach as might be PANA and EAP.
   In such a case, this configuration (i) allows for a number of
   configurations regarding the location of, e.g., the EAP authenticator



Garcia-Morchon, et al.  Expires September 15, 2011             [Page 14]


Internet-Draft     Security Considerations for the IoT        March 2011


   and authentication server and (ii) the layered architecture might
   allow for authentication at different places.  The drawback of this
   approach, however, lies in its high signaling traffic volume compared
   to other approaches.  Hence, future work is required to ensure
   security, performance and interoperability between IoT and the
   Internet.

5.2.  Bootstrapping of a Security Domain

   Creating a security domain from a set of previously unassociated IoT
   devices is a key operation in the lifecycle of a thing and in the IoT
   network.  In this section, we discuss general forms of network
   operation, how to communicate a thing's identity and the privacy
   implications arising from the communication of this identity.

5.2.1.  Distributed vs. Centralized Architecture and Operation

   Most things might be required to support both centralized and
   distributed operation patterns.  Distributed thing-to-thing
   communication might happen on demand, for instance, when two things
   form an ad-hoc security domain to cooperatively fulfill a certain
   task.  Likewise, nodes may communicate with a backend service located
   in the Internet without a central security manager.  The same nodes
   may also be part of a centralized architecture with a dedicated node
   being responsible for the security management for group communication
   between things in the IoT domain.  In today's IoT, most common
   architectures are fully centralized in the sense that all the
   security relationships within a segment are handled by a central
   party.  In the ZigBee standard, this entity is the trust center.
   Current proposals for 6LoWPAN/CoRE identify the 6LoWPAN Border Router
   (6LBR) as such a device.

   A centralized architecture allows for central management of devices
   and keying materials as well as for the backup of cryptographic keys.
   However, it also imposes some limitations.  First, it represents a
   single point of failure.  This is a major drawback, e.g., when key
   agreement between two devices requires online connectivity to the
   central node.  Second, it limits the possibility to create ad-hoc
   security domains without dedicated security infrastructure.  Third,
   it codifies a more static world view, where device roles are cast in
   stone, rather than a more dynamic world view that recognizes that
   networks and devices, and their roles and ownership, may change over
   time (e.g., due to device replacement and hand-over of control).

   Decentralized architectures, on the other hand, allow creating ad-hoc
   security domains that might not require a single online management
   entity and are operative in a much more stand-alone manner.  The ad-
   hoc security domains can be added to a centralized architecture at a



Garcia-Morchon, et al.  Expires September 15, 2011             [Page 15]


Internet-Draft     Security Considerations for the IoT        March 2011


   later point in time, allowing for central or remote management.

5.2.2.  Bootstrapping a thing's identity and keying materials

   Bootstrapping refers to the process by which a device is associated
   to another one, to a network, or to a system.  The way it is
   performed depends upon the architecture: centralized or distributed
   or a combination.  It is important to realize that bootstrapping may
   involve different types of information, ranging from network
   parameters and information on device capabilities and their presumed
   functionality, to management information related to, e.g., resource
   scheduling and trust initialization/management.  Furthermore,
   bootstrapping may occur in stages during the lifecycle of a device
   and may include provisioning steps already conducted during device
   manufacturing (e.g., imprinting a unique identifier or a root
   certificate into a device during chip testing), further steps during
   module manufacturing (e.g., setting of application-based
   configurations, such as temperature read-out frequencies and push-
   thresholds), during personalization (e.g., fine-tuned settings
   depending on installation context), during hand-over (e.g., transfer
   of ownership from supplier to user), and, e.g., in preparation of
   operation in a specific network.  In what follows, we focus on
   bootstrapping of security-related information, since bootstrapping of
   all other information can be conducted as ordinary secured
   communications, once a secure and authentic channel between devices
   has been put in place.

   In a distributed approach, a Diffie-Hellman type of handshake can
   allow two peers to agree on a common secret.  In general, IKEv2, HIP,
   TLS, DTLS, can perform key exchanges and the setup of security
   associations without online connections to a trust center.  If we do
   not consider the resource limitations of things, certificates and
   certificate chains can be employed to securely communicate
   capabilities in such a decentralized scenario.  HIP and Diet HIP do
   not directly use certificates for identifying a host, however
   certificate handling capabilities exist for HIP and the same protocol
   logic could be used for Diet HIP.  It is noteworthy, that Diet HIP
   does not require a host to implement cryptographic hashes.  Hence,
   some lightweight implementations of Diet HIP might not be able to
   verify certificates unless a hash function is implemented by the
   host.

   In a centralized architecture, preconfigured keys or certificates
   held by a thing can be used for the distribution of operational keys
   in a given security domain.  A current proposal [ID-O'Flynn] refers
   to the use of PANA for the transport of EAP messages between the PANA
   client (the joining thing) and the PANA Authentication Agent (PAA),
   the 6LBR.  EAP is thereby used to authenticate the identity of the



Garcia-Morchon, et al.  Expires September 15, 2011             [Page 16]


Internet-Draft     Security Considerations for the IoT        March 2011


   joining thing.  After the successful authentication, the PANA PAA
   provides the joining thing with fresh network and security
   parameters.

   IKEv2, HIP, TLS, and DTLS could be applied as well for the transfer
   of configuration parameters in a centralized scenario.  While HIP's
   cryptographic secret identifies the thing, the other protocols do not
   represent primary identifiers but are used instead to bind other
   identifiers such as the operation keys to the public-key identities.

   In addition to the protocols, operational aspects during
   bootstrapping are of key importance as well.  Many other standard
   Internet protocols assume that the identity of a host is either
   available by using secondary services like certificate authorities or
   secure name resolution (e.g., DNSsec) or can be provided over a side
   channel (entering passwords via screen and keyboard).  While these
   assumptions may hold in traditional networks, intermittent
   connectivity, localized communication, and lack of input methods
   complicate the situation for the IoT.

   The order in which the things within a security domain are
   bootstrapped plays an important role as well.  In [ID-Duffy], the
   PANA relay element is introduced, relaying PANA messages between a
   PaC (joining thing) and PAA of a segment [ID-O'Flynn].  This approach
   forces commissioning based on distance to PAA, i.e., things can only
   be bootstrapped hop-by-hop starting from those closer to the PAA, all
   things that are 1-hop away are bootstrapped first, followed by those
   that are 2-hop away, and so on.  Such an approach might impose
   important limitations on actual use cases in which, e.g., an
   installer without technical background has to roll-out the system,
   and may force installers to conduct site surveys that include
   measurement of communication range and signal strength prior to
   deciding on device placement and conducting the installation itself.

5.2.3.  Privacy-aware Identification

   During the last years, the introduction of RFID tags has raised
   privacy concerns because anyone might access and track tags.  As the
   IoT involves not only passive devices, but also includes active and
   sensing devices, the IoT might irrupt even deeper in people's privacy
   spheres.  Thus, IoT protocols should be designed to avoid these
   privacy threats during bootstrapping and operation where deemed
   necessary.  In H2T and T2T interactions, privacy-aware identifiers
   might be used to prevent unauthorized user tracking.  Similarly,
   authentication can be used to prove membership of a group without
   revealing unnecessary individual information.

   TLS and DTLS provide the option of only authenticating the responding



Garcia-Morchon, et al.  Expires September 15, 2011             [Page 17]


Internet-Draft     Security Considerations for the IoT        March 2011


   host.  This way, the initiating host can stay anonymous.  If
   authentication for the initiating host is required as well, either
   public-key certificates or authentication via the established
   encrypted payload channel can be employed.  Such a setup allows to
   only reveal the responder's identity to possible eavesdroppers.

   HIP and IKEv2 use public-key identities to authenticate the initiator
   of a connection.  These identities could easily be traced if no
   additional protection were in place.  IKEv2 transmits this
   information in an encrypted packet.  Likewise, HIP provides the
   option to keep the identity of the initiator secret from
   eavesdroppers by encrypting it with the symmetric key generated
   during the handshake.  However, Diet HIP cannot provide a similar
   feature because the identity of the initiator simultaneously serves
   as static Diffie-Hellman key.  Note that all discussed solutions
   could use anonymous public-key identities that change for each
   communication.  However, such identity cycling may require a
   considerable computational effort for generating new asymmetric key
   pairs.  In addition to the built-in privacy features of the here
   discussed protocols, a large body of anonymity research for key
   exchange protocols e xists.  However, the comparison of these
   protocols and protocol extensions is out of scope for this work.

5.3.  Operation

   After the bootstrapping phase, the system enters the operational
   phase.  During the operational phase, things can relate to the state
   information created during the bootstrapping phase in order to
   exchange information securely and in an authenticated fashion.  In
   this section, we discuss aspects of communication patterns and
   network dynamics during this phase.

5.3.1.  End-to-End Security

   Providing end-to-end security is of great importance to address and
   secure individual T2T or H2T communication within one IoT domain.
   Moreover, end-to-end security associations are an important measure
   to bridge the gap between the IoT and the Internet.  IKEv2 and HIP,
   TLS and DTLS provide end-to end security services including peer
   entity authentication, end-to-end encryption and integrity protection
   above the network layer and the transport layer respectively.  Once
   bootstrapped, these functions can be carried out without online
   connections to third parties, making the protocols applicable for
   decentralized use in the IoT.  However, protocol translation by
   intermediary nodes may invalidate end-to-end protection measures (see
   Section 5.1).





Garcia-Morchon, et al.  Expires September 15, 2011             [Page 18]


Internet-Draft     Security Considerations for the IoT        March 2011


5.3.2.  Group Membership and Security

   In addition to end-to-end security, group key negotiation is an
   important security service for the T2Ts and Ts2T communication
   patterns in the IoT as efficient local broadcast and multicast relies
   on symmetric group keys.

   All discussed protocols only cover unicast communication and
   therefore do not focus on group-key establishment.  However, the
   Diffie-Hellman keys that are used in IKEv2 and HIP could be used for
   group Diffie-Hellman key-negotiations.  Conceptually, solutions that
   provide secure group communication at the network layer (IPsec/IKEv2,
   HIP/Diet HIP) may have an advantage regarding the cryptographic
   overhead compared to application-focused security solutions (TLS/
   DTLS).  This is due to the fact that application-focused solutions
   require cryptographic operations per group application, whereas
   network layer approaches may allow to share secure group associations
   between multiple applications (e.g., for neighbor discovery and
   routing or service discovery).  Hence, implementing shared features
   lower in the communication stack can avoid redundant security
   measures.

   A number of group key solutions have been developed in the context of
   the IETF working group MSEC in the context of the MIKEY architecture
   [WG-MSEC][RFC3830].  These are specifically tailored for multicast
   and group broadcast applications in the Internet and should also be
   considered as candidate solutions for group key agreement in the IoT.
   The MIKEY architecture describes a coordinator entity that
   disseminates symmetric keys over pair-wise end-to-end secured
   channels.  However, such a centralized approach may not be applicable
   in a distributed environment, where the choice of one or several
   coordinators and the management of the group key is not trivial.

5.3.3.  Mobility and IP Network Dynamics

   It is expected that many things (e.g., wearable sensors, and user
   devices) will be mobile in the sense that they are attached to
   different networks during the lifetime of a security association.
   Built-in mobility signaling can greatly reduce the overhead of the
   cryptographic protocols because unnecessary and costly re-
   establishments of the session (possibly including handshake and key
   agreement) can be avoided.  IKEv2 supports host mobility with the
   MOBIKE [RFC4555][RFC4621] extension.  MOBIKE refrains from applying
   heavyweight cryptographic extensions for mobility.  However, MOBIKE
   mandates the use of IPsec tunnel mode which requires to transmit an
   additional IP header in each packet.  This additional overhead could
   be alleviated by using header compression methods or the Bound End-
   to-End Tunnel (BEET) mode [ID-Nikander], a hybrid of tunnel and



Garcia-Morchon, et al.  Expires September 15, 2011             [Page 19]


Internet-Draft     Security Considerations for the IoT        March 2011


   transport mode with smaller packet headers.

   HIP offers a simple yet effective mobility management by allowing
   hosts to signal changes to their associations [RFC5206].  However,
   slight adjustments might be necessary to reduce the cryptographic
   costs, for example, by making the public-key signatures in the
   mobility messages optional.  Diet HIP does not define mobility yet
   but it is sufficiently similar to HIP to employ the same mechanisms.
   TLS and DTLS do not have standards for mobility support, however,
   work on DTLS mobility exists in the form of an Internet draft
   [ID-Williams].  The specific need for IP-layer mobility mainly
   depends on the scenario in which nodes operate.  In many cases,
   mobility support by means of a mobile gateway may suffice to enable
   mobile IoT networks, such as body sensor networks.  However, if
   individual things change their point of network attachment while
   communicating, mobility support may gain importance.


6.  Next Steps towards a Flexible and Secure Internet of Things

   As evident from the discussions of the lifecycle of a thing and the
   IP security challenges in the Internet of Things, it is important to
   define specific steps towards a feasible security concept for the IP-
   based IoT with special emphasis on the employed security protocols.
   Due to the resource constraints of IoT devices and the specific
   limitations of IoT network scenarios, this security concept will
   differ from today's Internet security architectures.  Therefore,
   focusing on the protection of a single protocol such as CoAP will not
   suffice.  The aim is to put together the key security aspects of IoT,
   making clear how the architectural, operational, and technical
   aspects impact the protocol design and choices.  Next, we list the
   most important topics towards achieving this goal.

   1   Performance assessment of candidate IP security protocols on
       resource constrained devices in the context of the IoT and its
       requirements.  To the best of our knowledge, the implementation
       feasibility of existing protocols on constrained devices (e.g.,
       8-bit CPU and limited RAM budget) has not been fully assessed so
       far.  Hence, a performance evaluation of candidate security
       solutions is required in terms of CPU and communication overhead,
       energy consumption, and memory requirements for a better
       understanding of the impact of existing IP security solutions on
       the IoT ecosystem.  Such analysis should be carried out on a
       well-defined set of standard node platforms as a reference for
       the subsequent performance evaluation and comparison.  This
       benchmarking should not just involve cryptographic constructs and
       protocols, but also include implementation benchmarks for
       security policies, since these may impact overall system



Garcia-Morchon, et al.  Expires September 15, 2011             [Page 20]


Internet-Draft     Security Considerations for the IoT        March 2011


       performance and network traffic (an example of this would be
       policies including frequent key updates, which would necessitate
       securely propagating these to all devices in the network).  These
       results then serve as a basis for the design of a suitable
       security architecture for the IoT.

   2   In-depth evaluation of the security mechanisms employed in IP
       security protocols in order to design possible adaptations for
       these protocols fitting the IoT requirements.  Here, we focus on
       the discussion of the challenges for IP security solutions in the
       IoT and hint at IP security protocol properties that violate IoT
       requirements.  Possible adaptations should allow existing
       protocols to not only fulfill the performance requirements of the
       IoT, but also to provide the security properties they have been
       designed for in the context of the Internet architecture.  An
       example might be the incorporation of new security mechanisms for
       IoT-specific DoS protection.  This is due to the fact that
       Internet protocols have been designed with comparably high
       assumptions regarding MTU size.  However, IEEE 802.15.4 networks
       have physical packets of 127 B. Thus, IoT candidate security
       solutions should avoid prohibitively long messages in order to
       (i) prevent high resource usage in the network and individual
       nodes due to fragmentation, and (ii) mitigate attackers from
       launching fragmentation-based DoS attacks.

   3   Definition of a flexible security architecture matching the
       different operational scenarios during the lifecycle of a thing.
       IoT scenario might comprise both centralized and ad-hoc security
       domains.  Hence, the IoT security architecture should incorporate
       the properties of a fully centralized architecture as well as
       allow devices to be paired together initially without the need
       for a trusted third party to create ad-hoc security domains
       comprising a number of nodes.  These ad-hoc security domains
       could then be added later to the Internet via a single, central
       node or via a collection of nodes (thus, facilitating
       implementation of a centralized or distributed architecture,
       respectively).  The architecture should also facilitate
       scenarios, where an operational network may be partitioned or
       merged, and where hand-over of control functionality of a single
       device or even of a complete subnetwork may occur over time (if
       only to facilitate smooth device repair/replacement without the
       need for a hard "system reboot" or to realize ownership
       transfer).  Thus, the IoT can transparently and effortlessly move
       from an ad-hoc security domain to a centrally-managed single
       security domain or a heterogeneous collection of security domains
       and vice-versa.





Garcia-Morchon, et al.  Expires September 15, 2011             [Page 21]


Internet-Draft     Security Considerations for the IoT        March 2011


   4   Selection and coordination of an IP security suite.  With a good
       understanding of IP security in the IoT and adapted candidate
       solutions, a security protocol suite can be chosen that fulfills
       the IoT requirements during the different phases in the lifecycle
       of a thing.  Such a protocol suite must be closely interconnected
       across layers to ensure security efficiency as resource
       limitations make it challenging to secure all layers
       individually.  In this regard, securing only the application
       layer leaves the network open to attacks, while security focused
       only at the network and link layer might introduce possible
       inter-application security threats.  Hence, the limited resources
       of things may require sharing of keying material and common
       security mechanisms between layers.  It is required that the data
       format of the keying material is standardized to facilitate cross
       layer interaction.  Additionally, cross layer concepts should be
       considered for an IoT-driven re-design of Internet security
       protocols.  To our knowledge, such a "holistic" approach to
       security architectural design is still a nascent area.

   5   Definition of a standard lightweight bootstrapping protocol for
       the commissioning of devices with keying materials, addresses,
       and network parameters in order to allow for secure network
       communication.  The bootstrapping protocol should be reusable and
       lightweight to fit into small devices.  Such a standard
       bootstrapping protocol must allow for commissioning of devices
       from different manufacturers in both centralized and ad-hoc
       scenarios and facilitate transitions of control devices during
       the device's and system's lifecycle.  Examples of the latter
       include scenarios that involve hand-over of control, e.g., from a
       configuration device to an operational management console and
       involving replacement of such a control device.  A key challenge
       for secure bootstrapping of a device in a centralized
       architecture is that it is currently not feasible to commission a
       device when the adjacent devices have not been commissioned yet.


7.  Security Considerations

   This document reflects upon the requirements and challenges of the
   security architectural framework for Internet of Things.


8.  IANA Considerations

   This document contains no request to IANA.






Garcia-Morchon, et al.  Expires September 15, 2011             [Page 22]


Internet-Draft     Security Considerations for the IoT        March 2011


9.  Acknowledgements

   We gratefully acknowledge feedback and fruitful discussion with
   Tobias Heer and Robert Moskowitz.


10.  Normative References

   [AUTO-ID]  "AUTO-ID LABS", Web http://www.autoidlabs.org/, Sept 2010.

   [BACNET]   "BACnet", Web http://www.bacnet.org/, Feb 2011.

   [DALI]     "DALI", Web http://www.dalibydesign.us/dali.html,
              Feb 2011.

   [ID-CoAP]  Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-05 (work in progress), Mar 2011.

   [ID-Duffy]
              Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA) Relay Element", draft-ohba-pana-relay-03
              (work in progress), Feb 2011.

   [ID-HIP]   Moskowitz, R., "HIP Diet EXchange (DEX)",
              draft-moskowitz-hip-rg-dex-04 (work in progress),
              Jan 2011.

   [ID-KIM]   Kim, E., Kaspar, D., and J. Vasseur, "Design and
              Application Spaces for 6LoWPANs",
              draft-ietf-6lowpan-usecases-09 (work in progress),
              January 2011.

   [ID-Moskowitz]
              Moskowitz, R., Jokela, P., Henderson, T., and T. Heer,
              "Host Identity Protocol Version 2 (HIPv2)",
              draft-ietf-hip-rfc5201-bis-05 (work in progress),
              Mar 2011.

   [ID-Nikander]
              Nikander, P. and J. Melen, "A Bound End-to-End Tunnel
              (BEET) mode for ESP", Internet
              Draft draft-nikander-esp-beet-mode-09, Feb 2009.

   [ID-O'Flynn]
              O'Flynn, C., Sarikaya, B., Ohba, Y., Cao, Z., and R.
              Cragie, "Security Bootstrapping of Resource-Constrained



Garcia-Morchon, et al.  Expires September 15, 2011             [Page 23]


Internet-Draft     Security Considerations for the IoT        March 2011


              Devices", draft-oflynn-core-bootstrapping-03 (work in
              progress), Nov 2010.

   [ID-Tsao]  Tsao, T., Alexander, R., Dohler, M., Daza, V., and A.
              Lozano, "A Security Framework for Routing over Low Power
              and Lossy Networks", Internet
              Draft draft-ietf-roll-security-framework-04, Jan 2011.

   [ID-Williams]
              Williams, M. and J. Barrett, "Mobile DTLS", Internet
              Draft draft-barrett-mobile-dtls-00, Mar 2009.

   [JOURNAL-Perrig]
              Perrig, A., Szewczyk, R., Wen, V., Culler, D., and J.
              Tygar, "SPINS: Security protocols for Sensor Networks",
              Journal Wireless Networks, Sept 2002.

   [NIST]     Dworkin, M., "NIST Specification Publication 800-38B",
              2005.

   [PROC-Chan]
              Chan, H., Perrig, A., and D. Song, "Random Key
              Predistribution Schemes for Sensor Networks",
              Proceedings IEEE Symposium on Security and Privacy, 2003.

   [PROC-Gupta]
              Gupta, V., Wurm, M., Zhu, Y., Millard, M., Fung, S., Gura,
              N., Eberle, H., and S. Shantz, "Sizzle: A Standards-based
              End-to-End Security Architecture for the Embedded
              Internet", Proceedings Pervasive Computing and
              Communications (PerCom), 2005.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

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

   [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, Jan 2006.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol
              (updated by RFC5282)", RFC 4306, Dec 2005.



Garcia-Morchon, et al.  Expires September 15, 2011             [Page 24]


Internet-Draft     Security Considerations for the IoT        March 2011


   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492, May 2006.

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, Jun 2006.

   [RFC4621]  Kivinen, T. and H. Tschofenig, "Design of the IKEv2
              Mobility and Multihoming (MOBIKE) Protocol", RFC 4621,
              Aug 2006.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, Sept 2007.

   [RFC5191]  Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", RFC 5191, May 2008.

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", RFC 5201, Apr 2008.

   [RFC5206]  Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
              Host Mobility and Multi-homing with the Host Identity
              Protocol", RFC 5206, Apr 2008.

   [RFC5238]  Phelan, T., "Datagram Transport Layer Security (DTLS) over
              the Datagram Congestion Control Protocol (DCCP)",
              RFC 5238, May 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol version 1.2", RFC 5246, Aug 2008.

   [RFC5903]  Fu, D. and J. Solinas, "Elliptic Curve Groups Modulo a
              Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
              June 2010.

   [THESIS-Langheinrich]
              Langheinrich, M., "Personal Privacy in Ubiquitous
              Computing", PhD Thesis ETH Zurich, 2005.

   [WG-6LoWPAN]
              "IETF 6LoWPAN Working Group",
              Web https://datatracker.ietf.org/wg/6lowpan/charter/,
              Feb 2011.

   [WG-CoRE]  "IETF Constrained RESTful Environment (CoRE) Working
              Group", Web https://datatracker.ietf.org/wg/core/charter/,



Garcia-Morchon, et al.  Expires September 15, 2011             [Page 25]


Internet-Draft     Security Considerations for the IoT        March 2011


              Feb 2011.

   [WG-MSEC]  "MSEC Working Group",
              Web http://datatracker.ietf.org/wg/msec/.

   [ZB]       "ZigBee Alliance", Web http://www.zigbee.org/, Feb 2011.


Authors' Addresses

   Oscar Garcia-Morchon
   Philips Research
   High Tech Campus
   Eindhoven,   5656 AA
   The Netherlands

   Email: oscar.garcia@philips.com


   Sye Loong Keoh
   Philips Research
   High Tech Campus
   Eindhoven,   5656 AA
   The Netherlands

   Email: sye.loong.keoh@philips.com


   Sandeep S. Kumar
   Philips Research
   High Tech Campus
   Eindhoven,   5656 AA
   The Netherlands

   Email: sandeep.kumar@philips.com


   Rene Hummen
   RWTH Aachen University
   Templergraben 55
   Aachen,   52056
   Germany

   Email: rene.hummen@cs.rwth-aachen.de







Garcia-Morchon, et al.  Expires September 15, 2011             [Page 26]


Internet-Draft     Security Considerations for the IoT        March 2011


   Rene Struik
   Struik Security Consultancy
   Toronto, ON
   Canada

   Email: rstruik.ext@gmail.com













































Garcia-Morchon, et al.  Expires September 15, 2011             [Page 27]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/