Network Working Group                                  O. Garcia-Morchon
Internet-Draft                                                   Philips
Intended status: Informational                                   T. Dahm
Expires: January 3, 2019                                          Google
                                                           July 02, 2018


                         Automated IoT Security
          draft-garciamorchon-t2trg-automated-iot-security-00

Abstract

   The Internet of Things (IoT) concept refers to the usage of standard
   Internet protocols to allow for human-to-thing and thing-to-thing
   communication.  The security needs are well-recognized and and many
   standardization steps for providing security have been taken, for
   example, the specification of Constrained Application Protocol (CoAP)
   over Datagram Transport Layer Security (DTLS).  However, the design
   space of IoT applications and systems is complex and exposed to
   multiple types of threats.  In particular, threats keep evolving at a
   fast pace while many IoT systems are rarely updated and still remain
   operational for decades.

   This document has three main parts: First, it summarizes exemplary
   security threats and suitable mitigation strategies to protect
   against multiple types of threats.  Second, it describes a
   comprehensive agile security framework to integrate existing security
   processes such as risk asssement or vulnerability assessment in the
   lifecycle of a smart object in an IoT application.  Thus, instead of
   having a security configuration that is fixed at manufacturing time,
   our approach allows us to apply a - security profile - on the device
   tailored for a specific environment at any point of time.  Third, we
   discuss the concept of security profiles and give examples of them.

   The core of our agile security approach relies on two protocols: the
   Protocol for Automatic Security Configuration (PASC) and the Protocol
   for Automatic Vulnerability Assessment (PAVA).  PACS is executed
   during the onboarding phase of a smart object in an IoT system and is
   in charge of automatically performing a risk assessment and assigning
   a security profile to defeat the identified risks.  The assigned
   security profile fits the specific environment and threat model of
   the application in which the device has been deployed.  PAVA is
   executed during the operation of the IoT object and ensures that
   vulnerabilities in the smart object and IoT system are discovered in
   a proactive way.  These two protocols can benefit users, manufactures
   and operators by automating IoT security.  We describe a few
   examplary security profiles that could be applicable in different




Garcia-Morchon & Dahm    Expires January 3, 2019                [Page 1]


Internet-Draft           Automated IoT Security                July 2018


   application areas and automatically configured by means of PASC and
   PAVA.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 3, 2019.

Copyright Notice

   Copyright (c) 2018 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.  Conventions and Terminology Used in this Document . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The design space of secure IoT systems  . . . . . . . . . . .   5
     3.1.  The Thing Lifecycle . . . . . . . . . . . . . . . . . . .   5
     3.2.  Classifying IoT Use Cases . . . . . . . . . . . . . . . .   6
     3.3.  Examplary use cases and security challenges . . . . . . .   7
   4.  Security Threats  . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Mitigations  . . . . . . . . . . . . . . . . . . . .   8
   6.  Integrating security processess in the IoT lifecycle  . . . .   9
   7.  Protocol for Automatic Security Configuration (PASC)  . . . .  11
   8.  Protocol for Automatic Vulnerability Assessment (PAVA)  . . .  13



Garcia-Morchon & Dahm    Expires January 3, 2019                [Page 2]


Internet-Draft           Automated IoT Security                July 2018


   9.  Benefits of integrating security processes in the IoT
       lifecycle through PASC and PAVA . . . . . . . . . . . . . . .  13
   10. Security Profiles . . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Classes of IoT Systems . . . . . . . . . . . . . . . . .  15
     10.2.  Security Profile 1: Home usage . . . . . . . . . . . . .  17
     10.3.  Security Profile 2: Managed Home usage . . . . . . . . .  17
     10.4.  Security Profile 3: Industrial usage . . . . . . . . . .  18
     10.5.  Security Profile 4: Managed Industrial usage . . . . . .  19
   11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  20
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  20
   13. Summary of threats  . . . . . . . . . . . . . . . . . . . . .  21
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  24
   16. Informative References  . . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35

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 IoT is exposed to a high number of attack vectors, that if
   sucessfully exploited by an attacker can have severe consequences.
   Thus, this document firstly provides an overview of general threats.

   Which mitigation strategies are most suitable to and required in an
   IoT system depends on several factors, including, the operational
   features of the IoT system or the threats that are applicable to that
   system.  Thus, this document further discusses processes that
   facilitate the proper design and operation of secure IoT systems,
   namely business impact analysis, risk assessment, privacy impact
   analysis, vulnerability analyis and incident reporting.  We further
   argue that even if these processes help IoT system designers to make
   secure products, a better approach would be to fully integrate these



Garcia-Morchon & Dahm    Expires January 3, 2019                [Page 3]


Internet-Draft           Automated IoT Security                July 2018


   processes in the lifecycle of a smart object in an IoT application.
   The reason is that IoT products are designed assuming a given
   environment and threat model that determines the require mitigation
   strategies.  However, in practice, a IoT product can be deployed in
   very different environments and very different threat models.
   Furthermore, while threats keep appearing at a very fast pace, IoT
   systems remain operational - with limited amount of updates - for a
   very long period of time.

   Thus, in order to integrate security processes in the IoT lifecycle,
   we describe two protocols, the Protocol for Automatic Security
   Configuration (PACS) and the Protocol for Automatic Vulnerability
   Assessment (PAVA).  These two protocols allow us to integrate risk
   analysis, privacy impact analysis, and vulnerability assessments in
   the actual lifecycle of the smart objects so that smart objects can
   be configured - continuously - with security profiles tailored to the
   very specific environment in which they are deployed.

   Finally, this document describes diffent four exemplary security
   profiles, each comprising a set of threats, mitigation strategies,
   and configuration parameters, that would be automatically applied to
   smart objects when joining different environments.

   The rest of the Internet-Draft is organized as follows.
   Section Section 3 summarizes the design space of secure IoT systems,
   including lifecycle, device capabilities, and operational features.
   Section Section 4 discusses general threats that should be considered
   when designing and operating an IoT system.  In Section Section 5,
   general mitigation strategies to the identified threats are listed.
   Choosing which mitigation strategies apply to which use cases is not
   trivial since it is required to find a proper balance between
   security, cost and usuability.  Thus, Section Section 6 details
   methodologies for managing risks when designing a secure IoT system
   and dealing with vulnerabilities when operating the system.  This
   section further describes how these methodologies can be integrated
   in the lifecycle of a smart object.  Section Section 7 proposes the
   Protocol for Automatic Security Configuration (PASC) that allows
   moving methodologies for risk assessment and privacy impact analysis
   from the implementation to the onboarding phase of a device.  This is
   enforced since each device discloses its operational requirements
   when joining an IoT system, and at this specific point of time, a
   security profile is applied to the device.  Section Section 8
   describes the Protocol for Automatic Vulnerability Assessment (PAVA)
   that allows gathering information on potential vulnerabilities as
   detected by different devices so that vulnerabilities are detected
   and action can be taken, including the creation of incident reports
   delivered to the user and manufacturers.  Section Section 9 describes
   how manufactures and users will benefit from PASC and PAVA when



Garcia-Morchon & Dahm    Expires January 3, 2019                [Page 4]


