[Ietf-lac] Fwd: WG Action: Formed Software Updates for Internet of Things (suit)

[Alvaro Retana]

On December 15, 2017 at 12:59:51 PM, The IESG (iesg-secretary at ietf.org)
wrote:

A new IETF WG has been formed in the Security Area. For additional
information, please contact the Area Directors or the WG Chairs.

Software Updates for Internet of Things (suit)
-----------------------------------------------------------------------
Current status: Active WG

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

Assigned Area Director:
Kathleen Moriarty <Kathleen.Moriarty.ietf at gmail.com>

Security Area Directors:
Kathleen Moriarty <Kathleen.Moriarty.ietf at gmail.com>
Eric Rescorla <ekr at rtfm.com>

Mailing list:
Address: suit at ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/suit
Archive: https://mailarchive.ietf.org/arch/search/?email_list=suit

Group page: https://datatracker.ietf.org/group/suit/

Charter: https://datatracker.ietf.org/doc/charter-ietf-suit/

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.

Milestones:

Jan 2018 - Adopt "Architecture" document as WG item.

Mar 2018 - Adopt a manifest information model as a WG item.

Mar 2018 - Calendar item: First interoperability event at IETF 101.

Mar 2018 - Adopt initial manifest serialization format(s) as WG item(s).

Jul 2018 - Calendar item: Second interoperability event at IETF 102.

Jul 2018 - Submit manifest information model to the IESG for publication as
Informational.

Nov 2018 - Submit an initial manifest serialization format to the IESG for
publication as a Proposed Standard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/ietf-lac/attachments/20171215/b1821e72/attachment.html>