Draft: draft-ietf-rats-architecture

Commentary: Signed - off - by :
Paragraph (version B):
This section covers a number of representative use cases for
attestation, independent of solution.  The purpose is to provide
motivation for various aspects of the architecture presented in this
draft.  Many other use cases exist, and this document does not intend
to have a complete list, only to have a set of use cases that
collectively cover all the functionality required in the
architecture.
Paragraph (version B):
Each use case includes a description, and a summary of what an
Attester and a Relying Party refer to in the use case.
Paragraph (version B):
Network operators want a trustworthy report of identity and version
of information of the hardware and software on the machines attached
to their network, for purposes such as inventory, auditing, and/or
logging.  The network operator may also want a policy by which full
access is only granted to devices that meet some definition of
health, and so wants to get claims about such information and verify
their validity.  Attestation is desired to prevent vulnerable or
compromised devices from getting access to the network and
potentially harming others.
Paragraph (version B):
Typically, solutions start with some component (called a "Root of
Trust") that provides device identity and protected storage for
measurements.  They then perform a series of measurements, and
express this with Evidence as to the hardware and firmware/software
that is running.
Paragraph (version B):
Relying Party: A network infrastructure device such as a router,
switch, or access point.
Paragraph (version B):
A device manufacturer wants to protect its intellectual property in
terms of the ML model it developed and that runs in the devices that
its customers purchased, and it wants to prevent attackers,
potentially including the customer themselves, from seeing the
details of the model.
Paragraph (version B):
This typically works by having some protected environment in the
device attest to some manufacturer service.  If attestation succeeds.
then the manufacturer service releases either the model, or a key to
decrypt a model the Attester already has in encrypted form, to the
requester.
Paragraph (version B):
This is a generalization of the ML model use case above, where the
data can be any highly confidential data, such as health data about
customers, payroll data about employees, future business plans, etc.
Attestation is desired to prevent leaking data to compromised
devices.
Paragraph (version B):
In this use case, potentially dangerous physical equipment (e.g.,
power grid, traffic control, hazardous chemical processing, etc.) is
connected to a network.  The organization managing such
infrastructure needs to ensure that only authorized code and users
can control such processes, and they are protected from malware or
other adversaries.  When a protocol operation can affect some
critical system, the device attached to the critical equipment thus
wants some assurance that the requester has not been compromised.  As
such, attestation can be used to only accept commands from requesters
that are within policy.
Paragraph (version B):
Attester: A device or application wishing to control physical
equipment.
Paragraph (version B):
Relying Party: A device or application connected to potentially
dangerous physical equipment (hazardous chemical processing,
traffic control, power grid, etc.
Paragraph (version B):
A "Trusted Application Manager (TAM)" server is responsible for
managing the applications running in the TEE of a client device.  To
do this, the TAM wants to verify the state of a TEE, or of
applications in the TEE, of a client device.  The TEE attests to the
TAM, which can then decide whether the TEE is already in compliance
with the TAM's latest policy, or if the TAM needs to uninstall,
update, or install approved applications in the TEE to bring it back
into compliance with the TAM's policy.
Paragraph (version B):
Attester: A device with a trusted execution environment capable of
running trusted applications that can be updated.
Paragraph (version B):
Relying Party: A Trusted Application Manager.
Paragraph (version B):
One significant problem is malware that holds a device hostage and
does not allow it to reboot to prevent updates to be applied.  This
is a significant problem, because it allows a fleet of devices to be
held hostage for ransom.
Paragraph (version B):
A hardware watchdog can be implemented by forcing a reboot unless
attestation to a remote server succeeds within a periodic interval,
and having the reboot do remediation by bringing a device into
compliance, including installation of patches as needed.
Paragraph (version B):
Attester: The device that is desired to keep from being held
hostage for a long period of time.
Paragraph (version B):
Relying Party: A remote server that will securely grant the
Attester permission to continue operating (i.e., not reboot) for a
period of time.