idnits 2.17.00 (12 Aug 2021) /tmp/idnits49205/draft-moran-iot-nets-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 225: '...y IoT network, devices MUST be able to...' RFC 2119 keyword, line 238: '...ices, authorized entities MUST be able...' RFC 2119 keyword, line 260: '... devices SHOULD support a secure...' RFC 2119 keyword, line 264: '...ecurely, devices SHOULD support a supp...' RFC 2119 keyword, line 270: '... SHOULD support a remote update ...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2021) is 306 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IoTopia' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'SWID' is defined on line 397, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-rats-eat-09 == Outdated reference: A later version (-21) exists of draft-ietf-sacm-coswid-17 == Outdated reference: A later version (-17) exists of draft-ietf-suit-manifest-12 == Outdated reference: A later version (-17) exists of draft-ietf-teep-architecture-14 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IOTOPS B. Moran 3 Internet-Draft Arm Limited 4 Intended status: Informational July 12, 2021 5 Expires: January 13, 2022 7 A summary of security-enabling technologies for IoT devices 8 draft-moran-iot-nets-00 10 Abstract 12 The IETF regularly develops new technologies. Sometimes there are 13 several standards that can be combined to become vastly more than the 14 sum of their parts. Right now, there are six technologies either 15 recently adopted or poised for adoption that create such a cluster. 16 Combining secure onboarding, remote attestation, secure update, 17 software bill-of-materials/expected attestation, automated network 18 policy enforcement, and trusted execution environment provisioning, 19 devices can be defended from many threats. This is an opportunity 20 for an inflection point for more secure and trustworthy devices. 21 Simultaneous adoption of two or more of these six standards could 22 create the foundation of computing devices that are worth trusting. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 13, 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Barriers to IoT Adoption . . . . . . . . . . . . . . . . . . 3 60 3. Foundations of Trustworthy IoT . . . . . . . . . . . . . . . 3 61 3.1. Detecting a Compromise . . . . . . . . . . . . . . . . . 4 62 3.2. Halting Malicious Activity . . . . . . . . . . . . . . . 5 63 3.3. Remedying Vulnerabilities . . . . . . . . . . . . . . . . 5 64 4. Baseline Requirements for Secure Networks . . . . . . . . . . 5 65 5. IoT Technologies for Secure Networks . . . . . . . . . . . . 6 66 5.1. Trust Relationships in Secure IoT Networks . . . . . . . 7 67 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 IoT devices (unattended devices with network connections) are often 73 considered a weak point in networks and have often been used by 74 malicious parties to extract information, serve as relays, or mount 75 attacks. Appropriate use of security technologies can mitigate this 76 trend and enable users allow for security polices that do not have to 77 be overly protective of IoT systems and enable them to add the full 78 potential of value they were designed to add. 80 This draft addresses six trustworthiness problems in IoT devices and 81 proposes solutions to them with six technologies. The problems are: 83 1. What software is my device running? 85 2. How should my device connect to a network? 87 3. With which systems should my device communicate? 89 4. What is the provenance of my device's software? 91 5. Who is authorised to initiate a software update and under what 92 circumstances? 94 6. How should my device update its trusted software? 95 Each of these questions is answered by recently developed or 96 developing standards. 98 2. Barriers to IoT Adoption 100 IoT adoption is generally presented as a platform problem or a data 101 acquisition and analysis problem. The result is a proliferation of 102 communication formats, radio standards, network technologies, 103 operating systems, data gathering schemes, etc. Despite this effort, 104 IoT is not growing at the projected rates. 106 IoT is not simply a combination of a device platform and a data- 107 gathering platform. In the life-cycle of devices, they must be 108 commissioned and onboarded. When a flaw is discovered, they must be 109 updated to restore trustworthiness and there must be evidence that 110 they are effectively trustworthy (e.g. running the intended/expected 111 software). Acknowledging the chance of security breaches, network 112 infrastructure must be configured to allow access to necessary 113 services and restrict access to everything else. 115 Commissioning, onboarding, attestation, update, and access control 116 are complex core technologies that are difficult to implement well. 117 This can be seen with the plethora of poorly implemented IoT devices 118 that have been reported in the news whenever a defect is found. 120 IoT adoption is hampered by a lack of core technologies surrounding 121 the development of trustworthy devices and device trustworthiness. 122 These core technologies do not present obvious revenue streams and 123 they require cooperation between many vendors for them to succeed, 124 which may explain the low rate of innovation in this space. 126 To reduce this barrier to entry, the IETF has been investing in these 127 core technologies. 129 3. Foundations of Trustworthy IoT 131 IoT devices can bring a lot of value to businesses and individuals, 132 but they are also difficult to manage because of their diversity, 133 difficulty in auditing, maintenance, onboarding practices, and lack 134 of visibility about device security posture and device software. 136 Initiatives such as PSA Certified focus on device level security 137 principles and encourage the use of a hardware Root of Trust (RoT) 138 that provides a source of confidentiality and integrity for IoT 139 systems. The security principles led security requirements of PSA 140 Certified Level 1 cover topics such as trusted boot, validating 141 updates, attestation and secure communications. Complementary to 142 this, IETF provides standards that can be used to create secure 143 networks; this memo focuses on six standards that can beneficially be 144 used together at the network level. 146 Building trustworthy IoT is about more than just building devices 147 conforming to best-practice security. Users, Owners, Operators, and 148 Vendors must be able to respond when a compromise occurs. Responding 149 to compromised IoT consists of three key points: 151 1. Detecting a compromise 153 2. Halting malicious activity 155 3. Remedying vulnerabilities and flawed software. 157 Once a compromise has been detected, the affected device needs to be 158 quarantined from the network, then security patches must be applied. 160 3.1. Detecting a Compromise 162 There are two broadly applicable ways to remotely detect a 163 compromised IoT device: 165 1. Detect anomalous software on the device. 167 2. Detect anomalous network traffic from the device. 169 Detecting anomalous software on the device requires remote 170 attestation of software measurements; the report of what software the 171 device is running must be trustworthy even if the software is not. 172 However, attestation is an incomplete solution if the recipient of 173 attestation evidence does not know what to expect. Hence, 174 trustworthy and authortative sources with understanding of what is to 175 be expected are required. Furthermore, automated systems for 176 delivering these expected values must be very secure or else they 177 will become targets for threat actors as well. 179 Detecting anomalous traffic from the device requires a baseline of 180 expected traffic; otherwise, network infrastructure cannot know what 181 traffic is legitimate and what is not. This expected traffic 182 information needs to be closely associated with each individual 183 device, since network traffic patterns may shift from device to 184 device or version to version. These trustworthy and authoritative 185 sources of patterns must also be protected: a compromised device 186 could report an incorrect expected network traffic pattern, or a 187 threat actor could modify an expected network traffic pattern. 189 3.2. Halting Malicious Activity 191 Halting malicious activity is done by network infrastructure. A 192 Network Access Control (NAC) system, such as a router, gateway, 193 firewall, or L3 managed switch, can apply a network access policy on 194 a per-device basis. The NAC system uses a policy that is provided to 195 it in advance in order to determine the access requirements of each 196 connected autonomous device. Assuming that these policies are 197 constructed according to the principle of least privilege, This 198 allows the NAC system to drop any communication that does not match 199 the defined policies, effectively eliminating the use of IoT devices 200 as relays, proxies, or mechanism to pivot in a network. It may even 201 prevent compromises before they occur because inbound traffic to IoT 202 devices that does not conform to policy can be discarded. 204 For shared media, such as radio protocols, intra-LAN policies cannot 205 be preemptively effectively enforced, but they can be monitored and 206 enforced after violation, for example by removing network access 207 rights. Per-device Internet-to-LAN policies and LAN-to-Internet 208 policies can still be applied as normal. 210 3.3. Remedying Vulnerabilities 212 Remedying vulnerabilities requires a remote update system. Where 213 there are secure components that are independently updatable, 214 additional considerations are required. In both cases, the new 215 software must be signed, but that alone is insufficient: new software 216 must be authenticated against a known, authorized party. It must 217 also come with a statement of provenance: a software bill of 218 materials or SBoM. This statement must describe all the components 219 of the software along with defining the authorship of the software, 220 which may be separate from the authority to install that software on 221 a given device. 223 4. Baseline Requirements for Secure Networks 225 To establish a trustworthy IoT network, devices MUST be able to 226 prove: 228 1. What software they are running and, by extension: 230 1. The provenance of the software. 232 2. (Optionally) that it has been checked for common malware, 233 backdoors, etc. 235 2. Who they will connect to or exchange data with so that anomalies 236 can be registered. 238 To install and maintain IoT devices, authorized entities MUST be able 239 to: 241 1. Connect a device to a secure network. 243 2. Initiate an update of a device. 245 3. (Optionally) Add or remove authorized entities from the device. 247 4. (Optionally) Deploy and remove protected assets to and from the 248 device. 250 Each of these requirements stops a particular avenue of attack 251 against device, networks, or data collection systems. 253 5. IoT Technologies for Secure Networks 255 Assembling the foundations of trustworthy IoT and the baseline 256 requirements for secure networks, the result is a set of 257 requirements, described here with enabling standards: 259 1. To deploy new keys into a device and connect it to a network, 260 devices SHOULD support a secure onboarding protocol such as FIDO 261 Device Onboarding [FDO] or LwM2M Bootstrap ([LwM2M]). 263 2. To enable devices to report their current software version and 264 related data securely, devices SHOULD support a support a 265 mechanism of performing attestation measurements in a trustworthy 266 way and a Remote Attestation protocol, such as 267 [I-D.ietf-rats-eat]. 269 3. To enable devices to be updated securely in the field, they 270 SHOULD support a remote update protocol such as 271 [I-D.ietf-suit-manifest]. 273 4. To prove the provenance of a firmware update, update manifests 274 SHOULD include (directly, or by secure reference) a Software 275 Identifier or Software Bill of Materials, such as 276 [I-D.ietf-sacm-coswid]. 278 5. To enable a Relying Party of the Remote Attestation to correctly 279 evaluate the Attestation Report, the SBoM (such as 280 [I-D.ietf-sacm-coswid]) SHOULD contain expected values for the 281 Attestation Report. 283 6. To ensure that network infrastructure is configured discern the 284 difference between authentic traffic and anomalous traffic, 285 network infrastructure SHOULD contain a [RFC8520] Manufacturer 286 Usage Description (MUD) Controller which accepts MUD files in 287 order to automatically program rules into the network 288 infrastructure. 290 7. In order for network infrastructure to be configured in advance 291 of any changes to devices, MUD files SHOULD be transported 292 (directly or by secure reference) within update manifests. 294 8. To enable rapid response to evolving threats, the MUD controller 295 SHOULD also support dynamic update of MUD files. 297 9. Network infrastructure SHOULD apply risk management policy to 298 devices that attest non-compliant configuration. For example, a 299 device with out-of-date firmware may only be permitted to access 300 the update system. 302 5.1. Trust Relationships in Secure IoT Networks 304 [FDO] and [LwM2M] enable the installation of trust anchors in IoT 305 devices. These enable the services to ascertain that the devices are 306 not counterfeit. They also enable the devices to trust that the 307 services are not on-path attackers. 309 The combination of SUIT, CoSWID and RATS Attestation secures these 310 trust relationships further. A device operator receives a SUIT 311 manifest, that contains a CoSWID. They apply the SUIT manifest to a 312 device. The newly updated device then attests its software version 313 (one or more digests) to the device operator's infrastructure. The 314 device operator can then automatically compare the attestation 315 evidence to the CoSWID. 317 The device operator can trust that expected values are correct 318 because they are signed by the software author. The device operator 319 can trust that the attestation report is correct because it is signed 320 by the verifier and, finally, the device operator can trust the 321 device because its attestation evidence content matches its CoSWID. 323 To extend this relationship to Trusted Applications (TAs) as well, 324 devices that support TAs can also implement 325 [I-D.ietf-teep-architecture]. 327 Adding MUD to the combination above cements the established trust 328 with enforcement. The network operator also receives the SUIT 329 manifest for the device. The manifest contains a MUD file in 330 addition to the above. The device does not need to report a MUD URI 331 as described in [RFC8520]-which stops the device from falsifying it. 332 Instead, the network operator also receives an attestation report for 333 the device. If the attestation report matches the CoSWID in the 334 manifest, then the network operator automatically applies the MUD 335 file that is also contained in the manifest. This allows a secure 336 link to be established between a particular MUD file and a particular 337 software version. 339 The trust relationships are somewhat more complex with MUD: the 340 network operator may not trust the software author to produce 341 vulnerability-free software. This means that the network operator 342 may choose to override the MUD file in the manifest. Because the MUD 343 file is not even reported by the device, the network operator is free 344 to do this. The network operator can trust the attestation report 345 because it is signed by the verifier. They trust that the values 346 reported in the CoSWID are accurate because it is signed by the 347 software author who also signs the software. They trust that the 348 device is running the software described in the CoSWID because it 349 matches the attestation report. They trust the MUD file because it 350 is signed by the software author - or because they have supplied that 351 MUD file themselves. MUD files may also be obtained from third-party 352 providers, such as Global Platform Iotopia 353 (https://globalplatform.org/iotopia/mud-file-service/). 355 6. Normative References 357 [FDO] FIDO Alliance, ., "FIDO Device Onboarding", n.d., 358 . 361 [I-D.ietf-rats-eat] 362 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 363 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 364 ietf-rats-eat-09 (work in progress), March 2021. 366 [I-D.ietf-sacm-coswid] 367 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 368 Waltermire, "Concise Software Identification Tags", draft- 369 ietf-sacm-coswid-17 (work in progress), February 2021. 371 [I-D.ietf-suit-manifest] 372 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 373 "A Concise Binary Object Representation (CBOR)-based 374 Serialization Format for the Software Updates for Internet 375 of Things (SUIT) Manifest", draft-ietf-suit-manifest-12 376 (work in progress), February 2021. 378 [I-D.ietf-teep-architecture] 379 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 380 "Trusted Execution Environment Provisioning (TEEP) 381 Architecture", draft-ietf-teep-architecture-14 (work in 382 progress), February 2021. 384 [IoTopia] "Global Platform Iotopia", n.d., 385 . 387 [LwM2M] "LwM2M Core Specification", n.d., 388 . 392 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 393 Description Specification", RFC 8520, 394 DOI 10.17487/RFC8520, March 2019, 395 . 397 [SWID] NIST, ., "Software Identification (SWID) Tagging", n.d., 398 . 401 Author's Address 403 Brendan Moran 404 Arm Limited 406 EMail: Brendan.Moran@arm.com