Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8576

Internet of Things (IoT) Security: State of the Art and Challenges

Pages: 50
Informational
Part 1 of 3 – Pages 1 to 20
None   None   Next

Top   ToC   RFC8576 - Page 1
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).
Top   ToC   RFC8576 - Page 2
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.
Top   ToC   RFC8576 - Page 3

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
Top   ToC   RFC8576 - Page 4

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
Top   ToC   RFC8576 - Page 5
   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
Top   ToC   RFC8576 - Page 6
   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.
Top   ToC   RFC8576 - Page 7
    _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
Top   ToC   RFC8576 - Page 8
   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
Top   ToC   RFC8576 - Page 9
        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.
Top   ToC   RFC8576 - Page 10
   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.
Top   ToC   RFC8576 - Page 11
   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.
Top   ToC   RFC8576 - Page 12
   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].
Top   ToC   RFC8576 - Page 13

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
Top   ToC   RFC8576 - Page 14
   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.
Top   ToC   RFC8576 - Page 15
   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.
Top   ToC   RFC8576 - Page 16
   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
Top   ToC   RFC8576 - Page 17
   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.
Top   ToC   RFC8576 - Page 18
   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.
Top   ToC   RFC8576 - Page 19
   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
Top   ToC   RFC8576 - Page 20
        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.


(next page on part 2)

Next Section