Internet-Draft           Automated IoT Security                July 2018


   creating or using IoT systems.  Finally, Section 10 proposes a number
   of illustrative security profiles applicable to different
   illustrative clases of IoT systems.  Each security profile comprises
   a set of mitigation strategies can provide a suitable security level
   and can be automatically deployed using PASC.  Section Section 11
   includes final remarks and conclusions.

3.  The design space of secure IoT systems

   This section describes the design space of IoT systems regarding two
   aspects: a) the lifecycle of a device and b) how an IoT system is
   architectured.

3.1.  The Thing Lifecycle

   The lifecycle of a thing refers to the operational phases of a thing
   in the context of a given application or use case.  Figure 1 shows
   the generic phases of the lifecycle of a thing.  This generic
   lifecycle is applicable to very different IoT applications and
   scenarios.

   We consider an example, a Building Automation and Control (BAC)
   system, to illustrate the lifecycle and the meaning of these
   different phases.  A BAC system consists of a network of
   interconnected nodes that performs 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 execute 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,



Garcia-Morchon & Dahm    Expires January 3, 2019                [Page 5]


Internet-Draft           Automated IoT Security                July 2018


   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 by means of an end-
   to-end connection.  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-
   generation devices in order to provide additional functionality.
   Therefore the device can be removed and re-commissioned to be used in
   a different system under a different owner by starting the lifecycle
   all over again.

    _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

       Figure 1: The lifecycle of a thing in the Internet of Things.

3.2.  Classifying IoT Use Cases

   An IoT system is architectured according to four main aspects below.

   1.  Device: what is the role of the devices, what their capabilities
       are, and which assumptions are posed on them.

   2.  Network: how the communication happens either in the local
       network or going towards remote systems.

   3.  Application and user: requirements and assumptions of the
       application running on multiple devices on required input
       information or interactions with the users.

   4.  System: interacions between multiple devices and users.



Garcia-Morchon & Dahm    Expires January 3, 2019                [Page 6]


Internet-Draft           Automated IoT Security                July 2018


3.3.  Examplary use cases and security challenges

   One of the challenges for IoT security is the diversity in IoT
   systems and use cases.  Examples of use cases with different needs
   are as follows:

   1.  A lighting system that runs in a fully isolated manner and only
       requires some initial interaction by to user to associate a light
       bulb to a switch.

   2.  A personal healthcare system in which a user carries medical
       sensors that monitor the user's health status in real time and
       allows the user to share this information with his family doctor.

   3.  A heating, ventilation and air conditioning system used in a
       office building that allows controlling settings.

   4.  A nation-wide smart grid that allows controlling the electrical
       grid including tasks such as demand-response.

   5.  A smart home environment in which multiple devices targeted for
       different applications (e.g., smart lighting, smart lock, smart
       scale, ) can be integrated.

4.  Security Threats

   Different use cases have different types of threats.

   In the following, we describe specific threats.  This list is not
   exhaustive and can be further extended in the future.

   1.   Cloning of things

   2.   Counterfeiting

   3.   Malicious substitution of thing

   4.   Eavesdropping attack

   5.   Message injection

   6.   Message modification

   7.   Man-in-the-middle attack

   8.   Firmware Replacement attack

   9.   Extraction of private information



Garcia-Morchon & Dahm    Expires January 3, 2019                [Page 7]


Internet-Draft           Automated IoT Security                July 2018


   10.  Routing attack

   11.  Timing attacks

   12.  Privacy threat - identification

   13.  Privacy threat - localization

   14.  Privacy threat - profiling

   15.  Privacy threat - interaction

   16.  Privacy threat - lifecycle transitions

   17.  Privacy threat - inventory attacks

   18.  Privacy threat - linkage

   19.  Data leakage - cryptographic keys

   20.  Data leakage - source code

   21.  Data leakage - propietary algorithms

   22.  Denial-of-Service attack on device

   23.  Denial-of-Service attack on network:

   24.  Store and decrypt attack (Quantum-resistance)

   25.  Software vulnerabilities

   Tables Figure 5 and Figure 6 in Section Section 13 summarize how
   these threats apply to different parts of an IoT system at different
   phases in the device lifecycle.

5.  Security Mitigations

   Deal with the security threats detailed in Section 4 requires a
   number of security mitigations as the ones detailed in Internet Draft
   [ID-Moore].  In this section, we further detail some of them that
   will be used later to compose security profiles:

   1.   Capability to perform an authenticated software update.

   2.   Capability to perform server authentication.

   3.   Capability to perform client authentication.



Garcia-Morchon & Dahm    Expires January 3, 2019                [Page 8]


Internet-Draft           Automated IoT Security                July 2018


   4.   Capability to encrypt communications.

   5.   Capability to encrypt communications.

   6.   Application isololation.

   7.   Management gateway.

   8.   Two factor authentication of application requests.

   9.   Physical security of the device.

   10.  Usage of application layer proxy.

   11.  Regular update of authentication credentials.

6.  Integrating security processess in the IoT lifecycle

   Dealing with above threats and finding suitable security mitigations
   is challenging: there are very sophisticated threats that a very
   powerful attacker could use; also, new threats and exploits appear in
   a daily basis.  Therefore, the existence of proper secure product
   creation processes that allow managing and minimizing risks during
   the lifecycle of the IoT devices is at least as important as being
   aware of the threats.  A non-exhaustive list of relevant processes
   include:

   1.  A Business Impact Analysis (BIA) assesses the consequences of
       loss of basic security attributes, namely, confidentiality,
       integrity and availability in an IoT system.  These consequences
       might include impact on data lost, sales lost, increased
       expenses, regulatory fines, customer dissatisfaction, etc.
       Performing a business impact analysis allow determining the
       business relevance of having a proper security design placing
       security in the focus.

   2.  A Risk Assessment (RA) analyzes security threats to the IoT
       system, considering their likelihood and impact, and deriving for
       each of them a risk level.  Risks classified as moderate or high
       must be mitigated, i.e., security architecture should be able to
       deal with that threat bringing the risk to a low level.  Note
       that threats are usually classified according to their goal:
       confidentiality, integrity, and availability.  For instance, a
       specific threat to recover a symmetric-key used in the system
       relates to confidentiality.

   3.  A privacy impact assessment (PIA) aims at assessing Personal
       Identifiable Information (PII) that is collected, processed, or



Garcia-Morchon & Dahm    Expires January 3, 2019                [Page 9]


Internet-Draft           Automated IoT Security                July 2018


       used in the IoT system.  By doing so, the goals is to fulfill
       applicable legal requirements, determine risks and effects of the
       manipulation of PII, and evaluate proposed protections.

   4.  Procedures for vulnerability assessment (VA) aim at assessing
       whether the IoT system is secure or any vulnerabilities are
       present.  This can be due to changes in the context information
       such as people involved in the IoT system or new software
       vulnerabilities discovered.

   5.  Procedures for incident reporting (IR) and mitigation refer to
       the methodologies that allow becoming aware of any security
       issues that affect an IoT systeoT

   Traditionally, BIA, RA, and PIA are usually to be realized during the
   creation of a new IoT system, introduction of new technologies in the
   IoT system, or deployment of significant system upgrades.  In
   general, it is recommended to re-assess them on a regular basis
   taking into account new use cases or threats.  VA is also often
   realized before deployment, e.g., by performing a penetration test
   before the new product release is deployed.  Incident reporting is
   done during operation of the IoT system, when a vulnerability is
   discovered.

   All these processes, namely BIA, RA, PIA, VA, and IR, are a must in
   the design of any IoT system.  If they are not performed, the risk of
   not having a secure enough system is very high.  However, even if
   these procedures are in place, the IoT systems can still have an
   unsatisfactory security level due to multiple reasons:

   1.  First example: a risk assessment is performed, but the product is
       deployed in an environment in which the threats and boundaries
       are different.  This leads to the situation in which an IoT
       system was properly designed, but it is being used in an
       environment with different security needs.

   2.  Second example: a risk assessment is performed during the design
       phase, then also a vulnerability assessment is executed including
       a penetration test and the product is released to the customers.
       Some time later, new vulnerabilities appear in a new devices that
       was installed in the same IoT network.  This leads to the
       situation in which an IoT system was properly designed and tested
       for vulnerabilities, but it becomes later unsecured due to
       changes in the environment.

   Thus, the authors believe that the above procedures should be fully
   integrated in the lifecycle of a smart object as showed in Figure 2.
   BIA still takes place during the design phase of the new IoT device.



Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 10]


