RFC 8576

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

📅 published April 2019, from ietf

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

okay bestie, let's do the vibe check first 💖 This is RFC 8576, titled Internet of Things (IoT) Security: State of the Art and Challenges ✨ It's an Informational doc from the Internet Research Task Force (IRTF) 📜 It was written by O. Garcia-Morchon (Philips), S. Kumar (Signify), and M. Sethi (Ericsson), and it's dated April 2019 🌸 Its ISSN is 2070-1721. The title block has no Obsoletes or Updates entries, so it doesn't list any RFCs it replaces or changes 🦋

   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

Abstract 💅

okay so the whole IoT idea is basically using normal Internet protocols so humans can talk to things and things can talk to other things 🧚 Security for this stuff is a big deal and people have been working on it for ages. Think of the Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (DTLS) 💜 But ngl, there are still challenges. Some use cases don't have a good solution yet, and a lot of IoT devices and systems were built and shipped with super limited security 😭 This document goes through the stages in a thing's lifecycle first. Then it lists the security threats to a thing and the challenges you might hit while trying to protect against them. Last, it talks about next steps for making secure IoT systems actually happen 🔥 It's meant for implementers and authors of IoT specs as a reference for security considerations, so they can write up their own security challenges, threat models, and mitigations 🦋

This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG) 🌈

Status of This Memo 📜

Quick heads up: this is not a standards-track spec. It's published for informational purposes only 🌸

This document comes from the Internet Research Task Force (IRTF), which shares the results of Internet-related research and development. Those results might not be ready for deployment. Documents the IRSG approves for publication are not candidates for any level of Internet Standard. See Section 2 of RFC 7841 for the details 💖

For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8576 ✨

Copyright Notice ©️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this document 🎀

Table of Contents 🗂️

The full table of contents is above, right after the title block, so you can see how the sections are laid out 🦋

1. Introduction 🌸

okay, the Internet of Things (IoT) is about lots of different kinds of networked entities and networks, all talking with different patterns 💅 There's human-to-human (H2H), human-to-thing (H2T), thing-to-thing (T2T), and thing-to-things (T2Ts) 🫶 The term "IoT" was first used in 1999 by the Auto-ID center [AUTO-ID]. They pictured a world where every physical object had a radio-frequency identification (RFID) tag with a globally unique identifier 🧚 That would let you track objects in real time and also query data about them over the Internet. But the meaning has grown a LOT since then, and now it covers a huge range of technologies, objects, and protocols 😭 So it's no surprise the research community is super into (re)designing, applying, and using standard Internet technology and protocols for IoT 👑

The things in the Internet of Things are computing devices that sense and react to their environment ✨ People also call them smart objects or smart devices 💖 IPv6 [RFC6568] and CoAP [RFC7252] are the core building blocks that let IoT hosts connect to the Internet 🌈 That brings a few big perks: (i) a single, shared protocol ecosystem that makes it easy to hook things up with other Internet hosts; (ii) simpler development for devices with very different capabilities; and (iii) one unified interface for applications, so you don't need application-level proxies 💜 These building blocks make all the scenarios way easier to deploy, from building automation to production environments and personal area networks 🔥

This document gives an overview of the important security aspects of the Internet of Things. We start with the lifecycle of a thing in Section 2 🦋 Section 3 covers IoT security threats and ways to manage them when you're designing a secure system 🎀 Section 4 looks at existing IP-based (security) protocols for IoT and quickly sums up current guidelines and regulations 🌸 Section 5 lists the challenges that remain for a secure IoT and talks about possible solutions 💅 Section 6 has the final remarks and conclusions 🫶 This document can be used by IoT standards specifications as a reference for the security considerations that apply to the system or protocol they specify 🧚

Here's the history, because it's kind of a journey 🥹 The first draft was submitted in March 2011. Early drafts were presented and discussed at the Constrained RESTful Environments (CORE) Working Group meetings starting at IETF 80 ✨ Discussions about the security lifecycle at IETF 92 (March 2015) grew into broader security considerations, and that's how the draft got picked up to cover the T2TRG work item on security considerations and challenges for the Internet of Things 💖 More updates were presented at the T2TRG meetings at IETF 96 (July 2016) and IETF 97 (November 2016), and at the joint interim meeting in Amsterdam (March 2017) 🌈 The document was reviewed, commented on, and discussed heavily for nearly six years by a massive group of T2TRG and related group members, certainly more than 100 individuals 😭💜 The T2TRG consensus is that these security considerations should be published in the IRTF Stream of the RFC series 👑 And to be clear, this document does not constitute a standard 🍓

2. The Thing Lifecycle ✨

okay so let's talk about the lifecycle of a thing 🔄💖 It's basically the operational phases a thing goes through in a given application or use case. Figure 1 shows the generic phases, and this generic lifecycle fits super different IoT apps and scenarios. For a rundown of relevant IoT use cases, check out [RFC7744].

In this document we're using a Building Automation and Control (BAC) system to show the lifecycle and what each phase means 🏢✨ A BAC system is a network of interconnected nodes doing all sorts of jobs in Heating, Ventilating, and Air Conditioning (HVAC), lighting, safety, and more. The nodes are wildly different in what they do, and most of them are resource-constrained devices like sensors and luminaries 🔦 Some run on batteries or rely on energy harvesting, which means they also have to deal with sleeping during operation to save energy 😴 In our BAC scenario, a thing's life starts when it's manufactured 🏭 Since different application areas (HVAC, lighting, or safety) need different tailored nodes, it's pretty unlikely that one manufacturer makes every node in a building. So interoperability and trust bootstrapping between nodes from different vendors is a big deal 🫶

Next up, the thing gets installed and commissioned into a network by an installer during the bootstrapping phase 🔧 The device identity and the secret keys used during normal operation may be handed to the device in this phase. Different subcontractors might install different IoT devices for different purposes, and the installation and bootstrapping can be a non-discrete event that stretches out over a long period 🐢 Once bootstrapped, the device and the system of things are in operational mode and run the BAC system's functions 🎀 During this phase the device is controlled by the system owner and used by multiple system users. For devices with lifetimes spanning several years, occasional maintenance cycles may be required 🛠️ In each maintenance phase, the device's software can be upgraded, or the applications running on it can be reconfigured. Maintenance can happen locally or from a backend system. Depending on the operational changes, the device may need to rebootstrap at the end of a maintenance cycle 🔁 The device keeps looping through operational and maintenance phases until it's decommissioned at the end of its lifecycle 🌸 Here's the tea though: end-of-life doesn't automatically mean the device is defective 🙅‍♀️ It just means the network needs replacing and upgrading to next-generation devices for extra functionality. So the device can be removed and recommissioned into a different system under a different owner, which starts the whole lifecycle over again 🦋

