* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Suit Status Pages

Software Updates for Internet of Things (Concluded WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2017-Dec-15 —  

2021-03-11 charter

Software Updates for Internet of Things (suit)


 Current Status: Active

     Dave Thaler <dthaler@microsoft.com>
     David Waltermire <david.waltermire@nist.gov>
     Russ Housley <housley@vigilsec.com>

 Security Area Directors:
     Roman Danyliw <rdd@cert.org>
     Benjamin Kaduk <kaduk@mit.edu>

 Security Area Advisor:
     Roman Danyliw <rdd@cert.org>

 Mailing Lists:
     General Discussion: suit@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/suit
     Archive:            https://mailarchive.ietf.org/arch/search/?email_list=suit

Description of Working Group:

  Vulnerabilities in Internet of Things (IoT) devices have raised the need
  for a secure firmware update mechanism that is also suitable for constrained
  devices.  Security experts, researchers, and regulators recommend that all IoT
  devices be equipped with such a mechanism.  While there are many proprietary
  firmware update mechanisms in use today, there is no modern interoperable
  approach allowing secure updates to firmware in IoT devices. In June of 2016
  the Internet Architecture Board organized a workshop on 'Internet
  of Things (IoT) Software Update (IOTSU)', and RFC 8240 documents various
  requirements and challenges that are specific to IoT devices.

  A firmware update solution consists of several components, including:
  * A mechanism to transport firmware images to compatible devices.
  * A manifest that provides meta-data about the firmware image (such as a
  firmware package identifier, the hardware the package needs to run, and
  dependencies on other firmware packages), as well as cryptographic information
  for protecting the firmware image in an end-to-end fashion.
  * The firmware image itself.

  This group will focus on defining a firmware update solution (taking into
  account past learnings from RFC 4108 and other firmware update solutions) that
  will be usable on Class 1 (as defined in RFC 7228) devices, i.e., devices with
  ~10 KiB RAM and ~100 KiB flash.  The solution may apply to more capable devices
  as well.  This group will not define any new transport or discovery mechanisms,
  but may describe how to use existing mechanisms within the architecture.

  In particular this group aims to publish several documents, namely:
  * An IoT firmware update architecture that includes a description of the
  involved entities, security threats, and assumptions.
  * One or more manifest format specifications.

  To support specification of manifest format(s), this group will first develop the
  information model for the contents of a manifest. Once there is general agreement
  on the contents, the group will pick a small number of serialization formats such as
  CBOR and/or ASN.1 (and their associated cryptographic mechanisms) to encode the
  manifest. A small number of formats is preferred to reduce the complexity of a
  firmware management solution, where each IoT device would typically only
  support one format, but the same tool or service might support all such
  formats. To support a wide range of deployment scenarios, the formats are
  expected to be expressive enough to allow the use of different firmware sources
  and permission models.

  This group does not aim to create a standard for a generic application software
  update mechanism, but instead this group will focus on firmware development
  practices in the embedded industry. Software update solutions that target
  updating software other than the firmware binaries (e.g., applications) are
  also out of scope.

  This group will aim to maintain a close relationship with silicon vendors and
  OEMs that develop IoT operating systems.

Goals and Milestones:
  Mar 2020 - Submit an initial manifest serialization format to the IESG for publication as a Proposed Standard.
  Done     - Adopt "Architecture" document as WG item.
  Done     - Adopt a manifest information model as a WG item.
  Done     - Calendar item: First interoperability event at IETF 101.
  Done     - Calendar item: Second interoperability event at IETF 102.
  Done     - Adopt initial manifest serialization format(s) as WG item(s).
  Done     - Submit manifest information model to the IESG for publication as Informational.
  Done     - Submit architecture to the IESG for publication as Informational

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/suit/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -