diff options
Diffstat (limited to 'doc/rfc/rfc8576.txt')
| -rw-r--r-- | doc/rfc/rfc8576.txt | 2803 |
1 files changed, 2803 insertions, 0 deletions
diff --git a/doc/rfc/rfc8576.txt b/doc/rfc/rfc8576.txt new file mode 100644 index 0000000..a6b4f05 --- /dev/null +++ b/doc/rfc/rfc8576.txt @@ -0,0 +1,2803 @@ + + + + + + +Internet Research Task Force (IRTF) O. Garcia-Morchon +Request for Comments: 8576 Philips +Category: Informational S. Kumar +ISSN: 2070-1721 Signify + M. Sethi + Ericsson + April 2019 + + + Internet of Things (IoT) Security: State of the Art and Challenges + +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 for IoT systems are well + recognized, and many standardization steps to provide security have + been taken -- for example, the specification of the Constrained + Application Protocol (CoAP) secured with Datagram Transport Layer + Security (DTLS). However, security challenges still exist, not only + because there are some use cases that lack a suitable solution, but + also because many IoT devices and systems have been designed and + deployed with very limited security capabilities. In this document, + we first discuss the various stages in the lifecycle of a thing. + Next, we document the security threats to a thing and the challenges + that one might face to protect against these threats. Lastly, we + discuss the next steps needed to facilitate the deployment of secure + IoT systems. This document can be used by implementers and authors + of IoT specifications as a reference for details about security + considerations while documenting their specific security challenges, + threat models, and mitigations. + + This document is a product of the IRTF Thing-to-Thing Research Group + (T2TRG). + + + + + + + + + + + + + + + + + +Garcia-Morchon, et al. Informational [Page 1] + +RFC 8576 IoT Security April 2019 + + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Research Task Force + (IRTF). The IRTF publishes the results of Internet-related research + and development activities. These results might not be suitable for + deployment. Documents approved for publication by the IRSG are not + candidates for any level of Internet Standard; see Section 2 of RFC + 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8576. + +Copyright Notice + + Copyright (c) 2019 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. + + + + + + + + + + + + + + + + + + + + + + + + +Garcia-Morchon, et al. Informational [Page 2] + +RFC 8576 IoT Security April 2019 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. The Thing Lifecycle . . . . . . . . . . . . . . . . . . . . . 5 + 3. Security Threats and Managing Risk . . . . . . . . . . . . . 8 + 4. State of the Art . . . . . . . . . . . . . . . . . . . . . . 13 + 4.1. IP-Based IoT Protocols and Standards . . . . . . . . . . 13 + 4.2. Existing IP-Based Security Protocols and Solutions . . . 16 + 4.3. IoT Security Guidelines . . . . . . . . . . . . . . . . . 18 + 5. Challenges for a Secure IoT . . . . . . . . . . . . . . . . . 21 + 5.1. Constraints and Heterogeneous Communication . . . . . . . 21 + 5.1.1. Resource Constraints . . . . . . . . . . . . . . . . 21 + 5.1.2. Denial-of-Service Resistance . . . . . . . . . . . . 22 + 5.1.3. End-to-End Security, Protocol Translation, and the + Role of Middleboxes . . . . . . . . . . . . . . . . . 23 + 5.1.4. New Network Architectures and Paradigm . . . . . . . 25 + 5.2. Bootstrapping of a Security Domain . . . . . . . . . . . 25 + 5.3. Operational Challenges . . . . . . . . . . . . . . . . . 25 + 5.3.1. Group Membership and Security . . . . . . . . . . . . 26 + 5.3.2. Mobility and IP Network Dynamics . . . . . . . . . . 27 + 5.4. Secure Software Update and Cryptographic Agility . . . . 27 + 5.5. End-of-Life . . . . . . . . . . . . . . . . . . . . . . . 30 + 5.6. Verifying Device Behavior . . . . . . . . . . . . . . . . 30 + 5.7. Testing: Bug Hunting and Vulnerabilities . . . . . . . . 31 + 5.8. Quantum-Resistance . . . . . . . . . . . . . . . . . . . 32 + 5.9. Privacy Protection . . . . . . . . . . . . . . . . . . . 33 + 5.10. Reverse-Engineering Considerations . . . . . . . . . . . 34 + 5.11. Trustworthy IoT Operation . . . . . . . . . . . . . . . . 35 + 6. Conclusions and Next Steps . . . . . . . . . . . . . . . . . 36 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 + 9. Informative References . . . . . . . . . . . . . . . . . . . 37 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 + + + + + + + + + + + + + + + + + +Garcia-Morchon, et al. Informational [Page 3] + +RFC 8576 IoT Security April 2019 + + +1. Introduction + + The Internet of Things (IoT) denotes the interconnection of highly + heterogeneous networked entities and networks that follow a number of + different 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 in 1999 by the Auto-ID + center [AUTO-ID], which had envisioned a world where every physical + object has a radio-frequency identification (RFID) tag with a + globally unique identifier. This would not only allow tracking of + objects in real time but also allow querying of data about them over + the Internet. However, since then, the meaning of the Internet of + Things has expanded and now encompasses a wide variety of + technologies, objects, and protocols. It is not surprising that the + IoT has received significant attention from the research community to + (re)design, apply, and use standard Internet technology and protocols + for the IoT. + + The things that are part of the Internet of Things are computing + devices that understand and react to the environment they reside in. + These things are also often referred to as smart objects or smart + devices. The introduction of IPv6 [RFC6568] and CoAP [RFC7252] as + fundamental building blocks for IoT applications allows connecting + IoT hosts to the Internet. This brings several advantages, + including: (i) a homogeneous protocol ecosystem that allows simple + integration with other Internet hosts; (ii) simplified development + for devices that significantly vary in their capabilities; (iii) a + unified interface for applications, removing the need for + application-level proxies. These building blocks greatly simplify + the deployment of the envisioned scenarios, which range from building + automation to production environments and personal area networks. + + This document presents an overview of important security aspects for + the Internet of Things. We begin by discussing the lifecycle of a + thing in Section 2. In Section 3, we discuss security threats for + the IoT and methodologies for managing these threats when designing a + secure system. Section 4 reviews existing IP-based (security) + protocols for the IoT and briefly summarizes existing guidelines and + regulations. Section 5 identifies remaining challenges for a secure + IoT and discusses potential solutions. Section 6 includes final + remarks and conclusions. This document can be used by IoT standards + specifications as a reference for details about security + considerations that apply to the specified system or protocol. + + The first draft version of this document was submitted in March 2011. + Initial draft versions of this document were presented and discussed + during the meetings of the Constrained RESTful Environments (CORE) + Working Group at IETF 80 and later. Discussions on security + + + +Garcia-Morchon, et al. Informational [Page 4] + +RFC 8576 IoT Security April 2019 + + + lifecycle at IETF 92 (March 2015) evolved into more general security + considerations. Thus, the draft was selected to address the T2TRG + work item on the security considerations and challenges for the + Internet of Things. Further updates of the draft were presented and + discussed during the T2TRG meetings at IETF 96 (July 2016) and IETF + 97 (November 2016) and at the joint interim meeting in Amsterdam + (March 2017). This document has been reviewed by, commented on, and + discussed extensively for a period of nearly six years by a vast + majority of the T2TRG and related group members, the number of which + certainly exceeds 100 individuals. It is the consensus of T2TRG that + the security considerations described in this document should be + published in the IRTF Stream of the RFC series. This document does + not constitute a standard. + +2. 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. For instance, [RFC7744] provides an overview of relevant + IoT use cases. + + In this document, we consider 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 Heating, + Ventilating, and Air Conditioning (HVAC), lighting, safety, etc. The + nodes vary in functionality, and a large majority of them represent + resource-constrained devices such as sensors and luminaries. Some + devices may be battery operated or may rely on energy harvesting. + This requires us to also consider devices that sleep during their + operation to save energy. In our BAC scenario, the life of a thing + starts when it is manufactured. Due to the different application + areas (i.e., HVAC, lighting, or safety), nodes/things 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 may be + 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 discrete event and may stretch over an extended period. After + being bootstrapped, the device and the system of things are in + + + +Garcia-Morchon, et al. Informational [Page 5] + +RFC 8576 IoT Security April 2019 + + + operational mode and execute the functions of the BAC system. During + this operational phase, the device is under the control of the system + owner and used by multiple system users. 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 be performed either locally + or from a backend system. Depending on the operational changes to + the device, it may be required to rebootstrap at the end of a + maintenance cycle. The device continues to loop through the + operational phase and the eventual maintenance phases 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; rather, it denotes a need to replace and upgrade the + network to next-generation devices for additional functionality. + Therefore, the device can be removed and recommissioned to be used in + a different system under a different owner, thereby starting the + lifecycle all over again. + + We note that the presented lifecycle represents to some extent a + simplified model. For instance, it is possible to argue that the + lifecycle does not start when a tangible device is manufactured but + rather when the oldest bit of code that ends up in the device -- + maybe from an open-source project or the operating system -- was + written. Similarly, the lifecycle could also include an on-the-shelf + phase where the device is in the supply chain before an owner/user + purchases and installs it. Another phase could involve the device + being rebadged by some vendor who is not the original manufacturer. + Such phases can significantly complicate other phases such as + maintenance and bootstrapping. Finally, other potential end states + can be, e.g., a vendor that no longer supports a device type because + it is at the end of its life or a situation in which a device is + simply forgotten but remains functional. + + + + + + + + + + + + + + + + + + +Garcia-Morchon, et al. Informational [Page 6] + +RFC 8576 IoT Security April 2019 + + + _Manufactured _SW update _Decommissioned + / / / + | _Installed | _ Application | _Removed & + | / | / reconfigured | / replaced + | | _Commissioned | | | | + | | / | | | | _Reownership & + | | | _Application | | _Application | | / recommissioned + | | | / running | | / running | | | + | | | | | | | | | | \\ + +##+##+###+#############+##+##+#############+##+##+##############>>> + \/ \______________/ \/ \_____________/ \___/ time // + / / \ \ \ + Bootstrapping / Maintenance & \ Maintenance & + / rebootstrapping \ rebootstrapping + Operational Operational + + Figure 1: The Lifecycle of a Thing in the Internet of Things + + Security is a key requirement in any communication system. However, + security is an even more critical requirement in real-world IoT + deployments for several reasons. First, compromised IoT systems can + not only endanger the privacy and security of a user but can also + cause physical harm. This is because IoT systems often comprise + sensors, actuators, and other connected devices in the physical + environment of the user that could adversely affect the user if they + are compromised. Second, a vulnerable IoT system means that an + attacker can alter the functionality of a device from a given + manufacturer. This not only affects the manufacturer's brand image + but can also leak information that is very valuable for the + manufacturer (such as proprietary algorithms). Third, the impact of + attacking an IoT system goes beyond a specific device or an isolated + system, since compromised IoT systems can be misused at scale. For + example, they may be used to perform a Distributed Denial of Service + (DDoS) attack that limits the availability of other networks and + services. The fact that many IoT systems rely on standard IP + protocols allows for easier system integration, but this also makes + attacks on standard IP protocols widely applicable in other + environments. This results in new requirements regarding the + implementation of security. + + The term "security" subsumes a wide range of primitives, protocols, + and procedures. For instance, it includes services such as + confidentiality, authentication, integrity, authorization, source + authentication, and availability. It often also includes augmented + services such as duplicate detection and detection of stale packets + (timeliness). These security services can be implemented through a + combination of cryptographic mechanisms such as block ciphers, hash + functions, and signature algorithms, as well as noncryptographic + + + +Garcia-Morchon, et al. Informational [Page 7] + +RFC 8576 IoT Security April 2019 + + + mechanisms that implement authorization and other aspects of + security-policy enforcement. For ensuring security in IoT networks, + one should not only focus on the required security services but also + pay special attention to how the services are realized in the overall + system. + +3. Security Threats and Managing Risk + + Security threats in related IP protocols have been analyzed in + multiple documents, including Hypertext Transfer Protocol (HTTP) over + Transport Layer Security (TLS) (HTTPS) [RFC2818], Constrained + Application Protocol (CoAP) [RFC7252], IPv6 over Low-Power Wireless + Personal Area Networks (6LoWPAN) [RFC4919], Access Node Control + Protocol (ANCP) [RFC5713], Domain Name System (DNS) [RFC3833], IPv6 + Neighbor Discovery (ND) [RFC3756], and Protocol for Carrying + Authentication and Network Access (PANA) [RFC4016]. In this section, + we specifically discuss the threats that could compromise an + individual thing or the network as a whole. Some of these threats + might go beyond the scope of Internet protocols, but we gather them + here for the sake of completeness. The threats in the following list + are not in any particular order, and some threats might be more + critical than others, depending on the deployment scenario under + consideration: + + 1. Vulnerable software/code: Things in the Internet of Things rely + on software that might contain severe bugs and/or bad design + choices. This makes the things vulnerable to many different + types of attacks, depending on the criticality of the bugs, + e.g., buffer overflows or lack of authentication. This can be + considered one of the most important security threats. The + large-scale Distributed Denial of Service (DDoS) attack, + popularly known as the Mirai botnet [Mirai], was caused by + things that had well-known or easy-to-guess passwords for + configuration. + + 2. Privacy threat: The tracking of a thing's location and usage may + pose a privacy risk to people around it. For instance, an + attacker can infer privacy-sensitive information from the data + gathered and communicated by individual things. Such + information may subsequently be sold to interested parties for + marketing purposes and targeted advertising. In extreme cases, + such information might be used to track dissidents in oppressive + regimes. Unlawful surveillance and interception of traffic to/ + from a thing by intelligence agencies is also a privacy threat. + + 3. 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 + + + +Garcia-Morchon, et al. Informational [Page 8] + +RFC 8576 IoT Security April 2019 + + + the thing. Deployed things might also be compromised and their + software reverse engineered, allowing for cloning or software + modifications. Such a cloned thing may be sold at a cheaper + price in the market and yet can 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 + introduced in the cloned thing. An example of such + functionality is a backdoor. + + 4. Malicious substitution of things: During the installation of a + thing, a genuine thing may be replaced by a similar variant (of + lower quality) without being detected. The main motivation may + be cost savings, where the installation of lower-quality things + (for example, noncertified products) may significantly reduce + the installation and operational costs. The installers can + subsequently resell the genuine things to gain further financial + benefits. Another motivation may be to inflict damage to the + reputation of a competitor's offerings. + + 5. 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 + configuration settings are exchanged in the 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, 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 can be eavesdropped if the communication channel + is not sufficiently protected or if a session key is compromised + due to protocol weaknesses. An adversary may also be able to + eavesdrop if keys are not renewed or updated appropriately. + Lastly, messages can also be recorded and decrypted offline at a + later point of time. The VENONA project [venona-project] is one + such example where messages were recorded for offline + decryption. + + + + + + +Garcia-Morchon, et al. Informational [Page 9] + +RFC 8576 IoT Security April 2019 + + + 6. Man-in-the-middle attack: Both the commissioning and operational + phases may be vulnerable to man-in-the-middle attacks. For + example, when keying material between communicating entities is + exchanged in the clear, the security of the key establishment + protocol depends on the tacit assumption that no third party can + eavesdrop during the execution of this protocol. Additionally, + device authentication or device authorization may be nontrivial + or need the support of a human decision process, since things + usually do not have a priori knowledge about each other and + cannot always differentiate friends and foes via completely + automated mechanisms. + + 7. Firmware attacks: 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 maliciously replacing the + thing's firmware, thereby influencing its operational behavior. + 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 thing to a data repository for analysis. + The attacker can then use this information to determine when a + home or enterprise (where the thing is installed) is unoccupied + and break in. Similarly, devices whose software has not been + properly maintained and updated might contain vulnerabilities + that might be exploited by attackers to replace the firmware on + the device. + + 8. Extraction of private information: IoT devices (such as sensors, + actuators, etc.) are often physically unprotected in their + ambient environment, and they could easily be captured by an + attacker. An attacker with physical access may then attempt to + extract private information such as keys (for example, a group + key or the device's private key), data from sensors (for + example, healthcare status of a user), configuration parameters + (for example, the Wi-Fi key), or proprietary algorithms (for + example, the algorithm performing some data analytics task). + Even when the data originating from a thing is encrypted, + attackers can perform traffic analysis to deduce meaningful + information, which might compromise the privacy of the thing's + owner and/or user. + + + + + + + + + + + +Garcia-Morchon, et al. Informational [Page 10] + +RFC 8576 IoT Security April 2019 + + + 9. Routing attack: As highlighted in [Daniel], routing information + in IoT networks can be spoofed, altered, or replayed, in order + to create routing loops, attract/repel network traffic, extend/ + shorten source routes, etc. A nonexhaustive list of routing + attacks includes: + + a. 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. + + b. Selective forwarding, where an attacker may selectively + forward packets or simply drop a packet. + + c. 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. + + d. Sybil attack, whereby an attacker presents multiple + identities to other things in the network. We refer to + [Daniel] for further router attacks and a more detailed + description. + + 10. Elevation of privilege: An attacker with low privileges can + misuse additional flaws in the implemented authentication and + authorization mechanisms of a thing to gain more privileged + access to the thing and its data. + + 11. Denial of Service (DoS) attack: Often things have very limited + memory and computation capabilities. Therefore, they are + vulnerable to resource-exhaustion attack. Attackers can + continuously send requests to specific things so as to deplete + their resources. This is especially dangerous in the Internet + of Things since an attacker might be located in the backend and + target resource-constrained devices that are part of a + constrained-node network [RFC7228]. A DoS attack can also be + launched by physically jamming the 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 (DDoS) attack. + + + + + + + +Garcia-Morchon, et al. Informational [Page 11] + +RFC 8576 IoT Security April 2019 + + + To deal with the above threats, it is required to find and apply + suitable security mitigations. However, new threats and exploits + appear on a daily basis, and products are deployed in different + environments prone to different types of threats. Thus, ensuring a + proper level of security in an IoT system at any point of time is + challenging. To address this challenge, some of the following + methodologies can be used: + + 1. A Business Impact Analysis (BIA) assesses the consequences of the + loss of basic security attributes: confidentiality, integrity, + and availability in an IoT system. These consequences might + include the impact from lost data, reduced sales, increased + expenses, regulatory fines, customer dissatisfaction, etc. + Performing a business impact analysis allows a business to + determine the relevance of having a proper security design. + + 2. A Risk Assessment (RA) analyzes security threats to an IoT system + while considering their likelihood and impact. It also includes + categorizing each of them with a risk level. Risks classified as + moderate or high must be mitigated, i.e., the security + architecture should be able to deal with those threats. + + 3. A Privacy Impact Assessment (PIA) aims at assessing the + Personally Identifiable Information (PII) that is collected, + processed, or used in an IoT system. By doing so, the goal is to + fulfill applicable legal requirements and determine the risks and + effects of manipulation and loss of PII. + + 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 should generally be realized during the creation of + a new IoT system or when deploying significant system/feature + upgrades. In general, it is recommended to reassess them on a + regular basis, taking into account new use cases and/or threats. The + way a BIA, RA, or PIA is performed depends on the environment and the + industry. More information can be found in NIST documents such as + [NISTSP800-34r1], [NISTSP800-30r1], and [NISTSP800-122]. + + + + + + + + + + +Garcia-Morchon, et al. Informational [Page 12] + +RFC 8576 IoT Security April 2019 + + +4. State of the Art + + This section is organized as follows. Section 4.1 summarizes the + state of the art on IP-based IoT systems, within both the IETF and + other standardization bodies. Section 4.2 summarizes the state of + the art on IP-based security protocols and their usage. Section 4.3 + discusses guidelines and regulations for securing IoT as proposed by + other bodies. Note that the references included in this section are + a representative of the state of the art at the point of writing, and + they are by no means exhaustive. The references are also at varying + levels of maturity; thus, it is advisable to review their specific + status. + +4.1. IP-Based IoT Protocols and Standards + + Nowadays, there exists a multitude of control protocols for IoT. For + BAC systems, the ZigBee standard [ZB], BACNet [BACNET], and DALI + [DALI] play key roles. Recent trends, however, focus on an all-IP + approach for system control. + + In this setting, a number of IETF working groups are designing new + protocols for resource-constrained networks of smart things. The + 6LoWPAN Working Group [WG-6LoWPAN], for example, has defined methods + and protocols for the efficient transmission and adaptation of IPv6 + packets over IEEE 802.15.4 networks [RFC4944]. + + The CoRE Working Group [WG-CoRE] has specified the Constrained + Application Protocol (CoAP) [RFC7252]. CoAP is a RESTful protocol + for constrained devices that is modeled after HTTP and typically runs + over UDP to enable efficient application-level communication for + things. ("RESTful" refers to the Representational State Transfer + (REST) architecture.) + + In many smart-object networks, the smart objects are dispersed and + have intermittent reachability either because of network outages or + because they sleep during their operational phase to save energy. In + such scenarios, direct discovery of resources hosted on the + constrained server might not be possible. To overcome this barrier, + the CoRE Working Group is specifying the concept of a Resource + Directory (RD) [RD]. The Resource Directory hosts descriptions of + resources that are located on other nodes. These resource + descriptions are specified as CoRE link format [RFC6690]. + + While CoAP defines a standard communication protocol, a format for + representing sensor measurements and parameters over CoAP is + required. "Sensor Measurement Lists (SenML)" [RFC8428] is a + specification that defines media types for simple sensor measurements + and parameters. It has a minimalistic design so that constrained + + + +Garcia-Morchon, et al. Informational [Page 13] + +RFC 8576 IoT Security April 2019 + + + devices with limited computational capabilities can easily encode + their measurements and, at the same time, servers can efficiently + collect a large number of measurements. + + In many IoT deployments, the resource-constrained smart objects are + connected to the Internet via a gateway that is directly reachable. + For example, an IEEE 802.11 Access Point (AP) typically connects the + client devices to the Internet over just one wireless hop. However, + some deployments of smart-object networks require routing between the + smart objects themselves. The IETF has therefore defined the IPv6 + Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550]. + RPL provides support for multipoint-to-point traffic from resource- + constrained smart objects towards a more resourceful central control + point, as well as point-to-multipoint traffic in the reverse + direction. It also supports point-to-point traffic between the + resource-constrained devices. A set of routing metrics and + constraints for path calculation in RPL are also specified [RFC6551]. + + The IPv6 over Networks of Resource-constrained Nodes (6lo) Working + Group of the IETF [WG-6lo] has specified how IPv6 packets can be + transmitted over various link-layer protocols that are commonly + employed for resource-constrained smart-object networks. There is + also ongoing work to specify IPv6 connectivity for a Non-Broadcast + Multi-Access (NBMA) mesh network that is formed by IEEE 802.15.4 + Time-Slotted Channel Hopping (TSCH) links [ARCH-6TiSCH]. Other link- + layer protocols for which the IETF has specified or is currently + specifying IPv6 support include Bluetooth [RFC7668], Digital Enhanced + Cordless Telecommunications (DECT) Ultra Low Energy (ULE) air + interface [RFC8105], and Near Field Communication (NFC) + [IPv6-over-NFC]. + + Baker and Meyer [RFC6272] identify which IP protocols can be used in + smart-grid environments. They give advice to smart-grid network + designers on how they can decide on a profile of the Internet + protocol suite for smart-grid networks. + + The Low Power Wide-Area Network (LPWAN) Working Group [WG-LPWAN] is + analyzing features, requirements, and solutions to adapt IP-based + protocols to networks such as LoRa [LoRa], Sigfox [sigfox], NB-IoT + [NB-IoT], etc. These networking technologies enable a smart thing to + run for years on a single coin-cell by relying on a star network + topology and using optimized radio modulation with frame sizes in the + order of tens of bytes. Such networks bring new security challenges, + since most existing security mechanism do not work well with such + resource constraints. + + + + + + +Garcia-Morchon, et al. Informational [Page 14] + +RFC 8576 IoT Security April 2019 + + + JavaScript Object Notation (JSON) is a lightweight text- + representation format for structured data [RFC8259]. It is often + used for transmitting serialized structured data over the network. + The IETF has defined specifications for encoding cryptographic keys, + encrypted content, signed content, and claims to be transferred + between two parties as JSON objects. They are referred to as JSON + Web Keys (JWKs) [RFC7517], JSON Web Encryption (JWE) [RFC7516], JSON + Web Signatures (JWSs) [RFC7515], and JSON Web Token (JWT) [RFC7519]. + + An alternative to JSON, Concise Binary Object Representation (CBOR) + [RFC7049], is a concise binary data format that is used for + serialization of structured data. It is designed for resource- + constrained nodes, and therefore it aims to provide a fairly small + message size with minimal implementation code and extensibility + without the need for version negotiation. CBOR Object Signing and + Encryption (COSE) [RFC8152] specifies how to encode cryptographic + keys, message authentication codes, encrypted content, and signatures + with CBOR. + + The Light-Weight Implementation Guidance (LWIG) Working Group + [WG-LWIG] is collecting experiences from implementers of IP stacks in + constrained devices. The working group has already produced + documents such as [RFC7815], which defines how a minimal Internet Key + Exchange Version 2 (IKEv2) initiator can be implemented. + + The Thing-2-Thing Research Group (T2TRG) [RG-T2TRG] is investigating + the remaining research issues that need to be addressed to quickly + turn the vision of IoT into a reality where resource-constrained + nodes can communicate with each other and with other more capable + nodes on the Internet. + + Additionally, industry alliances and other standardization bodies are + creating constrained IP protocol stacks based on the IETF work. Some + important examples of this include: + + 1. Thread [Thread]: Specifies the Thread protocol that is intended + for a variety of IoT devices. It is an IPv6-based network + protocol that runs over IEEE 802.15.4. + + 2. Industrial Internet Consortium [IIoT]: The consortium defines + reference architectures and security frameworks for development, + adoption, and widespread use of Industrial Internet technologies + based on existing IETF standards. + + 3. IPSO Alliance (which subsequently merged with OMA SpecWorks + [OMASpecWorks]): The alliance specifies a common object model + that enables application software on any device to interoperate + with other conforming devices. + + + +Garcia-Morchon, et al. Informational [Page 15] + +RFC 8576 IoT Security April 2019 + + + 4. OneM2M [OneM2M]: The standards body defines technical and API + specifications for IoT devices. It aims to create a service + layer that can run on any IoT device hardware and software. + + 5. Open Connectivity Foundation (OCF) [OCF]: The foundation develops + standards and certifications primarily for IoT devices that use + Constrained Application Protocol (CoAP) as the application-layer + protocol. + + 6. Fairhair Alliance [Fairhair]: Specifies an IoT middleware to + enable a common IP network infrastructure between different + application standards used in building automation and lighting + systems such as BACnet, KNX, and ZigBee. + + 7. OMA LwM2M [LWM2M]: OMA Lightweight M2M is a standard from the OMA + SpecWorks for M2M and IoT device management. LwM2M relies on + CoAP as the application-layer protocol and uses a RESTful + architecture for remote management of IoT devices. + +4.2. Existing IP-Based Security Protocols and Solutions + + There are three main security objectives for IoT networks: + + 1. protecting the IoT network from attackers + + 2. protecting IoT applications and thus the things and users + + 3. protecting the rest of the Internet and other things from attacks + that use compromised things as an attack platform + + In the context of the IP-based IoT deployments, consideration of + existing Internet security protocols is important. There are a wide + range of specialized as well as general-purpose security solutions + for the Internet domain, such as IKEv2/IPsec [RFC7296], Transport + Layer Security (TLS) [RFC8446], Datagram Transport Layer Security + (DTLS) [RFC6347], Host Identity Protocol (HIP) [RFC7401], PANA + [RFC5191], Kerberos [RFC4120], Simple Authentication and Security + Layer (SASL) [RFC4422], and Extensible Authentication Protocol (EAP) + [RFC3748]. + + TLS provides security for TCP and requires a reliable transport. + DTLS secures and uses datagram-oriented protocols such as UDP. Both + protocols are intentionally kept similar and share the same ideology + and cipher suites. The CoAP base specification [RFC7252] provides a + description of how DTLS can be used for securing CoAP. It proposes + three different modes for using DTLS: the PreSharedKey mode, where + nodes have pre-provisioned keys for initiating a DTLS session with + another node, RawPublicKey mode, where nodes have asymmetric-key + + + +Garcia-Morchon, et al. Informational [Page 16] + +RFC 8576 IoT Security April 2019 + + + pairs but no certificates to verify the ownership, and Certificate + mode, where public keys are certified by a certification authority. + An IoT implementation profile is defined for TLS version 1.2 and DTLS + version 1.2 that offers communication security for resource- + constrained nodes [RFC7925]. + + There is ongoing work to define an authorization and access-control + framework for resource-constrained nodes. The Authentication and + Authorization for Constrained Environments (ACE) Working Group + [WG-ACE] is defining a solution to allow only authorized access to + resources that are hosted on a smart-object server and identified by + a URI. The current proposal [ACE-OAuth] is based on the OAuth 2.0 + framework [RFC6749], and it comes with profiles intended for + different communication scenarios, e.g., "Datagram Transport Layer + Security (DTLS) Profile for Authentication and Authorization for + Constrained Environments (ACE)" [ACE-DTLS]. + + Object Security for Constrained RESTful Environments (OSCORE) + [OSCORE] is a proposal that protects CoAP messages by wrapping them + in the COSE format [RFC8152]. Thus, OSCORE falls in the category of + object security, and it can be applied wherever CoAP can be used. + The advantage of OSCORE over DTLS is that it provides some more + flexibility when dealing with end-to-end security. Section 5.1.3 + discusses this further. + + The Automated Certificate Management Environment (ACME) Working Group + [WG-ACME] is specifying conventions for automated X.509 certificate + management. This includes automatic validation of certificate + issuance, certificate renewal, and certificate revocation. While the + initial focus of the working group is on domain-name certificates (as + used by web servers), other uses in some IoT deployments are + possible. + + The Internet Key Exchange (IKEv2)/IPsec -- as well as the less used + Host Identity protocol (HIP) -- reside at or above the network layer + in the OSI model. Both protocols are able to perform an + authenticated key exchange and set up the IPsec for secure payload + delivery. Currently, there are also ongoing efforts to create a HIP + variant coined Diet HIP [HIP-DEX] that takes constrained networks and + nodes into account at the authentication and key-exchange level. + + Migault et al. [Diet-ESP] are working on a compressed version of + IPsec so that it can easily be used by resource-constrained IoT + devices. They rely on the Internet Key Exchange Protocol Version 2 + (IKEv2) for negotiating the compression format. + + The Extensible Authentication Protocol (EAP) [RFC3748] is an + authentication framework supporting multiple authentication methods. + + + +Garcia-Morchon, et al. Informational [Page 17] + +RFC 8576 IoT Security April 2019 + + + EAP runs directly over the data link layer and thus does not require + the deployment of IP. It supports duplicate detection and + retransmission but does not allow for packet fragmentation. PANA is + a network-layer transport for EAP that enables network access + authentication between clients and the network infrastructure. In + EAP terms, PANA is a UDP-based EAP lower layer that runs between the + EAP peer and the EAP authenticator. + +4.3. IoT Security Guidelines + + Attacks on and from IoT devices have become common in recent years -- + for instance, large-scale DoS attacks on the Internet Infrastructure + from compromised IoT devices. This fact has prompted many different + standards bodies and consortia to provide guidelines for developers + and the Internet community at large to build secure IoT devices and + services. The following is a subset of the different guidelines and + ongoing projects: + + 1. Global System for Mobile Communications Association (GSMA) IoT + security guidelines [GSMAsecurity]: GSMA has published a set of + security guidelines for the benefit of new IoT product and + service providers. The guidelines are aimed at device + manufacturers, service providers, developers, and network + operators. An enterprise can complete an IoT Security Self- + Assessment to demonstrate that its products and services are + aligned with the security guidelines of the GSMA. + + 2. Broadband Internet Technical Advisory Group (BITAG) IoT Security + and Privacy Recommendations [BITAG]: BITAG has published + recommendations for ensuring the security and privacy of IoT + device users. BITAG observes that many IoT devices are shipped + from the factory with software that is already outdated and + vulnerable. The report also states that many devices with + vulnerabilities will not be fixed, either because the + manufacturer does not provide updates or because the user does + not apply them. The recommendations include that IoT devices + should function without cloud and Internet connectivity and that + all IoT devices should have methods for automatic secure + software updates. + + 3. United Kingdom Department for Digital, Culture, Media and Sport + (DCMS) [DCMS]: UK DCMS has released a report that includes a + list of 13 steps for improving IoT security. These steps, for + example, highlight the need for implementing a vulnerability + disclosure policy and keeping software updated. The report is + aimed at device manufacturers, IoT service providers, mobile + application developers, and retailers. + + + + +Garcia-Morchon, et al. Informational [Page 18] + +RFC 8576 IoT Security April 2019 + + + 4. Cloud Security Alliance (CSA) New Security Guidance for Early + Adopters of the IoT [CSA]: CSA recommendations for early + adopters of IoT encourage enterprises to implement security at + different layers of the protocol stack. It also recommends + implementation of an authentication/authorization framework for + IoT deployments. A complete list of recommendations is + available in the report [CSA]. + + 5. United States Department of Homeland Security (DHS) [DHS]: DHS + has put forth six strategic principles that would enable IoT + developers, manufacturers, service providers, and consumers to + maintain security as they develop, manufacture, implement, or + use network-connected IoT devices. + + 6. National Institute of Standards and Technology (NIST) + [NIST-Guide]: The NIST special publication urges enterprise and + US federal agencies to address security throughout the systems + engineering process. The publication builds upon the + International Organization for Standardization + (ISO)/International Electrotechnical Commission (IEC) 15288 + standard and augments each process in the system lifecycle with + security enhancements. + + 7. National Institute of Standards and Technology (NIST) + [NIST-LW-PROJECT] [NIST-LW-2016]: NIST is running a project on + lightweight cryptography with the purpose of: (i) identifying + application areas for which standard cryptographic algorithms + are too heavy, classifying them according to some application + profiles to be determined; (ii) determining limitations in those + existing cryptographic standards; and (iii) standardizing + lightweight algorithms that can be used in specific application + profiles. + + 8. Open Web Application Security Project (OWASP) [OWASP]: OWASP + provides security guidance for IoT manufacturers, developers, + and consumers. OWASP also includes guidelines for those who + intend to test and analyze IoT devices and applications. + + 9. IoT Security Foundation [IoTSecFoundation]: The IoT Security + Foundation has published a document that enlists various + considerations that need to be taken into account when + developing IoT applications. For example, the document states + that IoT devices could use a hardware root of trust to ensure + that only authorized software runs on the devices. + + 10. National Highway Traffic Safety Administration (NHTSA) [NHTSA]: + The US NHTSA provides guidance to the automotive industry for + improving the cyber security of vehicles. While some of the + + + +Garcia-Morchon, et al. Informational [Page 19] + +RFC 8576 IoT Security April 2019 + + + guidelines are general, the document provides specific + recommendations for the automotive industry, such as how various + automotive manufacturers can share cybersecurity vulnerabilities + discovered. + + 11. "Best Current Practices for Securing Internet of Things (IoT) + Devices" [Moore]: This document provides a list of minimum + requirements that vendors of IoT devices should to take into + account while developing applications, services, and firmware + updates in order to reduce the frequency and severity of + security incidents that arise from compromised IoT devices. + + 12. European Union Agency for Network and Information Security + (ENISA) [ENISA-ICS]: ENISA published a document on + communication-network dependencies for Industrial Control + Systems (ICS)/Supervisory Control And Data Acquisition (SCADA) + systems in which security vulnerabilities, guidelines, and + general recommendations are summarized. + + 13. Internet Society Online Trust Alliance [ISOC-OTA]: The Internet + Society's IoT Trust Framework identifies the core requirements + that manufacturers, service providers, distributors, purchasers, + and policymakers need to understand, assess, and embrace for + effective security and privacy as part of the Internet of + Things. + + Other guideline and recommendation documents may exist or may later + be published. This list should be considered nonexhaustive. Despite + the acknowledgment that security in the Internet is needed and the + existence of multiple guidelines, the fact is that many IoT devices + and systems have very limited security. There are multiple reasons + for this. For instance, some manufacturers focus on delivering a + product without paying enough attention to security. This may be + because of lack of expertise or limited budget. However, the + deployment of such insecure devices poses a severe threat to the + privacy and safety of users. The vast number of devices and their + inherently mobile nature also imply that an initially secure system + can become insecure if a compromised device gains access to the + system at some point in time. Even if all other devices in a given + environment are secure, this does not prevent external attacks caused + by insecure devices. Recently, the US Federal Communications + Commission (FCC) has stated the need for additional regulation of IoT + systems [FCC]. It is possible that we may see other such regional + regulations in the future. + + + + + + + +Garcia-Morchon, et al. Informational [Page 20] + +RFC 8576 IoT Security April 2019 + + +5. Challenges for a Secure IoT + + In this section, we take a closer look at the various security + challenges in the operational and technical features of IoT and then + discuss how existing Internet security protocols cope with these + technical and conceptual challenges through the lifecycle of a thing. + This discussion should not be understood as a comprehensive + evaluation of all protocols, nor can it cover all possible aspects of + IoT security. Yet, it aims at showing concrete limitations and + challenges in some IoT design areas rather than giving an abstract + discussion. In this regard, the discussion handles issues that are + most important from the authors' perspectives. + +5.1. Constraints and Heterogeneous Communication + + Coupling resource-constrained networks and the powerful Internet is a + challenge, because the resulting heterogeneity of both networks + complicates protocol design and system operation. In the following + subsections, we briefly discuss the resource constraints of IoT + devices and the consequences for the use of Internet protocols in the + IoT domain. + +5.1.1. Resource Constraints + + IoT deployments are often characterized by lossy and low-bandwidth + communication channels. IoT devices are also often constrained in + terms of the CPU, memory, and energy budget available [RFC7228]. + These characteristics directly impact the design of protocols for the + IoT domain. For instance, small packet-size limits at the physical + layer (127 Bytes in IEEE 802.15.4) can lead to (i) hop-by-hop + fragmentation and reassembly or (ii) small IP-layer maximum + transmission unit (MTU). In the first case, excessive fragmentation + of large packets that are often required by security protocols may + open new attack vectors for state-exhaustion attacks. The second + case might lead to more fragmentation at the IP layer, which commonly + downgrades the overall system performance due to packet loss and the + need for retransmission. + + The size and number of messages should be minimized to reduce memory + requirements and optimize bandwidth usage. In this context, layered + approaches involving a number of protocols might lead to worse + performance in resource-constrained devices since they combine the + headers of the different protocols. In some settings, protocol + negotiation can increase the number of exchanged messages. To + improve performance during basic procedures such as, for example, + bootstrapping, it might be a good strategy to perform those + procedures at a lower layer. + + + + +Garcia-Morchon, et al. Informational [Page 21] + +RFC 8576 IoT Security April 2019 + + + Small CPUs and scarce memory limit the usage of resource-expensive + cryptographic primitives such as public key cryptography as used in + most Internet security standards. This is especially true if the + basic cryptographic blocks need to be frequently used or the + underlying application demands low delay. + + There are ongoing efforts to reduce the resource consumption of + security protocols by using more efficient underlying cryptographic + primitives such as Elliptic Curve Cryptography (ECC) [RFC8446]. The + specification of elliptic curve X25519 [ecc25519], stream ciphers + such as ChaCha [ChaCha], Diet HIP [HIP-DEX], and ECC groups for IKEv2 + [RFC5903] are all examples of efforts to make security protocols more + resource efficient. Additionally, most modern security protocols + have been revised in the last few years to enable cryptographic + agility, making cryptographic primitives interchangeable. However, + these improvements are only a first step in reducing the computation + and communication overhead of Internet protocols. The question + remains if other approaches can be applied to leverage key agreement + in these heavily resource-constrained environments. + + A further fundamental need refers to the limited energy budget + available to IoT nodes. Careful protocol (re)design and usage are + required to reduce not only the energy consumption during normal + operation but also under DoS attacks. Since the energy consumption + of IoT devices differs from other device classes, judgments on the + energy consumption of a particular protocol cannot be made without + tailor-made IoT implementations. + +5.1.2. Denial-of-Service Resistance + + The tight memory and processing constraints of things naturally + alleviate resource-exhaustion attacks. Especially in unattended T2T + communication, such attacks are difficult to notice before the + service becomes unavailable (for example, because of battery or + memory exhaustion). As a DoS countermeasure, DTLS, IKEv2, HIP, and + Diet HIP implement return routability checks based on a cookie + mechanism to delay the establishment of state at the responding host + until the address of the initiating host is verified. The + effectiveness of these defenses strongly depends on the routing + topology of the network. Return routability checks are particularly + effective if hosts cannot receive packets addressed to other hosts + and if IP addresses present meaningful information as is the case in + today's Internet. However, they are less effective in broadcast + media or when attackers can influence the routing and addressing of + hosts (for example, if hosts contribute to the routing infrastructure + in ad hoc networks and meshes). + + + + + +Garcia-Morchon, et al. Informational [Page 22] + +RFC 8576 IoT Security April 2019 + + + In addition, HIP implements a puzzle mechanism that can force the + initiator of a connection (and potential attacker) to solve + cryptographic puzzles with variable difficulties. Puzzle-based + defense mechanisms are less dependent on the network topology but + perform poorly if CPU resources in the network are heterogeneous (for + example, if a powerful Internet host attacks a thing). Increasing + the puzzle difficulty under attack conditions can easily lead to + situations where a powerful attacker can still solve the puzzle while + weak IoT clients cannot and are excluded from communicating with the + victim. Still, puzzle-based approaches are a viable option for + sheltering IoT devices against unintended overload caused by + misconfiguration or malfunctioning things. + +5.1.3. End-to-End Security, Protocol Translation, and the Role of + Middleboxes + + The term "end-to-end security" often has multiple interpretations. + Here, we consider end-to-end security in the context of end-to-end IP + connectivity from a sender to a receiver. Services such as + confidentiality and integrity protection on packet data, message + authentication codes, or encryption are typically used to provide + end-to-end security. These protection methods render the protected + parts of the packets immutable as rewriting is either not possible + because (i) the relevant information is encrypted and inaccessible to + the gateway or (ii) rewriting integrity-protected parts of the packet + would invalidate the end-to-end integrity protection. + + Protocols for constrained IoT networks are not exactly identical to + their larger Internet counterparts, for efficiency and performance + reasons. Hence, more or less subtle differences between protocols + for constrained IoT networks and Internet protocols will remain. + While these differences can be bridged with protocol translators at + middleboxes, they may become major obstacles if end-to-end security + measures between IoT devices and Internet hosts are needed. + + If access to data or messages by the middleboxes is required or + acceptable, then a diverse set of approaches for handling such a + scenario is available. Note that some of these approaches affect the + meaning of end-to-end security in terms of integrity and + confidentiality, since the middleboxes will be able to either decrypt + or partially modify the exchanged messages: + + 1. Sharing credentials with middleboxes enables them to transform + (for example, decompress, convert, etc.) packets and reapply the + security measures after transformation. This method abandons + end-to-end security and is only applicable to simple scenarios + with a rudimentary security model. + + + + +Garcia-Morchon, et al. Informational [Page 23] + +RFC 8576 IoT Security April 2019 + + + 2. Reusing the Internet wire format for IoT makes conversion between + IoT and Internet protocols unnecessary. However, it can lead to + poor performance in some use cases because IoT-specific + optimizations (for example, stateful or stateless compression) + are not possible. + + 3. Selectively protecting vital and immutable packet parts with a + message authentication code or encryption requires a careful + balance between performance and security. Otherwise, this + approach might either result in poor performance or poor + security, depending on which parts are selected for protection, + where they are located in the original packet, and how they are + processed. [OSCORE] proposes a solution in this direction by + encrypting and integrity protecting most of the message fields + except those parts that a middlebox needs to read or change. + + 4. Homomorphic encryption techniques can be used in the middlebox to + perform certain operations. However, this is limited to data + processing involving arithmetic operations. Furthermore, the + performance of existing libraries -- for example, Microsoft SEAL + [SEAL] -- is still too limited, and homomorphic encryption + techniques are not widely applicable yet. + + 5. Message authentication codes that sustain transformation can be + realized by considering the order of transformation and + protection (for example, by creating a signature before + compression so that the gateway can decompress the packet without + recalculating the signature). Such an approach enables IoT- + specific optimizations but is more complex and may require + application-specific transformations before security is applied. + Moreover, the usage of encrypted or integrity-protected data + prevents middleboxes from transforming packets. + + 6. Mechanisms based on object security can bridge the protocol + worlds but still require that the two worlds use the same object- + security formats. Currently, the object-security format based on + COSE [RFC8152] is different from JSON Object Signing and + Encryption (JOSE) [RFC7520] or Cryptographic Message Syntax (CMS) + [RFC5652]. Legacy devices relying on traditional Internet + protocols will need to update to the newer protocols for + constrained environments to enable real end-to-end security. + Furthermore, middleboxes do not have any access to the data, and + this approach does not prevent an attacker who is capable of + modifying relevant message header fields that are not protected. + + + + + + + +Garcia-Morchon, et al. Informational [Page 24] + +RFC 8576 IoT Security April 2019 + + + To the best of our knowledge, none of the mentioned security + approaches that focus on the confidentiality and integrity of the + communication exchange between two IP endpoints provide the perfect + solution in this problem space. + +5.1.4. New Network Architectures and Paradigm + + There is a multitude of new link-layer protocols that aim to address + the resource-constrained nature of IoT devices. For example, IEEE + 802.11ah [IEEE802ah] has been specified for extended range and lower + energy consumption to support IoT devices. Similarly, LPWAN + protocols such as LoRa [LoRa], Sigfox [sigfox], and NarrowBand IoT + (NB-IoT) [NB-IoT] are all designed for resource-constrained devices + that require long range and low bit rates. [RFC8376] provides an + informational overview of the set of LPWAN technologies being + considered by the IETF. It also identifies the potential gaps that + exist between the needs of those technologies and the goal of running + IP in such networks. While these protocols allow IoT devices to + conserve energy and operate efficiently, they also add additional + security challenges. For example, the relatively small MTU can make + security handshakes with large X509 certificates a significant + overhead. At the same time, new communication paradigms also allow + IoT devices to communicate directly amongst themselves with or + without support from the network. This communication paradigm is + also referred to as Device-to-Device (D2D), Machine-to-Machine (M2M), + or Thing-to-Thing (T2T) communication, and it is motivated by a + number of features such as improved network performance, lower + latency, and lower energy requirements. + +5.2. Bootstrapping of a Security Domain + + Creating a security domain from a set of previously unassociated IoT + devices is a key operation in the lifecycle of a thing in an IoT + network. This aspect is further elaborated and discussed in the + T2TRG draft on bootstrapping [BOOTSTRAP]. + +5.3. Operational Challenges + + After the bootstrapping phase, the system enters the operational + phase. During the operational phase, things can use the state + information created during the bootstrapping phase in order to + exchange information securely. In this section, we discuss the + security challenges during the operational phase. Note that many of + the challenges discussed in Section 5.1 apply during the operational + phase. + + + + + + +Garcia-Morchon, et al. Informational [Page 25] + +RFC 8576 IoT Security April 2019 + + +5.3.1. Group Membership and Security + + Group-key negotiation is an important security service for IoT + communication patterns in which a thing sends some data to multiple + things or data flows from multiple things towards a thing. All + discussed protocols only cover unicast communication and therefore do + not focus on group-key establishment. This applies in particular to + (D)TLS and IKEv2. Thus, a solution is required in this area. A + potential solution might be to use the Diffie-Hellman keys -- which + are used in IKEv2 and HIP to set up a secure unicast link -- for + group Diffie-Hellman key negotiations. However, Diffie-Hellman is a + relatively heavy solution, especially if the group is large. + + Symmetric and asymmetric keys can be used in group communication. + Asymmetric keys have the advantage that they can provide source + authentication. However, doing broadcast encryption with a single + public/private key pair is also not feasible. Although a single + symmetric key can be used to encrypt the communication or compute a + message authentication code, it has inherent risks since the capture + of a single node can compromise the key shared throughout the + network. The usage of symmetric keys also does not provide source + authentication. Another factor to consider is that asymmetric + cryptography is more resource-intensive than symmetric key solutions. + Thus, the security risks and performance trade-offs of applying + either symmetric or asymmetric keys to a given IoT use case need to + be well analyzed according to risk and usability assessments + [RFC8387]. [MULTICAST] is looking at a combination of + confidentiality using a group key and source authentication using + public keys in the same packet. + + Conceptually, solutions that provide secure group communication at + the network layer (IPsec/IKEv2, HIP/Diet HIP) may have an advantage + in terms of the cryptographic overhead when compared to application- + focused security solutions (TLS/DTLS). This is due to the fact that + application-focused solutions require cryptographic operations per + group application, whereas network-layer approaches may allow sharing + secure group associations between multiple applications (for example, + for neighbor discovery and routing or service discovery). Hence, + implementing shared features lower in the communication stack can + avoid redundant security measures. However, it is important to note + that sharing security contexts among different applications involves + potential security threats, e.g., if one of the applications is + malicious and monitors exchanged messages or injects fake messages. + In the case of OSCORE, it provides security for CoAP group + communication as defined in RFC 7390, i.e., based on multicast IP. + If the same security association is reused for each application, then + this solution does not seem to have more cryptographic overhead + compared to IPsec. + + + +Garcia-Morchon, et al. Informational [Page 26] + +RFC 8576 IoT Security April 2019 + + + Several group-key solutions have been developed by the MSEC Working + Group of the IETF [WG-MSEC]. The MIKEY architecture [RFC4738] is one + example. While these solutions are specifically tailored for + multicast and group-broadcast applications in the Internet, they + should also be considered as candidate solutions for group-key + agreement in IoT. The MIKEY architecture, for example, describes a + coordinator entity that disseminates symmetric keys over pair-wise + end-to-end secured channels. However, such a centralized approach + may not be applicable in a distributed IoT environment, where the + choice of one or several coordinators and the management of the group + key is not trivial. + +5.3.2. Mobility and IP Network Dynamics + + It is expected that many things (for example, user devices and + wearable sensors) will be mobile in the sense that they are attached + to different networks during the lifetime of a security association. + Built-in mobility signaling can greatly reduce the overhead of the + cryptographic protocols because unnecessary and costly re- + establishments of the session (possibly including handshake and key + agreement) can be avoided. IKEv2 supports host mobility with the + MOBIKE extension [RFC4555] [RFC4621]. MOBIKE refrains from applying + heavyweight cryptographic extensions for mobility. However, MOBIKE + mandates the use of IPsec tunnel mode, which requires the + transmission of an additional IP header in each packet. + + HIP offers simple yet effective mobility management by allowing hosts + to signal changes to their associations [RFC8046]. However, slight + adjustments might be necessary to reduce the cryptographic costs -- + for example, by making the public key signatures in the mobility + messages optional. Diet HIP does not define mobility yet, but it is + sufficiently similar to HIP and can use the same mechanisms. DTLS + provides some mobility support by relying on a connection ID (CID). + The use of connection IDs can provide all the mobility functionality + described in [Williams] except sending the updated location. The + specific need for IP-layer mobility mainly depends on the scenario in + which the nodes operate. In many cases, mobility supported by means + of a mobile gateway may suffice to enable mobile IoT networks, such + as body-sensor networks. Using message-based application-layer + security solutions such as OSCORE [OSCORE] can also alleviate the + problem of re-establishing lower-layer sessions for mobile nodes. + +5.4. Secure Software Update and Cryptographic Agility + + IoT devices are often expected to stay functional for several years + or decades, even though they might operate unattended with direct + Internet connectivity. Software updates for IoT devices are + therefore required not only for new functionality but also to + + + +Garcia-Morchon, et al. Informational [Page 27] + +RFC 8576 IoT Security April 2019 + + + eliminate security vulnerabilities due to software bugs, design + flaws, or deprecated algorithms. Software bugs might remain even + after careful code review. Implementations of security protocols + might contain (design) flaws. Cryptographic algorithms can also + become insecure due to advances in cryptanalysis. Therefore, it is + necessary that devices that are incapable of verifying a + cryptographic signature are not exposed to the Internet, even + indirectly. + + In his essay, Schneier highlights several challenges that hinder + mechanisms for secure software update of IoT devices + [SchneierSecurity]. First, there is a lack of incentives for + manufacturers, vendors, and others on the supply chain to issue + updates for their devices. Second, parts of the software running on + IoT devices is simply a binary blob without any source code + available. Since the complete source code is not available, no + patches can be written for that piece of code. Lastly, Schneier + points out that even when updates are available, users generally have + to manually download and install them. However, users are never + alerted about security updates, and many times do not have the + necessary expertise to manually administer the required updates. + + The US Federal Trade Commission (FTC) staff report on "Internet of + Things - Privacy & Security in a Connected World" [FTCreport] and the + Article 29 Working Party's "Opinion 8/2014 on the Recent Developments + on the Internet of Things" [Article29] also document the challenges + for secure remote software update of IoT devices. They note that + even providing such a software-update capability may add new + vulnerabilities for constrained devices. For example, a buffer + overflow vulnerability in the implementation of a software update + protocol (TR69) [TR69] and an expired certificate in a hub device + [wink] demonstrate how the software-update process itself can + introduce vulnerabilities. + + Powerful IoT devices that run general-purpose operating systems can + make use of sophisticated software-update mechanisms known from the + desktop world. However, resource-constrained devices typically do + not have any operating system and are often not equipped with a + memory management unit or similar tools. Therefore, they might + require more specialized solutions. + + An important requirement for secure software and firmware updates is + source authentication. Source authentication requires the resource- + constrained things to implement public key signature verification + algorithms. As stated in Section 5.1.1, resource-constrained things + have limited computational capabilities and energy supply available, + which can hinder the amount and frequency of cryptographic processing + that they can perform. In addition to source authentication, + + + +Garcia-Morchon, et al. Informational [Page 28] + +RFC 8576 IoT Security April 2019 + + + software updates might require confidential delivery over a secure + (encrypted) channel. The complexity of broadcast encryption can + force the usage of point-to-point secure links; however, this + increases the duration of a software update in a large system. + Alternatively, it may force the usage of solutions in which the + software update is delivered to a gateway and then distributed to the + rest of the system with a network key. Sending large amounts of data + that later needs to be assembled and verified over a secure channel + can consume a lot of energy and computational resources. Correct + scheduling of the software updates is also a crucial design + challenge. For example, a user of connected light bulbs would not + want them to update and restart at night. More importantly, the user + would not want all the lights to update at the same time. + + Software updates in IoT systems are also needed to update old and + insecure cryptographic primitives. However, many IoT systems, some + of which are already deployed, are not designed with provisions for + cryptographic agility. For example, many devices come with a + wireless radio that has an AES128 hardware coprocessor. These + devices solely rely on the coprocessor for encrypting and + authenticating messages. A software update adding support for new + cryptographic algorithms implemented solely in software might not fit + on these devices due to limited memory, or might drastically hinder + its operational performance. This can lead to the use of old and + insecure software. Therefore, it is important to account for the + fact that cryptographic algorithms would need to be updated and + consider the following when planning for cryptographic agility: + + 1. Would it be secure to use the existing cryptographic algorithms + available on the device for updating with new cryptographic + algorithms that are more secure? + + 2. Will the new software-based implementation fit on the device + given the limited resources? + + 3. Would the normal operation of existing IoT applications on the + device be severely hindered by the update? + + Finally, we would like to highlight the previous and ongoing work in + the area of secure software and firmware updates at the IETF. + [RFC4108] describes how Cryptographic Message Syntax (CMS) [RFC5652] + can be used to protect firmware packages. The IAB has also organized + a workshop to understand the challenges for secure software update of + IoT devices. A summary of the recommendations to the standards + community derived from the discussions during that workshop have been + documented [RFC8240]. A working group called Software Updates for + Internet of Things (SUIT) [WG-SUIT] is currently working on a new + specification to reflect the best current practices for firmware + + + +Garcia-Morchon, et al. Informational [Page 29] + +RFC 8576 IoT Security April 2019 + + + update based on experience from IoT deployments. It is specifically + working on describing an IoT firmware update architecture and + specifying a manifest format that contains metadata about the + firmware update package. Finally, the Trusted Execution Environment + Provisioning Working Group [WG-TEEP] aims at developing a protocol + for lifecycle management of trusted applications running on the + secure area of a processor (Trusted Execution Environment (TEE)). + +5.5. End-of-Life + + Like all commercial devices, IoT devices have a given useful + lifetime. The term "end-of-life" (EOL) is used by vendors or network + operators to indicate the point of time at which they limit or end + support for the IoT device. This may be planned or unplanned (for + example, when the manufacturer goes bankrupt, the vendor just decides + to abandon a product, or a network operator moves to a different type + of networking technology). A user should still be able to use and + perhaps even update the device. This requires for some form of + authorization handover. + + Although this may seem far-fetched given the commercial interests and + market dynamics, we have examples from the mobile world where the + devices have been functional and up to date long after the original + vendor stopped supporting the device. CyanogenMod for Android + devices and OpenWrt for home routers are two such instances where + users have been able to use and update their devices even after the + official EOL. Admittedly, it is not easy for an average user to + install and configure their devices on their own. With the + deployment of millions of IoT devices, simpler mechanisms are needed + to allow users to add new trust anchors [RFC6024] and install + software and firmware from other sources once the device is EOL. + +5.6. Verifying Device Behavior + + Users using new IoT appliances such as Internet-connected smart + televisions, speakers, and cameras are often unaware that these + devices can undermine their privacy. Recent revelations have shown + that many IoT device vendors have been collecting sensitive private + data through these connected appliances with or without appropriate + user warnings [cctv]. + + An IoT device's user/owner would like to monitor and verify its + operational behavior. For instance, the user might want to know if + the device is connecting to the server of the manufacturer for any + reason. This feature -- connecting to the manufacturer's server -- + may be necessary in some scenarios, such as during the initial + configuration of the device. However, the user should be kept aware + + + + +Garcia-Morchon, et al. Informational [Page 30] + +RFC 8576 IoT Security April 2019 + + + of the data that the device is sending back to the vendor. For + example, the user might want to know if his/her TV is sending data + when he/she inserts a new USB stick. + + Providing such information to the users in an understandable fashion + is challenging. This is because IoT devices are not only resource + constrained in terms of their computational capability but also in + terms of the user interface available. Also, the network + infrastructure where these devices are deployed will vary + significantly from one user environment to another. Therefore, where + and how this monitoring feature is implemented still remains an open + question. + + Manufacturer Usage Description (MUD) files [RFC8520] are perhaps a + first step towards implementation of such a monitoring service. The + idea behind MUD files is relatively simple: IoT devices would + disclose the location of their MUD file to the network during + installation. The network can then retrieve those files and learn + about the intended behavior of the devices stated by the device + manufacturer. A network-monitoring service could then warn the user/ + owner of devices if they don't behave as expected. + + Many devices and software services that automatically learn and + monitor the behavior of different IoT devices in a given network are + commercially available. Such monitoring devices/services can be + configured by the user to limit network traffic and trigger alarms + when unexpected operation of IoT devices is detected. + +5.7. Testing: Bug Hunting and Vulnerabilities + + Given that IoT devices often have inadvertent vulnerabilities, both + users and developers would want to perform extensive testing on their + IoT devices, networks, and systems. Nonetheless, since the devices + are resource constrained and manufactured by multiple vendors, some + of them very small, devices might be shipped with very limited + testing, so that bugs can remain and can be exploited at a later + stage. This leads to two main types of challenges: + + 1. It remains to be seen how the software-testing and quality- + assurance mechanisms used from the desktop and mobile world will + be applied to IoT devices to give end users the confidence that + the purchased devices are robust. Bodies such as the European + Cyber Security Organization (ECSO) [ECSO] are working on + processes for security certification of IoT devices. + + 2. It is also an open question how the combination of devices from + multiple vendors might actually lead to dangerous network + configurations -- for example, if the combination of specific + + + +Garcia-Morchon, et al. Informational [Page 31] + +RFC 8576 IoT Security April 2019 + + + devices can trigger unexpected behavior. It is needless to say + that the security of the whole system is limited by its weakest + point. + +5.8. Quantum-Resistance + + Many IoT systems that are being deployed today will remain + operational for many years. With the advancements made in the field + of quantum computers, it is possible that large-scale quantum + computers will be available in the future for performing + cryptanalysis on existing cryptographic algorithms and cipher suites. + If this happens, it will have two consequences. First, + functionalities enabled by means of primitives such as RSA or ECC -- + namely, key exchange, public key encryption, and signature -- would + not be secure anymore due to Shor's algorithm. Second, the security + level of symmetric algorithms will decrease, for example, the + security of a block cipher with a key size of b bits will only offer + b/2 bits of security due to Grover's algorithm. + + The above scenario becomes more urgent when we consider the so-called + "harvest and decrypt" attack in which an attacker can start to + harvest (store) encrypted data today, before a quantum computer is + available, and decrypt it years later, once a quantum computer is + available. Such "harvest and decrypt" attacks are not new and were + used in the VENONA project [venona-project]. Many IoT devices that + are being deployed today will remain operational for a decade or even + longer. During this time, digital signatures used to sign software + updates might become obsolete, making the secure update of IoT + devices challenging. + + This situation would require us to move to quantum-resistant + alternatives -- in particular, for those functionalities involving + key exchange, public key encryption, and signatures. [C2PQ] + describes when quantum computers may become widely available and what + steps are necessary for transitioning to cryptographic algorithms + that provide security even in the presence of quantum computers. + While future planning is hard, it may be a necessity in certain + critical IoT deployments that are expected to last decades or more. + Although increasing the key size of the different algorithms is + definitely an option, it would also incur additional computational + overhead and network traffic. This would be undesirable in most + scenarios. There have been recent advancements in quantum-resistant + cryptography. We refer to [ETSI-GR-QSC-001] for an extensive + overview of existing quantum-resistant cryptography, and [RFC7696] + provides guidelines for cryptographic algorithm agility. + + + + + + +Garcia-Morchon, et al. Informational [Page 32] + +RFC 8576 IoT Security April 2019 + + +5.9. Privacy Protection + + People will eventually be surrounded by hundreds of connected IoT + devices. Even if the communication links are encrypted and + protected, information about people might still be collected or + processed for different purposes. The fact that IoT devices in the + vicinity of people might enable more pervasive monitoring can + negatively impact their privacy. For instance, imagine the scenario + where a static presence sensor emits a packet due to the presence or + absence of people in its vicinity. In such a scenario, anyone who + can observe the packet can gather critical privacy-sensitive + information. + + Such information about people is referred to as personal data in the + European Union (EU) or Personally identifiable information (PII) in + the US. In particular, the General Data Protection Regulation (GDPR) + [GDPR] defines personal data as: "any information relating to an + identified or identifiable natural person ('data subject'); an + identifiable natural person is one who can be identified, directly or + indirectly, in particular by reference to an identifier such as a + name, an identification number, location data, an online identifier + or to one or more factors specific to the physical, physiological, + genetic, mental, economic, cultural or social identity of that + natural person". + + Ziegeldorf [Ziegeldorf] defines privacy in IoT as a threefold + guarantee: + + 1. Awareness of the privacy risks imposed by IoT devices and + services. This awareness is achieved by means of transparent + practices by the data controller, i.e., the entity that is + providing IoT devices and/or services. + + 2. Individual control over the collection and processing of personal + information by IoT devices and services. + + 3. Awareness and control of the subsequent use and dissemination of + personal information by data controllers to any entity outside + the subject's personal control sphere. This point implies that + the data controller must be accountable for its actions on the + personal information. + + Based on this definition, several threats to the privacy of users + have been documented [Ziegeldorf] [RFC6973], in particular + considering the IoT environment and its lifecycle: + + 1. Identification - refers to the identification of the users, their + IoT devices, and generated data. + + + +Garcia-Morchon, et al. Informational [Page 33] + +RFC 8576 IoT Security April 2019 + + + 2. Localization - relates to the capability of locating a user and + even tracking them, e.g., by tracking MAC addresses in Wi-Fi or + Bluetooth. + + 3. Profiling - is about creating a profile of the user and their + preferences. + + 4. Interaction - occurs when a user has been profiled and a given + interaction is preferred, presenting (for example, visually) some + information that discloses private information. + + 5. Lifecycle transitions - take place when devices are, for example, + sold without properly removing private data. + + 6. Inventory attacks - happen if specific information about IoT + devices in possession of a user is disclosed. + + 7. Linkage - is about when information of two of more IoT systems + (or other data sets) is combined so that a broader view of the + personal data captured can be created. + + When IoT systems are deployed, the above issues should be considered + to ensure that private data remains private. These issues are + particularly challenging in environments in which multiple users with + different privacy preferences interact with the same IoT devices. + For example, an IoT device controlled by user A (low privacy + settings) might leak private information about another user B (high + privacy settings). How to deal with these threats in practice is an + area of ongoing research. + +5.10. Reverse-Engineering Considerations + + Many IoT devices are resource constrained and often deployed in + unattended environments. Some of these devices can also be purchased + off the shelf or online without any credential-provisioning process. + Therefore, an attacker can have direct access to the device and apply + advanced techniques to retrieve information that a traditional black- + box model does not consider. Examples of those techniques are side- + channel attacks or code disassembly. By doing this, the attacker can + try to retrieve data such as: + + 1. Long-term keys. These long-term keys can be extracted by means + of a side-channel attack or reverse engineering. If these keys + are exposed, then they might be used to perform attacks on + devices deployed in other locations. + + + + + + +Garcia-Morchon, et al. Informational [Page 34] + +RFC 8576 IoT Security April 2019 + + + 2. Source code. Extraction of source code might allow the attacker + to determine bugs or find exploits to perform other types of + attacks. The attacker might also just sell the source code. + + 3. Proprietary algorithms. The attacker can analyze these + algorithms gaining valuable know-how. The attacker can also + create copies of the product (based on those proprietary + algorithms) or modify the algorithms to perform more advanced + attacks. + + 4. Configuration or personal data. The attacker might be able to + read personal data, e.g., healthcare data, that has been stored + on a device. + + One existing solution to prevent such data leaks is the use of a + secure element, a tamper-resistant device that is capable of securely + hosting applications and their confidential data. Another potential + solution is the usage of a Physical Unclonable Function (PUF) that + serves as unique digital fingerprint of a hardware device. PUFs can + also enable other functionalities such as secure key storage. + Protection against such data leakage patterns is not trivial since + devices are inherently resource-constrained. An open question is + whether there are any viable techniques to protect IoT devices and + the data in the devices in such an adversarial model. + +5.11. Trustworthy IoT Operation + + Flaws in the design and implementation of IoT devices and networks + can lead to security vulnerabilities. A common flaw is the use of + well-known or easy-to-guess passwords for configuration of IoT + devices. Many such compromised IoT devices can be found on the + Internet by means of tools such as Shodan [shodan]. Once discovered, + these compromised devices can be exploited at scale -- for example, + to launch DDoS attacks. Dyn, a major DNS service provider, was + attacked by means of a DDoS attack originating from a large IoT + botnet composed of thousands of compromised IP cameras [Dyn-Attack]. + There are several open research questions in this area: + + 1. How to avoid vulnerabilities in IoT devices that can lead to + large-scale attacks? + + 2. How to detect sophisticated attacks against IoT devices? + + 3. How to prevent attackers from exploiting known vulnerabilities at + a large scale? + + + + + + +Garcia-Morchon, et al. Informational [Page 35] + +RFC 8576 IoT Security April 2019 + + + Some ideas are being explored to address this issue. One of the + approaches relies on the use of Manufacturer Usage Description (MUD) + files [RFC8520]. As explained earlier, this proposal requires IoT + devices to disclose the location of their MUD file to the network + during installation. The network can then (i) retrieve those files, + (ii) learn from the manufacturers the intended usage of the devices + (for example, which services they need to access), and then (iii) + create suitable filters and firewall rules. + +6. Conclusions and Next Steps + + This document provides IoT security researchers, system designers, + and implementers with an overview of security requirements in the IP- + based Internet of Things. We discuss the security threats, state of + the art, and challenges. + + Although plenty of steps have been realized during the last few years + (summarized in Section 4.1) and many organizations are publishing + general recommendations describing how IoT should be secured + (Section 4.3), there are many challenges ahead that require further + attention. Challenges of particular importance are bootstrapping of + security, group security, secure software updates, long-term security + and quantum-resistance, privacy protection, data leakage prevention + -- where data could be cryptographic keys, personal data, or even + algorithms -- and ensuring trustworthy IoT operation. + + Authors of new IoT specifications and implementers need to consider + how all the security challenges discussed in this document (and those + that emerge later) affect their work. The authors of IoT + specifications need to put in a real effort towards not only + addressing the security challenges but also clearly documenting how + the security challenges are addressed. This would reduce the chances + of security vulnerabilities in the code written by implementers of + those specifications. + +7. Security Considerations + + This entire memo deals with security issues. + +8. IANA Considerations + + This document has no IANA actions. + + + + + + + + + +Garcia-Morchon, et al. Informational [Page 36] + +RFC 8576 IoT Security April 2019 + + +9. Informative References + + [ACE-DTLS] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and + L. Seitz, "Datagram Transport Layer Security (DTLS) + Profile for Authentication and Authorization for + Constrained Environments (ACE)", Work in Progress, + draft-ietf-ace-dtls-authorize-08, April 2019. + + [ACE-OAuth] + Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and + H. Tschofenig, "Authentication and Authorization for + Constrained Environments (ACE) using the OAuth 2.0 + Framework (ACE-OAuth)", Work in Progress, draft-ietf-ace- + oauth-authz-24, March 2019. + + [ARCH-6TiSCH] + Thubert, P., "An Architecture for IPv6 over the TSCH mode + of IEEE 802.15.4", Work in Progress, draft-ietf-6tisch- + architecture-20, March 2019. + + [Article29] + Article 29 Data Protection Working Party, "Opinion 8/2014 + on the Recent Developments on the Internet of Things", + WP 223, September 2014, <https://ec.europa.eu/justice/ + article-29/documentation/opinion- + recommendation/files/2014/wp223_en.pdf>. + + [AUTO-ID] "Auto-ID Labs", September 2010, + <https://www.autoidlabs.org/>. + + [BACNET] American Society of Heating, Refrigerating and Air- + Conditioning Engineers (ASHRAE), "BACnet", February 2011, + <http://www.bacnet.org>. + + [BITAG] Broadband Internet Technical Advisory Group, "Internet of + Things (IoT) Security and Privacy Recommendations", + November 2016, <https://www.bitag.org/report-internet-of- + things-security-privacy-recommendations.php>. + + [BOOTSTRAP] + Sarikaya, B., Sethi, M., and D. Garcia-Carillo, "Secure + IoT Bootstrapping: A Survey", Work in Progress, + draft-sarikaya-t2trg-sbootstrapping-06, January 2019. + + [C2PQ] Hoffman, P., "The Transition from Classical to Post- + Quantum Cryptography", Work in Progress, draft-hoffman- + c2pq-04, August 2018. + + + + +Garcia-Morchon, et al. Informational [Page 37] + +RFC 8576 IoT Security April 2019 + + + [cctv] "Backdoor In MVPower DVR Firmware Sends CCTV Stills To an + Email Address In China", February 2016, + <https://hardware.slashdot.org/story/16/02/17/0422259/ + backdoor-in-mvpower-dvr-firmware-sends-cctv-stills-to-an- + email-address-in-china>. + + [ChaCha] Bernstein, D., "ChaCha, a variant of Salsa20", January + 2008, <http://cr.yp.to/chacha/chacha-20080128.pdf>. + + [CSA] Cloud Security Alliance Mobile Working Group, "Security + Guidance for Early Adopters of the Internet of Things + (IoT)", April 2015, + <https://downloads.cloudsecurityalliance.org/whitepapers/S + ecurity_Guidance_for_Early_Adopters_of_the_Internet_of_Thi + ngs.pdf>. + + [DALI] DALIbyDesign, "DALI Explained", February 2011, + <http://www.dalibydesign.us/dali.html>. + + [Daniel] Park, S., Kim, K., Haddad, W., Chakrabarti, S., and J. + Laganier, "IPv6 over Low Power WPAN Security Analysis", + Work in Progress, draft-daniel-6lowpan-security-analysis- + 05, March 2011. + + [DCMS] UK Department for Digital Culture, Media & Sport, "Secure + by Design: Improving the cyber security of consumer + Internet of Things Report", March 2018, + <https://www.gov.uk/government/publications/ + secure-by-design-report>. + + [DHS] U.S. Department of Homeland Security, "Strategic + Principles For Securing the Internet of Things (IoT)", + November 2016, + <https://www.dhs.gov/sites/default/files/publications/ + Strategic_Principles_for_Securing_the_Internet_of_Things- + 2016-1115-FINAL....pdf>. + + [Diet-ESP] Migault, D., Guggemos, T., Bormann, C., and D. Schinazi, + "ESP Header Compression and Diet-ESP", Work in Progress, + draft-mglt-ipsecme-diet-esp-07, March 2019. + + [Dyn-Attack] + Oracle Dyn, "Dyn Analysis Summary Of Friday October 21 + Attack", October 2016, <https://dyn.com/blog/ + dyn-analysis-summary-of-friday-october-21-attack/>. + + + + + + +Garcia-Morchon, et al. Informational [Page 38] + +RFC 8576 IoT Security April 2019 + + + [ecc25519] Bernstein, D., "Curve25519: new Diffie-Hellman speed + records", February 2006, + <https://cr.yp.to/ecdh/curve25519-20060209.pdf>. + + [ECSO] "European Cyber Security Organisation", + <https://www.ecs-org.eu/>. + + [ENISA-ICS] + European Union Agency for Network and Information + Security, "Communication network dependencies for ICS/ + SCADA Systems", February 2017, + <https://www.enisa.europa.eu/publications/ + ics-scada-dependencies>. + + [ETSI-GR-QSC-001] + European Telecommunications Standards Institute (ETSI), + "Quantum-Safe Cryptography (QSC); Quantum-safe algorithmic + framework", ETSI GR QSC 001, July 2016, + <https://www.etsi.org/deliver/etsi_gr/ + QSC/001_099/001/01.01.01_60/gr_qsc001v010101p.pdf>. + + [Fairhair] "The Fairhair Alliance", + <https://www.fairhair-alliance.org/>. + + [FCC] US Federal Communications Commission, Chairman Tom Wheeler + to Senator Mark Warner, December 2016, + <https://docs.fcc.gov/public/attachments/ + DOC-342761A1.pdf>. + + [FTCreport] + US Federal Trade Commission, "FTC Report on Internet of + Things Urges Companies to Adopt Best Practices to Address + Consumer Privacy and Security Risks", January 2015, + <https://www.ftc.gov/news-events/press-releases/2015/01/ + ftc-report-internet-things-urges-companies-adopt-best- + practices>. + + [GDPR] "The EU General Data Protection Regulation", + <https://www.eugdpr.org>. + + [GSMAsecurity] + "GSMA IoT Security Guidelines and Assessment", + <http://www.gsma.com/connectedliving/future-iot-networks/ + iot-security-guidelines>. + + [HIP-DEX] Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", + Work in Progress, draft-ietf-hip-dex-06, December 2017. + + + + +Garcia-Morchon, et al. Informational [Page 39] + +RFC 8576 IoT Security April 2019 + + + [IEEE802ah] + IEEE, "Status of Project IEEE 802.11ah", IEEE P802.11 - + Task Group AH - Meeting Update, + <http://www.ieee802.org/11/Reports/tgah_update.htm>. + + [IIoT] "Industrial Internet Consortium", + <http://www.iiconsortium.org>. + + [IoTSecFoundation] + Internet of Things Security Foundation, "Establishing + Principles for Internet of Things Security", + <https://iotsecurityfoundation.org/establishing- + principles-for-internet-of-things-security>. + + [IPv6-over-NFC] + Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, + "Transmission of IPv6 Packets over Near Field + Communication", Work in Progress, draft-ietf-6lo-nfc-13, + February 2019. + + [ISOC-OTA] Internet Society, "Online Trust Alliance (OTA)", + <https://www.internetsociety.org/ota/>. + + [LoRa] "LoRa Alliance", <https://www.lora-alliance.org/>. + + [LWM2M] OMA SpecWorks, "Lightweight M2M (LWM2M)", + <http://openmobilealliance.org/iot/lightweight-m2m-lwm2m>. + + [Mirai] Kolias, C., Kambourakis, G., Stavrou, A., and J. Voas,, + "DDoS in the IoT: Mirai and Other Botnets", Computer, + Vol. 50, Issue 7, DOI 10.1109/MC.2017.201, July 2017, + <https://ieeexplore.ieee.org/document/7971869>. + + [Moore] Moore, K., Barnes, R., and H. Tschofenig, "Best Current + Practices for Securing Internet of Things (IoT) Devices", + Work in Progress, draft-moore-iot-security-bcp-01, July + 2017. + + [MULTICAST] + Tiloca, M., Selander, G., Palombini, F., and J. Park, + "Group OSCORE - Secure Group Communication for CoAP", Work + in Progress, draft-ietf-core-oscore-groupcomm-04, March + 2019. + + [NB-IoT] Qualcomm Incorporated, "New Work Item: NarrowBand IOT (NB- + IOT)", September 2015, + <http://www.3gpp.org/ftp/tsg_ran/TSG_RAN/TSGR_69/Docs/ + RP-151621.zip>. + + + +Garcia-Morchon, et al. Informational [Page 40] + +RFC 8576 IoT Security April 2019 + + + [NHTSA] National Highway Traffic Safety Administration, + "Cybersecurity Best Practices for Modern Vehicles", Report + No. DOT HS 812 333, October 2016, + <https://www.nhtsa.gov/staticfiles/nvs/ + pdf/812333_CybersecurityForModernVehicles.pdf>. + + [NIST-Guide] + Ross, R., McEvilley, M., and J. Oren, "Systems Security + Engineering: Considerations for a Multidisciplinary + Approach in the Engineering of Trustworthy Secure + Systems", NIST Special Publication 800-160, + DOI 10.6028/NIST.SP.800-160, November 2016, + <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ + NIST.SP.800\ -160.pdf>. + + [NIST-LW-2016] + Sonmez Turan, M., "NIST's Lightweight Crypto Project", + October 2016, <https://www.nist.gov/sites/default/files/ + documents/2016/10/17/ + sonmez-turan-presentation-lwc2016.pdf>. + + [NIST-LW-PROJECT] + NIST, "Lightweight Cryptography", <https://www.nist.gov/ + programs-projects/lightweight-cryptography>. + + [NISTSP800-122] + McCallister, E., Grance, T., and K. Scarfone, "Guide to + Protecting the Confidentiality of Personally Identifiable + Information (PII)", NIST Special Publication 800-122, + April 2010, <https://nvlpubs.nist.gov/nistpubs/legacy/sp/ + nistspecialpublication800-122.pdf>. + + [NISTSP800-30r1] + National Institute of Standards and Technology, "Guide for + Conducting Risk Assessments", NIST Special + Publication 800-30 Revision 1, September 2012, + <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ + nistspecialpublication800-30r1.pdf>. + + [NISTSP800-34r1] + Swanson, M., Bowen, P., Phillips, A., Gallup, D., and D. + Lynes, "Contingency Planning Guide for Federal Information + Systems", NIST Special Publication 800-34 Revision 1, May + 2010, <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/ + nistspecialpublication800-34r1.pdf>. + + [OCF] "Open Connectivity Foundation", + <https://openconnectivity.org/>. + + + +Garcia-Morchon, et al. Informational [Page 41] + +RFC 8576 IoT Security April 2019 + + + [OMASpecWorks] + "OMA SpecWorks", + <https://www.omaspecworks.org/ipso-alliance>. + + [OneM2M] "OneM2M", <http://www.onem2m.org>. + + [OSCORE] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, + "Object Security for Constrained RESTful Environments + (OSCORE)", Work in Progress, draft-ietf-core-object- + security-16, March 2019. + + [OWASP] The OWASP Foundation, "IoT Security Guidance", February + 2017, + <https://www.owasp.org/index.php/IoT_Security_Guidance>. + + [RD] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. + Amsuess, Ed., "CoRE Resource Directory", Work in + Progress, draft-ietf-core-resource-directory-20, March + 2019. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, + DOI 10.17487/RFC2818, May 2000, + <https://www.rfc-editor.org/info/rfc2818>. + + [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>. + + [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to + Protect Firmware Packages", RFC 4108, + DOI 10.17487/RFC4108, August 2005, + <https://www.rfc-editor.org/info/rfc4108>. + + + + +Garcia-Morchon, et al. Informational [Page 42] + +RFC 8576 IoT Security April 2019 + + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + DOI 10.17487/RFC4120, July 2005, + <https://www.rfc-editor.org/info/rfc4120>. + + [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple + Authentication and Security Layer (SASL)", RFC 4422, + DOI 10.17487/RFC4422, June 2006, + <https://www.rfc-editor.org/info/rfc4422>. + + [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>. + + [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>. + + [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, + RFC 5652, DOI 10.17487/RFC5652, September 2009, + <https://www.rfc-editor.org/info/rfc5652>. + + + + + + + +Garcia-Morchon, et al. Informational [Page 43] + +RFC 8576 IoT Security April 2019 + + + [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>. + + [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management + Requirements", RFC 6024, DOI 10.17487/RFC6024, October + 2010, <https://www.rfc-editor.org/info/rfc6024>. + + [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart + Grid", RFC 6272, DOI 10.17487/RFC6272, June 2011, + <https://www.rfc-editor.org/info/rfc6272>. + + [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>. + + [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>. + + + +Garcia-Morchon, et al. Informational [Page 44] + +RFC 8576 IoT Security April 2019 + + + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., + Morris, J., Hansen, M., and R. Smith, "Privacy + Considerations for Internet Protocols", RFC 6973, + DOI 10.17487/RFC6973, July 2013, + <https://www.rfc-editor.org/info/rfc6973>. + + [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>. + + [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for + Constrained-Node Networks", RFC 7228, + DOI 10.17487/RFC7228, May 2014, + <https://www.rfc-editor.org/info/rfc7228>. + + [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>. + + [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>. + + [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", + RFC 7516, DOI 10.17487/RFC7516, May 2015, + <https://www.rfc-editor.org/info/rfc7516>. + + [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>. + + + + + + +Garcia-Morchon, et al. Informational [Page 45] + +RFC 8576 IoT Security April 2019 + + + [RFC7520] Miller, M., "Examples of Protecting Content Using JSON + Object Signing and Encryption (JOSE)", RFC 7520, + DOI 10.17487/RFC7520, May 2015, + <https://www.rfc-editor.org/info/rfc7520>. + + [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>. + + [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., + and S. Kumar, "Use Cases for Authentication and + Authorization in Constrained Environments", RFC 7744, + DOI 10.17487/RFC7744, January 2016, + <https://www.rfc-editor.org/info/rfc7744>. + + [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>. + + [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility + with the Host Identity Protocol", RFC 8046, + DOI 10.17487/RFC8046, February 2017, + <https://www.rfc-editor.org/info/rfc8046>. + + [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, + M., and D. Barthel, "Transmission of IPv6 Packets over + Digital Enhanced Cordless Telecommunications (DECT) Ultra + Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May + 2017, <https://www.rfc-editor.org/info/rfc8105>. + + [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", + RFC 8152, DOI 10.17487/RFC8152, July 2017, + <https://www.rfc-editor.org/info/rfc8152>. + + + + + +Garcia-Morchon, et al. Informational [Page 46] + +RFC 8576 IoT Security April 2019 + + + [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet + of Things Software Update (IoTSU) Workshop 2016", + RFC 8240, DOI 10.17487/RFC8240, September 2017, + <https://www.rfc-editor.org/info/rfc8240>. + + [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data + Interchange Format", STD 90, RFC 8259, + DOI 10.17487/RFC8259, December 2017, + <https://www.rfc-editor.org/info/rfc8259>. + + [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) + Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, + <https://www.rfc-editor.org/info/rfc8376>. + + [RFC8387] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical + Considerations and Implementation Experiences in Securing + Smart Object Networks", RFC 8387, DOI 10.17487/RFC8387, + May 2018, <https://www.rfc-editor.org/info/rfc8387>. + + [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. + Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, + DOI 10.17487/RFC8428, August 2018, + <https://www.rfc-editor.org/info/rfc8428>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage + Description Specification", RFC 8520, + DOI 10.17487/RFC8520, March 2019, + <https://www.rfc-editor.org/info/rfc8520>. + + [RG-T2TRG] IRTF, "Thing-to-Thing Research Group (T2TRG)", + <https://datatracker.ietf.org/rg/t2trg/charter/>. + + [SchneierSecurity] + Schneier, B., "The Internet of Things Is Wildly Insecure + -- And Often Unpatchable", January 2014, + <https://www.schneier.com/essays/archives/2014/01/ + the_internet_of_thin.html>. + + [SEAL] Microsoft, "Microsoft SEAL: Fast and Easy-to-Use + Homomorphic Encryption Library", + <https://www.microsoft.com/en-us/research/project/ + microsoft-seal/>. + + [shodan] "Shodan", <https://www.shodan.io>. + + + +Garcia-Morchon, et al. Informational [Page 47] + +RFC 8576 IoT Security April 2019 + + + [sigfox] "Sigfox - The Global Communications Service Provider for + the Internet of Things (IoT)", <https://www.sigfox.com>. + + [Thread] "Thread", <http://threadgroup.org>. + + [TR69] Oppenheim, L. and S. Tal, "Too Many Cooks - Exploiting the + Internet-of-TR-069-Things", December 2014, + <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>. + + [venona-project] + National Security Agency | Central Security Service, + "VENONA", <https://www.nsa.gov/news-features/declassified- + documents/venona/index.shtml>. + + [WG-6lo] IETF, "IPv6 over Networks of Resource-constrained Nodes + (6lo)", <https://datatracker.ietf.org/wg/6lo/charter/>. + + [WG-6LoWPAN] + IETF, "IPv6 over Low power WPAN (6lowpan)", + <http://datatracker.ietf.org/wg/6lowpan/charter/>. + + [WG-ACE] IETF, "Authentication and Authorization for Constrained + Environments (ace)", + <https://datatracker.ietf.org/wg/ace/charter/>. + + [WG-ACME] IETF, "Automated Certificate Management Environment + (acme)", <https://datatracker.ietf.org/wg/acme/charter/>. + + [WG-CoRE] IETF, "Constrained RESTful Environment (core)", + <https://datatracker.ietf.org/wg/core/charter/>. + + [WG-LPWAN] IETF, "IPv6 over Low Power Wide-Area Networks (lpwan)", + <https://datatracker.ietf.org/wg/lpwan/charter/>. + + [WG-LWIG] IETF, "Light-Weight Implementation Guidance (lwig)", + <https://datatracker.ietf.org/wg/lwig/charter/>. + + [WG-MSEC] IETF, "Multicast Security (msec)", + <https://datatracker.ietf.org/wg/msec/charter/>. + + [WG-SUIT] IETF, "Software Updates for Internet of Things (suit)", + <https://datatracker.ietf.org/wg/suit/charter/>. + + [WG-TEEP] IETF, "Trusted Execution Environment Provisioning (teep)", + <https://datatracker.ietf.org/wg/teep/charter/>. + + + + +Garcia-Morchon, et al. Informational [Page 48] + +RFC 8576 IoT Security April 2019 + + + [Williams] Williams, M. and J. Barrett, "Mobile DTLS", Work in + Progress, draft-barrett-mobile-dtls-00, March 2009. + + [wink] Barrett, B., "Wink's Outage Shows Us How Frustrating Smart + Homes Could Be", Wired, Gear, April 2015, + <http://www.wired.com/2015/04/smart-home-headaches/>. + + [ZB] "Zigbee Alliance", <http://www.zigbee.org/>. + + [Ziegeldorf] + Ziegeldorf, J., Garcia Morchon, O., and K. Wehrle, + "Privacy in the Internet of Things: Threats and + Challenges", Security and Communication Networks, Vol. 7, + Issue 12, pp. 2728-2742, DOI 10.1002/sec.795, 2014. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Garcia-Morchon, et al. Informational [Page 49] + +RFC 8576 IoT Security April 2019 + + +Acknowledgments + + We gratefully acknowledge feedback and fruitful discussion with + Tobias Heer, Robert Moskowitz, Thorsten Dahm, Hannes Tschofenig, + Carsten Bormann, Barry Raveendran, Ari Keranen, Goran Selander, Fred + Baker, Vicent Roca, Thomas Fossati, and Eliot Lear. We acknowledge + the additional authors of a draft version of this document: Sye Loong + Keoh, Rene Hummen, and Rene Struik. + +Authors' Addresses + + Oscar Garcia-Morchon + Philips + High Tech Campus 5 + Eindhoven, 5656 AE + The Netherlands + + Email: oscar.garcia-morchon@philips.com + + + Sandeep S. Kumar + Signify + High Tech Campus 7 + Eindhoven, 5656 AE + The Netherlands + + Email: sandeep.kumar@signify.com + + + Mohit Sethi + Ericsson + Jorvas 02420 + Finland + + Email: mohit@piuha.net + + + + + + + + + + + + + + + + +Garcia-Morchon, et al. Informational [Page 50] + |