Real talk, the lifecycle we just showed is kinda simplified 🙈 For example, you could argue the lifecycle doesn't start when a physical device is manufactured, but when the oldest bit of code in the device was written (maybe it came from an open-source project or the operating system) 💻 There could also be an on-the-shelf phase where the device sits in the supply chain before an owner or user buys and installs it 🛒 Another phase could be the device getting rebadged by a vendor that isn't the original manufacturer 🏷️ These extra phases can seriously complicate things like maintenance and bootstrapping 😭 And finally, other end states are possible too. A vendor might stop supporting a device type because it's reached the end of its life, or a device might simply get forgotten while still working 🕸️

    _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 🔐 But in real-world IoT deployments it's even more critical, and there are a few reasons why 😱 First, compromised IoT systems can endanger a user's privacy and security and can also cause physical harm 💥 That's because IoT systems often include sensors, actuators, and other connected devices sitting in the user's physical environment, which could hurt the user if they get compromised. Second, a vulnerable IoT system means an attacker can change how a device from a given manufacturer functions 🎭 That doesn't just hurt the manufacturer's brand image, it can also leak super valuable info like proprietary algorithms 🤫 Third, attacking an IoT system goes way beyond one device or one isolated system, because compromised IoT systems can be misused at scale 🌍 For example, they might be used to run a Distributed Denial of Service (DDoS) attack that takes down the availability of other networks and services. Also, many IoT systems rely on standard IP protocols, which makes integration easier, but it also means attacks on standard IP protocols are widely applicable in other environments 🫠 Bottom line, this creates new requirements for how security gets implemented 🛡️

The term "security" is a whole umbrella ☂️ It covers a wide range of primitives, protocols, and procedures. For instance, it includes confidentiality, authentication, integrity, authorization, source authentication, and availability. It often also includes augmented services like duplicate detection and detection of stale packets (timeliness) 🕰️ These security services can be built from a mix of cryptographic mechanisms, such as block ciphers, hash functions, and signature algorithms, plus noncryptographic mechanisms that handle authorization and other parts of security-policy enforcement 🧩 To keep IoT networks secure, you shouldn't just focus on the required security services. You also need to pay special attention to how those services get realized across the overall system 👑

3. Security Threats and Managing Risk 🚨

Security threats in related IP protocols have been analyzed across 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're getting specific about threats that could compromise an individual thing or the network as a whole 🕵️‍♀️ Some of these go beyond Internet protocols, but we gather them here for completeness 🎀 The threats in the list below aren't in any particular order, and some may be more critical than others depending on the deployment scenario being considered:

Vulnerable software/code: Things in the Internet of Things rely on software that might contain severe bugs and/or bad design choices 💀 That makes the things vulnerable to lots of different attacks, depending on how critical the bugs are, like 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] happened because things had well-known or easy-to-guess passwords for configuration 🙃
Privacy threat: Tracking 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. That info may then be sold to interested parties for marketing purposes and targeted advertising 💸 In extreme cases, it could be used to track dissidents in oppressive regimes 😤 Unlawful surveillance and interception of traffic to and from a thing by intelligence agencies is also a privacy threat 🔍
Cloning of things: During the manufacturing process, an untrusted factory can easily clone a thing's physical characteristics, firmware/software, or security configuration 🏭🙅‍♀️ Deployed things can also get compromised, with their software reverse engineered, which allows for cloning or software modifications. A cloned thing may be sold at a cheaper price and still 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 thing to note: an untrusted factory may also change the functionality of the cloned thing, which leads to degraded functionality compared to the genuine thing and can seriously damage the reputation of the original thing manufacturer 📉 On top of that, additional functionality can be introduced into the cloned thing. A backdoor is an example of that 🚪
Malicious substitution of things: During a thing's installation, a genuine thing may be swapped for a similar variant of lower quality without anyone noticing 🫣 The main motivation may be cost savings, since installing lower-quality things (for example, noncertified products) can significantly cut installation and operational costs 💰 The installers can then resell the genuine things for more financial benefits. Another motivation may be to damage the reputation of a competitor's offerings 🥀
Eavesdropping attack 👀: okay bestie, when a thing is getting commissioned into a network, it can be super vulnerable to eavesdropping. This happens if the operational keying materials, security parameters, or configuration settings get sent in the clear over a wireless medium, or if the cryptographic algorithms aren't strong enough for how long the device and system will be around. 😬 Once the attacker has the keying material, they might recover the secret keys shared between the communicating entities. That means the authenticity and confidentiality of the channel are compromised, along with the authenticity of commands and other traffic on it. 💔 When the network is up and running, T2T communication can be eavesdropped too, if the channel isn't protected well enough or a session key gets compromised because of protocol weaknesses. Keys that aren't renewed or updated properly are also an open door. And messages can be recorded now and decrypted offline later. 🕰️ The VENONA project [venona-project] is a famous example of exactly that, where messages were recorded for offline decryption. Iconic, but scary. 🙃
Man-in-the-middle attack 🥷: both the commissioning and operational phases can be vulnerable to man-in-the-middle attacks. Like, if keying material gets swapped between communicating entities in the clear, the key establishment protocol is only safe if you tacitly assume no third party is eavesdropping while it runs. 🫣 Also, device authentication or device authorization can be kind of messy, or might need a human to make the call, since things usually don't know anything about each other beforehand. They can't always tell friend from foe with fully automated mechanisms. Not me having to pull a human into the loop 💀
Firmware attacks 🔧: when a thing is in its operation or maintenance phase, its firmware or software might get updated to add new functionality or features. An attacker could exploit that upgrade by swapping in malicious firmware, which changes how the thing behaves. 😈 For example, imagine sneaking in some malicious code that makes the device periodically report its energy usage to a data repository. The attacker could then figure out when a home or enterprise (where the thing is installed) is empty and break in. Yikes. 🏚️ And devices whose software hasn't been properly maintained and updated may have vulnerabilities that attackers can use to replace the firmware. Please keep your updates up to date, babe 🫶
Extraction of private information 🔓: IoT devices (like sensors, actuators, and so on) are often physically unprotected in their surroundings, so an attacker could easily capture one. With physical access, an attacker might try to extract private information, such as keys (like a group key or the device's private key), data from sensors (like a user's healthcare status), configuration parameters (like the Wi-Fi key), or proprietary algorithms (like one doing some data analytics). 😭 Even when a thing's data is encrypted, attackers can do traffic analysis to deduce meaningful information, which might compromise the privacy of the thing's owner and/or user. Encryption isn't a magic cloak, sis. 🧥
Routing attack 🗺️: as highlighted in [Daniel], routing information in IoT networks can be spoofed, altered, or replayed. That lets attackers create routing loops, attract or repel network traffic, extend or shorten source routes, and more. A nonexhaustive list of routing attacks includes:
- a. Sinkhole attack (or blackhole attack): an attacker declares themselves to have a high-quality route or path to the base station, so they can manipulate all the packets passing through them. 🕳️
- b. Selective forwarding: an attacker may selectively forward packets or simply drop a packet. 🙅
- c. Wormhole attack: an attacker may record packets at one location in the network and tunnel them to another location. This influences the perceived network behavior, can distort statistics, and seriously messes with routing functionality. 🌀
- d. Sybil attack: an attacker presents multiple identities to other things in the network. For more router attacks and a more detailed description, check out [Daniel]. 👯
Elevation of privilege 👑: an attacker with low privileges can misuse additional flaws in the implemented authentication and authorization mechanisms of a thing. That lets them gain more privileged access to the thing and its data. Main character villain arc, not cute. 😤
Denial of Service (DoS) attack 🪫: things often have very limited memory and computation capabilities, which makes them vulnerable to resource-exhaustion attacks. Attackers can keep sending requests to specific things to drain their resources. This is especially dangerous in the Internet of Things, since an attacker might sit in the backend and target resource-constrained devices that are part of a constrained-node network [RFC7228]. A DoS attack can also happen by physically jamming the communication channel. Network availability can be disrupted by flooding the network with a huge number of packets. 🌊 And on the flip side, compromised things can be used to disrupt the operation of other networks or systems through a Distributed DoS (DDoS) attack. Chaos. 💥

To deal with the above threats, it is required to find and apply suitable security mitigations. 🛡️ But new threats and exploits show up every single day, and products get deployed in different environments with different threats. So keeping a proper level of security in an IoT system at any point in time is genuinely challenging. 😮‍💨 To tackle this, some of the following methodologies can be used:

A Business Impact Analysis (BIA) assesses the consequences of losing the basic security attributes (confidentiality, integrity, and availability) in an IoT system. Those consequences might include lost data, reduced sales, increased expenses, regulatory fines, customer dissatisfaction, and so on. Doing a business impact analysis helps a business figure out how much a proper security design actually matters to them. 💼
A Risk Assessment (RA) analyzes security threats to an IoT system while considering their likelihood and impact. It also categorizes each threat with a risk level. Risks classified as moderate or high must be mitigated, meaning the security architecture should be able to deal with those threats. 🚦
A Privacy Impact Assessment (PIA) looks at the Personally Identifiable Information (PII) that is collected, processed, or used in an IoT system. The goal is to meet applicable legal requirements and to figure out the risks and effects of manipulation and loss of PII. Privacy is literally a whole vibe. 🔐
Procedures for incident reporting and mitigation are the methods that let you become aware of any security issues affecting an IoT system. This also includes the steps toward actually deploying patches for the vulnerabilities you found. 🩹

BIA, RA, and PIA should generally be done when creating a new IoT system or when deploying significant system or feature upgrades. It's also recommended to reassess them on a regular basis, taking into account new use cases and/or threats. ♻️ How you perform a BIA, RA, or PIA depends on the environment and the industry. For more info, look at NIST documents like [NISTSP800-34r1], [NISTSP800-30r1], and [NISTSP800-122]. 📚

4. State of the Art ✨

This section is laid out like so 🗂️. Section 4.1 summarizes the state of the art on IP-based IoT systems, both within the IETF and other standardization bodies. Section 4.2 summarizes the state of the art on IP-based security protocols and how they're used. Section 4.3 discusses guidelines and regulations for securing IoT as proposed by other bodies. Note that the references in this section are a representative sample of the state of the art at the time of writing, and they are by no means exhaustive. 🙈 They're also at varying levels of maturity, so it's advisable to check their specific status before you rely on them. ⭐

4.1. IP-Based IoT Protocols and Standards ✨

Okay so, there are SO many control protocols for IoT right now 🤯 For BAC systems, the ZigBee standard [ZB], BACNet [BACNET], and DALI [DALI] are the big players 👑 But the newer trend is going all-IP for system control, and honestly? Iconic 🌐💖

A bunch of IETF working groups are building new protocols for resource-constrained networks of smart things 🧚 The 6LoWPAN Working Group [WG-6LoWPAN], for example, has come up with methods and protocols for efficiently transmitting and adapting IPv6 packets over IEEE 802.15.4 networks [RFC4944]. Main character energy 🎀

The CoRE Working Group [WG-CoRE] gave us the Constrained Application Protocol (CoAP) [RFC7252] 🦋 CoAP is a RESTful protocol for constrained devices that's modeled after HTTP and typically runs over UDP, so things can communicate at the application level efficiently 💅 ("RESTful" refers to the Representational State Transfer (REST) architecture, fyi 🤓)

Now, in lots of smart-object networks, the smart objects are spread out and have intermittent reachability. That's either because of network outages, or because they sleep during their operational phase to save energy 😴 Lowkey tricky, because in those scenarios, direct discovery of resources hosted on the constrained server might not be possible 🙈 To get around that barrier, the CoRE Working Group is specifying the concept of a Resource Directory (RD) [RD]. The Resource Directory hosts descriptions of resources that live on other nodes, and these resource descriptions are specified as CoRE link format [RFC6690] 🗂️✨

CoAP defines a standard communication protocol, but ngl, we also need a format for representing sensor measurements and parameters over CoAP 📊 That's where "Sensor Measurement Lists (SenML)" [RFC8428] comes in. It defines media types for simple sensor measurements and parameters, and it has a minimalistic design so constrained devices with limited computational capabilities can easily encode their measurements. At the same time, servers can efficiently collect a large number of measurements 🍓 Efficient AND cute 🫶

In lots of IoT deployments, the resource-constrained smart objects connect to the Internet through a gateway that's directly reachable 🌸 For example, an IEEE 802.11 Access Point (AP) usually connects client devices to the Internet over just one wireless hop. Some smart-object networks, though, need routing between the smart objects themselves 🔥 So the IETF defined the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550]. RPL supports multipoint-to-point traffic from resource-constrained smart objects toward a more resourceful central control point, plus point-to-multipoint traffic in the reverse direction. It also supports point-to-point traffic between the resource-constrained devices 💜 And a set of routing metrics and constraints for path calculation in RPL is also specified [RFC6551]. Literally so organized 😭

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 used for resource-constrained smart-object networks 🌈 There's also ongoing work to specify IPv6 connectivity for a Non-Broadcast Multi-Access (NBMA) mesh network formed by IEEE 802.15.4 Time-Slotted Channel Hopping (TSCH) links [ARCH-6TiSCH]. Other link-layer protocols where 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 smart-grid network designers advice on how to decide on a profile of the Internet protocol suite for smart-grid networks. Very helpful, bestie 🫶