Internet-Draft           Automated IoT Security                July 2018


   However, RA and PIA are moved now to the installation and
   commissioning phases of the devices since it is then when the actual
   environment in which smart objects are deployed is really known.  The
   VA keeps running during the operation of the IoT system.  Information
   gathered during VA can feed the RA and PIA processes to update
   security settings.  Similarly, security incidents found out during
   continuous VA lead to IR.  When smart objects are sold or the system
   updated, this triggers again RA and PIA.

    _Manufactured           _SW update          _Decommissioned
   /                       /                   /
   |   _Installed          |   _ Application   |   _Removed &
   |  /                    |  / reconfigured   |  /  replaced
   |  |   _Commissioned    |  |                |  |
   |  |  /                 |  |                |  |   _Reownership &
   |  |  |    _Application |  |   _Application |  |  / recommissioned
   |  |  |   /   running   |  |  / running     |  |  |
   |  |  |   |             |  |  |             |  |  |             \\
   +##+##+###+#############+##+##+#############+##+##+##############>>>
    \   \/  \______________________________________/ /   time //
     \   \                        \                 /
    BIA   \               Continuous VA--->IR      /
           RA and PIA <__________|           RA and PIA


    Figure 2: Security processes integrated in the lifecycle of a thing
                        in the Internet of Things.

   In Section Section 7 we describe the Protocol for Automatic Security
   Configuration (PACS) that addresses how to solve the integration of
   the RA and PIA processes in the installation and commissioning phase.
   Then, in Section Section 8 we describe the Protocol for Automatic
   Vulnerability Assessment that addresses how to perform continuous
   vulnerability assessment.

7.  Protocol for Automatic Security Configuration (PASC)

   Traditional IoT systems are created from scratch and require a
   suitable security design following the phases descrbed in
   Section Section 6.  Many generic IoT platforms are emerging that can
   be instantiated in different products that can be deployed in many
   different environments.  Thus, we describe the Protocol for Automatic
   Security Configuration (PASC) that enables automatic security
   configuration by shifting methodologies for risk management from the
   tailored product design and implementation phases to the onboarding
   phase.





Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 11]


Internet-Draft           Automated IoT Security                July 2018


  _________________________________________________
|                                                    |
| Thing1       Thing2         GW         Router      |   M1     Platform
|                                                    |
|    ++++++++++ m1 +++++++++>
|                                                    |
|                           +++++++++++++ m2 ++++++++++++>
|                                                    |
|                           <++++++++++++ m3 ++++++++++++
|                                                    |
|                       RA and PIA
|                                                    |
|                           ++++++++++++++++++++ m4 +++++++++++++++++++>
|                                                    |
|                           <+++++++++++++++++++ m5 +++++++++++++++++++
|                                                    |
|      <+++++++++ m6 +++++++++
|                                                    |
|              <++++ m7 ++++++
|                                                    |
|                           ++++ m8 ++++>
|                                                    |
|              IoT Security Domain                   |
  _________________________________________________

         Figure 3: Protocol for Automatic Security Configuration.

   Figure 3 depicts the main parties involved in the protocol: two smart
   objects denoted as 'Thing1' and 'Thing2', a device controlling the
   IoT domain called 'GW', a router towards the IoT domain, the
   manufacturer server of 'Thing1' denoted as 'M1' and the server of the
   platform denoted as 'platform'.

   The main protocol steps of PASC are as follows: When 'Thing1' is
   introduced in the IoT domain, 'Thing1' first publishes its profile to
   the available 'GW' in message 'm1'.  'GW' then gathers information
   from 'm1' regarding 'Thing1' in messages 'm2' and 'm3'.  At this
   stage, 'GW' has information about the available smart objects in the
   IoT domain and also can gather input from the user on the usage and
   expected interactions of the smart object with other devices in the
   deployment environment.  Thus, 'GW' can perform an automated risk
   assessment of the IoT device in the security domain determining
   potential threats on the device and on the system, and assigning a
   security profile containing security mitigations to the identified
   threats.  In messages 'm4' and 'm5' the GW can gather security
   updates from 'platform' that might be required for the new situation
   after the introduction of 'Thing1' in the IoT security domain.
   Finally, messages 'm6', 'm7' and 'm8' are used to deploy updated



Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 12]


Internet-Draft           Automated IoT Security                July 2018


   security profiles to the new smart object 'Thing1' and potentially
   also to other devices already present in the deployment environment,
   namely, the 'router' and other smart objects (e.g., 'Thing2').

   In practice, PACS can be created by extending and combining a number
   of protocols.  Messages 'm1', 'm2', and 'm3' resemble steps of the
   Manufacturer Usage Descriptor (MUD) protocol.  After these messages,
   RA and PIA can be executed given available information on the
   expected usage of the devices and input from the user.  Messages 'm4'
   and 'm5' require standardization since they resemble the access for
   various software updates that might be required to fullfil security
   needs.  Configuration messages 'm6' and 'm7' might be instantiated by
   a combination and extension of ACE and MUD protocol.  Message 'm8'
   requires standarization to automatically configure router and
   firewall rules.

8.  Protocol for Automatic Vulnerability Assessment (PAVA)

   Today vulnerability assessment is either not performed at all or it
   is only performed when products are designed.  The Protocol for
   Automatic Vulnerability Assessment (PAVA) overcomes this.  PAVA
   relies on each smart object (e.g., Thing1) sending standarized
   reports of potential vulnerabilities to 'GW', the device managing the
   IoT security domain.  Such reports would build on RFC 5424, RFC 5425
   and RFC 5426.  Reports and methodology can also benefit from RFC6872.
   The 'GW' then analyzes the logs and takes a decision regarding the
   existence of a vulnerability, its origin and its impact.  Output of
   this decision is threefold:

   1.  incident report towards the user

   2.  update of security profiles in smart objects of the IoT security
       domain.

   3.  automatic incident reporting towards the manufacturer

   4.  automatic incident reporting towards the platform provider

9.  Benefits of integrating security processes in the IoT lifecycle
    through PASC and PAVA

   Section Section 8 describes how manufacturers, system operators and
   end users benefit from PASC and PAVA when creating, making or using
   IoT systems.

   Users benefit since security configuration is done in an automatic
   way - they need to do nothing.  Security settings are automatically




Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 13]


