idnits 2.17.00 (12 Aug 2021) /tmp/idnits38727/draft-ietf-suit-architecture-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == 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 1447 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 816 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUIT B. Moran 3 Internet-Draft Arm Limited 4 Intended status: Informational M. Meriac 5 Expires: December 5, 2018 Consultant 6 H. Tschofenig 7 Arm Limited 8 June 03, 2018 10 A Firmware Update Architecture for Internet of Things Devices 11 draft-ietf-suit-architecture-00 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 This document lists requirements and describes an architecture for a 22 firmware update mechanism suitable for IoT devices. The architecture 23 is agnostic to the transport of the firmware images and associated 24 meta-data. 26 This version of the document assumes asymmetric cryptography and a 27 public key infrastructure. Future versions may also describe a 28 symmetric key approach for very constrained devices. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 5, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 78 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3.1. Agnostic to how firmware images are distributed . . . . . 5 80 3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 5 81 3.3. Use state-of-the-art security mechanisms . . . . . . . . 5 82 3.4. Rollback attacks must be prevented . . . . . . . . . . . 6 83 3.5. High reliability . . . . . . . . . . . . . . . . . . . . 6 84 3.6. Operate with a small bootloader . . . . . . . . . . . . . 6 85 3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 7 86 3.8. Minimal impact on existing firmware formats . . . . . . . 7 87 3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 7 88 3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 8 89 4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10 91 6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 7. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . 13 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 95 10. Mailing List Information . . . . . . . . . . . . . . . . . . 16 96 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 99 12.2. Informative References . . . . . . . . . . . . . . . . . 17 100 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 103 1. Introduction 105 When developing IoT devices, one of the most difficult problems to 106 solve is how to update the firmware on the device. Once the device 107 is deployed, firmware updates play a critical part in its lifetime, 108 particularly when devices have a long lifetime, are deployed in 109 remote or inaccessible areas or where manual intervention is cost 110 prohibitive or otherwise difficult. The need for a firmware update 111 may be to fix bugs in software, to add new functionality, or to re- 112 configure the device. 114 The firmware update process has to ensure that 116 - The firmware image is authenticated and attempts to flash a 117 malicious firmware image are prevented. 119 - The firmware image can be confidentiality protected so that 120 attempts by an adversary to recover the plaintext binary can be 121 prevented. Obtaining the plaintext binary is often one of the 122 first steps for an attack to mount an attack. 124 2. Conventions and Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in RFC 129 2119 [RFC2119]. 131 This document uses the following terms: 133 - Manifest: The manifest contains meta-data about the firmware 134 image. The manifest is protected against modification and 135 provides information about the author. 137 - Firmware Image: The firmware image is a binary that may contain 138 the complete software of a device or a subset of it. The firmware 139 image may consist of multiple images, if the device contains more 140 than one microcontroller. The image may consist of a differential 141 update for performance reasons. Firmware is the more universal 142 term. Both terms are used in this document and are 143 interchangeable. 145 - Bootloader: A bootloader is a piece of software that is executed 146 once a microcontroller has been reset. It is responsible for 147 deciding whether to boot a firmware image that is present or 148 whether to obtain and verify a new firmware image. Since the 149 bootloader is a security critical component its functionality may 150 be split into separate stages. Such a multi-stage bootloader may 151 offer very basic functionality in the first stage and resides in 152 ROM whereas the second stage may implement more complex 153 functionality and resides in flash memory so that it can be 154 updated in the future (in case bugs have been found). The exact 155 split of components into the different stages, the number of 156 firmware images stored by an IoT device, and the detailed 157 functionality varies throughout different implementations. 159 The following entities are used: 161 - Author: The author is the entity that creates the firmware image, 162 signs and/or encrypts it. The author is most likely a developer 163 using a set of tools. 165 - Device: The device is the recipient of the firmware image and the 166 manifest. The goal is to update the firmware of the device. 168 - Untrusted Storage: Firmware images and manifests may be stored on 169 untrusted fileservers or cloud storage infrastructure. Some 170 deployments may require storage of the firmware images/manifests 171 to be stored on various entities before they reach the device. 173 3. Requirements 175 The firmware update mechanism described in this specification was 176 designed with the following requirements in mind: 178 - Agnostic to how firmware images are distributed 180 - Friendly to broadcast delivery 182 - Use state-of-the-art security mechanisms 184 - Rollback attacks must be prevented 186 - High reliability 188 - Operate with a small bootloader 189 - Small Parsers 191 - Minimal impact on existing firmware formats 193 - Robust permissions 195 - Diverse modes of operation 197 3.1. Agnostic to how firmware images are distributed 199 Firmware images can be conveyed to devices in a variety of ways, 200 including USB, UART, WiFi, BLE, low-power WAN technologies, etc. and 201 use different protocols (e.g., CoAP, HTTP). The specified mechanism 202 needs to be agnostic to the distribution of the firmware images and 203 manifests. 205 3.2. Friendly to broadcast delivery 207 This architecture does not specify any specific broadcast protocol 208 however, given that broadcast may be desirable for some networks, 209 updates must cause the least disruption possible both in metadata and 210 payload transmission. 212 For an update to be broadcast friendly, it cannot rely on link layer, 213 network layer, or transport layer security. In addition, the same 214 message must be deliverable to many devices, both those to which it 215 applies and those to which it does not, without a chance that the 216 wrong device will accept the update. Considerations that apply to 217 network broadcasts apply equally to the use of third-party content 218 distribution networks for payload distribution. 220 3.3. Use state-of-the-art security mechanisms 222 End-to-end security between the author and the device, as shown in 223 Section 5, is used to ensure that the device can verify firmware 224 images and manifests produced by authorized authors. 226 The use of post-quantum secure signature mechanisms, such as hash- 227 based signatures, should be explored. A migration to post-quantum 228 secure signatures would require significant effort, therefore, 229 mandatory-to-implement support for post-quantum secure signatures is 230 a goal. 232 A mandatory-to-implement set of algorithms has to be defined offering 233 a key length of 112-bit symmetric key or security or more, as 234 outlined in Section 20 of RFC 7925 [RFC7925]. This corresponds to a 235 233 bit ECC key or a 2048 bit RSA key. 237 If the firmware image is to be encrypted, it must be done in such a 238 way that every intended recipient can decrypt it. The information 239 that is encrypted individually for each device must be an absolute 240 minimum, for example AES Key Wrap [RFC5649], in order to maintain 241 friendliness to Content Distribution Networks, bulk storage, and 242 broadcast protocols. 244 3.4. Rollback attacks must be prevented 246 A device presented with an old, but valid manifest and firmware must 247 not be tricked into installing such firmware since a vulnerability in 248 the old firmware image may allow an attacker to gain control of the 249 device. 251 3.5. High reliability 253 A power failure at any time must not cause a failure of the device. 254 A failure to validate any part of an update must not cause a failure 255 of the device. One way to achieve this functionality is to provide a 256 minimum of two storage locations for firmware and one bootable 257 location for firmware. An alternative approach is to use a 2nd stage 258 bootloader with build-in full featured firmware update functionality 259 such that it is possible to return to the update process after power 260 down. 262 Note: This is an implementation requirement rather than a requirement 263 on the manifest format. 265 3.6. Operate with a small bootloader 267 The bootloader must be minimal, containing only flash support, 268 cryptographic primitives and optionally a recovery mechanism. The 269 recovery mechanism is used in case the update process failed and may 270 include support for firmware updates over serial, USB or even a 271 limited version of wireless connectivity standard like a limited 272 Bluetooth Smart. Such a recovery mechanism must provide security at 273 least at the same level as the full featured firmware update 274 functionalities. 276 The bootloader needs to verify the received manifest and to install 277 the bootable firmware image. The bootloader should not require 278 updating since a failed update poses a risk in reliability. If more 279 functionality is required in the bootloader, it must use a two-stage 280 bootloader, with the first stage comprising the functionality defined 281 above. 283 All information necessary for a device to make a decision about the 284 installation of a firmware update must fit into the available RAM of 285 a constrained IoT device. This prevents flash write exhaustion. 287 Note: This is an implementation requirement. 289 3.7. Small Parsers 291 Since parsers are known sources of bugs they must be minimal. 292 Additionally, it must be easy to parse only those fields that are 293 required to validate at least one signature or MAC with minimal 294 exposure. 296 3.8. Minimal impact on existing firmware formats 298 The design of the firmware update mechanism must not require changes 299 to existing firmware formats. 301 3.9. Robust permissions 303 A device may have many modules that require updating individually. 304 It may also need to trust several actors in order to authorize an 305 update. These actors might include the following (this is not a 306 comprehensive list). 308 * A firmware author 309 * A device OEM 310 * A device operator 311 * A network operator 312 * A device owner 314 These actors exert their authority on the device by making claims (as 315 in Section 4). 317 For example, a firmware author may not have the authority to install 318 firmware on a device in critical infrastructure without the 319 authorization of a device operator. In this case, the device may be 320 programmed to reject firmware updates unless they are signed both by 321 the firmware author and by the device operator. To facilitate 322 complex use-cases such as this, updates require several claims. 324 Alternatively, a device may trust precisely one authority, which does 325 all permission management and coordination. Effectively, the 326 authority allows the device to offload complex permissions 327 calculations for the device. 329 3.10. Operating modes 331 There are three broad classifications of update operating modes. 333 * Self initiated 334 * Third-party initiated 335 * Hybrid 337 Self initiated updates take the form of a proactive IoT device that 338 checks for updates. Third-party initiated updates are triggered by 339 an actor other than the IoT device, be it a server, a peer, or a 340 user. Hybrid updates are those that require agreement from both the 341 target IoT device and another actor. 343 Third-party initiated updates are important to consider because 344 timing of updates may need to be tightly controlled in some high- 345 reliability environments. 347 An IoT device goes through several steps in the course of an update, 348 each of which can be self-initiated or third-party initiated, or 349 hybrid. An IoT device may go through the following steps, though 350 this is not a comprehensive list. 352 * Notification 353 * Pre-authorisation 354 * Dependency resolution 355 * Download 356 * Installation 358 The notification step consists informing an IoT device that an update 359 is available. This can be accomplished via polling (self-initiated), 360 push notifications (third-party initiated), or more complex 361 mechanisms. 363 The pre-authorisation step involves verifying the update authority 364 and making a determination that the device is prepared to initiate 365 the fetching and processing of updates. If the device has all 366 information that is necessary to make this determination, then the 367 pre-authorisation may be self-initiated. However, the device can 368 wait for instruction to begin (third-party initiated). Hybrid 369 approaches are possible as well. 371 A dependency resolution phase is needed when more than one component 372 can be updated or when a differential update is used. The necessary 373 dependencies must be available prior to installation. 375 The download step is the process of acquiring a local copy of the 376 payload. When the download is self-initiated, this means that the 377 IoT device chooses when a download occurs and initiates the download 378 process. When a download is third-party initiated, this means that 379 either the remote service tells the IoT device when to download or 380 that it initiates the transfer directly to the IoT device. For 381 example, a download from an HTTP server is initiated locally. A 382 transfer to a LwM2M Firmware Update resource [LwM2M] is initiated 383 remotely. 385 Installation is the act of processing the payload into a format that 386 the IoT device can recognise. 388 Each of these steps may require different permissions expressed in 389 claims and may be implemented in a variety of ways. 391 4. Claims 393 When a simple set of permissions fails to encapsulate the rules 394 required for a device to make decisions about firmware, claims can be 395 used instead. Claims represent a form of policy. Several claims can 396 be used together, when multiple actors should have the rights to set 397 policies. 399 Some example claims are: 401 - Trust the actor identified by the referenced public key. 403 - Trust the actor with access to the referenced shared secret (MAC). 405 - Three actors are trusted identified by their public keys. 406 Signatures from at least two of these actors are required to trust 407 a manifest. 409 - The actor identified by the referenced public key is authorized to 410 create secondary policies 412 The baseline claims for all manifests are described in [SUIT-IM]. In 413 summary, they are: 415 - Do not install firmware with earlier metadata than the current 416 metadata. 418 - Only install firmware with a matching vendor, model, hardware 419 revision, software version, etc. 421 - Only install firmware that is before its best-before timestamp. 423 - Only install firmware with metadata signed/authenticated by a 424 trusted actor. 426 - Only allow an actor to exercise rights on the device via a 427 manifest if that actor has signed the manifest. 429 - Only allow a firmware installation if all required rights have 430 been met through signatures/MACs (one or more) or manifest 431 dependencies (one or more). 433 - Use the instructions provided by the manifest to install the 434 firmware. 436 - Install any and all firmware images that are linked together with 437 manifest dependencies. 439 - Choose the mechanism to install the firmware, based on the type of 440 firmware it is. 442 5. Architecture 444 We start the architectural description with the security model. It 445 is based on end-to-end security. In Figure 1 a firmware image is 446 created by an author, sent to the device and subsequently installed. 447 When the author is ready to distribute the firmware image it is 448 conveyed using some communication channel to the device, which will 449 typically involve the use of untrusted storage. Examples of 450 untrusted storage are FTP servers, Web servers or USB sticks. End- 451 to-end security mechanisms are used to protect the firmware image. 452 Figure 1 does not show the manifest itself, which provides the meta- 453 data about the firmware image and offers the security protection. It 454 may bundled with the firmware image or travel as a standalone item. 456 +-----------+ 457 +--------+ | | +--------+ 458 | | Firmware Image | Untrusted | Firmware Image | | 459 | Device |<-----------------| Storage |<------------------| Author | 460 | | | | | | 461 +--------+ +-----------+ +--------+ 462 ^ * 463 * * 464 ************************************************************ 465 End-to-End Security 467 Figure 1: End-to-End Security. 469 Whether the firmware image and the manifest is pushed to the device 470 or fetched by the device is outside the scope of this work and 471 existing device management protocols can be used for efficiently 472 distributing this information. 474 The following assumptions are made to allow the device to verify the 475 received firmware image and manifest before updating software: 477 - To accept an update, a device needs to decide whether the author 478 signing the firmware image and the manifest is authorized to make 479 the updates. We use public key cryptography to accomplish this. 480 The device verifies the signature covering the manifest using a 481 digital signature algorithm OR the device verifies the MAC 482 covering the manifest using a MAC algorithm. The device is 483 provisioned with a trust anchor that is used to validate the 484 digital signature or MAC produced by the author. This trust 485 anchor is potentially different from the trust anchor used to 486 validate the digital signature produced for other protocols (such 487 as device management protocols). This trust anchor may be 488 provisioned to the device during manufacturing or during 489 commissioning. 491 - For confidentiality protection of firmware images the author needs 492 to be in possession of the certificate/public key or a pre-shared 493 key of a device. 495 There are different types of delivery modes, which are illustrated 496 based on examples below. 498 There is an option for embedding a firmware image into a manifest. 499 This is a useful approach for deployments where devices are not 500 connected to the Internet and cannot contact a dedicated server for 501 download of the firmware. It is also applicable when the firmware 502 update happens via a USB stick or via Bluetooth Smart. Figure 2 503 shows this delivery mode graphically. 505 /------------\ /------------\ 506 /Manifest with \ /Manifest with \ 507 |attached | |attached | 508 \firmware image/ \firmware image/ 509 \------------/ +-----------+ \------------/ 510 +--------+ | | +--------+ 511 | |<.................| Untrusted |<................| | 512 | Device | | Storage | | Author | 513 | | | | | | 514 +--------+ +-----------+ +--------+ 516 Figure 2: Manifest with attached firmware. 518 Figure 3 shows an option for remotely updating a device where the 519 device fetches the firmware image from some file server. The 520 manifest itself is delivered independently and provides information 521 about the firmware image(s) to download. 523 /------------\ 524 / \ 525 | Manifest | 526 \ / 527 +--------+ \------------/ +--------+ 528 | |<..............................................>| | 529 | Device | -- | Author | 530 | |<- --- | | 531 +--------+ -- --- +--------+ 532 -- --- 533 --- --- 534 -- +-----------+ -- 535 -- | | -- 536 /------------\ -- | Untrusted |<- /------------\ 537 / \ -- | Storage | / \ 538 | Firmware | | | | Firmware | 539 \ / +-----------+ \ / 540 \------------/ \------------/ 542 Figure 3: Independent retrieval of the firmware image. 544 This architecture does not mandate a specific delivery mode but a 545 solution must support both types. 547 6. Manifest 549 In order for a device to apply an update, it has to make several 550 decisions about the update: 552 - Does it trust the author of the update? 554 - Has the firmware been corrupted? 556 - Does the firmware update apply to this device? 558 - Is the update older than the active firmware? 560 - When should the device apply the update? 562 - How should the device apply the update? 564 - What kind of firmware binary is it? 566 - Where should the update be obtained? 568 - Where should the firmware be stored? 569 The manifest encodes the information that devices need in order to 570 make these decisions. It is a data structure that contains the 571 following information: 573 - information about the device(s) the firmware image is intended to 574 be applied to, 576 - information about when the firmware update has to be applied, 578 - information about when the manifest was created, 580 - dependencies on other manifests, 582 - pointers to the firmware image and information about the format, 584 - information about where to store the firmware image, 586 - cryptographic information, such as digital signatures or message 587 authentication codes (MACs). 589 The manifest information model is described in [SUIT-IM]. 591 7. Example Flow 593 The following example message flow illustrates the interaction for 594 distributing a firmware image to a device starting with an author 595 uploading the new firmware to untrusted storage and creating a 596 manifest. The firmware and manifest are stored on the same untrusted 597 storage. 599 +--------+ +-----------------+ +------+ 600 | Author | |Untrusted Storage| |Device| 601 +--------+ +-----------------+ +------+ 602 | | | 603 | Create Firmware | | 604 |--------------- | | 605 | | | | 606 |<-------------- | | 607 | | | 608 | Upload Firmware | | 609 |------------------>| | 610 | | | 611 | Create Manifest | | 612 |---------------- | | 613 | | | | 614 |<--------------- | | 615 | | | 616 | Sign Manifest | | 617 |-------------- | | 618 | | | | 619 |<------------- | | 620 | | | 621 | Upload Manifest | | 622 |------------------>| | 623 | | | 624 | | Query Manifest | 625 | |<--------------------| 626 | | | 627 | | Send Manifest | 628 | |-------------------->| 629 | | | 630 | | | Validate Manifest 631 | | |------------------ 632 | | | | 633 | | |<----------------- 634 | | | 635 | | Request Firmware | 636 | |<--------------------| 637 | | | 638 | | Send Firmware | 639 | |-------------------->| 640 | | | 641 | | | Verify Firmware 642 | | |--------------- 643 | | | | 644 | | |<-------------- 645 | | | 646 | | | Store Firmware 647 | | |-------------- 648 | | | | 649 | | |<------------- 650 | | | 651 | | | Reboot 652 | | |------- 653 | | | | 654 | | |<------ 655 | | | 656 | | | Bootloader validates 657 | | | Firmware 658 | | |---------------------- 659 | | | | 660 | | |<--------------------- 661 | | | 662 | | | Bootloader activates 663 | | | Firmware 664 | | |---------------------- 665 | | | | 666 | | |<--------------------- 667 | | | 668 | | | Bootloader transfers 669 | | | control to new Firmware 670 | | |---------------------- 671 | | | | 672 | | |<--------------------- 673 | | | 675 Figure 4: Example Flow for a Firmware Upate. 677 8. IANA Considerations 679 This document does not require any actions by IANA. 681 9. Security Considerations 683 Firmware updates fix security vulnerabilities and are considered to 684 be an important building block in securing IoT devices. Due to the 685 importance of firmware updates for IoT devices the Internet 686 Architecture Board (IAB) organized a 'Workshop on Internet of Things 687 (IoT) Software Update (IOTSU)', which took place at Trinity College 688 Dublin, Ireland on the 13th and 14th of June, 2016 to take a look at 689 the big picture. A report about this workshop can be found at 690 [RFC8240]. A standardized firmware manifest format providing end-to- 691 end security from the author to the device will be specified in a 692 separate document. 694 There are, however, many other considerations raised during the 695 workshop. Many of them are outside the scope of standardization 696 organizations since they fall into the realm of product engineering, 697 regulatory frameworks, and business models. The following 698 considerations are outside the scope of this document, namely 700 - installing firmware updates in a robust fashion so that the update 701 does not break the device functionality of the environment this 702 device operates in. 704 - installing firmware updates in a timely fashion considering the 705 complexity of the decision making process of updating devices, 706 potential re-certification requirements, and the need for user 707 consent to install updates. 709 - the distribution of the actual firmware update, potentially in an 710 efficient manner to a large number of devices without human 711 involvement. 713 - energy efficiency and battery lifetime considerations. 715 - key management required for verifying the digital signature 716 protecting the manifest. 718 - incentives for manufacturers to offer a firmware update mechanism 719 as part of their IoT products. 721 10. Mailing List Information 723 The discussion list for this document is located at the e-mail 724 address suit@ietf.org [1]. Information on the group and information 725 on how to subscribe to the list is at 726 https://www1.ietf.org/mailman/listinfo/suit 728 Archives of the list can be found at: https://www.ietf.org/mail- 729 archive/web/suit/current/index.html 731 11. Acknowledgements 733 We would like to thank the following persons for their feedback: 735 - Geraint Luff 737 - Amyas Phillips 739 - Dan Ros 741 - Thomas Eichinger 743 - Michael Richardson 745 - Emmanuel Baccelli 747 - Ned Smith 749 - David Brown 751 - Jim Schaad 753 - Carsten Bormann 755 - Cullen Jennings 757 - Olaf Bergmann 759 - Suhas Nandakumar 760 - Phillip Hallam-Baker 762 - Marti Bolivar 764 - Andrzej Puzdrowski 766 - Markus Gueller 768 - Henk Birkholz 770 - Jintao Zhu 772 We would also like to thank the WG chairs, Russ Housley, David 773 Waltermire, Dave Thaler for their support and their reviews. 774 Kathleen Moriarty was the responsible security area director when 775 this work was started. 777 12. References 779 12.1. Normative References 781 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 782 Requirement Levels", BCP 14, RFC 2119, 783 DOI 10.17487/RFC2119, March 1997, . 786 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 787 Security (TLS) / Datagram Transport Layer Security (DTLS) 788 Profiles for the Internet of Things", RFC 7925, 789 DOI 10.17487/RFC7925, July 2016, . 792 12.2. Informative References 794 [LwM2M] OMA, ., "Lightweight Machine to Machine Technical 795 Specification, Version 1.0.2", February 2018, 796 . 800 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 801 (AES) Key Wrap with Padding Algorithm", RFC 5649, 802 DOI 10.17487/RFC5649, September 2009, . 805 [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet 806 of Things Software Update (IoTSU) Workshop 2016", 807 RFC 8240, DOI 10.17487/RFC8240, September 2017, 808 . 810 [SUIT-IM] Moran, B., Tschofenig, H., Birkholz, H., and J. Jimenez, 811 "Firmware Updates for Internet of Things Devices - An 812 Information Model for Manifests", June 2018. 814 12.3. URIs 816 [1] mailto:suit@ietf.org 818 Authors' Addresses 820 Brendan Moran 821 Arm Limited 823 EMail: Brendan.Moran@arm.com 825 Milosch Meriac 826 Consultant 828 EMail: milosch@meriac.com 830 Hannes Tschofenig 831 Arm Limited 833 EMail: hannes.tschofenig@gmx.net