The Low Power Wide-Area Network (LPWAN) Working Group [WG-LPWAN] is analyzing features, requirements, and solutions for adapting IP-based protocols to networks such as LoRa [LoRa], Sigfox [sigfox], NB-IoT [NB-IoT], etc. These networking technologies let a smart thing 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 🔋 Because of that, they bring new security challenges, since most existing security mechanisms don't work well with such resource constraints 💀

JavaScript Object Notation (JSON) is a lightweight text-representation format for structured data [RFC8259] 📝 It's 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. These are JSON Web Keys (JWKs) [RFC7517], JSON Web Encryption (JWE) [RFC7516], JSON Web Signatures (JWSs) [RFC7515], and JSON Web Token (JWT) [RFC7519] 🎀

Then there's an alternative to JSON: Concise Binary Object Representation (CBOR) [RFC7049], a concise binary data format used for serializing structured data 🦋 It's designed for resource-constrained nodes, so it aims for a fairly small message size, minimal implementation code, and extensibility without the need for version negotiation. CBOR Object Signing and Encryption (COSE) [RFC8152] then 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 🌸 It has already produced documents like [RFC7815], which defines how a minimal Internet Key Exchange Version 2 (IKEv2) initiator can be implemented. Small but mighty 💪

The Thing-2-Thing Research Group (T2TRG) [RG-T2TRG] is investigating the remaining research issues that need solving to quickly turn the vision of IoT into reality, where resource-constrained nodes can communicate with each other and with other, more capable nodes on the Internet 🔭💜

Industry alliances and other standardization bodies are also building constrained IP protocol stacks based on the IETF work 🤝 Some important examples include:

Thread [Thread]: Specifies the Thread protocol, intended for a variety of IoT devices. It's an IPv6-based network protocol that runs over IEEE 802.15.4 🧵
Industrial Internet Consortium [IIoT]: The consortium defines reference architectures and security frameworks for the development, adoption, and widespread use of Industrial Internet technologies based on existing IETF standards 🏭
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 🧩
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 🌐
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 🦋
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 💡
OMA LwM2M [LWM2M]: OMA Lightweight M2M is a standard from 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 ✨

okay so there are three main security goals for IoT networks 🛡️:

protecting the IoT network from attackers
protecting IoT applications, and therefore the things and users 🫶
protecting the rest of the Internet and other things from attacks that use compromised things as an attack platform 💀

when you're building IP-based IoT stuff, you have to look at the security protocols the Internet already has, bestie 💅. there's a whole buffet of specialized and general-purpose options, like 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 secures TCP and needs a reliable transport 🌸. DTLS secures datagram-oriented protocols like UDP 🦋. they're intentionally kept pretty similar, sharing the same ideology and cipher suites, so it's giving family resemblance 🥹.

the CoAP base specification [RFC7252] explains how DTLS can be used to secure CoAP 🔐. it lays out three modes for doing that:

PreSharedKey mode: nodes have pre-provisioned keys for starting a DTLS session with another node 🗝️
RawPublicKey mode: nodes have asymmetric-key pairs but no certificates to verify who owns them 🤷‍♀️
Certificate mode: public keys are certified by a certification authority 📜

there's also an IoT implementation profile for TLS version 1.2 and DTLS version 1.2 that gives communication security to resource-constrained nodes [RFC7925] ✨. the lowkey goal here is making security fit on tiny devices 🧚.

there's ongoing work on an authorization and access-control framework for resource-constrained nodes too 🎀. the Authentication and Authorization for Constrained Environments (ACE) Working Group [WG-ACE] is defining a solution that allows only authorized access to resources hosted on a smart-object server and identified by a URI 🔑. the current proposal [ACE-OAuth] is built on the OAuth 2.0 framework [RFC6749], and it comes with profiles 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] 🎁. so OSCORE counts as object security, and it works anywhere CoAP works 🌈. the perk over DTLS is that it's more flexible when it comes to end-to-end security 💜. Section 5.1.3 goes deeper on this, so go check it out if you're curious 👀.

the Automated Certificate Management Environment (ACME) Working Group [WG-ACME] is writing conventions for automated X.509 certificate management 🤖. that covers automatic validation of certificate issuance, certificate renewal, and certificate revocation 🔄. right now the group is mostly focused on domain-name certificates (the kind web servers use), but other uses in some IoT deployments are possible 🌷.

IKEv2/IPsec, plus the less-used Host Identity Protocol (HIP), live at or above the network layer in the OSI model 🧱. both can do an authenticated key exchange and set up IPsec for secure payload delivery 📦. there's also ongoing work on a HIP variant called Diet HIP [HIP-DEX], which 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 resource-constrained IoT devices can actually use it 🪶. they rely on the Internet Key Exchange Protocol Version 2 (IKEv2) to negotiate the compression format 🤝.

the Extensible Authentication Protocol (EAP) [RFC3748] is an authentication framework that supports multiple authentication methods 🦄.

EAP runs directly over the data link layer, so it doesn't need IP to be deployed 🙌. it supports duplicate detection and retransmission, but it does not allow 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 ✨

Okay so attacks on and from IoT devices have become super common lately 😭. Like, large-scale DoS attacks hitting the Internet Infrastructure, launched from compromised IoT devices? Iconic in the worst way 💀. That's why so many standards bodies and consortia have put out guidelines to help developers and the wider Internet community build secure IoT devices and services 🫶. Here's a taste of the different guidelines and ongoing projects:

