Network Working Group O. Garcia-Morchon Internet-Draft Philips IP&S Intended status: Informational S. Kumar Expires: June 15, 2019 Philips Research M. Sethi Ericsson December 12, 2018 IoT Security - Threats, Security mitigations and Profiles draft-garcia-security-mitigations-and-profiles 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. This document summarizes key security threats and suitable mitigation strategies to protect against these threats. We introduce the concept of security profiles, sets of security mitigations applicable to IoT applications and systems exposed to similar security threats. 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 https://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 June 15, 2019. Garcia-Morchon, et al. Expires June 15, 2019 [Page 1] Internet-Draft IoT Security December 2018 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 (https://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 . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The design space of secure IoT systems . . . . . . . . . . . 4 3.1. The Thing Lifecycle . . . . . . . . . . . . . . . . . . . 4 3.2. Classes of IoT device . . . . . . . . . . . . . . . . . . 6 3.3. Classes of IoT systems . . . . . . . . . . . . . . . . . 6 4. Security Threats . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Mitigations . . . . . . . . . . . . . . . . . . . . 10 6. Designing and operating secure IoT systems . . . . . . . . . 11 7. Security Profiles . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Classes of IoT Systems . . . . . . . . . . . . . . . . . 14 7.2. Security Profile 1: Home usage . . . . . . . . . . . . . 17 7.3. Security Profile 2: Managed Home usage . . . . . . . . . 17 7.4. Security Profile 3: Industrial usage . . . . . . . . . . 17 7.5. Security Profile 4: Managed Industrial usage . . . . . . 17 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 12. Informative References . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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]. Garcia-Morchon, et al. Expires June 15, 2019 [Page 2] Internet-Draft IoT Security December 2018 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. This document summarizes threats and existing mitigation strategies to overcome those 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 can facilitate the proper design and operation of secure IoT systems. Finally, this document proposes diffent security profiles, i.e., sets of mitigation strategies, that address typical threats in different IoT 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. This section further gives general definitions for the main security building blocks within the IoT domain. Section Section 4 discusses threats that should be considered when designing and operating an IoT system. In Section 5, 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, the following section details methodologies for managing risks when designing a secure IoT system and dealing with vulnerabilities when operating the system. Finally, Section 7 proposes a number of illustrative security profiles applicable to different illustrative clases of IoT systems. Each security profile comprises a set of mitigation strategies and security processes that can provide a suitable security level while matching the cost and usuability goals of the corresponding class of IoT systems. Section 8 includes final remarks and conclusions. Garcia-Morchon, et al. Expires June 15, 2019 [Page 3] Internet-Draft IoT Security December 2018 3. The design space of secure IoT systems ToDo: write intro for this section whose goal is to describe 'general' aspects to consider when designing/operating/maintaining an IoT system. 3.1. The Thing Lifecycle ToDo: describe IoT lifecycle and how that impacts security design. The text below is old and belongs to the old draft. Part of the text could be reused. Garcia-Morchon, et al. Expires June 15, 2019 [Page 4] Internet-Draft IoT Security December 2018 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, 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. Garcia-Morchon, et al. Expires June 15, 2019 [Page 5] Internet-Draft IoT Security December 2018 _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. Classes of IoT device ToDo: describe classes of IoT devices and how that impacts security design. 3.3. Classes of IoT systems ToDo: describe classes of IoT systems and how that impacts security design. 4. Security Threats ToDo: This section should summarize threats. The list below is from the old draft and it is not complete or very detailed. This shold be improved. Garcia-Morchon, et al. Expires June 15, 2019 [Page 6] Internet-Draft IoT Security December 2018 This section explores security threats and vulnerabilities in the IoT and discusses how to manage risks. Security threats have been analyzed in related IP protocols including HTTPS [RFC2818], COAP[RFC7252] 6LoWPAN [RFC4919], ANCP [RFC5713], DNS security threats [RFC3833], SIP [RFC3261], IPv6 ND [RFC3756], and PANA [RFC4016]. Nonetheless, the challenge is about their impacts on scenarios of the IoTs. In this section, we specifically discuss the threats that could compromise an individual thing, or network as a whole. Note that these set of threats might go beyond the scope of Internet protocols but we gather them here for the sake of completeness. We also note that these threats can be classified according to either (i) the thing's lifecycle phases (when does the threat occur?) or (ii) the security building blocks (which functionality is affected by the threat?). All these threats are summarized in Table 2. 1. Cloning of things: During the manufacturing process of a thing, an untrusted factory can easily clone the physical characteristics, firmware/software, or security configuration of the thing. Deployed things might also be compromised and their software reserve engineered allowing for cloning or software modifications. Such a cloned thing may be sold at a cheaper price in the market, and yet be able to function normally, as a genuine thing. For example, two cloned devices can still be associated and work with each other. In the worst case scenario, a cloned device can be used to control a genuine device or perform an attack. One should note here, that an untrusted factory may also change functionality of the cloned thing, resulting in degraded functionality with respect to the genuine thing (thereby, inflicting potential damage to the reputation of the original thing manufacturer). Moreover, additional functionality can be implemented within the cloned thing, such as a backdoor. 2. Malicious substitution of things: During the installation of a thing, a genuine thing may be substituted with a similar variant of lower quality without being detected. The main motivation may be cost savings, where the installation of lower-quality things (e.g., non-certified products) may significantly reduce the installation and operational costs. The installers can subsequently resell the genuine things in order to gain further financial benefits. Another motivation may be to inflict damage to the reputation of a competitor's offerings. 3. Eavesdropping attack: During the commissioning of a thing into a network, it may be susceptible to eavesdropping, especially if operational keying materials, security parameters, or Garcia-Morchon, et al. Expires June 15, 2019 [Page 7] Internet-Draft IoT Security December 2018 configuration settings, are exchanged in clear using a wireless medium or if used cryptographic algorithms are not suitable for the envisioned lifetime of the device and the system. After obtaining the keying material, the attacker might be able to recover the secret keys established between the communicating entities (e.g., H2T, T2Ts, or Thing to the backend management system), thereby compromising the authenticity and confidentiality of the communication channel, as well as the authenticity of commands and other traffic exchanged over this communication channel. When the network is in operation, T2T communication may be eavesdropped upon if the communication channel is not sufficiently protected or in the event of session key compromise due to a long period of usage without key renewal or updates. 4. Man-in-the-middle attack: Both the commissioning phase and operational phases may also be vulnerable to man-in-the-middle attacks, e.g., when keying material between communicating entities are exchanged in the clear and the security of the key establishment protocol depends on the tacit assumption that no third party is able to eavesdrop during the execution of this protocol. Additionally, device authentication or device authorization may be non-trivial, or may need support of a human decision process, since things usually do not have a-priori knowledge about each other and cannot always be able to differentiate friends and foes via completely automated mechanisms. Thus, even if the key establishment protocol provides cryptographic device authentication, this knowledge on device identities may still need complementing with a human- assisted authorization step (thereby, presenting a weak link and offering the potential of man-in-the-middle attacks this way). 5. Firmware Replacement attack: When a thing is in operation or maintenance phase, its firmware or software may be updated to allow for new functionality or new features. An attacker may be able to exploit such a firmware upgrade by replacing the thing's software with malicious software, thereby influencing the operational behavior of the thing. For example, an attacker could add a piece of malicious code to the firmware that will cause it to periodically report the energy usage of the lamp to a data repository for analysis. Similarly, devices whose software has not been properly maintained and updated might contain vulnerabilities that might be exploited by attackers. 6. Extraction of private information: in the ambient environment the things (such as sensors, actuators, etc.) are usually physically unprotected and could easily be captured by an attacker. Such an attacker may then attempt to extract private information such as Garcia-Morchon, et al. Expires June 15, 2019 [Page 8] Internet-Draft IoT Security December 2018 keys (e.g., device's key, private-key, group key), sensed data (e.g., healthcare status of a user), configuration parameters (e.g., the WiFi key), or proprietary algorithms (e.g., algorithm performing some data analytic task) from this thing. Compromise of a thing's unique key compromises communication channels of this particular thing and also compromise all data communicated over this channel. 7. Routing attack: As highlighted in [ID-Daniel], routing information in IoT can be spoofed, altered, or replayed, in order to create routing loops, attract/repel network traffic, extend/ shorten source routes, etc. Other relevant routing attacks include 1) Sinkhole attack (or blackhole attack), where an attacker declares himself to have a high-quality route/path to the base station, thus allowing him to do manipulate all packets passing through it. 2) Selective forwarding, where an attacker may selectively forward packets or simply drop a packet. 3) Wormhole attack, where an attacker may record packets at one location in the network and tunnel them to another location, thereby influencing perceived network behavior and potentially distorting statistics, thus greatly impacting the functionality of routing. 4) Sybil attack, whereby an attacker presents multiple identities to other things in the network. 8. Privacy threat: The tracking of a thing's location and usage may pose a privacy risk to its users. An attacker can infer information based on the information gathered about individual things, thus deducing behavioral patterns of the user of interest to him. Such information can subsequently be sold to interested parties for marketing purposes and targeted advertising. 9. Denial-of-Service attack: Typically, things have tight memory and limited computation, they are thus vulnerable to resource exhaustion attack. Attackers can continuously send requests to be processed by specific things so as to deplete their resources. This is especially dangerous in the IoTs since an attacker might be located in the backend and target resource-constrained devices in an Low-Latency Network (LLN). Additionally, DoS attack can be launched by physically jamming the communication channel, thus breaking down the T2T communication channel. Network availability can also be disrupted by flooding the network with a large number of packets. On the other hand, things compromised by attackers can be used to disrupt the operation of other networks or systems by means of a Distributed DoS attack. The following table summarizes the above generic security threats and the potential point of vulnerabilities at different layers of the communication stack. We also include related RFCs and ongoing Garcia-Morchon, et al. Expires June 15, 2019 [Page 9] Internet-Draft IoT Security December 2018 standardization efforts that include a threat model that might apply to the IoTs. +------------------+------------------+------------------+ | Manufacturing | Installation/ | Operation | | | Commissioning | | +------------+------------------+------------------+------------------+ |Thing's | Device Cloning |Substitution |Privacy threat | |Model | |ACE-OAuth(draft) |Extraction of | | | | |private inform. | +------------+------------------+------------------+------------------+ |Application | |RFC2818, RFC7252 |RFC2818, Firmware | |Layer | |OSCOAP(draft) |replacement | +------------+------------------+------------------+------------------+ |Transport | | Eavesdropping & |Eavesdropping | |Layer | | Man-in-the-middle|Man-in-the-middle | +------------+------------------| attack, RFC7925 |------------------+ |Network | | RFC4919, RFC5713 |RFC4919,DoS attack| |Layer | | RFC3833, RFC3756 |Routing attack | | | | |RFC3833 | +------------+------------------+------------------+------------------+ |Physical | | |DoS attack | |Layer | | | | +-------------------------------+------------------+------------------+ Figure 2: Classification of threats according to the lifecycle phases and security building blocks. 5. Security Mitigations ToDo: this section should contain mitigation strategies to deal with threats. Garcia-Morchon, et al. Expires June 15, 2019 [Page 10] Internet-Draft IoT Security December 2018 6. Designing and operating secure IoT systems [ToDo: This section should describe how an IoT system should be designed/operated. The text below is from the old draft and it should be further improved.] 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 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 incident reporting and mitigation refer to the methodologies that allow becoming aware of any security issues that affect an IoT system. Furthermore, this includes steps towards the actual deployment of patches that mitigate the identified vulnerabilities. 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, Garcia-Morchon, et al. Expires June 15, 2019 [Page 11] Internet-Draft IoT Security December 2018 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. 7. Security Profiles ToDo: this section should contain the security profiles. My thinking is to (i) define some classes of IoT systems that are illustrative of real-world scenarios describing the features of those (lifecycle, device capabilities, IoT system). Then, (ii) describe the types of threats that would be typically applicable to them. And finally, (iii) describe mitigation strategies that should be used to deal with those threats while taking into account the features of the IoT system. NOTE THAT THE 4 PROFILES ARE MERE PLACEHOLDERS. The text below is old and belongs to the old draft. Part of the text could be reused. Garcia-Morchon, et al. Expires June 15, 2019 [Page 12] Internet-Draft IoT Security December 2018 There is a wide range of IoT applications including building automation systems, healthcare, smart cities, logistics, etc. For each of these applications, properties such as device capability, network infrastructure, or available security services can be completely different. 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. For example, IoT applications may have different needs regarding authentication and confidentiality. While some application might not require any confidentiality at all, others might require strong end- to-end confidentiality. In terms of secure bootstrapping of keys, some applications might assume the existence and online availability of a central key-distribution-center (KDC) within the network to distribute and manage keys; while other applications cannot rely on such a central party or on their availability. This section describes some exemplary security profiles fitting the security needs of applications with the same characteristics and requirements. This approach is similar to that in the security profiles in [nist_lightweight_project]. Such security profiles can help to (i) guide the design process of different application types by identifying open gaps; (ii) allow for later interoperability; and (iii) prevent possible security misconfiguration. Each security profile is identified by: 1. a short description, 2. an exemplary application that might use/require such a security profile, 3. the security requirements for each of the above security aspects according to our classification. These security profiles can serve to guide the standardization process, since these explicitly describe the basic functionalities and protocols required to get different use cases up and running. They can allow for later interoperability since different manufacturers can describe the implemented security profile in their products. Finally, the security profiles can avoid possible security misconfiguration, since each security profile can be bound to a Garcia-Morchon, et al. Expires June 15, 2019 [Page 13] Internet-Draft IoT Security December 2018 different application domain so that security protocols are clearly defined and under which circumstances they are applied. We compare the security capabilities in each of the security profiles according to security building blocks, namely: 1. Security architecture, 2. Security model, 3. Security bootstrapping, 4. Network security, and 5. Application security. IMPORTANT: Note that each of these exemplary profiles aims at summarizing the required security requirements for different exemplary application areas and at providing a set of initial security features. In other words, these profiles reflect the need for different security configurations, depending on the threat and trust models of the underlying applications. In this sense, this section does not provide an overview of existing protocols as done in previous sections, but it rather explicitly describes what should be in place to ensure secure system operation. Observe also that this list of security profiles is not exhaustive and that it should be considered just as an example not related to existing legal regulations for any existing application. The remainder of this section is organized as follows. The following section first describes four generic security profiles and discuss how different applications of IP networks, e.g., 6LoWPAN/CoAP networks, involve different security needs. The following five subsections summarize the expected security features or capabilities for each the security profile with regards to "Security Architecture", "Security Model", "Security Bootstrapping", "Network Security", and "Application Security". 7.1. Classes of IoT Systems ToDo: This section should describe some exemplary classes of IoT systems. As already said above, my thinking would be to describe the features of those systems and also the typical threat model for each of those classes of IoT systems. With this, we can also 'assign' mitigation strategies to each of the classes of IoT systems and that set of mitigation strategies would be the security profile. The text below is from the old draft. Garcia-Morchon, et al. Expires June 15, 2019 [Page 14] Internet-Draft IoT Security December 2018 We consider four generic security profiles as summarized in the table below: +---------------------------------------------------------+ | 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 3: Security profiles and application areas. The classification in the table considers different potential applications in which security mechanism are chosen according to the operational features (network size, existence of a central device, connectivity to the Internet, importance of the exchanged information, etc.) and threat model (what are the assets that an attacker looks for). As already pointed out, this set of scenarios is just exemplary and they should be further discussed based on a broader consensus. The security suite (SecProf_1) is catered for environments in which IP protocols (e.g., 6LoWPAN/CoAP) can be used to enable communication between things in an ad-hoc manner and the security requirements are minimal. An example, is a home application in which two devices should exchange information and no further connection with other devices (local or with a backend) is required. In this scenario, value of the exchanged information is low and usually happens in a confined room, thus, it is possible to have a short period of time during which initial secrets can be exchanged in the clear. Due to this fact, there is no requirement to enable devices from different manufacturers to inter operate in a secure way (keys are just exchanged). The expected network size of applications using this profile is expected to be small such that the provision of network security, e.g., secure routing, is of low importance. Garcia-Morchon, et al. Expires June 15, 2019 [Page 15] Internet-Draft IoT Security December 2018 The next security suite (SecProf_2) represents an evolution of SecProf_1 in which, e.g., home devices, can be managed. A first possibility for the securing domain management refers to the creation of a centrally managed security domain without any connectivity to the Internet. The central device used for management can serve as, e.g., a key distribution center including policies for key update, storage, etc. The presence of a central device can help in the management of larger networks. Network security becomes more relevant in this scenario since the IP network (e.g., 6LoWPAN/CoAP network) can be prone to Denial of Service attacks (e.g., flooding if L2 is not protected) or routing attacks. Similarly, the network of devices could also be the source of a DDoS attack and a central device connecting to the Internet can block traffic of ongoing attacks. SecProf_3 considers that a central device is always required for managing the system. Example applications of this profile include building control and automation, sensor networks for industrial use, environmental monitoring, etc. As before, the manager can be located in the same network (e.g., 6LoWPAN/CoAP network) and handle key management. In this case, the first association of devices to the network is required to be done in a secure way, i.e., requiring authentication and authorization. This step can involve the secure transmission of keying materials used for network security at different layers. The information exchanged in the network is considered to be valuable and it should be protected in the sense of pairwise links. Commands should be secured and broadcast should be secured with entity authentication [RFC7390]. Network should be protected from routing attacks. A further extension to this use case is to allow for remote management. A "backend manager" is in charge of securely managing SW or information exchanged or collected within the network, e.g., a 6LoWPAN/CoAP network. This requires connection of devices to the Internet over a 6LBR involving a number of new threats that were not present before. A list of potential attacks include: resource-exhaustion attacks from the Internet; amplification attacks; trust issues related a HTTP-CoAP proxy [ID-proHTTPCoAP], etc. This use case requires protecting the communication from a device in the backend to a device in the IP network, e.g., a 6LoWPAN/ CoAP network, end-to-end. This use case also requires measures to provide the 6LBR with the capability of dropping fake requests coming from the Internet. This becomes especially challenging when the 6LBR is not trusted and access to the exchanged information is limited; and even more in the case of a HTTP-CoAP proxy since protocol translation is required. This use case should take care of protecting information accessed from the backend due to privacy issues (e.g., information such as type of devices, location, usage, type and amount of exchanged information, or mobility patterns can be Garcia-Morchon, et al. Expires June 15, 2019 [Page 16] Internet-Draft IoT Security December 2018 gathered at the backend threatening the privacy sphere of users) so that only required information is disclosed. The last security suite (SecProf_4) essentially represents interoperability of all the security profiles defined previously. It considers applications with some additional requirements regarding operation such as: (i) ad-hoc establishment of security relationships between things (potentially from different manufacturers) in non- secure environments or (ii) dynamic roaming of things between different IP network security domains. Such operational requirements pose additional security requirements, e.g., in addition to secure bootstrapping of a device within an IP, e.g., 6LowPan/CoAP, security domain and the secure transfer of network operational key, there is a need to enable inter-domains secure communication to facilitate data sharing. In this scenario, there is also a higher pressure to ensure that an attacker cannot compromise deployed devices and extract or modify any type of private data such as cryptographic keys, data, or proprietary algorithms. 7.2. Security Profile 1: Home usage ToDo: include typical threats and mitigation strategies for this scenario. Describe why that set of mitigation strategies would lead to a good trade-off between security/cost/usuability. 7.3. Security Profile 2: Managed Home usage ToDo: include typical threats and mitigation strategies for this scenario. Describe why that set of mitigation strategies would lead to a good trade-off between security/cost/usuability. 7.4. Security Profile 3: Industrial usage ToDo: include typical threats and mitigation strategies for this scenario. Describe why that set of mitigation strategies would lead to a good trade-off between security/cost/usuability. 7.5. Security Profile 4: Managed Industrial usage ToDo: include typical threats and mitigation strategies for this scenario. Describe why that set of mitigation strategies would lead to a good trade-off between security/cost/usuability. 8. Conclusions ToDo Garcia-Morchon, et al. Expires June 15, 2019 [Page 17] Internet-Draft IoT Security December 2018 9. Security Considerations This document reflects upon the requirements and challenges of the security architectural framework for the Internet of Things. 10. IANA Considerations This document contains no request to IANA. 11. Acknowledgments We gratefully acknowledge feedback and fruitful discussion with Tobias Heer, Robert Moskowitz, and Thorsten Dahm. We acknowledge the additional authors of the previous version of this document Sye Loong Keoh, Rene Hummen and Rene Struik. 12. 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.. Garcia-Morchon, et al. Expires June 15, 2019 [Page 18] Internet-Draft IoT Security December 2018 [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.. [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. Garcia-Morchon, et al. Expires June 15, 2019 [Page 19] Internet-Draft IoT Security December 2018 [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. [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. Garcia-Morchon, et al. Expires June 15, 2019 [Page 20] Internet-Draft IoT Security December 2018 [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. [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. Garcia-Morchon, et al. Expires June 15, 2019 [Page 21] Internet-Draft IoT Security December 2018 [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.. [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.. Garcia-Morchon, et al. Expires June 15, 2019 [Page 22] Internet-Draft IoT Security December 2018 [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.. [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, . Garcia-Morchon, et al. Expires June 15, 2019 [Page 23] Internet-Draft IoT Security December 2018 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . [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, . [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, . [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, . [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August 2004, . [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements", RFC 4016, DOI 10.17487/RFC4016, March 2005, . [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, . [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, . [RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, DOI 10.17487/RFC4621, August 2006, . [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, . Garcia-Morchon, et al. Expires June 15, 2019 [Page 24] Internet-Draft IoT Security December 2018 [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, . [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, . [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, . [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, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [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, . [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, . [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, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . Garcia-Morchon, et al. Expires June 15, 2019 [Page 25] Internet-Draft IoT Security December 2018 [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, . [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, . [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, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, . [RFC7158] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7158, DOI 10.17487/RFC7158, March 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [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, . Garcia-Morchon, et al. Expires June 15, 2019 [Page 26] Internet-Draft IoT Security December 2018 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, . [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, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [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, . [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, . [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation", RFC 7815, DOI 10.17487/RFC7815, March 2016, . [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, . [RG-T2TRG] "IRTF Thing-to-Thing (T2TRG) Research Group", Web https://datatracker.ietf.org/rg/t2trg/charter/, December 2015. Garcia-Morchon, et al. Expires June 15, 2019 [Page 27] Internet-Draft IoT Security December 2018 [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. [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.. Garcia-Morchon, et al. Expires June 15, 2019 [Page 28] Internet-Draft IoT Security December 2018 [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. [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 IP&S High Tech Campus 5 Eindhoven, 5656 AA The Netherlands Email: oscar.garcia-morchon@philips.com Sandeep S. Kumar Philips Research High Tech Campus Eindhoven, 5656 AA The Netherlands Email: sandeep.kumar@philips.com Mohit Sethi Ericsson Hirsalantie 11 Jorvas Finland Email: mohit@piuha.net Garcia-Morchon, et al. Expires June 15, 2019 [Page 29]