    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]