Global System for Mobile Communications Association (GSMA) IoT security guidelines [GSMAsecurity]: GSMA published a set of security guidelines for new IoT product and service providers 🎀. They're aimed at device manufacturers, service providers, developers, and network operators. An enterprise can complete an IoT Security Self-Assessment to show that its products and services line up with the GSMA security guidelines ✅.
Broadband Internet Technical Advisory Group (BITAG) IoT Security and Privacy Recommendations [BITAG]: BITAG put out recommendations for keeping IoT device users secure and private 🔒. Here's the tea: BITAG notes that a lot of IoT devices ship from the factory with software that's already outdated and vulnerable 😤. The report also says plenty of vulnerable devices never get fixed, either because the manufacturer doesn't provide updates or because the user doesn't 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 🌸.
United Kingdom Department for Digital, Culture, Media and Sport (DCMS) [DCMS]: UK DCMS released a report with a list of 13 steps for improving IoT security 👑. These steps highlight things like implementing a vulnerability disclosure policy and keeping software updated 🆙. The report is aimed at device manufacturers, IoT service providers, mobile application developers, and retailers 🛍️.
Cloud Security Alliance (CSA) New Security Guidance for Early Adopters of the IoT [CSA]: CSA's recommendations for early adopters of IoT encourage enterprises to build in security at different layers of the protocol stack 🥞. They also recommend implementing an authentication/authorization framework for IoT deployments 🔑. The complete list of recommendations is in the report [CSA] 📄.
United States Department of Homeland Security (DHS) [DHS]: DHS has put forth six strategic principles to help IoT developers, manufacturers, service providers, and consumers stay secure as they develop, manufacture, implement, or use network-connected IoT devices 🇺🇸✨.
National Institute of Standards and Technology (NIST) [NIST-Guide]: This NIST special publication urges enterprises and US federal agencies to address security throughout the systems engineering process 🧠. It builds on the International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 15288 standard and adds security enhancements to each process in the system lifecycle 🔁.
National Institute of Standards and Technology (NIST) [NIST-LW-PROJECT] [NIST-LW-2016]: NIST is running a lightweight cryptography project 🦋. The goals are: (i) identifying application areas where standard cryptographic algorithms are too heavy, and classifying them according to 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 💜.
Open Web Application Security Project (OWASP) [OWASP]: OWASP provides security guidance for IoT manufacturers, developers, and consumers 🙌. It also has guidelines for anyone who wants to test and analyze IoT devices and applications 🔍.
IoT Security Foundation [IoTSecFoundation]: The IoT Security Foundation published a document listing various considerations to take into account when developing IoT applications 📋. For example, the document states that IoT devices could use a hardware root of trust to make sure only authorized software runs on the devices 🔐.
National Highway Traffic Safety Administration (NHTSA) [NHTSA]: The US NHTSA gives the automotive industry guidance for improving vehicle cyber security 🚗. Some of the guidelines are general, but the document also offers specific recommendations for the automotive industry, like how different automotive manufacturers can share cybersecurity vulnerabilities they discover 🤝.
"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 🛠️. The goal is to reduce the frequency and severity of security incidents that arise from compromised IoT devices 🎯.
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 🏭. It sums up security vulnerabilities, guidelines, and general recommendations for those systems 📊.
Internet Society Online Trust Alliance [ISOC-OTA]: The Internet Society's IoT Trust Framework spells out 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 📚. Even with all this talk about security and multiple guidelines out there, the truth is that many IoT devices and systems have very limited security 😩. There are multiple reasons for this. For instance, some manufacturers focus on shipping a product without paying enough attention to security. That might be because of lack of expertise or a limited budget 💸. Still, deploying insecure devices poses a severe threat to the privacy and safety of users 🚨. The vast number of devices and their inherently mobile nature also mean that an initially secure system can become insecure if a compromised device gains access to the system at some point in time 📱. Even if every other device in a given environment is secure, that doesn't stop external attacks caused by insecure devices 😬. Recently, the US Federal Communications Commission (FCC) has said IoT systems need additional regulation [FCC] 🏛️. It's possible we'll see other regional regulations like this in the future 🔮.

5. Challenges for a Secure IoT 🔥

In this section, we take a closer look at the security challenges in the operational and technical features of IoT, and then talk about how existing Internet security protocols cope with these technical and conceptual challenges across the lifecycle of a thing 🧐. This discussion should not be understood as a comprehensive evaluation of all protocols, and it can't cover every possible aspect of IoT security 🙈. It does aim to show concrete limitations and challenges in some IoT design areas, rather than staying abstract. The discussion focuses on the issues that matter most from the authors' perspectives 💅.

5.1. Constraints and Heterogeneous Communication

Coupling resource-constrained networks with 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 what those constraints mean for using 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 CPU, memory, and energy budget [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) a small IP-layer maximum transmission unit (MTU) 🧃. In the first case, excessive fragmentation of large packets, which security protocols often require, may open new attack vectors for state-exhaustion attacks 🚪. The second case might lead to more fragmentation at the IP layer, which commonly downgrades 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 on resource-constrained devices, since they stack 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 bootstrapping, it might be a good strategy to perform those procedures at a lower layer 🪜.

Small CPUs and scarce memory limit the use 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 used frequently, or if 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 🌈. Plus, most modern security protocols have been revised in the last few years to enable cryptographic agility, which makes cryptographic primitives interchangeable 🔄. However, these improvements are only a first step in reducing the computation and communication overhead of Internet protocols 🫠. The question remains whether other approaches can be applied to leverage key agreement in these heavily resource-constrained environments 🤔.

A further fundamental need is the limited energy budget available to IoT nodes ⚡. Careful protocol (re)design and usage are required to reduce not only 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 🛡️

okay so the tiny memory and processing power of things kind of already helps against resource-exhaustion attacks 🦋 but ngl, these attacks are sneaky, especially in unattended T2T communication. Nobody notices until the service is already down, because the battery or memory has run out 💀. As a DoS countermeasure, DTLS, IKEv2, HIP, and Diet HIP all use return routability checks based on a cookie mechanism. The point is to delay creating state at the responding host until the address of the initiating host is verified 🔐. How well this works really depends on the routing topology of the network 🗺️. Return routability checks are super effective when hosts can't receive packets addressed to other hosts, and when IP addresses carry meaningful information, which is the case on today's Internet ✨. They're way less effective on 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) 🙈.

HIP also has a puzzle mechanism 🧩. It can force the initiator of a connection (and potential attacker) to solve cryptographic puzzles with variable difficulties. Puzzle-based defenses depend less on the network topology, but they perform poorly when CPU resources in the network are heterogeneous (for example, if a powerful Internet host attacks a thing) 😭. Cranking up the puzzle difficulty under attack can easily end with a powerful attacker still solving the puzzle while weak IoT clients can't, so those clients get locked out of talking to 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" has multiple interpretations, so let's be clear 💅. Here, we're talking about end-to-end security in the context of end-to-end IP connectivity from a sender to a receiver 📦. Things like confidentiality and integrity protection on packet data, message authentication codes, or encryption are typically used to provide end-to-end security 🔒. These protection methods make the protected parts of the packets immutable, because rewriting is either not possible or would break things. That happens either because (i) the relevant information is encrypted and the gateway can't access it, or (ii) rewriting integrity-protected parts of the packet would invalidate the end-to-end integrity protection 🙅‍♀️.

Protocols for constrained IoT networks aren't exactly the same as their bigger Internet counterparts, because they're built for efficiency and performance 🧚. So more or less subtle differences between the two will stick around 🌸. Those differences can be bridged with protocol translators at middleboxes, but they can turn into major obstacles if end-to-end security between IoT devices and Internet hosts is needed 😬.

