idnits 2.17.1 draft-ietf-suit-information-model-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 : ---------------------------------------------------------------------------- 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 (June 03, 2018) is 2154 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 809 Summary: 0 errors (**), 0 flaws (~~), 2 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: December 5, 2018 H. Birkholz 6 Fraunhofer SIT 7 J. Jimenez 8 Ericsson 9 June 03, 2018 11 Firmware Updates for Internet of Things Devices - An Information Model 12 for Manifests 13 draft-ietf-suit-information-model-00 15 Abstract 17 Vulnerabilities with Internet of Things (IoT) devices have raised the 18 need for a solid and secure firmware update mechanism that is also 19 suitable for constrained devices. Incorporating such update 20 mechanism to fix vulnerabilities, to update configuration settings as 21 well as adding new functionality is recommended by security experts. 23 One component of such a firmware update is the meta-data, or 24 manifest, that describes the firmware image(s) and offers appropriate 25 protection. This document describes all the information that must be 26 present in the manifest. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 5, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 76 3. Motivation for Manifest Fields . . . . . . . . . . . . . . . 4 77 3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 4 78 3.2. Threat Descriptions . . . . . . . . . . . . . . . . . . . 5 79 3.2.1. Threat MFT1: Old Firmware . . . . . . . . . . . . . . 5 80 3.2.2. Threat MFT2: Mismatched Firmware . . . . . . . . . . 5 81 3.2.3. Threat MFT3: Offline device + Old Firmware . . . . . 5 82 3.2.4. Threat MFT4: The target device misinterprets the type 83 of payload . . . . . . . . . . . . . . . . . . . . . 6 84 3.2.5. Threat MFT5: The target device installs the payload 85 to the wrong location . . . . . . . . . . . . . . . . 6 86 3.2.6. Threat MFT6: Redirection . . . . . . . . . . . . . . 6 87 3.2.7. Threat MFT7: Payload Verification on Boot . . . . . . 6 88 3.2.8. Threat MFT8: Unauthenticated Updates . . . . . . . . 7 89 3.2.9. Threat MFT9: Unexpected Precursor images . . . . . . 7 90 3.2.10. Threat MFT10: Unqualified Firmware . . . . . . . . . 7 91 3.2.11. Threat MFT11: Reverse Engineering Of Firmware Image 92 for Vulnerability Analysis . . . . . . . . . . . . . 8 94 3.3. Security Requirements . . . . . . . . . . . . . . . . . . 9 95 3.3.1. Security Requirement MFSR1: Monotonic Sequence 96 Numbers . . . . . . . . . . . . . . . . . . . . . . . 9 97 3.3.2. Security Requirement MFSR2: Vendor, Device-type 98 Identifiers . . . . . . . . . . . . . . . . . . . . . 9 99 3.3.3. Security Requirement MFSR3: Best-Before Timestamps . 9 100 3.3.4. Security Requirement MFSR4: Signed Payload Descriptor 9 101 3.3.5. Security Requirement MFSR5: Cryptographic 102 Authenticity . . . . . . . . . . . . . . . . . . . . 10 103 3.3.6. Security Requirement MFSR6: Rights Require 104 Authenticity . . . . . . . . . . . . . . . . . . . . 10 105 3.3.7. Security Requirement MFSR7: Firmware encryption . . . 11 106 3.4. User Stories . . . . . . . . . . . . . . . . . . . . . . 11 107 3.4.1. Use Case MFUC1: Installation Instructions . . . . . . 11 108 3.4.2. Use Case MFUC2: Reuse Local Infrastructure . . . . . 12 109 3.4.3. Use Case MFUC3: Modular Update . . . . . . . . . . . 12 110 3.4.4. Use Case MFUC4: Multiple Authorisations . . . . . . . 12 111 3.4.5. Use Case MFUC5: Multiple Payload Formats . . . . . . 12 112 3.4.6. Use Case MFUC6: IP Protection . . . . . . . . . . . . 12 113 3.5. Usability Requirements . . . . . . . . . . . . . . . . . 13 114 3.5.1. Usability Requirement MFUR1 . . . . . . . . . . . . . 13 115 3.5.2. Usability Requirement MFUR2 . . . . . . . . . . . . . 13 116 3.5.3. Usability Requirement MFUR3 . . . . . . . . . . . . . 13 117 3.5.4. Usability Requirement MFUR4 . . . . . . . . . . . . . 13 118 3.5.5. Usability Requirement MFUR5 . . . . . . . . . . . . . 13 119 4. Manifest Fields . . . . . . . . . . . . . . . . . . . . . . . 14 120 4.1. Manifest Version Field: version identifier of the 121 manifest structure . . . . . . . . . . . . . . . . . . . 14 122 4.2. Manifest Field: Monotonic Sequence Number . . . . . . . . 14 123 4.3. Manifest Field: Vendor ID Condition . . . . . . . . . . . 14 124 4.4. Manifest Field: Class ID Condition . . . . . . . . . . . 15 125 4.5. Manifest Field: Precursor Image Digest Condition . . . . 15 126 4.6. Manifest Field: Best-Before timestamp condition . . . . . 15 127 4.7. Manifest Field: Payload Format . . . . . . . . . . . . . 15 128 4.8. Manifest Field: Storage Location . . . . . . . . . . . . 15 129 4.9. Manifest Field: URIs . . . . . . . . . . . . . . . . . . 16 130 4.10. Manifest Field: Digests . . . . . . . . . . . . . . . . . 16 131 4.11. Manifest Field: Size . . . . . . . . . . . . . . . . . . 16 132 4.12. Manifest Field: Signature . . . . . . . . . . . . . . . . 16 133 4.13. Manifest Field: Directives . . . . . . . . . . . . . . . 16 134 4.14. Manifest Field: Aliases . . . . . . . . . . . . . . . . . 16 135 4.15. Manifest Field: Dependencies . . . . . . . . . . . . . . 17 136 4.16. Manifest Field: Content Key Distribution Method . . . . . 17 137 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 138 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 139 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 140 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 141 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 142 8.2. Informative References . . . . . . . . . . . . . . . . . 17 143 Appendix A. Mailing List Information . . . . . . . . . . . . . . 19 144 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 146 1. Introduction 148 The information model aims to describe all the information that must 149 be present in the manifest that is consumed by an IoT device. 150 Additional information is possible. The fields that are described 151 here are the minimum required to meet the usability and security 152 requirements outlined in Section 3.3. 154 2. Conventions and Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in RFC 159 2119 [RFC2119]. 161 3. Motivation for Manifest Fields 163 The following sub-sections describe the threat model, user stories, 164 security requirements, and usability requirements. 166 3.1. Threat Model 168 The following sub-sections aim to provide information about the 169 threats that were considered, the security requirements that are 170 derived from those threats and the fields that permit implementation 171 of the security requirements. This model uses the S.T.R.I.D.E. 172 [STRIDE] approach. Each threat is classified according to: 174 - Spoofing Identity 176 - Tampering with data 178 - Repudiation 180 - Information disclosure 182 - Denial of service 184 - Elevation of privilege 186 This threat model only covers elements related to the transport of 187 firmware updates. It explicitly does not cover threats outside of 188 the transport of firmware updates. For example, threats to an IoT 189 device due to physical access are out of scope. 191 3.2. Threat Descriptions 193 3.2.1. Threat MFT1: Old Firmware 195 Classification: Elevation of Privilege 197 An attacker sends an old, but valid manifest with an old, but valid 198 firmware image to a device. If there is a known vulnerability in the 199 provided firmware image, this may allow an attacker to exploit the 200 vulnerability and gain control of the device. 202 Threat Escalation: If the attacker is able to exploit the known 203 vulnerability, then this threat can be escalated to ALL TYPES. 205 Mitigated by: MFSR1 207 3.2.2. Threat MFT2: Mismatched Firmware 209 Classification: Denial of Service 211 An attacker sends a valid firmware image, for the wrong type of 212 device, signed by an actor with firmware installation permission on 213 both types of device. The firmware is verified by the device 214 positively because it is signed by an actor with the appropriate 215 permission. This could have wide-ranging consequences. For devices 216 that are similar, it could cause minor breakage, or expose security 217 vulnerabilities. For devices that are very different, it is likely 218 to render devices inoperable. 220 Mitigated by: MFSR2 222 3.2.3. Threat MFT3: Offline device + Old Firmware 224 Classification: Elevation of Privilege 226 An attacker targets a device that has been offline for a long time 227 and runs an old firmware version. The attacker sends an old, but 228 valid manifest to a device with an old, but valid firmware image. 229 The attacker-provided firmware is newer than the installed one but 230 older than the most recently available firmware. If there is a known 231 vulnerability in the provided firmware image then this may allow an 232 attacker to gain control of a device. Because the device has been 233 offline for a long time, it is unaware of any new updates. As such 234 it will treat the old manifest as the most current. 236 Threat Escalation: If the attacker is able to exploit the known 237 vulnerability, then this threat can be escalated to ALL TYPES. 239 Mitigated by: MFSR3 241 3.2.4. Threat MFT4: The target device misinterprets the type of payload 243 Classification: Denial of Service 245 If a device misinterprets the type of the firmware image, it may 246 cause a device to install a firmware image incorrectly. An 247 incorrectly installed firmware image would likely cause the device to 248 stop functioning. 250 Threat Escalation: An attacker that can cause a device to 251 misinterpret the received firmware image may gain elevation of 252 privilege and potentially expand this to all types of threat. 254 Mitigated by: MFSR4 256 3.2.5. Threat MFT5: The target device installs the payload to the wrong 257 location 259 Classification: Denial of Service 261 If a device installs a firmware image to the wrong location on the 262 device, then it is likely to break. For example, a firmware image 263 installed as an application could cause a device and/or an 264 application to stop functioning. 266 Threat Escalation: An attacker that can cause a device to 267 misinterpret the received code may gain elevation of privilege and 268 potentially expand this to all types of threat. 270 Mitigated by: MFSR4 272 3.2.6. Threat MFT6: Redirection 274 Classification: Denial of Service 276 If a device does not know where to obtain the payload for an update, 277 it may be redirected to an attacker's server. This would allow an 278 attacker to provide broken payloads to devices. 280 Mitigated by: MFSR4 282 3.2.7. Threat MFT7: Payload Verification on Boot 284 Classification: Elevation of Privilege 285 An attacker replaces a newly downloaded firmware after a device 286 finishes verifying a manifest. This could cause the device to 287 execute the attacker's code. This attack likely requires physical 288 access to the device. However, it is possible that this attack is 289 carried out in combination with another threat that allows remote 290 execution. 292 Threat Escalation: If the attacker is able to exploit the known 293 vulnerability, then this threat can be escalated to ALL TYPES. 295 Mitigated by: MFSR4 297 3.2.8. Threat MFT8: Unauthenticated Updates 299 Classification: Elevation of Privilege 301 If an attacker can install their firmware on a device, by 302 manipulating either payload or metadata, then they have complete 303 control of the device. 305 Threat Escalation: If the attacker is able to exploit the known 306 vulnerability, then this threat can be escalated to ALL TYPES. 308 Mitigated by: MFSR5 310 3.2.9. Threat MFT9: Unexpected Precursor images 312 Classification: Denial of Service 314 An attacker sends a valid, current manifest to a device that has an 315 unexpected precursor image. If a payload format requires a precursor 316 image (for example, delta updates) and that precursor image is not 317 available on the target device, it could cause the update to break. 319 Threat Escalation: An attacker that can cause a device to install a 320 payload against the wrong precursor image could gain elevation of 321 privilege and potentially expand this to all types of threat. 323 Mitigated by: MFSR4 325 3.2.10. Threat MFT10: Unqualified Firmware 327 Classification: Denial of Service, Elevation of Privilege 329 This threat can appear in several ways, however it is ultimately 330 about interoperability of devices with other systems. The owner or 331 operator of a network needs to approve firmware for their network in 332 order to ensure interoperability with other devices on the network, 333 or the network itself. If the firmware is not qualified, it may not 334 work. Therefore, if a device installs firmware without the approval 335 of the network owner or operator, this is a threat to devices and the 336 network. 338 Example 1: We assume that OEMs expect the rights to create firmware, 339 but that Operators expect the rights to qualify firmware as fit-for- 340 purpose on their networks. 342 An attacker obtains a manifest for a device on Network A. They send 343 that manifest to a device on Network B. Because Network A and 344 Network B are different, and the firmware has not been qualified for 345 Network B, the target device is disabled by this unqualified, but 346 signed firmware. 348 This is a denial of service because it can render devices inoperable. 349 This is an elevation of privilege because it allows the attacker to 350 make installation decisions that should be made by the Operator. 352 Example 2: Multiple devices that interoperate are used on the same 353 network. Some devices are manufactured by OEM A and other devices by 354 OEM B. These devices communicate with each other. A new firmware is 355 released by OEM A that breaks compatibility with OEM B devices. An 356 attacker sends the new firmware to the OEM A devices without approval 357 of the network operator. This breaks the behaviour of the larger 358 system causing denial of service and possibly other threats. Where 359 the network is a distributed SCADA system, this could cause 360 misbehaviour of the process that is under control. 362 Threat Escalation: If the firmware expects configuration that is 363 present in Network A devices, but not Network B devices, then the 364 device may experience degraded security, leading to threats of All 365 Types. 367 Mitigated by: MFSR6 369 3.2.11. Threat MFT11: Reverse Engineering Of Firmware Image for 370 Vulnerability Analysis 372 Classification: All Types 374 An attacker wants to mount an attack on an IoT device. To prepare 375 the attack he or she retrieves the provided firmware image and 376 performs reverse engineering of the firmware image to analyze it for 377 specific vulnerabilities. 379 Mitigated by: MFSR7 381 3.3. Security Requirements 383 The security requirements here are a set of policies that mitigate 384 the threats described in Section 3.1. 386 3.3.1. Security Requirement MFSR1: Monotonic Sequence Numbers 388 Only an actor with firmware installation authority is permitted to 389 decide when device firmware can be installed. To enforce this rule, 390 Manifests MUST contain monotonically increasing sequence numbers. 391 Manifests MAY use UTC epoch timestamps to coordinate monotonically 392 increasing sequence numbers across many actors in many locations. 393 Devices MUST reject manifests with sequence numbers smaller than any 394 onboard sequence number. 396 N.B. This is not a firmware version. It is a manifest sequence 397 number. A firmware version may be rolled back by creating a new 398 manifest for the old firmware version with a later sequence number. 400 Mitigates: Threat MFT1 Implemented by: Manifest Field: Timestamp 402 3.3.2. Security Requirement MFSR2: Vendor, Device-type Identifiers 404 Devices MUST only apply firmware that is intended for them. Devices 405 MUST know with fine granularity that a given update applies to their 406 vendor, model, hardware revision, software revision. Human-readable 407 identifiers are often error-prone in this regard, so unique 408 identifiers SHOULD be used. 410 Mitigates: Threat MFT2 Implemented by: Manifest Fields: Vendor ID 411 Condition, Class ID Condition 413 3.3.3. Security Requirement MFSR3: Best-Before Timestamps 415 Firmware MAY expire after a given time. Devices MAY provide a secure 416 clock (local or remote). If a secure clock is provided and the 417 Firmware manifest has a best-before timestamp, the device MUST reject 418 the manifest if current time is larger than the best-before time. 420 Mitigates: Threat MFT3 Implemented by: Manifest Field: Best-Before 421 timestamp condition 423 3.3.4. Security Requirement MFSR4: Signed Payload Descriptor 425 All descriptive information about the payload MUST be signed. This 426 MUST include: 428 - The type of payload (which may be independent of format) 429 - The location to store the payload 431 - The payload digest, in each state of installation (encrypted, 432 plaintext, installed, etc.) 434 - The payload size 436 - The payload format 438 - Where to obtain the payload 440 - All instructions or parameters for applying the payload 442 - Any rules that identify whether or not the payload can be used on 443 this device 445 Mitigates: Threats MFT4, MFT5, MFT6, MFT7, MFT9 Implemented by: 446 Manifest Fields: Vendor ID Condition, Class ID Condition, Precursor 447 Image Digest Condition, Payload Format, Storage Location, URIs, 448 Digests, Size 450 3.3.5. Security Requirement MFSR5: Cryptographic Authenticity 452 The authenticity of an update must be demonstrable. Typically, this 453 means that updates must be digitally signed. Because the manifest 454 contains information about how to install the update, the manifest's 455 authenticity must also be demonstrable. To reduce the overhead 456 required for validation, the manifest contains the digest of the 457 firmware image, rather than a second digital signature. The 458 authenticity of the manifest can be verified with a digital 459 signature, the authenticity of the firmware image is tied to the 460 manifest by the use of a fingerprint of the firmware image. 462 Mitigates: Threat MFT8 Implemented by: Signature 464 3.3.6. Security Requirement MFSR6: Rights Require Authenticity 466 If a device grants different rights to different actors, exercising 467 those rights MUST be accompanied by proof of those rights, in the 468 form of proof of authenticity. Authenticity mechanisms such as those 469 required in MFSR5 are acceptable but need to follow the end-to-end 470 security model. 472 For example, if a device has a policy that requires that firmware 473 have both an Authorship right and a Qualification right and if that 474 device grants Authorship and Qualification rights to different 475 parties, such as an OEM and an Operator, respectively, then the 476 firmware cannot be installed without proof of rights from both the 477 OEM and the Operator. 479 Mitigates: MFT10 Implemented by: Signature 481 3.3.7. Security Requirement MFSR7: Firmware encryption 483 Firmware images must support encryption. Encryption helps to prevent 484 third parties, including attackers, from reading the content of the 485 firmware image and to reverse engineer the code. 487 Mitigates: MFT11 Implemented by: Manifest Field: Content Key 488 Distribution Method 490 3.4. User Stories 492 User stories provide expected use cases. These are used to feed into 493 usability requirements. 495 3.4.1. Use Case MFUC1: Installation Instructions 497 As an OEM for IoT devices, I want to provide my devices with 498 additional installation instructions so that I can keep process 499 details out of my payload data. 501 Some installation instructions might be: 503 - Specify a package handler 505 - Use a table of hashes to ensure that each block of the payload is 506 validated before writing. 508 - Run post-processing script after the update is installed 510 - Do not report progress 512 - Pre-cache the update, but do not install 514 - Install the pre-cached update matching this manifest 516 - Install this update immediately, overriding any long-running 517 tasks. 519 Satisfied by: MFUR1 521 3.4.2. Use Case MFUC2: Reuse Local Infrastructure 523 As an Operator of IoT devices, I would like to tell my devices to 524 look at my own infrastructure for payloads so that I can manage the 525 traffic generated by firmware updates on my network and my peers' 526 networks. 528 Satisfied by: MFUR2, MFUR3 530 3.4.3. Use Case MFUC3: Modular Update 532 As an OEM of IoT devices, I want to divide my firmware into 533 frequently updated and infrequently updated components, so that I can 534 reduce the size of updates and make different parties responsible for 535 different components. 537 Satisfied by: MFUR3 539 3.4.4. Use Case MFUC4: Multiple Authorisations 541 As an Operator, I want to ensure the quality of a firmware update 542 before installing it, so that I can ensure a high standard of 543 reliability on my network. The OEM may restrict my ability to create 544 firmware, so I cannot be the only authority on the device. 546 Satisfied by: MFUR4 548 3.4.5. Use Case MFUC5: Multiple Payload Formats 550 As an OEM or Operator of devices, I want to be able to send multiple 551 payload formats to suit the needs of my update, so that I can 552 optimise the bandwidth used by my devices. 554 Satisfied by: MFUR5 556 3.4.6. Use Case MFUC6: IP Protection 558 As an OEM or developer for IoT devices, I want to protect the IP 559 contained in the firmware image, such as the utilized algorithms. 560 The need for protecting IP may have also been imposed on me due to 561 the use of some third party code libraries. 563 Satisfied by: MFSR7 565 3.5. Usability Requirements 567 The following usability requirements satisfy the user stories listed 568 above. 570 3.5.1. Usability Requirement MFUR1 572 It must be possible to write additional installation instructions 573 into the manifest. 575 Satisfies: Use-Case MFUC1 Implemented by: Manifest Field: Directives 577 3.5.2. Usability Requirement MFUR2 579 It must be possible to redirect payload fetches. This applies where 580 two manifests are used in conjunction. For example, an OEM manifest 581 specifies a payload and signs it, and provides a URI for that 582 payload. An Operator creates a second manifest, with a dependency on 583 the first. They use this second manifest to override the URIs 584 provided by the OEM, directing them into their own infrastructure 585 instead. 587 Satisfies: Use-Case MFUC2 Implemented by: Manifest Field: Aliases 589 3.5.3. Usability Requirement MFUR3 591 It MUST be possible to link multiple manifests together so that a 592 multi-component update can be described. This allows multiple 593 parties with different permissions to collaborate in creating a 594 single update for the IoT device, across multiple components. 596 Satisfies: Use-Case MFUC2, MFUC3 Implemented by: Manifest Field: 597 Dependencies 599 3.5.4. Usability Requirement MFUR4 601 It MUST be possible to sign a manifest multiple times so that 602 signatures from multiple parties with different permissions can be 603 required in order to authorise installation of a manifest. 605 Satisfies: Use-Case MFUC4 Implemented by: COSE Signature (or similar) 607 3.5.5. Usability Requirement MFUR5 609 The manifest format MUST accommodate any payload format that an 610 operator or OEM wishes to use. Some examples of payload format would 611 be: 613 - Binary 615 - Elf 617 - Differential 619 - Compressed 621 - Packed configuration 623 Satisfies: Use-Case MFUC5 Implemented by: Manifest Field: Payload 624 Format 626 4. Manifest Fields 628 Each manifest field is anchored in a security requirement or a 629 usability requirement. The manifest fields are described below and 630 justified by their requirements. 632 4.1. Manifest Version Field: version identifier of the manifest 633 structure 635 An identifier that describes which iteration of the manifest format 636 is contained in the structure. 638 4.2. Manifest Field: Monotonic Sequence Number 640 A monotonically increasing sequence number. For convenience, the 641 monotonic sequence number MAY be a UTC timestamp. This allows global 642 synchronisation of sequence numbers without any additional 643 management. 645 Implements: Security Requirement MFSR1. 647 4.3. Manifest Field: Vendor ID Condition 649 Vendor IDs MUST be unique. This is to prevent similarly, or 650 identically named entities from different geographic regions from 651 colliding in their customer's infrastructure. Recommended practice 652 is to use version 5 UUIDs with the vendor's domain name and the UUID 653 DNS prefix [RFC4122]. Other options include version 1 and type 4 654 UUIDs. 656 Implements: Security Requirement MFSR2, MFSR4. 658 4.4. Manifest Field: Class ID Condition 660 Class Identifiers MUST be unique within a Vendor ID. This is to 661 prevent similarly, or identically named devices colliding in their 662 customer's infrastructure. Recommended practice is to use type 5 663 UUIDs with the model, hardware revision, etc. and use the Vendor ID 664 as the UUID prefix. Other options include type 1 and type 4 UUIDs. 665 A device "Class" is defined as any device that can run the same 666 firmware without modification. Classes MAY be implemented in a more 667 granular way. Classes MUST NOT be implemented in a less granular 668 way. Class ID can encompass model name, hardware revision, software 669 revision. Devices MAY have multiple Class IDs. 671 Implements: Security Requirement MFSR2, MFSR4. 673 4.5. Manifest Field: Precursor Image Digest Condition 675 When a precursor image is required by the payload format, a precursor 676 image digest condition MUST be present in the conditions list. 678 Implements: Security Requirement MFSR4 680 4.6. Manifest Field: Best-Before timestamp condition 682 This field tells a device the last application time. This is only 683 usable in conjunction with a secure clock. 685 Implements: Security Requirement MFSR3 687 4.7. Manifest Field: Payload Format 689 The format of the payload must be indicated to devices in an 690 unambiguous way. This field provides a mechanism to describe the 691 payload format, within the signed metadata. 693 Implements: Security Requirement MFSR4, Usability Requirement MFUR5 695 4.8. Manifest Field: Storage Location 697 This field tells the device which component is being updated. The 698 device can use this to establish which permissions are necessary and 699 the physical location to use. 701 Implements: Security Requirement MFSR4 703 4.9. Manifest Field: URIs 705 This field is a list of weighted URIs, which are used to select where 706 to obtain a payload. 708 Implements: Security Requirement MFSR4 710 4.10. Manifest Field: Digests 712 This field is a map of digests, each for a separate stage of 713 installation. This allows the target device to ensure authenticity 714 of the payload at every step of installation. 716 Implements: Security Requirement MFSR4 718 4.11. Manifest Field: Size 720 The size of the payload in bytes. 722 Implements: Security Requirement MFSR4 724 4.12. Manifest Field: Signature 726 This is not strictly a manifest field. Instead, the manifest is 727 wrapped by a standardised authentication container, such as a COSE or 728 CMS signature object. The authentication container MUST support 729 multiple actors and multiple authentications. 731 Implements: Security Requirement MFSR5, MFSR6, MFUR4 733 4.13. Manifest Field: Directives 735 A list of instructions that the device should execute, in order, when 736 installing the payload. 738 Implements: Usability Requirement MFUR1 740 4.14. Manifest Field: Aliases 742 A list of URI/Digest pairs. A device is expected to build an alias 743 table while paring a manifest tree and treat any aliases as top- 744 ranked URIs for the corresponding digest. 746 Implements: Usability Requirement MFUR2 748 4.15. Manifest Field: Dependencies 750 A list of URI/Digest pairs that refer to other manifests by digest. 751 The manifests that are linked in this way must be acquired and 752 installed simultaneously in order to form a complete update. 754 Implements: Usability Requirement MFUR3 756 4.16. Manifest Field: Content Key Distribution Method 758 Efficiently encrypting firmware images requires the use of symmetric 759 key cryptography. Since there are several methods to protect or 760 distribute the symmetric content encryption keys, the manifest 761 contains a field for the Content Key Distribution Method. One 762 example for such a Content Key Distribution Method is the usage of 763 Key Tables, pointing to content encryption keys, which themselves are 764 encrypted using the public keys of devices. 766 Implements: Security Requirement MFSR7. 768 5. Security Considerations 770 Security considerations for this document are covered in Section 3. 772 6. IANA Considerations 774 This document does not require any actions by IANA. 776 7. Acknowledgements 778 We would like to thank our working group chairs, Dave Thaler, Russ 779 Housley and David Waltermire, for their review comments and their 780 support. 782 8. References 784 8.1. Normative References 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, 788 DOI 10.17487/RFC2119, March 1997, . 791 8.2. Informative References 793 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 794 Unique IDentifier (UUID) URN Namespace", RFC 4122, 795 DOI 10.17487/RFC4122, July 2005, . 798 [STRIDE] Microsoft, "The STRIDE Threat Model", May 2018, 799 . 802 8.3. URIs 804 [1] mailto:suit@ietf.org 806 Appendix A. Mailing List Information 808 The discussion list for this document is located at the e-mail 809 address suit@ietf.org [1]. Information on the group and information 810 on how to subscribe to the list is at 811 https://www1.ietf.org/mailman/listinfo/suit 813 Archives of the list can be found at: https://www.ietf.org/mail- 814 archive/web/suit/current/index.html 816 Authors' Addresses 818 Brendan Moran 819 Arm Limited 821 EMail: Brendan.Moran@arm.com 823 Hannes Tschofenig 824 Arm Limited 826 EMail: hannes.tschofenig@gmx.net 828 Henk Birkholz 829 Fraunhofer SIT 831 EMail: henk.birkholz@sit.fraunhofer.de 833 Jaime Jimenez 834 Ericsson 836 EMail: jaime.jimenez@ericsson.com