Internet-Draft           Automated IoT Security                July 2018


   configured according to the specific deployment environment that a
   user only needs to confirm.

   Manufacturers benefit since they do not need to decide which security
   mitigations they require on a product.  Instead of it, they just need
   to describe the expected usage of the product that is then confirmed
   by the user.  Security profiles are then automatically deployed on
   the smart object.

   System operators use these protocols to minimize operational cost
   while ensuring that the system remains secure at any moment.

10.  Security Profiles

   We expect the various types of IoT deployments to be widespread and
   to penetrate almost all areas of our personal and professional life
   including building automation systems, healthcare, smart cities,
   logistics, etc.  For each of these environments, properties such as
   device capabilities, network infrastructure, or available security
   services can be completely different.  That makes it difficult to
   define and deploy complete security configurations for each generic
   use case.  Furthermore, each of those applications is featured by a
   different number of actors deployed in very different environments
   and with very different purposes.  Consequently, when a Business
   Impact Analysis or Risk Assessment is performed, not only the types
   of threats will be different, but also their likelihood and potential
   impact.  This determines that different applications tend to require
   different or complementary types of security mechanisms mitigating
   the identified risks.

   This section describes some exemplary Security Profiles that can be
   automatically created by means of PASC fitting the security needs of
   applications with the same characteristics and requirements.  These
   security profiles are beneficial since they make the underlying
   threats transparent, allow for interoperability while preserving
   security and prevent possible security misconfiguration.  It is
   expected that the security profiles defined in this section need to
   be extended and adapted based on the individual risk profiles of each
   environment as described in Section 6 of this document.

   Each security profile includes:

   1.  a short descriptive name,

   2.  an exemplary application that might use the security profile,

   3.  the main security threats applicable to the profile,




Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 14]


Internet-Draft           Automated IoT Security                July 2018


   4.  the security mitigations required by the profile,

   5.  specific configuration parameters for the protocols and actors
       involved in the application.

10.1.  Classes of IoT Systems

   Based on the PASC the IoT devices can be grouped by function, by
   required access and by deployment scope into individual IoT device
   classes.  While grouping things into individual device classes based
   on function and required access is a universal part of each PASC
   independent of the desired deployment environment, the deployment
   scope MUST be considered as well based on the different threats in
   various deployment environments.  For example, the same thing
   deployed in smart homes or in smart cities will have the same PASC
   entries for function and required access, however, the deployment
   scope and the inherited security threats from the different
   environments will require different PASC and PAVA for the two
   deployment scenarios.

   Each one of these IoT device classes will represent an isolated
   segment in itself and will receive an individual and continuous PAVA
   during the lifetime of the things in the device class.  In order to
   connect with things in different segments, the management gateway
   MUST be used.

   The goal of creating device classes for IoT devices is to enable the
   near-automatic management of a clear separation of security threats
   and risk assessments by enforcing device segmentation for each class
   of devices.  This segmentation process SHOULD therefore be automated,
   but the automation part itself is out of scope for this document.
   The segments must be pre-defined before the PASC is created.  If the
   PASC requires a new segment to introduce a thing into a certain
   environment, the segment MUST be defined first.  Protocols like MUD
   SHOULD be used as a valuable source of information during the
   classification and provisioning process in PASC.

   We consider four generic security profiles applicable to four
   exemplary application areas as summarized in the table below:












Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 15]


Internet-Draft           Automated IoT Security                July 2018


             +---------------------------------------------------------+
             | Exemplary       |                                       |
             | IoT Application |          Description                  |
  +----------+---------------------------------------------------------+
  |SecProf_1 |Home usage       |Enables operation between home things  |
  |          |                 |without interaction with central device|
  +----------+-----------------+---------------------------------------+
  |SecProf_2 |Managed Home     |Enables operation between home things. |
  |          | usage           |Interaction with a central and local   |
  |          |                 |device is possible                     |
  +----------+-----------------+---------------------------------------+
  |SecProf_3 |Industrial usage |Enables operation between things.      |
  |          |                 |Relies on central (local or backend)   |
  |          |                 |device for security                    |
  +----------+-----------------+---------------------------------------+
  |SecProf_4 |Advanced         |Enables ad-hoc operation between things|
  |          |Industrial usage |and relies on central device or        |
  |          |                 |on a collection of control devices     |
  +----------+-----------------+---------------------------------------+

            Figure 4: Security profiles and application areas.

   The currently existing IoT products can be loosely categorized in 4
   different profiles, where SecProf_1 would be the lowest category of
   security profiles and SecProf_4 would be the highest category of
   security profiles.  It is considered best practice in the security
   world to allow higher security profiles to connect to lower security
   profiles, but to never let lower security profiles connect to higher
   security profiles.  The same precautions SHOULD be used for the IoT
   Security Profiles defined below.  The separation between the Security
   Profiles described in Figure 4 is not a strict physical separation,
   but a logical one.  A home IoT device and its management software may
   include components that fall into the SecProf_1 as well as SecProf_2
   category.  Within every security profile exists a graduation of
   different security levels.  The exact category within a security
   profile will be determined with a risk analysis of the thing and its
   functionality and MUST be reviewed on a regular basis.  This is
   because each security profile will contain devices with a high
   lifecycle variation.  Certain IoT devices are meant to be used for a
   few hours only, while others are expected to last decades.  Given the
   technological progress, the security of a thing may degenerate over
   time within the same security profile.

   The best mitigation strategy against unknown future threats are
   software updates, for example, to replace a broken hash algorithm
   with a more secure one as long as the thing can handle the
   computational load of the new hash algorithm.




Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 16]


Internet-Draft           Automated IoT Security                July 2018


10.2.  Security Profile 1: Home usage

   SecProf_1 categorizes unmanaged IoT devices mostly found in private
   homes.  The things in this Security Profile are single-purpose
   devices, used either on a daily or less frequent basis.  The types of
   threats those things will face are usually minimal risk.  The
   likelihood of misuse entirely depends on physical proximity to the
   thing.

   Given the example of an internet-connected button for the delivery of
   fresh bananas, it would require physical interaction ("button press")
   and SHOULD make use of technologies like fingerprint sensors to limit
   the order ability to a small set of authorized individuals.  A misuse
   would at maximum lead to an unwanted delivery of fruits, and a
   supermarket can easily enforce a maximum amount of fruits an
   individual household would order before assuming malicious intent.

   This Security Profile requires unidirectional communication from the
   thing to a specific service.  Additional services like order
   confirmation will be handled via separate channels.  Mitigations for
   security threats identified in the PASC MUST contain encryption on
   the transport layer of the application, a strict isolation from other
   nodes in a shared network and a proper physical placement of the
   thing.  Additionally, a strong identification mechanism, like X.509
   Certificates, MUST be used to identify the exact thing that talks to
   the specific service.

   +----------------------------------------------+
   | Threats  |  Mitigations                      |
   +----------+-----------------------------------+
   |   T4     |    M4
   +----------+-----------------------------------+
   |   T5     |    M2, M3, M8
   +----------+-----------------------------------+
   |   T6     |    M2, M3, M8
   +----------+-----------------------------------+


10.3.  Security Profile 2: Managed Home usage

   SecProf_2 categorizes managed IoT devices mostly found in private
   homes.  The things in this Security Profile are more complex, often
   multi-purpose devices, and meant to be used on a daily basis.  The
   types of threats those things will face are usually in the medium to
   high risk category.  Misuse of the thing depends on the security of
   the managed service bundled to the thing.





Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 17]