If the middleboxes are required to access or be able to access data or messages, there's a whole buffet of approaches available 🍓. Just note that some of these affect what end-to-end security means for integrity and confidentiality, since the middleboxes will be able to either decrypt or partially modify the exchanged messages 👀:

Sharing credentials with middleboxes lets them transform packets (for example, decompress, convert, etc.) and reapply the security measures after the transformation. This method abandons end-to-end security and only works for simple scenarios with a rudimentary security model 💀.
Reusing the Internet wire format for IoT means no conversion between IoT and Internet protocols is needed ✨. However, it can lead to poor performance in some use cases, because IoT-specific optimizations (for example, stateful or stateless compression) aren't possible 😭.
Selectively protecting vital and immutable packet parts with a message authentication code or encryption takes a careful balance between performance and security 🎯. Otherwise, this approach might end up with poor performance or poor security, depending on which parts are selected for protection, where they sit in the original packet, and how they're processed 🫠. [OSCORE] goes in this direction with a solution that encrypts and integrity protects most of the message fields, except the parts a middlebox needs to read or change 🧠.
Homomorphic encryption techniques can be used in the middlebox to perform certain operations 🔮. But this is limited to data processing involving arithmetic operations. Plus, the performance of existing libraries (for example, Microsoft SEAL [SEAL]) is still too limited, so homomorphic encryption techniques aren't widely applicable yet 🥲.
Message authentication codes that survive transformation can be realized by considering the order of transformation and protection (for example, by creating a signature before compression, so the gateway can decompress the packet without recalculating the signature) 🪄. This approach enables IoT-specific optimizations, but it's more complex and may require application-specific transformations before security is applied 🧩. Also, using encrypted or integrity-protected data prevents middleboxes from transforming packets 🚫.
Mechanisms based on object security can bridge the protocol worlds, but both worlds still need to use the same object-security formats 🌈. Right now, 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 that rely on traditional Internet protocols will need to update to the newer protocols for constrained environments to get real end-to-end security 🔄. Plus, middleboxes don't have any access to the data, and this approach doesn't stop an attacker who can modify relevant message header fields that aren't protected 🕵️‍♀️.

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 give the perfect solution to this problem space 💔. We're still working on it, bestie 🫶.

5.1.4. New Network Architectures and Paradigm 🌍

There's 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 need long range and low bit rates 🌄. [RFC8376] gives an informational overview of the set of LPWAN technologies the IETF is considering 📚. It also identifies the potential gaps between the needs of those technologies and the goal of running IP in such networks 🔍. These protocols help IoT devices conserve energy and operate efficiently, but they also add extra 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 let IoT devices talk directly to each other, with or without support from the network 💬. This paradigm is also called Device-to-Device (D2D), Machine-to-Machine (M2M), or Thing-to-Thing (T2T) communication, and it's motivated by features like improved network performance, lower latency, and lower energy requirements ⚡. Main character energy, honestly 👑.

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 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 bootstrapping 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 too 🫶.

5.3.1. Group Membership and Security ✨

okay so group-key negotiation is a HUGE security service for IoT 🫶 it matters when a thing sends data to multiple things, or when data flows from multiple things toward one thing. like, very common vibe 🦋 but here's the tea: every protocol they looked at only does unicast, one-to-one 💀 so none of them really focus on setting up group keys. that goes for (D)TLS and IKEv2 too. so yes, a solution is needed in this area, periodt 💅

one idea is to reuse the Diffie-Hellman keys that IKEv2 and HIP already use to set up a secure unicast link, and use them for group Diffie-Hellman key negotiations 🌸 but ngl, Diffie-Hellman is kind of heavy, especially when the group gets big 😭

symmetric and asymmetric keys can both be used in group communication 🎀 asymmetric keys have the perk that they can provide source authentication ✨ BUT doing broadcast encryption with one single public/private key pair is also not feasible 💀 a single symmetric key can encrypt the communication or compute a message authentication code, but it has real risks, because if one node gets captured, the key shared across the whole network is compromised 😱 symmetric keys also don't give you source authentication. and asymmetric crypto is more resource-intensive than symmetric solutions 🥺 so the security risks and performance trade-offs of each option need to be analyzed carefully for a given IoT use case, based on risk and usability assessments [RFC8387]. [MULTICAST] is looking at combining confidentiality with a group key and source authentication with public keys in the same packet 🧚

conceptually, solutions that do secure group communication at the network layer (IPsec/IKEv2, HIP/Diet HIP) might have an advantage in cryptographic overhead compared to application-focused security (TLS/DTLS) 🍓 why? because application-focused solutions need crypto operations for each group application, while network-layer approaches can share secure group associations between multiple applications (like neighbor discovery, routing, or service discovery) ✨ so putting shared features lower in the stack can avoid redundant security work 👑 BUT, sharing security contexts between apps comes with threats too, e.g., if one app is malicious and watches exchanged messages or injects fake ones 🙈 with OSCORE, it provides security for CoAP group communication as defined in RFC 7390, so based on multicast IP 🦋 if the same security association gets reused for each application, this solution doesn't seem to have more crypto overhead than IPsec 💖

several group-key solutions were developed by the MSEC Working Group of the IETF [WG-MSEC] 🌈 MIKEY architecture [RFC4738] is one example. these are specifically tailored for multicast and group-broadcast apps on the Internet, but they should still be considered as candidate solutions for group-key agreement in IoT 🫶 the MIKEY architecture, for example, describes a coordinator entity that hands out symmetric keys over pair-wise end-to-end secured channels. however, a centralized approach like that may not work in a distributed IoT environment, where picking one or several coordinators and managing the group key isn't trivial 😭🌸

5.3.2. Mobility and IP Network Dynamics 🦋

okay so lots of things (like user devices and wearable sensors) will be mobile, meaning they'll attach to different networks during the lifetime of a security association 🧳 built-in mobility signaling can seriously cut down the overhead of crypto protocols 🔥 because you can skip unnecessary and costly re-establishments of the session (which might include handshake and key agreement) 🙌 IKEv2 supports host mobility with the MOBIKE extension [RFC4555] [RFC4621] 💅 MOBIKE refrains from using heavyweight crypto extensions for mobility, which is iconic of it 👑 however, MOBIKE mandates IPsec tunnel mode, which requires an additional IP header in each packet 😬

HIP offers simple yet effective mobility management by letting hosts signal changes to their associations [RFC8046] ✨ still, some small adjustments might be needed to reduce the crypto costs, for example by making the public key signatures in the mobility messages optional 🎀 Diet HIP doesn't define mobility yet, but it's similar enough to HIP that it can use the same mechanisms 🧚 DTLS gets some mobility support by relying on a connection ID (CID) 💜 connection IDs can provide all the mobility functionality described in [Williams] except sending the updated location 🌈 the specific need for IP-layer mobility mostly depends on the scenario the nodes operate in 🍓 in many cases, mobility supported through a mobile gateway may be enough to enable mobile IoT networks, like body-sensor networks 🫶 and using message-based application-layer security like OSCORE [OSCORE] can also ease the problem of re-establishing lower-layer sessions for mobile nodes ✨🦋

5.4. Secure Software Update and Cryptographic Agility 💖

okay bestie, IoT devices are expected to stay functional for several years or even decades 😭, and they might be sitting unattended with direct Internet connectivity the whole time. So software updates are needed for more than new features. They also kill security vulnerabilities caused by software bugs, design flaws, or deprecated algorithms 💅. Bugs can survive even careful code review, security protocol implementations might have (design) flaws, and cryptographic algorithms can get insecure as cryptanalysis advances 🔍. That's why it's essential that devices which can't verify a cryptographic signature are not exposed to the Internet, even indirectly 🚫🌐.

In his essay, Schneier spills the tea on the challenges that get in the way of secure software update for IoT devices [SchneierSecurity] 🍵. First, nobody has much incentive: manufacturers, vendors, and others on the supply chain aren't really motivated to issue updates for their devices 😩. Second, parts of the software running on IoT devices are just a binary blob with no source code available. No source, no patches, periodt 💀. Lastly, even when updates exist, users generally have to manually download and install them 🙃. Users are never alerted about security updates, and plenty of them don't have the expertise to manually administer the updates they need.

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 of secure remote software update for IoT devices 📚. They point out that even providing a software-update capability can add new vulnerabilities for constrained devices 😬. For example, a buffer overflow in the implementation of a software update protocol (TR69) [TR69] and an expired certificate in a hub device [wink] show how the software-update process itself can introduce vulnerabilities. Yikes 🫣.

Powerful IoT devices that run general-purpose operating systems can use sophisticated software-update mechanisms from the desktop world 🖥️✨. Resource-constrained devices, though, typically don't have any operating system and often aren't equipped with a memory management unit or similar tools 🥺. So they might need 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, which can hinder how much and how often they can do cryptographic processing 🔋. On top of source authentication, software updates might also require confidential delivery over a secure (encrypted) channel 🔒. The complexity of broadcast encryption can force the use of point-to-point secure links. However, this increases the duration of a software update in a large system 🐢. Alternatively, it may force solutions where 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 need to be assembled and verified over a secure channel can eat up a lot of energy and computational resources 🍽️. Correct scheduling of 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 replace old and insecure cryptographic primitives 🔄. However, many IoT systems, some of which are already deployed, weren't designed with provisions for cryptographic agility 😔. For example, many devices come with a wireless radio that has an AES128 hardware coprocessor. These devices rely solely 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 it might drastically hinder their operational performance 📉. That can leave people stuck running old and insecure software 🥀. So it's important to account for the fact that cryptographic algorithms will need to be updated, and to consider the following when planning for cryptographic agility 🧠:

Would it be secure to use the existing cryptographic algorithms available on the device for updating with new cryptographic algorithms that are more secure?
Will the new software-based implementation fit on the device given the limited resources?
Would the normal operation of existing IoT applications on the device be severely hindered by the update?

Finally, let's highlight the previous and ongoing work on 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 also organized a workshop to understand the challenges of secure software update for IoT devices, and a summary of the recommendations to the standards community that came out of those discussions has 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 update, based on experience from IoT deployments 🌸. It's specifically working on describing an IoT firmware update architecture and specifying a manifest format that contains metadata about the firmware update package 🏗️. And the Trusted Execution Environment Provisioning Working Group [WG-TEEP] aims to develop a protocol for lifecycle management of trusted applications running in 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 mark the point in time when they limit or end support for the IoT device 🪦. This can be planned or unplanned. For example, 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, but that requires some form of authorization handover 🤝.

I know this might sound far-fetched given the commercial interests and market dynamics, but we've seen examples in the mobile world where devices stayed functional and up to date long after the original vendor stopped supporting them 📱. CyanogenMod for Android devices and OpenWrt for home routers are two such instances where users kept using and updating their devices even after the official EOL 🙌. Admittedly, it's not easy for an average user to install and configure their devices on their own 😅. With millions of IoT devices out there, simpler mechanisms are needed so users can add new trust anchors [RFC6024] and install software and firmware from other sources once a device is EOL 🔑✨.

5.6. Verifying Device Behavior 👀

Users of new IoT appliances, like 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] 🚨. Not okay 😤.

An IoT device's user or 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 manufacturer's server 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 of the data the device is sending back to the vendor 🫵. For example, the user might want to know if their TV is sending data when they insert a new USB stick 🔌.

Providing this information to users in an understandable way is challenging 🤯. That's because IoT devices are not only resource constrained in terms of computational capability, but also in terms of the user interface available 📟. Also, the network infrastructure where these devices are deployed varies significantly from one user environment to another 🏠. So where and how this monitoring feature gets implemented still remains an open question ❓.

Manufacturer Usage Description (MUD) files [RFC8520] are perhaps a first step toward this kind of monitoring service 🪜. The idea behind MUD files is pretty simple: IoT devices 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, as stated by the device manufacturer 📜. A network-monitoring service could then warn the user or owner if devices 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 🛒. These monitoring devices and 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 test their IoT devices, networks, and systems extensively 🧪. Still, the devices are resource constrained, made by multiple vendors, and some of them are very small. So devices might ship with very limited testing, which means bugs can stick around and get exploited later 💀. This leads to two main types of challenges:

It remains to be seen how the software-testing and quality-assurance mechanisms used in the desktop and mobile world will be applied to IoT devices, so end users can feel confident that the devices they buy are robust 🤞. Bodies such as the European Cyber Security Organization (ECSO) [ECSO] are working on processes for security certification of IoT devices 🏅.
It's also an open question how combining devices from multiple vendors might lead to dangerous network configurations. For example, what if a specific combination of devices triggers unexpected behavior? 😳 It goes without saying that the security of the whole system is limited by its weakest point 🔗💔.

5.8. Quantum-Resistance 🔮

Okay bestie, so a LOT of IoT stuff being deployed right now is gonna keep running for YEARS 😭. And quantum computers are getting more advanced, so it's possible that large-scale ones will exist in the future and be used to do cryptanalysis on existing cryptographic algorithms and cipher suites 💀. If that happens, two things go wrong. First, the stuff enabled by RSA or ECC, namely key exchange, public key encryption, and signatures, would not be secure anymore because of Shor's algorithm 🙅‍♀️. Second, symmetric algorithms get weaker too. A block cipher with a key size of b bits only offers b/2 bits of security because of Grover's algorithm 📉.

This gets even more urgent with the so-called "harvest and decrypt" attack 🫣. The attacker starts harvesting (storing) encrypted data today, before a quantum computer exists, and then decrypts it years later once one is available. This kind of attack is not new, btw. It was used in the VENONA project [venona-project] 🕵️‍♀️. Lots of IoT devices going out today will stay operational for a decade or even longer 🕰️. During that time, the digital signatures used to sign software updates might become obsolete, which makes securely updating IoT devices super tricky 😩.

So this situation would require us to move to quantum-resistant alternatives 🛡️, especially for key exchange, public key encryption, and signatures. [C2PQ] explains when quantum computers may become widely available and what steps are needed to move to cryptographic algorithms that stay secure even when quantum computers are around 📚. Future planning is hard, ngl, but it may be a necessity for certain critical IoT deployments that are expected to last decades or more 🏗️. Increasing the key size of the different algorithms is definitely an option ✅, but it also adds extra computational overhead and network traffic 🐢. That would be undesirable in most scenarios 🙅. There have been recent advancements in quantum-resistant cryptography ✨. For an extensive overview of existing quantum-resistant cryptography, check [ETSI-GR-QSC-001] 🔍, and [RFC7696] gives guidelines for cryptographic algorithm agility 🦋.

5.9. Privacy Protection 🎀

People are eventually gonna be surrounded by hundreds of connected IoT devices 🏠✨. Even if the communication links are encrypted and protected, information about people can still get collected or processed for different purposes 👀. The fact that IoT devices near people can enable more pervasive monitoring can seriously hurt their privacy 😭. Picture this: a static presence sensor emits a packet based on whether people are nearby or not. Anyone who can observe that packet can gather super critical, privacy-sensitive info 🚨.

That kind of information about people is called personal data in the European Union (EU) or Personally identifiable information (PII) in the US 🌍. 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, and honestly it's giving very organized energy 🗂️✨:

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.
Individual control over the collection and processing of personal information by IoT devices and services.
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], especially for the IoT environment and its lifecycle 😳. Here's the lineup:

Identification - refers to the identification of the users, their IoT devices, and generated data.
Localization - relates to the capability of locating a user and even tracking them, e.g., by tracking MAC addresses in Wi-Fi or Bluetooth 📍.
Profiling - is about creating a profile of the user and their preferences 🗃️.
Interaction - occurs when a user has been profiled and a given interaction is preferred, presenting (for example, visually) some information that discloses private information 🫠.
Lifecycle transitions - take place when devices are, for example, sold without properly removing private data 🗑️.
Inventory attacks - happen if specific information about IoT devices in possession of a user is disclosed 📦.
Linkage - is about when information of two or 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 get deployed, these issues should be considered to make sure private data stays private 🔒. It gets especially hard in environments where 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 still an area of ongoing research 🔬💜.

5.10. Reverse-Engineering Considerations 🕵️‍♀️

Many IoT devices are resource constrained and often deployed in unattended environments 🏚️. Some of them can also be bought off the shelf or online without any credential-provisioning process 🛒. So an attacker can have direct access to the device and use advanced techniques to get info that a traditional black-box model doesn't consider 😬. Examples of those techniques are side-channel attacks or code disassembly 🔧. With these, the attacker can try to retrieve data such as:

Long-term keys. These can be extracted by means of a side-channel attack or reverse engineering. If they're exposed, they might be used to attack devices deployed in other locations 🔑💀.
Source code. Extracting source code might let the attacker find bugs or exploits to launch other types of attacks. The attacker might also just sell it 💸.
Proprietary algorithms. The attacker can analyze these and gain valuable know-how 🧠. They can also create copies of the product based on those algorithms, or modify them to perform more advanced attacks 😈.
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 these data leaks is a secure element, a tamper-resistant device that can securely host applications and their confidential data 🛡️🔐. Another potential solution is a Physical Unclonable Function (PUF), which serves as a unique digital fingerprint of a hardware device 🧬. PUFs can also enable other functionalities, such as secure key storage 🗝️. Protecting against these 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 them 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 super common one is using well-known or easy-to-guess passwords to configure IoT devices 🔓. Many such compromised devices can be found on the Internet with tools like Shodan [shodan] 🔎. Once found, they can be exploited at scale, for example to launch DDoS attacks 💥. Dyn, a major DNS service provider, was hit by a DDoS attack from a huge IoT botnet made of thousands of compromised IP cameras [Dyn-Attack] 📷😱. There are several open research questions here:

How to avoid vulnerabilities in IoT devices that can lead to large-scale attacks?
How to detect sophisticated attacks against IoT devices?
How to prevent attackers from exploiting known vulnerabilities at a large scale?

Some ideas are being explored to tackle this. One approach relies on Manufacturer Usage Description (MUD) files [RFC8520] 🗂️. As explained earlier, this proposal has IoT devices 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 gives IoT security researchers, system designers, and implementers an overview of security requirements in the IP-based Internet of Things 🎓. We talk through the security threats, the state of the art, and the challenges 🧐.

Plenty of steps have been taken over the last few years (summarized in Section 4.1), and many organizations are publishing general recommendations on how IoT should be secured (Section 4.3) 🙌. But there are still lots of challenges that need more attention 🚧. The big ones are bootstrapping of security, group security, secure software updates, long-term security and quantum-resistance, privacy protection, data leakage prevention (where the data could be cryptographic keys, personal data, or even algorithms), and ensuring trustworthy IoT operation 🔑🫶.

Authors of new IoT specifications and implementers need to think about how all the security challenges discussed in this document (and those that show up later) affect their work 🧠. The authors of IoT specifications need to put in a real effort, not only into addressing the security challenges but also into clearly documenting how they're addressed 📝. That helps cut down the chances of security vulnerabilities in the code written by implementers of those specifications 💅🔥.

7. Security Considerations 🔐💀

This entire memo deals with security issues. Like, the whole thing. Every single page 😭🔐.

8. IANA Considerations 🧚

This document has no IANA actions 🌸.

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.

okay the reading list keeps going and it's honestly so good 📚💖 these are the receipts for everything we've been talking about 🫶

[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.
[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/Security_Guidance_for_Early_Adopters_of_the_Internet_of_Things.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/>.
[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.
[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>.
[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/>.
[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>.

[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>.

[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>.

[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>.

[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>.

[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/>.

Okay bestie, the reference list is where all the receipts live 🧾💖 Every single source the document leans on is below, with its details exactly as written.

[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>.
[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/>.
[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.

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 ✨

📦 where this page comes from

ietf: rfc8576 2019-04
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms