markdown version of sidemeeting notes

draft-richardson-rats-usecases.md

@@ -43,6 +43,7 @@ informative:
   RFC7030:
   RFC4210:
   RFC8555:
+  I-D.fedorkow-rats-network-device-attestation:
   I-D.tschofenig-rats-psa-token:
   I-D.gutmann-scep:
   keystore:
@@ -52,6 +53,27 @@ informative:
       ins: "Google"
       date: 2019
 
+  SP800-155:
+    target: "https://csrc.nist.gov/CSRC/media/Publications/sp/800-155/draft/documents/draft-SP800-155_Dec2011.pdf"
+    title: "BIOS Integrity Measurement Guidelines (Draft)"
+    author:
+      name: NIST
+      date: 2011
+
+  SP800-147B:
+    target: "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-147B.pdf"
+    title: "BIOS Protection Guidelines for Servers"
+    author:
+      name: NIST
+      date: "August 2014"
+
+  tcgglossary:
+    target: "https://trustedcomputinggroup.org/wp-content/uploads/TCG-Glossary-V1.1-Rev-1.0.pdf"
+    title: "TCG Glossary, Version 1.1"
+    author:
+      name: Trusted Computing Group
+      date: 2017-05-11
+
   ieee802-1AR:
     target: "http://standards.ieee.org/findstds/standard/802.1AR-2009.html"
     title: "IEEE 802.1AR Secure Device Identifier"
@@ -202,7 +224,41 @@ which is being attested to.
 
 ## Hardware Root Of Trust
 
-(TBD: Seeking something useful here.)
+{{SP800-155}} offers the following definition for root of trust.
+
+    “Roots of Trust are components (software, hardware, or hybrid) and computing
+    engines that constitute a set of unconditionally trusted functions. Reliable
+    and trustworthy BIOS integrity measurement and reporting depend upon software
+    agents; each software agent relies upon Roots of Trust, and the level of
+    trustworthiness in each agent depends on its Roots of Trust. BIOS integrity
+    measurement requires the coordination of a Measurement Agent to harvest
+    measurements, a Storage Agent to protect the measurements from modification
+    until they can be reported, and a Reporting Agent to reliably report the
+    measurements. Each of these agents has a corresponding Root of Trust (Root of
+    Trust for Measurement, etc.) These Roots of Trust must act in concert and
+    build on each other to enable reliable and trustworthy measurement,
+    reporting, and verification of BIOS integrity measurements.”
+
+SP800-155 uses the terms RoT for Reporting, Storage and Measurement, but not
+RoT for Verification – it uses “Verification Agent”. Though it is assumed the
+verifier is trustworthy. 
+
+However, {{tcgglossary}} (page 9) includes a RoT for Verification (RTV) as well.
+
+The TCG Glossary also offers a general definition for Root of Trust “A
+component that performs one or more security-specific functions, such as
+measurement, storage, reporting, verification, and/or update. It is trusted
+always to behave in the expected manner, because its misbehavior cannot be
+detected (such as by measurement) under normal operation. “ 
+
+{{SP800-147B}} defines RoT for Update (RoTU) and RoTU verification (RoTU-v).  
+
+The TCG definition seems more concise than the NIST, but gets to the same point.
+
+For the purpose of this documenet, a hardware root of trust refers to
+security functionality that is trusted to behave in the expected manner,
+because its misbehavior cannot be detected under normal operation and resists
+soft exploits by encapsulating the functionality in hardware.
 
 # Requirements Language {#rfc2119}
 
@@ -254,7 +310,7 @@ in attestations that the relying parties can depend upon.
 ### Autonomous Relying Party
 
 The signed measurements are sent to a relying party which must validate them
-directly.  (It may do so with the help of of a signed list of golden values,
+directly.  (It may do so with the help of a signed list of golden values,
 or some other process).  The relying party needs to validate the signed
 statements directly.
 
@@ -264,7 +320,7 @@ not be connected until the equipment is validated.
 ### Proxy Root of Trust
 
 A variety of devices provide measurements via their Root of Trust.
-A server collects these measurements, and (having applied a local policy)
+A proxy server collects these measurements, and (having applied a local policy)
 then creates a device agnostic attestation.  The relying party can validate
 the claims in a standard format.
 
@@ -291,7 +347,7 @@ system of N:1:M relationships can be setup via proxy attestations.
 
 An entire network of systems need to be continuously attested.  This could be
 all of the smartphones on an LTE network, or every desktop system in a
-worldwide enterprise.  The network operator wishes to do this in order
+worldwide enterprise.  The network operator wishes to do this in order to
 maintain identities of connected devices more than to validate correct
 firmware, but both situations are reasonable.
 
@@ -400,7 +456,8 @@ ownership) over the end device.
 This use case convinces the relying party of the characteristics of a
 device.  For privacy reasons, it might not identify the actual device itself,
 but rather the class of device.  The relying party can understand from either
-in-band (claims) or out-of-band (model numbers, which may be expressed as a claim) whether the device has
+in-band (claims) or out-of-band (model numbers, which may be expressed as a claim) 
+whether the device has trustworthy
 features such as a hardware TPM, software TPM via TEE, or software TPM
 without TEE.  Other details such as the availability of finger-print readers
 or HDMI outputs may also be inferred.
@@ -482,16 +539,41 @@ situation would be a media owner needing to know what TV device is connected
 via HDMI and if High-bandwidth Digital Content Protection (HDCP) is
 intact.
 
+## Component connectivity attestation
+
+A management controller or similar hardware component wants to know what
+peripherals, rack scale device or other dynamically configurable components
+are currently attached to the platform that is under management controller
+control. The management controller may serve as attestation verifier over a
+local bus or backplane but may also aggregate local attestation results and
+act as a platform attester to a remote verifier. 
+
+## Device provenance attestation
+
+A newly manufactured device needs to be onboarded into a network where many
+if not all device management duties are performed by the network owner. The
+device owner wants to verify the device originated from a legitimate
+vendor. A cryptographic device identity such as an IEEE802.1AR is embedded
+during manufacturing and a certificate identifying the device is delivered to
+the owner onboarding agent. The device authenticates using its 802.1AR IDevID
+to prove it originated from the expected vendor.  
+
+The device chain of custody from the original device manufacturer to the new
+owner may also be verified as part of device provenance attestation. The
+chain of custody history may be collected by a cloud service or similar
+capability that the supply chain and owner agree to use. 
+
+
 
 # Technology users for RATS
 
 ## Trusted Computing Group (TCG)
 
-The TCG is trying to solve the problem of knowing if a networking device
+The TCG embedded systems work is trying to solve the problem of knowing if a networking device
 should be part of a network, if it belongs to the operator, and if it is running
 appropriate software.  The work covers most of the use cases in {{netattest}}.
 
-This proposal is a work-in-progress, and is available to TCG members only.
+This proposal is available as {{I-D.fedorkow-rats-network-device-attestation}}.
 The goal is to be multi-vendor, scalable and extensible.   The proposal
 intentionally limits itself to: