INFORMATIONAL

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 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 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 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 2 . The Thing Lifecycle 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 Garcia-Morchon, et al. Informational [Page 6]

RFC 8576 IoT Security April 2019 Garcia-Morchon, et al. Informational [Page 7]

RFC 8576 IoT Security April 2019 3 . Security Threats and Managing Risk 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 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 Garcia-Morchon, et al. Informational [Page 10]

RFC 8576 IoT Security April 2019 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 4 . State of the Art 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 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 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 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 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 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 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 4.3 . 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 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 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 5.1 . Constraints and Heterogeneous Communication 5.1.1 . Resource Constraints 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 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 Garcia-Morchon, et al. Informational [Page 22]

RFC 8576 IoT Security April 2019 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 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 5.1.4 . New Network Architectures and Paradigm 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 BOOTSTRAP]. 5.3 . Operational Challenges 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 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 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 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 Garcia-Morchon, et al. Informational [Page 27]

RFC 8576 IoT Security April 2019 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 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 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 RFC6024] and install software and firmware from other sources once the device is EOL. 5.6 . Verifying Device Behavior 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 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 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 5.8 . Quantum-Resistance 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 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 5.11 . Trustworthy IoT Operation 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 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 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 8 . IANA Considerations 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 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 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]