<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" category="std" docName="draft-nandakumar-suit-secfu-requirements-00">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc private=""?>
<?rfc topblock="yes"?>
<?rfc comments="no"?>
<front>
<title abbrev="SecFU">Solution Requirements - Secure Firmware Upgrade (SecFU)</title>

<author initials="S." surname="Nandakumar" fullname="Suhas Nandakumar">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>snandaku@cisco.com</email>
<uri></uri>
</address>
</author>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>fluffy@iii.ca</email>
<uri></uri>
</address>
</author>
<author initials="S." surname="Cooley" fullname="Shaun Cooley">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
<region></region>
</postal>
<phone></phone>
<email>scooley@cisco.com</email>
<uri></uri>
</address>
</author>
<date year="2017" month="October" day="30"/>

<area>Internet</area>
<workgroup></workgroup>


<abstract>
<t>The IETF SUIT effort has been forming to define a secure firmware
upgrade solution for Internet of Things (IOT). Recent vulnerabilities
and the need to upgrade firmware on the IoT devices for security updates in
a standardized, secure, and automated fashion has been the driving
force behind this work.
</t>
<t>This specification is a requirements document to aid in developing
a solution for Secure Firmware upgrade of the IoT devices.
</t>
</abstract>


</front>

<middle>

<section anchor="introduction" title="Introduction">
<t>This draft outlines a set of requirements around firmware download for
IoT devices. A sketch of a proposed solution can be found in .
</t>
</section>

<section anchor="solution-requirements" title="Solution Requirements">
<t>Informally, a secure firmware upgrade solution might need to address
following components:
</t>
<t>
<list style="symbols">
<t>Secure firmware description container format, in the form of Manifest</t>
<t>Locating a server to download the firmware from</t>
<t>Downloading the manifest and the firmware image(s)</t>
<t>Cryptographic validation of the manifest and signed code images</t>
<t>Complete the installation</t>
</list>
</t>
<t>Given above tasks, this specification breaks down the secure firmware
upgrade solution into following requirements:
</t>
<t>
<list style="numbers">
<t>Solution must allow devices that delete the old firmware before installing
the new firmware. Thus implying a solution that can easily be implementable
on a minimal boot-loader</t>
<t>Solution must enable devices that have enough memory to have the new firmware
image of the firmware simultaneously loaded with the existing image.</t>
<t>The manifest format should be self describing.</t>
<t>Allow a given device to decide which manifest format is appropriate
for it choosing from JSON, CBOR, or perhaps ASN.1 if there is a a
device vendor that plans to use this</t>
<t>Manifest must allow metadata about the firmware sourced by a single
manufacturer</t>
<t>Optionally, the solution may allow the manifest to describe metadata
about firmwares from different providers</t>
<t>The solution should enable firmware that is delivered as a single image</t>
<t>Optionally, the solution may enable firmware to be split into multiple images.</t>
<t>The charter should recommend a solution agnostic to the format of the firmware image and inter dependencies. Dependency management is complicated and is by nature proprietary and should not be in the initial scope.</t>
<t>The proposed solution must provide mechanism to discover where to download the
firmware where that mechanism includes the ability for a local cache.</t>
<t>The proposed solution should allow flexibility to choose the underlying transport
protocol as defined by the deployment scenarios. The WG should define a MTI set of protocols that firmware servers need to implement and clients can choose which one to use</t>
<t>The proposed solution must require a device to validate signatures on the manifest
and firmware image(s)</t>
<t>Optionally, the solution might want to support encrypted manifest and firmware</t>
<t>The proposed solution should enable crypto agility and prevent roll-back attacks.</t>
<t>Solution should allow for secure transition between the generations of the keying material</t>
<t>Charter should not invent new crypto or transports and use existing techniques</t>
</list>
</t>
</section>

<section anchor="iana-consideration" title="IANA Consideration">
<t>Not Applicable
</t>
</section>

<section anchor="security-considerations" title="Security Considerations">
<t>Not Applicable
</t>
</section>

<section anchor="acknowledgements" title="Acknowledgements">
<t>Thanks IOTSU workshop.
</t>
</section>

</middle>
</rfc>