Internet-Draft           Automated IoT Security                July 2018


   Given the example of an smart door lock, the PASC contains physical
   and logical security risks.  The physical security of the lock MUST
   be on the same standard that non-smart door locks provide.  For the
   logical security of the door lock, physical presence close to the
   smart door lock MUST be enforced for the unlocking functionality,
   while the locking functionality might also be used remotely.  Key
   escrow must be possible via a secure procedure for emergency services
   like Police or the Fire Brigade.

   This Security Profile requires bidirectional communication from the
   thing to a specific management gateway.  All communication with
   specific services as well as other smart objects MUST go through the
   management gateway.  The management gateway may act as an application
   layer proxy when it is used as a relay to enable communication
   between smart objects and nodes within a single domain or local
   network.  Mitigations for security threats identified in the PASC
   MUST contain encryption on the transport layer of the application and
   a strict isolation from other nodes except the management gateway in
   a shared network.  Additionally, a strong identification and
   authentication mechanism, like X.509 Certificates, MUST be used to
   identify and authenticate the thing when it talks to the management
   gateway.  The credentials used for authentication and authorization
   MUST be refreshed on a regular basis.

10.4.  Security Profile 3: Industrial usage

   SecProf_3 categorizes unmanaged or partially managed IoT devices
   found in industrial or commercial environments.  The things in this
   Security Profile are single-purpose devices, used by a number of
   unidentified people.  The types of threats those things will face are
   in the minimal or medium risk category.  Misuse could lead to a
   certain inconvenience, but would not put the operation of the
   industrial or commercial environment at risk.

   Given the example of a HVAC system in a commercial office building,
   the components of such a system would include a central HVAC
   management service for the building, temperature sensors spread
   across the whole building and heating and cooling devices at certain
   places across the building.  Communication from the smart objects
   spread across the building would be unidirectional depending on their
   functionality.  The temperature sensors would unidirectional
   communicate frequently with the HVAC central management service.  The
   HVAC central management service would unidirectional communicate as
   needed with the heating and cooling devices to regulate the
   temperature across the building.

   This Security Profile requires a mix of unidirectional and
   bidirectional communication between the things and a specific



Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 18]


Internet-Draft           Automated IoT Security                July 2018


   service.  Mitigations for security threats identified in the PASC
   MUST contain encryption on the transport layer of the application, a
   strict isolation from other nodes in a shared network for the smart
   things and a strong identification mechanism, like X.509
   Certificates, MUST be used to identify the exact thing that talks to
   the central management service.  Mitigations for security threats
   identified in the PASC for central management service which requires
   bidirectional communication with multiple things MUST contain
   encryption on the transport layer of the application and MUST use a
   strong identification and authorization mechanism, like X.509
   Certificates, to identify and authenticate the central management
   service when it talks to the individual smart objects.  The central
   management service may act as an application layer proxy when it is
   used as a relay to enable communication between smart objects and
   nodes within a single domain or local network.  The credentials used
   for authentication and authorization MUST be refreshed on a regular
   basis.

10.5.  Security Profile 4: Managed Industrial usage

   SecProf_4 categorizes fully managed IoT devices found in industrial
   or commercial environments.  The things in this Security Profile are
   multi-purpose devices, used by a number of authenticated and
   authorized people.  The types of threats those things will face are
   in the high risk category.  Misuse could lead to a partial or full
   compromise of the industrial or commercial environment.

   Given the example of a physical security system with managed access
   in a commercial datacenter, the components of such a system would
   include components like cameras, infrared sensors, access control
   systems and fire safety.  All components have either unidirectional
   or bidirectional connectivity to a local or remote management
   gateway.  All communication with specific services as well as other
   smart objects MUST go through the management gateway.  The management
   gateway controls the functionality of each smart component within the
   integrated physical security system.  The management gateway may act
   as an application layer proxy when it is used as a relay to enable
   communication between the individual components of the integrated
   physical security system and external nodes within a single domain or
   local and remote networks.

   Mitigations for security threats identified in the PASC MUST contain
   encryption on the transport layer of the application and a strict
   isolation from other nodes except the management gateway in a shared
   network.  Additionally, a strong identification and authentication
   mechanism, like X.509 Certificates, MUST be used to identify and
   authenticate all IoT components for the communication with the




Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 19]


Internet-Draft           Automated IoT Security                July 2018


   management gateway.  The credentials used for authentication and
   authorization MUST be refreshed on a regular basis.

11.  Conclusions

   The main contribution of this document is to describe and propose
   protocols to automate IoT security.  This is done in two steps.
   First, the PASC protocol allows to automatically configure devices
   and deploying security profiles - sets of security configurations -
   to the devices that join a given network and system.  Second, the
   PAVA protocol allows to automatically monitor the operation of the
   network and system in order to defeat any attack.  A key contribution
   of this document is the definition of exemplary security profiles
   that can be deploy to the devices.

12.  Security Considerations

   Security is a key factor in the acceptance and long-term success of
   IoT systems.  When comparing established Things that already exists
   as non-smart versions in the real word for a long time, for example
   light switches or door locks, and the typical modern approach to
   software engineering, we can often see a culture clash.  This culture
   clash is not surprising.  The reasons for this are simple, the
   building and manufacturing industry for example are some of the
   slowest changing industry sectors in the world, often also due to
   high demands and regulations on safety and security of the physical
   products they produce, e. g. bridges or houses.  On the other side,
   we have the IT and Web industry, one of the most dynamic industry
   sectors currently existing.  While the formula on how to mix concrete
   or unlocking a door with a physical key has not changed much in the
   last 100 years, we went to a huge number of fundamental changes in
   the software industry in a relatively short period of time.

   Additionally, there is a fundamental difference of traditional
   connected and networked devices "for people" vs. IoT devices which
   are typically headless.  E. g., many standard application layer
   authentication mechanisms like OAuth assume a person is there to "do
   something" in a challenge response sequence.  Also, people have an
   identity, that typically links to authorization of resources, while
   an IoT device is more single-purpose and typically has no intrinsic
   sense of other resources it might/should communicate with.  This
   distinction between devices lends itself to a number of
   considerations in terms of authentication, access control,
   manageability, and other challenges that will take time to properly
   normalize in a modern IoT enabled world.

   From a security perspective, it is difficult to trust IoT devices.
   There are simply too many of them, and due to their constrained



Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 20]


Internet-Draft           Automated IoT Security                July 2018


   nature there are often compromises that weaken security overall.
   Most IoT devices are typically focused on their physical task rather
   than on being general purpose computing platforms.  Therefore, the
   security profiles described in this document aim to bridge the
   initial risk analysis gap between the involved industry sectors and
   put a higher emphasis on the minimizing risk and containing the blast
   radius factors.

