Draft: draft-ietf-suit-information-model

Commentary: Removed the term OEM from the document and replaced it with Network or Device Operator . Listed names in the Acknowledgements section . Minor editorial bugfixes .
Paragraph (version A):
This document uses terms defined in I-D.ietf-suit-architecture.
Paragraph (version B):
This document uses terms defined in I-D.ietf-suit-architecture.  The
term 'Operator' refers to both, Device and Network Operator.
Paragraph (version A):
In this example let us assume that OEMs expect the rights to create
firmware but that Operators expect the rights to qualify firmware as
fit-for-purpose on their networks.  Additionally assume that an OEM
sells devices that operate on any network, including Network A and B
in our example.
Paragraph (version B):
In this example let us assume that Device Operators expect the rights
to create firmware but that Network Operators expect the rights to
qualify firmware as fit-for-purpose on their networks.  Additionally
assume that an Device Operators manage devices that can be deployed
on any network, including Network A and B in our example.
Paragraph (version A):
Multiple devices that interoperate are used on the same network and
communicate with each other.  Some devices are manufactured by OEM A
and other devices by OEM B.  A new firmware is released by OEM A that
breaks compatibility with OEM B devices.  An attacker sends the new
firmware to the OEM A devices without approval of the Operator.  This
breaks the behaviour of the larger system causing denial of service
and possibly other threats.  Where the network is a distributed SCADA
system, this could cause misbehaviour of the process that is under
control.
Paragraph (version B):
Multiple devices that interoperate are used on the same network and
communicate with each other.  Some devices are manufactured and
managed by Device Operator A and other devices by Device Operator B.
A new firmware is released by Device Operator A that breaks
compatibility with devices from Device Operator B.  An attacker sends
the new firmware to the devices managed by Device Operator A without
approval of the Network Operator.  This breaks the behaviour of the
larger system causing denial of service and possibly other threats.
Where the network is a distributed SCADA system, this could cause
misbehaviour of the process that is under control.
Paragraph (version A):
N.B.  This is not a firmware version.  It is a manifest sequence
number.  A firmware version may be rolled back by creating a new
manifest for the old firmware version with a later sequence number.
Paragraph (version B):
Note: This is not a firmware version.  It is a manifest sequence
number.  A firmware version may be rolled back by creating a new
manifest for the old firmware version with a later sequence number.
Paragraph (version A):
For example, if a device has a policy that requires that firmware
have both an Authorship right and a Qualification right and if that
device grants Authorship and Qualification rights to different
parties, such as an OEM and an Operator, respectively, then the
firmware cannot be installed without proof of rights from both the
OEM and the Operator.
Paragraph (version B):
For example, if a device has a policy that requires that firmware
have both an Authorship right and a Qualification right and if that
device grants Authorship and Qualification rights to different
parties, such as a Device Operator and a Network Operator,
respectively, then the firmware cannot be installed without proof of
rights from both the Device and the Network Operator.
Paragraph (version A):
As an OEM for IoT devices, I want to provide my devices with
additional installation instructions so that I can keep process
details out of my payload data.
Paragraph (version B):
As an Device Operator, I want to provide my devices with additional
installation instructions so that I can keep process details out of
my payload data.
Paragraph (version A):
As a Network Operator, I would like to be able to override the non-
critical information in the manifest so that I can control my devices
more precisely.  This assumes that the OEM holds more rights on a
device than the Network Operator.
Paragraph (version B):
As a Network Operator, I would like to be able to override the non-
critical information in the manifest so that I can control my devices
more precisely.  This assumes that the Device Operator delegated
rights about the device to the Network Operator.
Paragraph (version A):
As an Operator, I want to ensure the quality of a firmware update
before installing it, so that I can ensure a high standard of
reliability on my network.  The OEM may restrict my ability to create
firmware, so I cannot be the only authority on the device.
Paragraph (version A):
As a Operator, I want to be able to send multiple payload formats to
suit the needs of my update, so that I can optimise the bandwidth
used by my devices.
Paragraph (version B):
As a Device Operator, I want to ensure the quality of a firmware
update before installing it, so that I can ensure interoperability of
all devices in my product family.  I want to restrict the ability to
make changes to my firmware to certain operations only.
Paragraph (version B):
As an Operator, I want to be able to send multiple payload formats to
suit the needs of my update, so that I can optimise the bandwidth
used by my devices.
Paragraph (version A):
As an OEM or developer, I want to prevent confidential information
from being disclosed during firmware updates.  It is assumed that
channel security is adequate to protect the manifest itself against
information disclosure.
Paragraph (version B):
As an firmware author, I want to prevent confidential information
from being disclosed during firmware updates.  It is assumed that
channel security is adequate to protect the manifest itself against
information disclosure.
Paragraph (version A):
As an Operator, I want devices to determine whether they can process
a payload prior to downloading it.
Paragraph (version A):
In some cases, it may be desirable for a third party to perform some
processing on behalf of a target.  For this to occur, the third party
MUST indicate what processing occurred and how to verify it against
the Firmware Authority's intent.
Paragraph (version B):
As a Device Operator, I want devices to determine whether they can
process a payload prior to downloading it.
Paragraph (version B):
In some cases, it may be desirable for a third party to perform some
processing on behalf of a target.  For this to occur, the third party
MUST indicate what processing occurred and how to verify it against
the Trust Provisioning Authority's intent.
Paragraph (version A):
As an Operator, I want to be able to target devices for updates based
on their current firmware version, so that I can control which
versions are replaced with a single manifest.
Paragraph (version B):
As a Device Operator, I want to be able to target devices for updates
based on their current firmware version, so that I can control which
versions are replaced with a single manifest.
Paragraph (version A):
It must be possible to redirect payload fetches.  This applies where
two manifests are used in conjunction.  For example, an OEM manifest
specifies a payload and signs it, and provides a URI for that
payload.  An Operator creates a second manifest, with a dependency on
the first.  They use this second manifest to override the URIs
provided by the OEM, directing them into their own infrastructure
instead.  Some devices may provide this capability, while others may
only look at canonical sources of firmware.  For this to be possible,
the device must fetch the payload, whereas a device that accpets
payload pushes will ignore this feature.
Paragraph (version B):
It must be possible to redirect payload fetches.  This applies where
two manifests are used in conjunction.  For example, a Device
Operator creates a manifest specifying a payload and signs it, and
provides a URI for that payload.  A Network Operator creates a second
manifest, with a dependency on the first.  They use this second
manifest to override the URIs provided by the Device Operator,
directing them into their own infrastructure instead.  Some devices
may provide this capability, while others may only look at canonical
sources of firmware.  For this to be possible, the device must fetch
the payload, whereas a device that accpets payload pushes will ignore
this feature.
Paragraph (version A):
An IoT device firmware can be divided into two payloads: code and
configuration.  These payloads may require authority from different
actors in order to install (see MFSR6 and MFSR8).  This structure
means that multiple manifests may be required, with a dependency
structure between them.
Paragraph (version A):
An IoT device firmware can be divided into multiple functional blocks
for separate testing and distribution.  This means that code would
need to be distributed in multiple payloads.  For example, this might
be desirable in order to ensure that common code between devices is
identical in order to reduce distribution bandwidth.
Paragraph (version B):
A firmware image can be divided into two payloads: code and
configuration.  These payloads may require authorizations from
different actors in order to install (see MFSR6 and MFSR8).  This
structure means that multiple manifests may be required, with a
dependency structure between them.
Paragraph (version B):
A firmware image can be divided into multiple functional blocks for
separate testing and distribution.  This means that code would need
to be distributed in multiple payloads.  For example, this might be
desirable in order to ensure that common code between devices is
identical in order to reduce distribution bandwidth.