idnits 2.17.1 draft-ietf-suit-information-model-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 02, 2018) is 2123 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1329 == Unused Reference: 'RFC4122' is defined on line 1313, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-suit-architecture-01 ** Downref: Normative reference to an Informational draft: draft-ietf-suit-architecture (ref. 'I-D.ietf-suit-architecture') Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUIT B. Moran 3 Internet-Draft H. Tschofenig 4 Intended status: Standards Track Arm Limited 5 Expires: January 3, 2019 H. Birkholz 6 Fraunhofer SIT 7 July 02, 2018 9 Firmware Updates for Internet of Things Devices - An Information Model 10 for Manifests 11 draft-ietf-suit-information-model-01 13 Abstract 15 Vulnerabilities with Internet of Things (IoT) devices have raised the 16 need for a solid and secure firmware update mechanism that is also 17 suitable for constrained devices. Incorporating such update 18 mechanism to fix vulnerabilities, to update configuration settings as 19 well as adding new functionality is recommended by security experts. 21 One component of such a firmware update is the meta-data, or 22 manifest, that describes the firmware image(s) and offers appropriate 23 protection. This document describes all the information that must be 24 present in the manifest. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 3, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 74 3. Motivation for Manifest Fields . . . . . . . . . . . . . . . 5 75 3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 5 76 3.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 6 77 3.2.1. Threat MFT1: Old Firmware . . . . . . . . . . . . . . 6 78 3.2.2. Threat MFT2: Mismatched Firmware . . . . . . . . . . 6 79 3.2.3. Threat MFT3: Offline device + Old Firmware . . . . . 7 80 3.2.4. Threat MFT4: The target device misinterprets the type 81 of payload . . . . . . . . . . . . . . . . . . . . . 7 82 3.2.5. Threat MFT5: The target device installs the payload 83 to the wrong location . . . . . . . . . . . . . . . . 7 84 3.2.6. Threat MFT6: Redirection . . . . . . . . . . . . . . 8 85 3.2.7. Threat MFT7: Payload Verification on Boot . . . . . . 8 86 3.2.8. Threat MFT8: Unauthenticated Updates . . . . . . . . 8 87 3.2.9. Threat MFT9: Unexpected Precursor images . . . . . . 8 88 3.2.10. Threat MFT10: Unqualified Firmware . . . . . . . . . 9 89 3.2.11. Threat MFT11: Reverse Engineering Of Firmware Image 90 for Vulnerability Analysis . . . . . . . . . . . . . 10 91 3.2.12. Threat MFT12: Overriding Critical Manifest Elements . 10 92 3.3. Security Requirements . . . . . . . . . . . . . . . . . . 11 93 3.3.1. Security Requirement MFSR1: Monotonic Sequence 94 Numbers . . . . . . . . . . . . . . . . . . . . . . . 11 95 3.3.2. Security Requirement MFSR2: Vendor, Device-type 96 Identifiers . . . . . . . . . . . . . . . . . . . . . 11 97 3.3.3. Security Requirement MFSR3: Best-Before Timestamps . 11 98 3.3.4. Security Requirement MFSR5: Cryptographic 99 Authenticity . . . . . . . . . . . . . . . . . . . . 12 100 3.3.5. Security Requirement MFSR4a: Authenticated Payload 101 Type . . . . . . . . . . . . . . . . . . . . . . . . 12 102 3.3.6. Security Requirement MFSR4b: Authenticated Storage 103 Location . . . . . . . . . . . . . . . . . . . . . . 12 104 3.3.7. Security Requirement MFSR4c: Authenticated Remote 105 Resource Location . . . . . . . . . . . . . . . . . . 12 106 3.3.8. Security Requirement MFSR4d: Secure Boot . . . . . . 13 107 3.3.9. Security Requirement MFSR4e: Authenticated precursor 108 images . . . . . . . . . . . . . . . . . . . . . . . 13 109 3.3.10. Security Requirement MFSR4f: Authenticated Vendor and 110 Class IDs . . . . . . . . . . . . . . . . . . . . . . 13 111 3.3.11. Security Requirement MFSR4f: Authenticated Vendor and 112 Class IDs . . . . . . . . . . . . . . . . . . . . . . 13 113 3.3.12. Security Requirement MFSR6: Rights Require 114 Authenticity . . . . . . . . . . . . . . . . . . . . 13 115 3.3.13. Security Requirement MFSR7: Firmware encryption . . . 14 116 3.3.14. Security Requirement MFSR8: Access Control Lists . . 14 117 3.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 14 118 3.4.1. Use Case MFUS1: Installation Instructions . . . . . . 15 119 3.4.2. Use Case MFUS2: Override Non-Critical Manifest 120 Elements . . . . . . . . . . . . . . . . . . . . . . 15 121 3.4.3. Use Case MFUS3: Modular Update . . . . . . . . . . . 16 122 3.4.4. Use Case MFUS4: Multiple Authorisations . . . . . . . 16 123 3.4.5. Use Case MFUS5: Multiple Payload Formats . . . . . . 16 124 3.4.6. Use Case MFUS6: Prevent Confidential Information 125 Disclosures . . . . . . . . . . . . . . . . . . . . . 16 126 3.4.7. Use Case MFUS7: Prevent Devices from Unpacking 127 Unknown Formats . . . . . . . . . . . . . . . . . . . 16 128 3.4.8. Use Case MFUS8: Specify Version Numbers of Target 129 Firmware . . . . . . . . . . . . . . . . . . . . . . 17 130 3.4.9. Use Case MFUS9: Enable devices to choose between 131 images . . . . . . . . . . . . . . . . . . . . . . . 17 132 3.5. Usability Requirements . . . . . . . . . . . . . . . . . 17 133 3.5.1. Usability Requirement MFUR1 . . . . . . . . . . . . . 17 134 3.5.2. Usability Requirement MFUR2 . . . . . . . . . . . . . 17 135 3.5.3. Usability Requirement MFUR3 . . . . . . . . . . . . . 18 136 3.5.4. Usability Requirement MFUR4 . . . . . . . . . . . . . 19 137 3.5.5. Usability Requirement MFUR5 . . . . . . . . . . . . . 19 138 3.5.6. Usability Requirement MFUR6 . . . . . . . . . . . . . 19 139 3.5.7. Usability Requirement MFUR7 . . . . . . . . . . . . . 19 140 3.5.8. Usability Requirement MFUR8 . . . . . . . . . . . . . 20 141 4. Manifest Information Elements . . . . . . . . . . . . . . . . 20 142 4.1. Manifest Element: version identifier of the manifest 143 structure . . . . . . . . . . . . . . . . . . . . . . . . 20 145 4.2. Manifest Element: Monotonic Sequence Number . . . . . . . 20 146 4.3. Manifest Element: Vendor ID Condition . . . . . . . . . . 20 147 4.3.1. Example: Domain Name-based UUIDs . . . . . . . . . . 21 148 4.4. Manifest Element: Class ID Condition . . . . . . . . . . 21 149 4.4.1. Example 1: Different Classes . . . . . . . . . . . . 21 150 4.4.2. Example 2: Upgrading Class ID . . . . . . . . . . . . 22 151 4.4.3. Example 3: Shared Functionality . . . . . . . . . . . 22 152 4.5. Manifest Element: Precursor Image Digest Condition . . . 23 153 4.6. Manifest Element: Required Image Version List . . . . . . 23 154 4.7. Manifest Element: Best-Before timestamp condition . . . . 23 155 4.8. Manifest Element: Payload Format . . . . . . . . . . . . 23 156 4.9. Manifest Element: Processing Steps . . . . . . . . . . . 24 157 4.10. Manifest Element: Storage Location . . . . . . . . . . . 24 158 4.10.1. Example 1: Two Storage Locations . . . . . . . . . . 24 159 4.10.2. Example 2: File System . . . . . . . . . . . . . . . 24 160 4.10.3. Example 3: Flash Memory . . . . . . . . . . . . . . 24 161 4.11. Manifest Element: Component Identifier . . . . . . . . . 25 162 4.12. Manifest Element: URIs . . . . . . . . . . . . . . . . . 25 163 4.13. Manifest Element: Payload Digest . . . . . . . . . . . . 25 164 4.14. Manifest Element: Size . . . . . . . . . . . . . . . . . 25 165 4.15. Manifest Element: Signature . . . . . . . . . . . . . . . 26 166 4.16. Manifest Element: Directives . . . . . . . . . . . . . . 26 167 4.17. Manifest Element: Aliases . . . . . . . . . . . . . . . . 26 168 4.18. Manifest Element: Dependencies . . . . . . . . . . . . . 26 169 4.19. Manifest Element: Content Key Distribution Method . . . . 27 170 4.20. Manifest Element: XIP Address . . . . . . . . . . . . . . 27 171 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 172 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 173 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 174 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 175 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 176 8.2. Informative References . . . . . . . . . . . . . . . . . 28 177 Appendix A. Mailing List Information . . . . . . . . . . . . . . 29 178 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 180 1. Introduction 182 The information model describes all the information elements required 183 to secure firmware updates of IoT devices from the threats described 184 in Section 3.1 and enable the user stories captured in Section 3.4. 185 These threats and user stories are not intended to be an exhaustive 186 list of the threats against IoT devices, nor of the possible use 187 cases of firmware update; instead they are intended to describe the 188 threats against firmware update in isolation and provide sufficient 189 motivation to provide information elements that cover a wide range of 190 use cases. The information model does not define the encoding, 191 ordering, or structure of information elements, only their semantics. 193 Because the information model covers a wide range of user stories and 194 a wide range of threats, not all information elements apply to all 195 scenarios. As a result, many information elements could be 196 considered optional to implement and optional to use, depending on 197 which threats exist in a particular system and which use cases are 198 required. Elements marked as mandatory provide baseline security and 199 usability properties that are expected to be required for most 200 applications. Those elements are mandatory to implement and 201 mandatory to use. Elements marked as recommended provide important 202 security or usability properties that are needed on most devices. 203 Elements marked as optional enable security or usability properties 204 that are useful in some applications. 206 2. Conventions and Terminology 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 210 "OPTIONAL" in this document are to be interpreted as described in RFC 211 2119 [RFC2119]. 213 This document uses terms defined in [I-D.ietf-suit-architecture]. 214 The term 'Operator' refers to both, Device and Network Operator. 216 3. Motivation for Manifest Fields 218 The following sub-sections describe the threat model, user stories, 219 security requirements, and usability requirements. 221 3.1. Threat Model 223 The following sub-sections aim to provide information about the 224 threats that were considered, the security requirements that are 225 derived from those threats and the fields that permit implementation 226 of the security requirements. This model uses the S.T.R.I.D.E. 227 [STRIDE] approach. Each threat is classified according to: 229 - Spoofing Identity 231 - Tampering with data 233 - Repudiation 235 - Information disclosure 237 - Denial of service 239 - Elevation of privilege 240 This threat model only covers elements related to the transport of 241 firmware updates. It explicitly does not cover threats outside of 242 the transport of firmware updates. For example, threats to an IoT 243 device due to physical access are out of scope. 245 3.2. Threat Descriptions 247 3.2.1. Threat MFT1: Old Firmware 249 Classification: Elevation of Privilege 251 An attacker sends an old, but valid manifest with an old, but valid 252 firmware image to a device. If there is a known vulnerability in the 253 provided firmware image, this may allow an attacker to exploit the 254 vulnerability and gain control of the device. 256 Threat Escalation: If the attacker is able to exploit the known 257 vulnerability, then this threat can be escalated to ALL TYPES. 259 Mitigated by: MFSR1 261 3.2.2. Threat MFT2: Mismatched Firmware 263 Classification: Denial of Service 265 An attacker sends a valid firmware image, for the wrong type of 266 device, signed by an actor with firmware installation permission on 267 both types of device. The firmware is verified by the device 268 positively because it is signed by an actor with the appropriate 269 permission. This could have wide-ranging consequences. For devices 270 that are similar, it could cause minor breakage, or expose security 271 vulnerabilities. For devices that are very different, it is likely 272 to render devices inoperable. 274 Mitigated by: MFSR2 276 Example: 278 Suppose that two vendors, Vendor A and Vendor B, adopt the same trade 279 name in different geographic regions, and they both make products 280 with the same names, or product name matching is not used. This 281 causes firmware from Vendor A to match devices from Vendor B. 283 If the vendors are the firmware authorities, then devices from Vendor 284 A will reject images signed by Vendor B since they use different 285 credentials. However, if both devices trust the same firmware 286 authority, then, devices from Vendor A could install firmware 287 intended for devices from Vendor B. 289 3.2.3. Threat MFT3: Offline device + Old Firmware 291 Classification: Elevation of Privilege 293 An attacker targets a device that has been offline for a long time 294 and runs an old firmware version. The attacker sends an old, but 295 valid manifest to a device with an old, but valid firmware image. 296 The attacker-provided firmware is newer than the installed one but 297 older than the most recently available firmware. If there is a known 298 vulnerability in the provided firmware image then this may allow an 299 attacker to gain control of a device. Because the device has been 300 offline for a long time, it is unaware of any new updates. As such 301 it will treat the old manifest as the most current. 303 Threat Escalation: If the attacker is able to exploit the known 304 vulnerability, then this threat can be escalated to ALL TYPES. 306 Mitigated by: MFSR3 308 3.2.4. Threat MFT4: The target device misinterprets the type of payload 310 Classification: Denial of Service 312 If a device misinterprets the type of the firmware image, it may 313 cause a device to install a firmware image incorrectly. An 314 incorrectly installed firmware image would likely cause the device to 315 stop functioning. 317 Threat Escalation: An attacker that can cause a device to 318 misinterpret the received firmware image may gain elevation of 319 privilege and potentially expand this to all types of threat. 321 Mitigated by: MFSR4a 323 3.2.5. Threat MFT5: The target device installs the payload to the wrong 324 location 326 Classification: Denial of Service 328 If a device installs a firmware image to the wrong location on the 329 device, then it is likely to break. For example, a firmware image 330 installed as an application could cause a device and/or an 331 application to stop functioning. 333 Threat Escalation: An attacker that can cause a device to 334 misinterpret the received code may gain elevation of privilege and 335 potentially expand this to all types of threat. 337 Mitigated by: MFSR4b 339 3.2.6. Threat MFT6: Redirection 341 Classification: Denial of Service 343 If a device does not know where to obtain the payload for an update, 344 it may be redirected to an attacker's server. This would allow an 345 attacker to provide broken payloads to devices. 347 Mitigated by: MFSR4c 349 3.2.7. Threat MFT7: Payload Verification on Boot 351 Classification: Elevation of Privilege 353 An attacker replaces a newly downloaded firmware after a device 354 finishes verifying a manifest. This could cause the device to 355 execute the attacker's code. This attack likely requires physical 356 access to the device. However, it is possible that this attack is 357 carried out in combination with another threat that allows remote 358 execution. 360 Threat Escalation: If the attacker is able to exploit a known 361 vulnerability, or if the attacker can supply their own firmware, then 362 this threat can be escalated to ALL TYPES. 364 Mitigated by: MFSR4d 366 3.2.8. Threat MFT8: Unauthenticated Updates 368 Classification: Elevation of Privilege 370 If an attacker can install their firmware on a device, by 371 manipulating either payload or metadata, then they have complete 372 control of the device. 374 Threat Escalation: If the attacker is able to exploit a known 375 vulnerability, or if the attacker can supply their own firmware, then 376 this threat can be escalated to ALL TYPES. 378 Mitigated by: MFSR5 380 3.2.9. Threat MFT9: Unexpected Precursor images 382 Classification: Denial of Service 383 An attacker sends a valid, current manifest to a device that has an 384 unexpected precursor image. If a payload format requires a precursor 385 image (for example, delta updates) and that precursor image is not 386 available on the target device, it could cause the update to break. 388 Threat Escalation: An attacker that can cause a device to install a 389 payload against the wrong precursor image could gain elevation of 390 privilege and potentially expand this to all types of threat. 392 Mitigated by: MFSR4e 394 3.2.10. Threat MFT10: Unqualified Firmware 396 Classification: Denial of Service, Elevation of Privilege 398 This threat can appear in several ways, however it is ultimately 399 about interoperability of devices with other systems. The owner or 400 operator of a network needs to approve firmware for their network in 401 order to ensure interoperability with other devices on the network, 402 or the network itself. If the firmware is not qualified, it may not 403 work. Therefore, if a device installs firmware without the approval 404 of the network owner or operator, this is a threat to devices and the 405 network. 407 Threat Escalation: If the firmware expects configuration that is 408 present in devices deployed in Network A, but not in devices deployed 409 in Network B, then the device may experience degraded security, 410 leading to threats of All Types. 412 Mitigated by: MFSR6, MFSR8 414 3.2.10.1. Example 1: Multiple Network Operators with a Single Device 415 Operator 417 In this example let us assume that Device Operators expect the rights 418 to create firmware but that Network Operators expect the rights to 419 qualify firmware as fit-for-purpose on their networks. Additionally 420 assume that an Device Operators manage devices that can be deployed 421 on any network, including Network A and B in our example. 423 An attacker may obtain a manifest for a device on Network A. Then, 424 this attacker sends that manifest to a device on Network B. Because 425 Network A and Network B are under control of different Operators, and 426 the firmware for a device on Network A has not been qualified to be 427 deployed on Network B, the target device on Network B is now in 428 violation of the Operator B's policy and may get disabled by this 429 unqualified, but signed firmware. 431 This is a denial of service because it can render devices inoperable. 432 This is an elevation of privilege because it allows the attacker to 433 make installation decisions that should be made by the Operator. 435 3.2.10.2. Example 2: Single Network Operator with Multiple Device 436 Operators 438 Multiple devices that interoperate are used on the same network and 439 communicate with each other. Some devices are manufactured and 440 managed by Device Operator A and other devices by Device Operator B. 441 A new firmware is released by Device Operator A that breaks 442 compatibility with devices from Device Operator B. An attacker sends 443 the new firmware to the devices managed by Device Operator A without 444 approval of the Network Operator. This breaks the behaviour of the 445 larger system causing denial of service and possibly other threats. 446 Where the network is a distributed SCADA system, this could cause 447 misbehaviour of the process that is under control. 449 3.2.11. Threat MFT11: Reverse Engineering Of Firmware Image for 450 Vulnerability Analysis 452 Classification: All Types 454 An attacker wants to mount an attack on an IoT device. To prepare 455 the attack he or she retrieves the provided firmware image and 456 performs reverse engineering of the firmware image to analyze it for 457 specific vulnerabilities. 459 Mitigated by: MFSR7 461 3.2.12. Threat MFT12: Overriding Critical Manifest Elements 463 Classification: Elevation of Privilege 465 An authorised actor, but not the firmware authority, uses an override 466 mechanism (MFUS2) to change an information element in a manifest 467 signed by the firmware authority. For example, if the authorised 468 actor overrides the digest and URI of the payload, the actor can 469 replace the entire payload with a payload of their choice. 471 Threat Escalation: By overriding elements such as payload 472 installation instructions or firmware digest, this threat can be 473 escalated to all types. 475 Mitigated by: MFSR8 477 3.3. Security Requirements 479 The security requirements here are a set of policies that mitigate 480 the threats described in Section 3.1. 482 3.3.1. Security Requirement MFSR1: Monotonic Sequence Numbers 484 Only an actor with firmware installation authority is permitted to 485 decide when device firmware can be installed. To enforce this rule, 486 manifests MUST contain monotonically increasing sequence numbers. 487 Manifests MAY use UTC epoch timestamps to coordinate monotonically 488 increasing sequence numbers across many actors in many locations. If 489 UTC epoch timestamps are used, they MUST NOT be treated as times, 490 they MUST be treated only as sequence numbers. Devices MUST reject 491 manifests with sequence numbers smaller than any onboard sequence 492 number. 494 Note: This is not a firmware version. It is a manifest sequence 495 number. A firmware version may be rolled back by creating a new 496 manifest for the old firmware version with a later sequence number. 498 Mitigates: Threat MFT1 500 Implemented by: Manifest Element: Monotonic Sequence Number 502 3.3.2. Security Requirement MFSR2: Vendor, Device-type Identifiers 504 Devices MUST only apply firmware that is intended for them. Devices 505 MUST know with fine granularity that a given update applies to their 506 vendor, model, hardware revision, software revision. Human-readable 507 identifiers are often error-prone in this regard, so unique 508 identifiers SHOULD be used. 510 Mitigates: Threat MFT2 512 Implemented by: Manifest Elements: Vendor ID Condition, Class ID 513 Condition 515 3.3.3. Security Requirement MFSR3: Best-Before Timestamps 517 Firmware MAY expire after a given time. Devices MAY provide a secure 518 clock (local or remote). If a secure clock is provided and the 519 Firmware manifest has a best-before timestamp, the device MUST reject 520 the manifest if current time is larger than the best-before time. 522 Mitigates: Threat MFT3 524 Implemented by: Manifest Element: Best-Before timestamp condition 526 3.3.4. Security Requirement MFSR5: Cryptographic Authenticity 528 The authenticity of an update must be demonstrable. Typically, this 529 means that updates must be digitally authenticated. Because the 530 manifest contains information about how to install the update, the 531 manifest's authenticity must also be demonstrable. To reduce the 532 overhead required for validation, the manifest contains the digest of 533 the firmware image, rather than a second digital signature. The 534 authenticity of the manifest can be verified with a digital signature 535 or Message Authentication Code, the authenticity of the firmware 536 image is tied to the manifest by the use of a digest of the firmware 537 image. 539 Mitigates: Threat MFT8 541 Implemented by: Signature, Payload Digest 543 3.3.5. Security Requirement MFSR4a: Authenticated Payload Type 545 The type of payload (which may be independent of format) MUST be 546 authenticated. For example, the target must know whether the payload 547 is XIP firmware, a loadable module, or serialized configuration data. 549 Mitigates: MFT4 551 Implemented by: Manifest Elements: Payload Format, Storage Location 553 3.3.6. Security Requirement MFSR4b: Authenticated Storage Location 555 The location on the target where the payload is to be stored MUST be 556 authenticated. 558 Mitigates: MFT5 560 Implemented by: Manifest Elements: Storage Location 562 3.3.7. Security Requirement MFSR4c: Authenticated Remote Resource 563 Location 565 The location where a target should find a payload MUST be 566 authenticated. 568 Mitigates: MFT6 570 Implemented by: Manifest Elements: URIs 572 3.3.8. Security Requirement MFSR4d: Secure Boot 574 The target SHOULD verify firmware at time of boot. This requires 575 authenticated payload size, and digest. 577 Mitigates: MFT7 579 Implemented by: Manifest Elements: Payload Digest, Size 581 3.3.9. Security Requirement MFSR4e: Authenticated precursor images 583 If an update uses a differential compression method, it MUST specify 584 the digest of the precursor image and that digest MUST be 585 authenticated. 587 Mitigates: MFT9 589 Implemented by: Manifest Elements: Precursor Image Digest Condition 591 3.3.10. Security Requirement MFSR4f: Authenticated Vendor and Class IDs 593 The identifiers that specify firmware compatibility MUST be 594 authenticated to ensure that only compatible firmware is installed on 595 a target device. 597 Mitigates: MFT2 599 Implemented By: Manifest Elements: Vendor ID Condition, Class ID 600 Condition 602 3.3.11. Security Requirement MFSR4f: Authenticated Vendor and Class IDs 604 The identifiers that specify firmware compatibility MUST be 605 authenticated to ensure that only compatible firmware is installed on 606 a target device. 608 Mitigates: MFT2 610 Implemented By: Manifest Elements: Vendor ID Condition, Class ID 611 Condition 613 3.3.12. Security Requirement MFSR6: Rights Require Authenticity 615 If a device grants different rights to different actors, exercising 616 those rights MUST be accompanied by proof of those rights, in the 617 form of proof of authenticity. Authenticity mechanisms such as those 618 required in MFSR5 are acceptable but need to follow the end-to-end 619 security model. 621 For example, if a device has a policy that requires that firmware 622 have both an Authorship right and a Qualification right and if that 623 device grants Authorship and Qualification rights to different 624 parties, such as a Device Operator and a Network Operator, 625 respectively, then the firmware cannot be installed without proof of 626 rights from both the Device and the Network Operator. 628 Mitigates: MFT10 630 Implemented by: Signature 632 3.3.13. Security Requirement MFSR7: Firmware encryption 634 The manifest information model must enable encrypted payloads. 635 Encryption helps to prevent third parties, including attackers, from 636 reading the content of the firmware image. This can protect against 637 confidential information disclosures and discovery of vulnerabilities 638 through reverse engineering. Therefore the manifest must convey the 639 information required to allow an intended recipient to decrypt an 640 encrypted payload. 642 Mitigates: MFT11 644 Implemented by: Manifest Element: Content Key Distribution Method 646 3.3.14. Security Requirement MFSR8: Access Control Lists 648 If a device grants different rights to different actors, then an 649 exercise of those rights must be validated against a list of rights 650 for the actor. This typically takes the form of an Access Control 651 List (ACL). ACLs are applied to two scenarios: 653 1. An ACL decides which elements of the manifest may be overridden 654 and by which actors. 656 2. An ACL decides which component identifier/storage identifier 657 pairs can be written by which actors. 659 Mitigates: MFT12, MFT10 661 Implemented by: Client-side code, not specified in manifest. 663 3.4. User Stories 665 User stories provide expected use cases. These are used to feed into 666 usability requirements. 668 3.4.1. Use Case MFUS1: Installation Instructions 670 As an Device Operator, I want to provide my devices with additional 671 installation instructions so that I can keep process details out of 672 my payload data. 674 Some installation instructions might be: 676 - Use a table of hashes to ensure that each block of the payload is 677 validate before writing. 679 - Do not report progress. 681 - Pre-cache the update, but do not install. 683 - Install the pre-cached update matching this manifest. 685 - Install this update immediately, overriding any long-running 686 tasks. 688 Satisfied by: MFUR1 690 3.4.2. Use Case MFUS2: Override Non-Critical Manifest Elements 692 As a Network Operator, I would like to be able to override the non- 693 critical information in the manifest so that I can control my devices 694 more precisely. This assumes that the Device Operator delegated 695 rights about the device to the Network Operator. 697 Some examples of potentially overridable information: 699 - URIs: this allows the Network Operator to direct devices to their 700 own infrastructure in order to reduce network load. 702 - Conditions: this allows the Network Operator to pose additional 703 constraints on the installation of the manifest. 705 - Directives: this allows the Network Operator to add more 706 instructions such as time of installation. 708 - Processing Steps: If an intermediary performs an action on behalf 709 of a device, it may need to override the processing steps. It is 710 still possible for a device to verify the final content and the 711 result of any processing step that specifies a digest. Some 712 processing steps should be non-overridable. 714 Satisfied by: MFUR2, MFUR3 716 3.4.3. Use Case MFUS3: Modular Update 718 As an Operator, I want to divide my firmware into frequently updated 719 and infrequently updated components, so that I can reduce the size of 720 updates and make different parties responsible for different 721 components. 723 Satisfied by: MFUR3 725 3.4.4. Use Case MFUS4: Multiple Authorisations 727 As a Device Operator, I want to ensure the quality of a firmware 728 update before installing it, so that I can ensure interoperability of 729 all devices in my product family. I want to restrict the ability to 730 make changes to my devices to require my express approval. 732 Satisfied by: MFUR4, MFSR8 734 3.4.5. Use Case MFUS5: Multiple Payload Formats 736 As an Operator, I want to be able to send multiple payload formats to 737 suit the needs of my update, so that I can optimise the bandwidth 738 used by my devices. 740 Satisfied by: MFUR5 742 3.4.6. Use Case MFUS6: Prevent Confidential Information Disclosures 744 As an firmware author, I want to prevent confidential information 745 from being disclosed during firmware updates. It is assumed that 746 channel security is adequate to protect the manifest itself against 747 information disclosure. 749 Satisfied by: MFSR7 751 3.4.7. Use Case MFUS7: Prevent Devices from Unpacking Unknown Formats 753 As a Device Operator, I want devices to determine whether they can 754 process a payload prior to downloading it. 756 In some cases, it may be desirable for a third party to perform some 757 processing on behalf of a target. For this to occur, the third party 758 MUST indicate what processing occurred and how to verify it against 759 the Trust Provisioning Authority's intent. 761 This amounts to overriding Processing Steps and URIs. 763 Satisfied by: MFUR6, MFUR2 765 3.4.8. Use Case MFUS8: Specify Version Numbers of Target Firmware 767 As a Device Operator, I want to be able to target devices for updates 768 based on their current firmware version, so that I can control which 769 versions are replaced with a single manifest. 771 Satisfied by: MFUR7 773 3.4.9. Use Case MFUS9: Enable devices to choose between images 775 As a developer, I want to be able to sign two or more versions of my 776 firmware in a single manifest so that I can use a very simple 777 bootloader that chooses between two or more images that are executed 778 in-place. 780 Satisfied by: MFUR8 782 3.5. Usability Requirements 784 The following usability requirements satisfy the user stories listed 785 above. 787 3.5.1. Usability Requirement MFUR1 789 It must be possible to provide all information necessary for the 790 processing of a manifest into the manifest. 792 Satisfies: User story MFUS1 794 Implemented by: Manifest Element: Directives 796 3.5.2. Usability Requirement MFUR2 798 It must be possible to redirect payload fetches. This applies where 799 two manifests are used in conjunction. For example, a Device 800 Operator creates a manifest specifying a payload and signs it, and 801 provides a URI for that payload. A Network Operator creates a second 802 manifest, with a dependency on the first. They use this second 803 manifest to override the URIs provided by the Device Operator, 804 directing them into their own infrastructure instead. Some devices 805 may provide this capability, while others may only look at canonical 806 sources of firmware. For this to be possible, the device must fetch 807 the payload, whereas a device that accpets payload pushes will ignore 808 this feature. 810 Satisfies: User story MFUS2 812 Implemented by: Manifest Element: Aliases 814 3.5.3. Usability Requirement MFUR3 816 It must be possible express the requirement to install one or more 817 payloads from one or more authorities so that a multi-payload update 818 can be described. This allows multiple parties with different 819 permissions to collaborate in creating a single update for the IoT 820 device, across multiple components. 822 This requirement effectively means that it must be possible to 823 construct a tree of manifests on a multi-image target. 825 Because devices can be either HeSA or HoSA both the storage system 826 and the storage location within that storage system must be possible 827 to specify. In a HoSA device, the payload location may be as simple 828 as an address, or a file path. In a HeSA device, the payload 829 location may be scoped by a component identifier. It is expedient to 830 consider that all HoSA devices are HeSA devices with a single 831 component. 833 3.5.3.1. Example 1: Multiple Microcontrollers 835 An IoT device with multiple microcontrollers in the same physical 836 device (HeSA) will likely require multiple payloads with different 837 component identifiers. 839 3.5.3.2. Example 2: Code and Configuration 841 A firmware image can be divided into two payloads: code and 842 configuration. These payloads may require authorizations from 843 different actors in order to install (see MFSR6 and MFSR8). This 844 structure means that multiple manifests may be required, with a 845 dependency structure between them. 847 3.5.3.3. Example 3: Multiple Chunks 849 A firmware image can be divided into multiple functional blocks for 850 separate testing and distribution. This means that code would need 851 to be distributed in multiple payloads. For example, this might be 852 desirable in order to ensure that common code between devices is 853 identical in order to reduce distribution bandwidth. 855 Satisfies: User story MFUS2, MFUS3 857 Implemented by Manifest Element: Dependencies, StorageIdentifier, 858 ComponentIdentifier 860 3.5.4. Usability Requirement MFUR4 862 It MUST be possible to sign a manifest multiple times so that 863 signatures from multiple parties with different permissions can be 864 required in order to authorise installation of a manifest. 866 Satisfies: User story MFUS4 868 Implemented by: COSE Signature (or similar) 870 3.5.5. Usability Requirement MFUR5 872 The manifest format MUST accommodate any payload format that an 873 Operator wishes to use. Some examples of payload format would be: 875 - Binary 877 - Elf 879 - Differential 881 - Compressed 883 - Packed configuration 885 - Intel HEX 887 - S-Record 889 Satisfies: User story MFUS5 891 Implemented by: Manifest Element: Payload Format 893 3.5.6. Usability Requirement MFUR6 895 The manifest format must accommodate nested formats, announcing to 896 the target device all the nesting steps and any parameters used by 897 those steps. 899 Satisfies: User story MFUS6 901 Implemented by: Manifest Element: Processing Steps 903 3.5.7. Usability Requirement MFUR7 905 The manifest format must provide a method to specify multiple version 906 numbers of firmware to which the manifest applies, either with a list 907 or with range matching. 909 Satisfies: User story MFUS8 911 Implemented by: Manifest Element: Required Image Version List 913 3.5.8. Usability Requirement MFUR8 915 The manifest format must provide a mechanism to list multiple 916 equivalent payloads by Execute-In-Place Installation Address, 917 including the payload digest and, optionally, payload URIs. 919 Satisfies: User story MFUS9 921 Implemented by: Manifest Element: XIP Address 923 4. Manifest Information Elements 925 Each manifest element is anchored in a security requirement or a 926 usability requirement. The manifest elements are described below and 927 justified by their requirements. 929 4.1. Manifest Element: version identifier of the manifest structure 931 An identifier that describes which iteration of the manifest format 932 is contained in the structure. 934 This element is MANDATORY and must be present in order to allow 935 devices to identify the version of the manifest data model that is in 936 use. 938 4.2. Manifest Element: Monotonic Sequence Number 940 A monotonically increasing sequence number. For convenience, the 941 monotonic sequence number MAY be a UTC timestamp. This allows global 942 synchronisation of sequence numbers without any additional 943 management. 945 This element is MANDATORY and is necessary to prevent malicious 946 actors from reverting a firmware update against the wishes of the 947 relevant authority. 949 Implements: Security Requirement MFSR1. 951 4.3. Manifest Element: Vendor ID Condition 953 Vendor IDs MUST be unique. This is to prevent similarly, or 954 identically named entities from different geographic regions from 955 colliding in their customer's infrastructure. Recommended practice 956 is to use type 5 UUIDs with the vendor's domain name and the UUID DNS 957 prefix. Other options include type 1 and type 4 UUIDs. 959 This ID is OPTIONAL but RECOMMENDED and helps to distinguish between 960 identically named products from different vendors. 962 Implements: Security Requirement MFSR2, MFSR4f. 964 4.3.1. Example: Domain Name-based UUIDs 966 Vendor A creates a UUID based on their domain name: 968 vendorId = UUID5(DNS, "vendor-a.com") 970 Because the DNS infrastructure prevents multiple registrations of the 971 same domain name, this UUID is guaranteed to be unique. Because the 972 domain name is known, this UUID is reproducible. Type 1 and type 4 973 UUIDs produce similar guarantees of uniqueness, but not 974 reproducibility. 976 4.4. Manifest Element: Class ID Condition 978 A device "Class" is defined as any device that can accept the same 979 firmware update without modification. Class Identifiers MUST be 980 unique within a Vendor ID. This is to prevent similarly, or 981 identically named devices colliding in their customer's 982 infrastructure. Recommended practice is to use type 5 UUIDs with the 983 model, hardware revision, etc. and use the Vendor ID as the UUID 984 prefix. Other options include type 1 and type 4 UUIDs. Classes MAY 985 be implemented in a more granular way. Classes MUST NOT be 986 implemented in a less granular way. Class ID can encompass model 987 name, hardware revision, software revision. Devices MAY have 988 multiple Class IDs. 990 Note Well: Class ID is not a human-readable element. It is intended 991 for match/mismatch use only. 993 This ID is OPTIONAL but RECOMMENDED and allows devices to determine 994 applicability of a firmware in an unambiguous way. 996 Implements: Security Requirement MFSR2, MFSR4f. 998 4.4.1. Example 1: Different Classes 1000 Vendor A creates product Z and product Y. The firmware images of 1001 products Z and Y are not interchangeable. Vendor A creates UUIDs as 1002 follows: 1004 - vendorId = UUID5(DNS, "vendor-a.com") 1006 - ZclassId = UUID5(vendorId, "Product Z") 1008 - YclassId = UUID5(vendorId, "Product Y") 1010 This ensures that Vendor A's Product Z cannot install firmware for 1011 Product Y and Product Y cannot install firmware for Product Z. 1013 4.4.2. Example 2: Upgrading Class ID 1015 Vendor A creates product X. Later, Vendor A adds a new feature to 1016 product X, creating product X v2. Product X requires a firmware 1017 update to work with firmware intended for product X v2. 1019 Vendor A creates UUIDs as follows: 1021 - vendorId = UUID5(DNS, "vendor-a.com") 1023 - XclassId = UUID5(vendorId, "Product X") 1025 - Xv2classId = UUID5(vendorId, "Product X v2") 1027 When product X receives the firmware update necessary to be 1028 compatible with product X v2, part of the firmware update changes the 1029 class ID to Xv2classId. 1031 4.4.3. Example 3: Shared Functionality 1033 Vendor A produces two products, product X and product Y. These 1034 components share a common core (such as an operating system), but 1035 have different applications. The common core and the applications 1036 can be updated independently. To enable X and Y to receive the same 1037 common core update, they require the same class ID. To ensure that 1038 only product X receives application X and only product Y receives 1039 application Y, product X and product Y must have different class IDs. 1040 The vendor creates Class IDs as follows: 1042 - vendorId = UUID5(DNS, "vendor-a.com") 1044 - XclassId = UUID5(vendorId, "Product X") 1046 - YclassId = UUID5(vendorId, "Product Y") 1048 - CommonClassId = UUID5(vendorId, "common core") 1050 Product X matches against both XclassId and CommonClassId. Product Y 1051 matches against both YclassId and CommonClassId. 1053 4.5. Manifest Element: Precursor Image Digest Condition 1055 When a precursor image is required by the payload format, a precursor 1056 image digest condition MUST be present in the conditions list. The 1057 precursor image may be installed or stored as a candidate. 1059 This element is MANDATORY for differential updates. Otherwise, it is 1060 not needed. 1062 Implements: Security Requirement MFSR4e 1064 4.6. Manifest Element: Required Image Version List 1066 When a payload applies to multiple versions of a firmware, the 1067 required image version list specifies which versions must be present 1068 for the update to be applied. This allows the update author to 1069 target specific versions of firmware for an update, while excluding 1070 those to which it should not be applied. 1072 Where an update can only be applied over specific predecessor 1073 versions, that version MUST be specified by the Required Image 1074 Version List. 1076 This element is OPTIONAL. 1078 Implements: MFUR7 1080 4.7. Manifest Element: Best-Before timestamp condition 1082 This element tells a device the last application time. This is only 1083 usable in conjunction with a secure clock. 1085 This element is OPTIONAL and MAY enable use cases where a secure 1086 clock is provided and firmware is intended to expire regularly. 1088 Implements: Security Requirement MFSR3 1090 4.8. Manifest Element: Payload Format 1092 The format of the payload must be indicated to devices is in an 1093 unambiguous way. This element provides a mechanism to describe the 1094 payload format, within the signed metadata. 1096 This element is MANDATORY and MUST be present to enable devices to 1097 decode payloads correctly. 1099 Implements: Security Requirement MFSR4a, Usability Requirement MFUR5 1101 4.9. Manifest Element: Processing Steps 1103 A list of all payload processors necessary to process a nested format 1104 and any parameters needed by those payload processors. Each 1105 Processing Step SHOULD indicate the expected digest of the payload 1106 after the processing is complete. Processing steps are distinct from 1107 Directives in that Directives apply to the manifest as a whole, 1108 whereas Processing Steps apply to an individual payload and provide 1109 instructions on how to unpack it. 1111 Implements: Usability Requirement MFUR6 1113 4.10. Manifest Element: Storage Location 1115 This element tells the device which component is being updated. The 1116 device can use this to establish which permissions are necessary and 1117 the physical location to use. 1119 This element is MANDATORY and MUST be present to enable devices to 1120 store payloads to the correct location. 1122 Implements: Security Requirement MFSR4b 1124 4.10.1. Example 1: Two Storage Locations 1126 A device supports two components: an OS and an application. These 1127 components can be updated independently, expressing dependencies to 1128 ensure compatibility between the components. The firmware authority 1129 chooses two storage identifiers: 1131 - OS 1133 - APP 1135 4.10.2. Example 2: File System 1137 A device supports a full filesystem. The firmware authority chooses 1138 to make the storage identifier the path at which to install the 1139 payload. The payload may be a tarball, in which case, it unpacks the 1140 tarball into the specified path. 1142 4.10.3. Example 3: Flash Memory 1144 A device supports flash memory. The firmware authority chooses to 1145 make the storage identifier the offset where the image should be 1146 written. 1148 4.11. Manifest Element: Component Identifier 1150 In a heterogeneous storage architecture, a storage identifier is 1151 insufficient to identify where and how to store a payload. To 1152 resolve this, a component identifier indicates which part of the 1153 storage architecture is targeted by the payload. In a homogeneous 1154 storage architecture, this element is unnecessary. 1156 This element is OPTIONAL and only necessary in heterogeneous storage 1157 architecture devices. 1159 Implements: MFUR3 1161 4.12. Manifest Element: URIs 1163 This element is a list of weighted URIs that the device uses to 1164 select where to obtain a payload. 1166 This element is OPTIONAL and only needed when the target device does 1167 not intrinsically know where to find the payload. 1169 Note: Devices will typically require URIs. 1171 Implements: Security Requirement MFSR4c 1173 4.13. Manifest Element: Payload Digest 1175 This element contains the digest of the payload. This allows the 1176 target device to ensure authenticity of the payload. It MUST be 1177 possible to specify more than one payload digest, indexed by Manifest 1178 Element: XIP Address. 1180 This element is MANDATORY and fundamentally necessary to ensure the 1181 authenticity and integrity of the payload. 1183 Implements: Security Requirement MFSR4d, Usability Requirement MFUR8 1185 4.14. Manifest Element: Size 1187 The size of the payload in bytes. 1189 This element is MANDATORY and informs the target device how big of a 1190 payload to expect. Without it, devices are exposed to some classes 1191 of denial of service attack. 1193 Implements: Security Requirement MFSR4d 1195 4.15. Manifest Element: Signature 1197 This is not strictly a manifest element. Instead, the manifest is 1198 wrapped by a standardised authentication container, such as a COSE or 1199 CMS signature object. The authentication container MUST support 1200 multiple actors and multiple authentications. 1202 This element is MANDATORY and represents the foundation of all 1203 security properties of the manifest. 1205 Implements: Security Requirement MFSR5, MFSR6, MFUR4 1207 4.16. Manifest Element: Directives 1209 A list of instructions that the device should execute, in order, when 1210 processing the manifest. This information is distinct from the 1211 information necessary to process a payload (Processing Steps) and 1212 applies to the whole manifest including all payloads that it 1213 references. Directives include information such as update timing 1214 (For example, install only on Sunday, at 0200), procedural 1215 considerations (for example, shut down the equipment under control 1216 before executing the update), pre and post-installation steps (for 1217 example, run a script). 1219 This element is OPTIONAL and enables some use cases. 1221 Implements: Usability Requirement MFUR1 1223 4.17. Manifest Element: Aliases 1225 A list of Digest/URI pairs. A device should build an alias table 1226 while paring a manifest tree and treat any aliases as top-ranked URIs 1227 for the corresponding digest. 1229 This element is OPTIONAL and enables some use cases. 1231 Implements: Usability Requirement MFUR2 1233 4.18. Manifest Element: Dependencies 1235 A list of Digest/URI pairs that refer to other manifests by digest. 1236 The manifests that are linked in this way must be acquired and 1237 installed simultaneously in order to form a complete update. 1239 This element is MANDATORY to use in deployments that include both 1240 multiple authorities and multiple payloads. 1242 Implements: Usability Requirement MFUR3 1244 4.19. Manifest Element: Content Key Distribution Method 1246 Encrypting firmware images requires symmetric content encryption 1247 keys. Since there are several methods to protect or distribute the 1248 symmetric content encryption keys, the manifest contains a element 1249 for the Content Key Distribution Method. One examples for such a 1250 Content Key Distribution Method is the usage of Key Tables, pointing 1251 to content encryption keys, which themselves are encrypted using the 1252 public keys of devices. This MAY be included in a decryption step 1253 contained in Processing Steps. 1255 This element is MANDATORY to use for encrypted payloads, 1257 Implements: Security Requirement MFSR7. 1259 4.20. Manifest Element: XIP Address 1261 In order to support XIP systems with multiple possible base 1262 addresses, it is necessary to specify which address the payload is 1263 linked for. 1265 For example a microcontroller may have a simple bootloader that 1266 chooses one of two images to boot. That microcontroller then needs 1267 to choose one of two firmware images to install, based on which of 1268 its two images is older. 1270 Implements: MFUR8 1272 5. Security Considerations 1274 Security considerations for this document are covered in Section 3. 1276 6. IANA Considerations 1278 This document does not require any actions by IANA. 1280 7. Acknowledgements 1282 We would like to thank our working group chairs, Dave Thaler, Russ 1283 Housley and David Waltermire, for their review comments and their 1284 support. 1286 We would like to thank the participants of the 2018 Berlin SUIT 1287 Hackathon and the June 2018 virtual design team meetings for their 1288 discussion input. In particular, we would like to thank Koen 1289 Zandberg, Emmanuel Baccelli, Carsten Bormann, David Brown, Markus 1290 Gueller, Frank Audun Kvamtro, Oyvind Ronningstad, Michael Richardson, 1291 Jan-Frederik Rieckers Francisco Acosta, Anton Gerasimov, Matthias 1292 Waehlisch, Max Groening, Daniel Petry, Gaetan Harter, Ralph Hamm, 1293 Steve Patrick, Fabio Utzig, Paul Lambert, Benjamin Kaduk, Said 1294 Gharout, and Milen Stoychev. 1296 8. References 1298 8.1. Normative References 1300 [I-D.ietf-suit-architecture] 1301 Moran, B., Meriac, M., Tschofenig, H., and D. Brown, "A 1302 Firmware Update Architecture for Internet of Things 1303 Devices", draft-ietf-suit-architecture-01 (work in 1304 progress), July 2018. 1306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1307 Requirement Levels", BCP 14, RFC 2119, 1308 DOI 10.17487/RFC2119, March 1997, . 1311 8.2. Informative References 1313 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1314 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1315 DOI 10.17487/RFC4122, July 2005, . 1318 [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, 1319 . 1322 8.3. URIs 1324 [1] mailto:suit@ietf.org 1326 Appendix A. Mailing List Information 1328 The discussion list for this document is located at the e-mail 1329 address suit@ietf.org [1]. Information on the group and information 1330 on how to subscribe to the list is at 1331 https://www1.ietf.org/mailman/listinfo/suit 1333 Archives of the list can be found at: https://www.ietf.org/mail- 1334 archive/web/suit/current/index.html 1336 Authors' Addresses 1338 Brendan Moran 1339 Arm Limited 1341 EMail: Brendan.Moran@arm.com 1343 Hannes Tschofenig 1344 Arm Limited 1346 EMail: hannes.tschofenig@gmx.net 1348 Henk Birkholz 1349 Fraunhofer SIT 1351 EMail: henk.birkholz@sit.fraunhofer.de