13.  Summary of threats

   We can classify threats presented in Section Section 4 according to
   two criteria: a) what is the target of the threat? and b) when does
   the threat take place?

   The target of the threat can be - as described in Section 3.2 - the
   IoT architecture (T-arch), the device (T-dev), the network (T-nwk),
   and the application (T-app).  The lifecycle moment in which the
   threat takes place can be - as described in Section 3.1 - during
   manufacturing (L-make), commissioning process (L-conf), operation
   (L-oper), software updates (L-update), and decommissioning
   (L-deconf).

         +----------+-----------+-----------+---------+
         |T-arch    | T-dev     |  T-nwk    | T-app   |
   +-----+----------+-----------+-----------+---------+
   |  1  |    y     |     y     |           |         |
   +-----+----------+-----------+-----------+---------+
   |  2  |    y     |     y     |           |         |
   +-----+----------+-----------+-----------+---------+
   |  3  |    y     |     y     |           |         |
   +-----+----------+-----------+-----------+---------+
   |  4  |    y     |           |    y      |    y    |
   +-----+----------+-----------+-----------+---------+
   |  5  |     y    |           |    y      |    y    |
   +-----+----------+-----------+-----------+---------+
   |  6  |     y    |           |    y      |    y    |
   +-----+----------+-----------+-----------+---------+
   |  7  |     y    |           |    y      |    y    |
   +-----+----------+-----------+-----------+---------+
   |  8  |     y    |     y     |           |    y    |
   +-----+----------+-----------+-----------+---------+
   |  9  |     y    |     y     |           |         |
   +-----+----------+-----------+-----------+---------+
   |  10 |    y     |           |    y      |         |
   +-----+----------+-----------+-----------+---------+
   |  11 |    y     |    y      |    y      |   y     |
   +-----+----------+-----------+-----------+---------+
   |  12 |    y     |     y     |    y      |   y     |



Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 21]


Internet-Draft           Automated IoT Security                July 2018


   +-----+----------+-----------+-----------+---------+
   |  13 |    y     |     y     |     y     |    y    |
   +-----+----------+-----------+-----------+---------+
   |  14 |          |     y     |           |   y     |
   +-----+----------+-----------+-----------+---------+
   |  15 |          |     y     |           |    y    |
   +-----+----------+-----------+-----------+---------+
   |  16 |     y    |     y     |    y      |    y    |
   +-----+----------+-----------+-----------+---------+
   |  17 |     y    |           |           |    y    |
   +-----+----------+-----------+-----------+---------+
   |  18 |     y    |           |           |    y    |
   +-----+----------+-----------+-----------+---------+
   |  19 |     y    |     y     |     y     |    y    |
   +-----+----------+-----------+-----------+---------+
   |  20 |    y     |     y     |           |         |
   +-----+----------+-----------+-----------+---------+
   |  21 |    y     |    y      |           |   y     |
   +-----+----------+-----------+-----------+---------+
   |  22 |          |     y     |           |         |
   +-----+----------+-----------+-----------+---------+
   |  23 |    y     |     y     |     y     |         |
   +-----+----------+-----------+-----------+---------+
   |  24 |    y     |           |           |   y     |
   +-----+----------+-----------+-----------+---------+
   |  25 |    y     |     y     |           |    y    |
   +-----+----------+-----------+-----------+---------+


    Figure 5: This tables illustrates which parts of the IoT system are
                       affected by different theats.

         +--------+--------+---------+--------+--------+---------+
         |L-make  | L-conf | L-oper  | L-upd  | L-dec  | L-after |
   +-----+--------+--------+---------+--------+--------+---------+
   |  1  |    y   |        |   y     |  y     |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  2  |    y   |        |   y     |  y     |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  3  |    y   |        |   y     |        |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  4  |        |    y   |   y     |  y     |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  5  |        |    y   |   y     |  y     |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  6  |        |    y   |   y     |  y     |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  7  |        |    y   |   y     |  y     |        |         |



Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 22]


Internet-Draft           Automated IoT Security                July 2018


   +-----+--------+--------+---------+--------+--------+---------+
   |  8  |    y   |        |         |  y     |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  9  |    y   |        |   y     |  y     |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  10 |        |    y   |   y     |  y     |   y    |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  11 |    y   |    y   |   y     |  y     |   y    |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  12 |    y   |    y   |   y     |  y     |   y    |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  13 |        |    y   |   y     |  y     |   y    |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  14 |        |        |   y     |        |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  15 |        |        |   y     |        |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  16 |        |    y   |   y     |  y     |   y    |    y    |
   +-----+--------+--------+---------+--------+--------+---------+
   |  17 |        |    y   |   y     |  y     |   y    |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  18 |    y   |        |         |  y     |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  19 |    y   |   y    |   y     |  y     |   y    |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  20 |    y   |        |   y     |  y     |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  21 |    y   |        |   y     |  y     |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  22 |        |    y   |   y     |  y     |   y    |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  23 |        |    y   |   y     |        |        |         |
   +-----+--------+--------+---------+--------+--------+---------+
   |  24 |        |        |   y     |        |        |    y    |
   +-----+--------+--------+---------+--------+--------+---------+
   |  25 |        |   y    |   y     |   y    |  y     |         |
   +-----+--------+--------+---------+--------+--------+---------+

      Figure 6: This tables illustrates in which moment of a thing's
                    lifecycle a threat can take place.

14.  IANA Considerations

   This document contains no request to IANA.







Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 23]


Internet-Draft           Automated IoT Security                July 2018


15.  Acknowledgments

16.  Informative References

   [Article29]
              "Opinion 8/2014 on the on Recent Developments on the
              Internet of Things", Web http://ec.europa.eu/justice/data-
              protection/article-29/documentation/opinion-
              recommendation/files/2014/wp223_en.pdf, n.d..

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

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

   [BITAG]    "Internet of Things (IoT) Security and Privacy
              Recommendations", Web http://www.bitag.org/report-
              internet-of-things-security-privacy-recommendations.php,
              n.d..

   [cctv]     "Backdoor In MVPower DVR Firmware Sends CCTV Stills To an
              Email Address In China", Web
              https://hardware.slashdot.org/story/16/02/17/0422259/
              backdoor-in-mvpower-dvr-firmware-sends-cctv-stills-to-an-
              email-address-in-china, n.d..

   [CSA]      "Security Guidance for Early Adopters of the Internet of
              Things (IoT)", Web
              https://downloads.cloudsecurityalliance.org/whitepapers/Se
              curity_Guidance_for_Early_Adopters_of_the_Internet_of_Thin
              gs.pdf, n.d..

   [d2dsecurity]
              Haus, M., Waqas, M., Ding, A., Li, Y., Tarkoma, S., and J.
              Ott, "Security and Privacy in Device-to-Device (D2D)
              Communication: A Review", Paper IEEE Communications
              Surveys and Tutorials, 2016.

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

   [DHS]      "Strategic Principles For Securing the Internet of Things
              (IoT)", Web
              https://www.dhs.gov/sites/default/files/publications/
              Strategic_Principles_for_Securing_the_Internet_of_Things-
              2016-1115-FINAL....pdf, n.d..





Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 24]


Internet-Draft           Automated IoT Security                July 2018


   [ENISA_ICS]
              "Communication network dependencies for ICS/SCADA
              Systems", European Union Agency For Network And
              Information Security , February 2017.

   [ETSI_GR_QSC_001]
              "Quantum-Safe Cryptography (QSC);Quantum-safe algorithmic
              framework", European Telecommunications Standards
              Institute (ETSI) , June 2016.

   [Fairhair]
              "Fairhair Alliance", Web https://www.fairhair-
              alliance.org/, n.d..

   [FCC]      "Federal Communications Comssion Response 12-05-2016",
              FCC , February 2016.

   [FTCreport]
              "FTC Report on Internet of Things Urges Companies to Adopt
              Best Practices to Address Consumer Privacy and Security
              Risks", Web https://www.ftc.gov/news-events/press-
              releases/2015/01/ftc-report-internet-things-urges-
              companies-adopt-best-practices, n.d..

   [GSMAsecurity]
              "GSMA IoT Security Guidelines", Web
              http://www.gsma.com/connectedliving/future-iot-networks/
              iot-security-guidelines/, n.d..

   [ID-6lodect]
              Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D.
              Barthel, "Transmission of IPv6 Packets over DECT Ultra Low
              Energy", draft-ietf-6lo-dect-ule-09 , December 2016.

   [ID-6lonfc]
              Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi,
              "Transmission of IPv6 Packets over Near Field
              Communication", draft-ietf-6lo-nfc-05 , October 2016.

   [ID-6tisch]
              Thubert, P., "An Architecture for IPv6 over the TSCH mode
              of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 ,
              January 2017.








Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 25]


Internet-Draft           Automated IoT Security                July 2018


   [ID-aceoauth]
              Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments (ACE)", draft-ietf-ace-oauth-
              authz-05 , March 2011.

   [ID-bootstrap]
              Sarikaya, B. and M. Sethi, "Secure IoT Bootstrapping : A
              Survey", draft-sarikaya-t2trg-sbootstrapping-01 , July
              2016.

   [ID-cose]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              draft-ietf-cose-msg-24 , November 2016.

   [ID-Daniel]
              Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J.
              Laganier, "IPv6 over Low Power WPAN Security Analysis",
              draft-daniel-6lowpan-security-analysis-05 , March 2011.

   [ID-dietesp]
              Migault, D., Guggemos, T., and C. Bormann, "Diet-ESP: a
              flexible and compressed format for IPsec/ESP", draft-mglt-
              6lo-diet-esp-02 , August 2016.

   [ID-Hartke]
              Hartke, K. and O. Bergmann, "Datagram Transport Layer
              Security in Constrained Environments", draft-hartke-core-
              codtls-02 , July 2012.

   [ID-HIP]   Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz-
              hip-rg-dex-06 , May 2012.

   [ID-Moore]
              Moore, K., Barnes, R., and H. Tschofenig, "Best Current
              Practices for Securing Internet of Things (IoT) Devices",
              draft-moore-iot-security-bcp-00 , October 2016.

   [ID-MUD]   Lear, E., Droms, R., and D. Domascanu, "Manufacturer Usage
              Description Specification", March 2017.

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







Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 26]


Internet-Draft           Automated IoT Security                July 2018


   [ID-OFlynn]
              O'Flynn, C., Sarikaya, B., Ohba, Y., Cao, Z., and R.
              Cragie, "Security Bootstrapping of Resource-Constrained
              Devices", draft-oflynn-core-bootstrapping-03 , November
              2010.

   [ID-OSCOAP]
              Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security of CoAP (OSCOAP)", draft-selander-ace-
              object-security-05 , July 2016.

   [ID-proHTTPCoAP]
              Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
              E. Dijk, "Best practices for HTTP-CoAP mapping
              implementation", draft-castellani-core-http-mapping-07 ,
              February 2013.

   [ID-rd]    Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
              Resource Directory", draft-ietf-core-resource-
              directory-09 , October 2016.

   [ID-senml]
              Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
              Bormann, "Media Types for Sensor Measurement Lists
              (SenML)", draft-ietf-core-resource-directory-09 , October
              2016.

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

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

   [IEEE802ah]
              "Status of Project IEEE 802.11ah, IEEE P802.11- Task Group
              AH-Meeting Update.",
              Web http://www.ieee802.org/11/Reports/tgah_update.htm,
              n.d..

   [IIoT]     "Industrial Internet Consortium",
              Web http://www.iiconsortium.org/, n.d..







Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 27]


Internet-Draft           Automated IoT Security                July 2018


   [IoTSecFoundation]
              "Establishing Principles for Internet of Things Security",
              Web https://iotsecurityfoundation.org/establishing-
              principles-for-internet-of-things-security/, n.d..

   [iotsu]    "Patching the Internet of Things: IoT Software Update
              Workshop 2016", Web
              https://www.ietf.org/blog/2016/07/patching-the-internet-
              of-things-iot-software-update-workshop-2016/, n.d..

   [IPSO]     "IPSO Alliance", Web http://www.ipso-alliance.org, n.d..

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

   [lora]     "LoRa - Wide Area Networks for IoT", Web https://www.lora-
              alliance.org/, n.d..

   [nbiot]    "NarrowBand IoT", Web
              http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_69/Docs/
              RP-151621.zip, n.d..

   [NHTSA]    "Cybersecurity Best Practices for Modern Vehicles", Web
              https://www.nhtsa.gov/staticfiles/nvs/
              pdf/812333_CybersecurityForModernVehicles.pdf, n.d..

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

   [NIST-Guide]
              Ross, R., McEVILLEY, M., and J. Oren, "Systems Security
              Engineering", Web
              http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-160.pdf, n.d..

   [nist_lightweight_project]
              "NIST lightweight Project", Web www.nist.gov/programs-
              projects/lightweight-cryptography,
              www.nist.gov/sites/default/files/documents/2016/10/17/
              sonmez-turan-presentation-lwc2016.pdf, n.d..

   [OCF]      "Open Connectivity Foundation",
              Web https://openconnectivity.org/, n.d..

   [OneM2M]   "OneM2M", Web http://www.onem2m.org/, n.d..




Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 28]


Internet-Draft           Automated IoT Security                July 2018


   [OWASP]    "IoT Security Guidance",
              Web https://www.owasp.org/index.php/IoT_Security_Guidance,
              n.d..

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

   [PROC-Smetters-02]
              Balfanz, D., Smetters, D., Steward, P., and H. Chi Wong,,
              "Talking To Strangers: Authentication in Ad-Hoc Wireless
              Networks", Paper NDSS, 2002.

   [PROC-Smetters-04]
              Balfanz, D., Durfee, G., Grinter, R., Smetters, D., and P.
              Steward, "Network-in-a-Box: How to Set Up a Secure
              Wireless Network in Under a Minute", Paper USENIX, 2004.

   [PROC-Stajano-99]
              Stajano, F. and R. Anderson, "Resurrecting Duckling -
              Security Issues for Adhoc Wireless Networks",
              7th International Workshop Proceedings, November 1999.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000, <https://www.rfc-
              editor.org/info/rfc2818>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
              editor.org/info/rfc3261>.






Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 29]


Internet-Draft           Automated IoT Security                July 2018


   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <https://www.rfc-editor.org/info/rfc3748>.

   [RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
              Neighbor Discovery (ND) Trust Models and Threats",
              RFC 3756, DOI 10.17487/RFC3756, May 2004,
              <https://www.rfc-editor.org/info/rfc3756>.

   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
              Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August
              2004, <https://www.rfc-editor.org/info/rfc3833>.

   [RFC4016]  Parthasarathy, M., "Protocol for Carrying Authentication
              and Network Access (PANA) Threat Analysis and Security
              Requirements", RFC 4016, DOI 10.17487/RFC4016, March 2005,
              <https://www.rfc-editor.org/info/rfc4016>.

   [RFC4251]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
              January 2006, <https://www.rfc-editor.org/info/rfc4251>.

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
              <https://www.rfc-editor.org/info/rfc4555>.

   [RFC4621]  Kivinen, T. and H. Tschofenig, "Design of the IKEv2
              Mobility and Multihoming (MOBIKE) Protocol", RFC 4621,
              DOI 10.17487/RFC4621, August 2006, <https://www.rfc-
              editor.org/info/rfc4621>.

   [RFC4738]  Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
              RSA-R: An Additional Mode of Key Distribution in
              Multimedia Internet KEYing (MIKEY)", RFC 4738,
              DOI 10.17487/RFC4738, November 2006, <https://www.rfc-
              editor.org/info/rfc4738>.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",
              RFC 4919, DOI 10.17487/RFC4919, August 2007,
              <https://www.rfc-editor.org/info/rfc4919>.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <https://www.rfc-editor.org/info/rfc4944>.



Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 30]


Internet-Draft           Automated IoT Security                July 2018


   [RFC5191]  Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
              and A. Yegin, "Protocol for Carrying Authentication for
              Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
              May 2008, <https://www.rfc-editor.org/info/rfc5191>.

   [RFC5206]  Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko,
              "End-Host Mobility and Multihoming with the Host Identity
              Protocol", RFC 5206, DOI 10.17487/RFC5206, April 2008,
              <https://www.rfc-editor.org/info/rfc5206>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
              editor.org/info/rfc5246>.

   [RFC5713]  Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
              Threats and Security Requirements for the Access Node
              Control Protocol (ANCP)", RFC 5713, DOI 10.17487/RFC5713,
              January 2010, <https://www.rfc-editor.org/info/rfc5713>.

   [RFC5903]  Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
              Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
              DOI 10.17487/RFC5903, June 2010, <https://www.rfc-
              editor.org/info/rfc5903>.

   [RFC6345]  Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and
              A. Yegin, "Protocol for Carrying Authentication for
              Network Access (PANA) Relay Element", RFC 6345,
              DOI 10.17487/RFC6345, August 2011, <https://www.rfc-
              editor.org/info/rfc6345>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <https://www.rfc-editor.org/info/rfc6347>.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012, <https://www.rfc-
              editor.org/info/rfc6550>.

   [RFC6551]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
              and D. Barthel, "Routing Metrics Used for Path Calculation
              in Low-Power and Lossy Networks", RFC 6551,
              DOI 10.17487/RFC6551, March 2012, <https://www.rfc-
              editor.org/info/rfc6551>.




Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 31]


Internet-Draft           Automated IoT Security                July 2018


   [RFC6568]  Kim, E., Kaspar, D., and JP. Vasseur, "Design and
              Application Spaces for IPv6 over Low-Power Wireless
              Personal Area Networks (6LoWPANs)", RFC 6568,
              DOI 10.17487/RFC6568, April 2012, <https://www.rfc-
              editor.org/info/rfc6568>.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <https://www.rfc-editor.org/info/rfc6690>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
              October 2013, <https://www.rfc-editor.org/info/rfc7049>.

   [RFC7158]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7158, DOI 10.17487/RFC7158, March
              2014, <https://www.rfc-editor.org/info/rfc7158>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014, <https://www.rfc-
              editor.org/info/rfc7252>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC7390]  Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
              the Constrained Application Protocol (CoAP)", RFC 7390,
              DOI 10.17487/RFC7390, October 2014, <https://www.rfc-
              editor.org/info/rfc7390>.

   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
              RFC 7401, DOI 10.17487/RFC7401, April 2015,
              <https://www.rfc-editor.org/info/rfc7401>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.






Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 32]


Internet-Draft           Automated IoT Security                July 2018


   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015, <https://www.rfc-
              editor.org/info/rfc7517>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC7668]  Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
              Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
              Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
              <https://www.rfc-editor.org/info/rfc7668>.

   [RFC7696]  Housley, R., "Guidelines for Cryptographic Algorithm
              Agility and Selecting Mandatory-to-Implement Algorithms",
              BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
              <https://www.rfc-editor.org/info/rfc7696>.

   [RFC7815]  Kivinen, T., "Minimal Internet Key Exchange Version 2
              (IKEv2) Initiator Implementation", RFC 7815,
              DOI 10.17487/RFC7815, March 2016, <https://www.rfc-
              editor.org/info/rfc7815>.

   [RFC7925]  Tschofenig, H., Ed. and T. Fossati, "Transport Layer
              Security (TLS) / Datagram Transport Layer Security (DTLS)
              Profiles for the Internet of Things", RFC 7925,
              DOI 10.17487/RFC7925, July 2016, <https://www.rfc-
              editor.org/info/rfc7925>.

   [RG-T2TRG]
              "IRTF Thing-to-Thing (T2TRG) Research Group",
              Web https://datatracker.ietf.org/rg/t2trg/charter/,
              December 2015.

   [SchneierSecurity]
              "The Internet of Things Is Wildly Insecure--And Often
              Unpatchable", Web
              https://www.schneier.com/essays/archives/2014/01/
              the_internet_of_thin.html, n.d..

   [sigfox]   "Sigfox - The Global Communications Service Provider for
              the Internet of Things (IoT)",
              Web https://www.sigfox.com/, n.d..

   [SPEKE]    "IEEE P1363.2: Password-based Cryptography", 2008.






Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 33]


Internet-Draft           Automated IoT Security                July 2018


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

   [Thread]   "Thread Group", Web http://threadgroup.org/, n.d..

   [TinyDTLS]
              "TinyDTLS", Web http://tinydtls.sourceforge.net/, February
              2012.

   [TR69]     "Too Many Cooks - Exploiting the Internet-of-TR-
              069-Things", Web https://media.ccc.de/v/31c3_-_6166_-_en_-
              _saal_6_-_201412282145_-_too_many_cooks_-
              _exploiting_the_internet-of-tr-069-things_-
              _lior_oppenheim_-_shahar_tal, n.d..

   [WG-6LoWPAN]
              "IETF 6LoWPAN Working Group",
              Web http://tools.ietf.org/wg/6lowpan/, February 2011.

   [WG-ACE]   "IETF Authentication and Authorization for Constrained
              Environments (ACE) Working Group",
              Web https://datatracker.ietf.org/wg/ace/charter/, June
              2014.

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

   [WG-LWIG]  "IETF Light-Weight Implementation Guidance (LWIG) Working
              Group", Web https://datatracker.ietf.org/wg/lwig/charter/,
              March 2011.

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

   [wink]     "Wink's Outage Shows Us How Frustrating Smart Homes Could
              Be",
              Web http://www.wired.com/2015/04/smart-home-headaches/,
              n.d..

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








Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 34]


Internet-Draft           Automated IoT Security                July 2018


   [Ziegeldorf]
              Ziegeldorf, J., Garcia-Morchon, O., and K. Wehrle,,
              "Privacy in the Internet of Things: Threats and
              Challenges", Paper Security and Communication Networks -
              Special Issue on Security in a Completely Interconnected
              World, 2013.

Authors' Addresses

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

   Email: oscar.garcia-morchon@philips.com


   Thorsten Dahm
   Google
   todo
   Dublin
   Ireland

   Email: thorstendlux@google.com


























Garcia-Morchon & Dahm    Expires January 3, 2019               [Page 35]