draft-fedorkow-rats-network-device-attestation-01b.xml

<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC8348 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8348.xml">
<!ENTITY RFC7049 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7049.xml">
<!ENTITY RFC8572 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8572.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I-D.birkholz-yang-basic-remote-attestation SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-birkholz-yang-basic-remote-attestation-01.xml">
<!ENTITY I-D.birkholz-rats-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-birkholz-rats-architecture-01.xml">
<!ENTITY I-D.birkholz-yang-swid SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-birkholz-yang-swid-02.xml">
<!ENTITY I-D.ietf-sacm-coswid SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sacm-coswid-11.xml">
<!ENTITY I-D.birkholz-rats-reference-interaction-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-birkholz-rats-reference-interaction-model-00.xml">
<!ENTITY I-D.birkholz-suit-coswid-manifest SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-birkholz-suit-coswid-manifest-00.xml">

]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes"?>

<?rfc tocdepth="4"?>

<?rfc symrefs="yes"?>

<?rfc sortrefs="yes" ?>

<?rfc compact="yes" ?>

<?rfc subcompact="no" ?>

<rfc category="info" docName="draft-fedorkow-rats-network-device-attestation-00" ipr="trust200902">
 
	<!-- ***** FRONT MATTER ***** -->

	<front>
		
		<title abbrev="Network Device Attestation Workflow">Network Device Attestation Workflow</title>

		<!-- add 'role="editor"' below for the editors if appropriate -->

		<!-- Another author who claims to be an editor -->

		<author fullname="Guy Fedorkow" initials="G.F." role="editor"
							surname="Fedorkow">
				<organization>Juniper Networks, Inc.</organization>
				<address>
					<postal>
						<street></street>
						<city></city>
						<region></region>
						<code></code>
						<country>US</country>
					</postal>
					<phone></phone>
					<email>gfedorkow@juniper.net</email>
				</address>
			</author>

		<author fullname="Jessica Fitzgerald-McKay" initials="J"
							surname="Fitzgerald-McKay">
				<organization>National Security Agency</organization>

				<address>
					<postal>
						<street></street>
						<city></city>
						<region></region>
						<code></code>
						<country>US</country>
					</postal>

					<phone></phone>

					<email>jmfitz2@nsa.gov</email>
				</address>
			</author>

			<date month="June" year="2019" />
		

			<!-- Meta-data Declarations -->

			<area>Security</area>

			<workgroup>RATS Working Group</workgroup>

			<keyword>Internet-Draft</keyword>

			<abstract>
			<t>This document describes a workflow for network device attestation.</t>
			</abstract>
	</front>

	<middle>
		<section title="Introduction">

		<t>There are many components to consider in fielding a trusted computing device, from operating systems to applications.  Part of that is a trusted supply chain, where manufacturers can certify that the product they intended to build is actually the one that was installed at a customer's site.</t>
				<t>Attestation is defined here as the process of creating, conveying and appraising assertions about Platform trustworthiness characteristics, including Roots of Trust, supply chain trust, identity, platform provenance, shielded locations, protected capabilities, software configuration, hardware configuration, platform composition, compliance to test suites, functional and assurance evaluations, etc.</t>
				<t>The supply chain itself has many elements, from validating suppliers of electronic components, to ensuring that shipping procedures protect against tampering through many stages of distribution and warehousing.  One element that helps maintain the integrity of the supply chain after manufacturing is Attestation.</t>
				<t>Within the Trusted Computing Group context, attestation is the process by which an independent Verifier can obtain cryptographic proof as to the identity of the device in question, evidence of the integrity of software loaded on that device when it started up, and then verify that what's there is what's supposed to be there.  For networking equipment, a verifier capability can be embedded in a Network Management Station (NMS), a posture collection server, or other network analytics tool (such as a software asset management solution, or a threat detection and mitigation tool, etc.). While informally referred to as attestation, this document focuses on a subset defined here as Remote Integrity Verification (RIV).  RIV takes a network equipment centric perspective that includes a set of protocols and procedures for determining whether a particular device was launched with untampered software, starting from Roots of Trust.  While there are many ways to accomplish attestation, RIV sets out a specific set of protocols and tools that work in environments commonly found in Networking Equipment.  RIV does not cover other platform characteristics that could be attested, although it does provide evidence of a secure infrastructure to increase the level of trust in other platform characteristics attested by other means.</t>
				<t>This profile outlines the RIV problem, and then identifies components that are necessary to get the complete attestation procedure working in a scalable solution using commercial products.</t>
				<t>This document focuses primarily on software integrity verification using the Trusted Platform Module (TPM) as a root of trust.</t>
				<t>Attestation information of course must be protected by means of cryptographic techniques to assure its validity.  It's important to note that TCG technologies are available to use either symmetric key encryption with shared keys, or public key cryptography using private/public key pairs.  The two techniques can each produce secure results, but do require different provisioning mechanisms.  The RIV document currently focuses on asymmetric keying approaches only; future work might include techniques for attestation using symmetric keys.</t>

			<section title="Requirements Language">
				<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",	"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>	<xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>

				<!-- <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
				"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
				document are to be interpreted as described in <xref
				target="RFC2119">RFC 2119</xref>.</t>
				-->
			</section>
		
		<section title ="Goals">
			<t>As a part of a trusted supply chain, Attestation requires two interlocking services:</t>
			<t><list style="symbols">
					<t>Platform Identity, the mechanism providing trusted identity, can reassure network managers that the specific devices they ordered from authorized manufacturers for attachment to their network are those that were installed, and that they continue to be present in their network. As part of the mechanism for Platform Identity, cryptographic proof of the identity of the manufacturer is also provided.</t>
					<t>Software Measurement is the mechanism that reports the state of mutable components on the device, and can assure network managers that they have known, untampered software configured to run in their network.</t>
				</list></t>		
			<t>The RIV attestation workflow outlined in this document is intended to meet the following high-level goals:</t>
			<t><list style="symbols">
					<t>Provable Device Identity - The ability to identify a device using a cryptographic identifier is a critical prerequisite to software inventory attestation.</t>
			<t>Software Inventory - A key goal is to identify the software release installed on the device, and to provide evidence of its integrity.</t>
			<t>Verification - Verification of software and configuration of the device shows that the software that's supposed to be installed on  there actually has been launched, without unauthorized modification.</t>
		</list></t>
		<t>This document itself is non-normative; the document does not define protocols, but rather identifies protocols that can be used together to achieve the goals above, and in some cases, highlights gaps in existing protocols.</t>

		</section> <!-- end Goals-->

		<section title="Problem Description">
			<t>RIV is a procedure that assures a network operator that the equipment on their network can be reliably identified, and that untampered software of a known version is installed on each endpoint. In this context, endpoint might include the conventional connected devices like servers and laptops, but also connected devices that make up the network itself, such as routers, switches and firewalls.</t>
			<t>RIV can be viewed as a link in a trusted supply chain, and includes three major processes:</t>
			<t><list style="symbols">
					<t>Creation of Evidence is the process whereby an endpoint generates cryptographic proof (evidence) of claims about platform properties. In particular, the platform identity and its software configuration are of critical importance.</t>
				</list></t>

<figure align="center">
<artwork align="left"><![CDATA[
        * Platform Identity refers to the mechanism assuring the
        attestation verifier (typically a network administrator)
        of the identity of devices that make up their network,
        and that their manufacturers are known.

        * Software used to boot a platform can be described as a chain
        of measurements, started by a Root of Trust for Measurement,
        that normally ends when the system software is loaded.  
        A measurement signifies the identity, integrity and version of each
        software component registered with the TPM, so that the
        subsequent appraisal stage can determine if the software 
        installed is authentic, up-to-date, and free of tampering. Clearly the 
        second part of the problem, attesting the state of mutable components
        of a given device, is of little value without
        reliable identification of the device in question.  By the
        same token, unambiguous identity of a device is necessary,
        but is insufficient to assure the operator of the provenance
        of the device through the supply chain, or that the device is
        configured to behave properly.
]]></artwork>
</figure>
<t><list style="symbols">
					<t>Conveyance of Evidence is the process of reliably transporting evidence from the point in a connected device where a measurement is stored to an appraiser/verifier, e.g. a management station. The transport is typically carried out via a management network. The channel must provide integrity and authenticity, and, in some use cases, may also require confidentiality.</t>
					<t>Appraisal of Evidence is the process of verifying the evidence received by a verifier/appraiser from a device, and using verified evidence to inform decision making. In this context, verification means comparing the device measurements reported as evidence with the configuration expected by the system administrator. This step can work only when there is a way to express what should be there, often referred to as golden measurements, or Reference Integrity Measurements, representing the intended configured state of the connected device.</t>

				</list></t>
			<t>An implementation of RIV requires three technologies</t>
			<t><list style="numbers">
					<t>Identity: Platform identity can be based on IEEE 802.1AR Device Identity <xref target="IEEE-802-1AR"/>, coupled with careful supply-chain management by the manufacturer.  The DevID certificate contains a statement by the manufacturer that establishes the provenance of the device as it left the factory.  Some applications with a more-complex post-manufacture supply chain (e.g. Value Added Resellers), or with privacy concerns, may want to use an alternate mechanism for platform authentication based on TCG Platform Certificates <xref target="Platform-Certificates"/>.  RIV currently relies on asymmetric keying for identity; alternate approaches might use symmetric keys.</t>
					<t>Platform Attestation provides evidence of configuration of software elements throughout the product lifecycle.  This form of attestation  can be implemented with TPM PCR, Quote and log mechanisms, which provide an authenticated mechanism to report what software actually starts up on the device each time it reboots.</t>
				<t>Reference Integrity Measurements must be conveyed from the software authority (often the manufacturer for embedded systems) to the system in which verification will take place</t>
				</list></t>
			<t>Service Providers benefit from a trustworthy attestation mechanism that provides assurance that their network comprises authentic equipment, and has loaded software free of known vulnerabilities and unauthorized tampering.</t>

		</section> <!-- end Problem Description -->
		
		<section title="Solution Requirements">

			<t>The RIV attestation solution must meet a number of requirements to make it simple to deploy at scale.</t>
			<t><list style="numbers">
				<t>Easy to Use - This solution should work "out of the box" as far as possible, that is, with the fewest possible steps needed at the end-user's site.  Eliminate complicated databases or provisioning steps that would have to be executed by the owner of a new device. Network equipment is often required to "self-configure", to reliably reach out without manual intervention to prove its identity and operating posture, then download its own configuration. See <xref target="RFC8572"/> for an example of Secure Zero Touch Provisioning.</t>
				<t>Multi-Vendor - This solution should identify standards-based interfaces that allow attestation to work with attestation-capable devices and verifiers supplied by different vendors in one network.</t>
				<t>Scalable - The solution must not depend on choke points that limit the number of endpoints that could be evaluated in one network domain.</t>
				<t>Extensible - A network equipment attestation solution needs to expand over time as new features are added. The solution must allow new features to be added easily, providing for a smooth transition and allowing newer and older architectural components to continue to work together. Further, a network equipment attestation solution and the specifications referenced here must define safe extensibility mechanisms that enable innovation without breaking interoperability.</t>
				<t>Efficient - A network equipment attestation solution should, to the greatest extent feasible, continuously monitor the health and posture status of network devices. Posture measurements should be updated in real-time as changes to device posture occur and should be published to remote integrity validators. Validation reports should also be shared with their relying parties (for example, network administrators, or network analytics that rely on these reports for posture assessment) as soon as they are available.</t>
			</list></t>

		</section> <!-- end Solution Requirements -->
		
		<section title="Scope">

			<t>This document includes a number of assumptions to limit the scope:</t>
			<t><list style="symbols">
				<t>This solution is for use in non-privacy-preserving applications (for example, networking, Industrial IoT), avoiding the need for a Privacy Certificate Authority for attestation keys</t>
				<t>This document applies primarily to "embedded" applications, where the device manufacturer ships the software image for the device.</t>
				<t>The approach outlined in this document assumes the use of TPM 1.2 or TPM 2.0.</t>
			</list></t>
			
			<section title="Out of Scope">
				<t><list style="symbols">
					<t>Run-Time Attestation: Run-time attestation of Linux or other multi-threaded operating system processes considerably expands the scope of the problem.  Many researchers are working on that problem, but this document defers the run-time attestation problem.</t>
					<t>Multi-Vendor Embedded Systems: Additional coordination would be needed for devices that themselves comprise hardware and software from multiple vendors, integrated by the end user.</t>
					<t>Processor Sleep Modes: Networking equipment typically does not "sleep", so sleep and hibernate modes are not considered.</t>
					<t>Virtualization and Containerization:  These technologies are increasingly used in embedded systems, but are not considered in this revision of the document.</t>
				</list></t>

			</section> <!-- end Out of Scope -->
			
			<section title="Why Remote Integrity Verification?">

				<t>Remote Integrity Verification can go a long way to solving the "Lying Endpoint" problem, in which malicious software on an endpoint may both subvert the intended function, and also prevent the endpoint from reporting its compromised status.  Man-in-the Middle attacks are also made more difficult through a strong focus on device identity</t>
				<t>Attestation data can be used for asset management, vulnerability and compliance assessment, plus configuration management.</t>

			</section><!-- end Why Remote Attestation? -->
			<section title="Network Device Attestation Challenges">

				<t>There have been demonstrations of attestation using TPMs for years, accompanied by compelling security reasons for adopting attestation. Despite this, the technology has not been widely adopted, in part, due to the difficulties in deploying TPM-based attestation. Some of those difficulties are:</t>
				<t><list style="symbols">
					<t>Standardizing device identity. Creating and using unique device identifiers is difficult, especially in a privacy-sensitive environment.  But attestation is of limited value if the operator is unable to determine which devices pass attestation validation tests, and which fail. This problem is substantially simplified for infrastructure devices like network equipment, where identity can be explicitly coded using IEEE 802.1AR, but doing so relies on adoption of 802.1AR <xref target="IEEE-802-1AR"/> by manufacturers and hardware system integrators.</t>
					<t>Standardizing attestation representations and conveyance. Interoperable remote attestation has a fundamental dependence on vendors agreeing to a limited set of network protocols commonly used in existing network equipment for communicating attestation data. Network device vendors will be slow to adopt the protocols necessary to implement remote attestation without a fully-realized plan for deployment.</t>
					<t>Interoperability. Networking equipment operates in a fundamentally multi-vendor environment, putting additional emphasis on the need for standardized procedures and protocols.</t>
					<t>Attestation evidence is complex. Operating systems used in larger embedded devices are often multi-threaded, so the order of completion for individual processes is non-deterministic.  While the hash of a specific component is stable, once extended into a PCR, the resulting values are dependent on the (non-deterministic) ordering of events, so there will never be a single known-good value for some PCRs.  Careful analysis of event logs can provide proof that the expected modules loaded, but it's much more complicated than simply comparing reported and expected hashes, as collected in TPM Platform Configuration Registers (PCRs).</t>
					<t>Software configurations can have seemingly infinite variability.  This problem is nearly intractable on PC and server equipment, where end users have unending needs for customization and new applications.  However, embedded systems, like networking equipment, are often simpler, in that there are fewer variations and releases, with vendors typically offering fewer options for mixing and matching.</t>
					<t>Standards-based mechanisms to encode and distribute Reference Integrity Measurements, (i.e., expected values) are still in development.</t>
					<t>Software updates can be complex.  Even the most organized network operator may have many different releases in their network at any given time, with the result that there's never a single digest or fingerprint that indicates the software is "correct"; digests formed by hashing software modules on a device can only show the correct combination of versions for a specific device at a specific time.</t>
				</list></t>
				<t>None of these issues are insurmountable, but together, they've made deployment of attestation a major challenge.  The intent of this document is to outline an attestation profile that's simple enough to deploy, while yielding enough security to be useful.</t>

			</section><!-- end Network Device Attestation Challenges-->
			<section title="Why is OS Attestation Different?">
				<t>Even in embedded systems, adding Attestation at the OS level (e.g. Linux IMA, Integrity Measurement Architecture <xref target="IMA"/>) increases the number of objects to be attested by one or two orders of magnitude, involves software that's updated and changed frequently, and introduces processes that begin in unpredictable order.</t>
			<t>TCG and others (including the Linux community) are working on methods and procedures for attesting the operating system and application software, but standardization is still in process.</t>

		</section><!-- end Why is OS Attestation Different -->
		
			
		</section> <!-- end Scope -->
		</section> <!-- end Section 1 -->
	
		<section title="Solution Outline">
			<section title="2.1	RIV Software Configuration Attestation using TPM">
				<t>RIV Attestation is a process for determining the identity of software running on a specifically-identified device.  Remote Attestation is broken into two phases, shown in Figure 1:</t>
				<t><list style="symbols">
					<t>During system startup, measurements (i.e., digests computed as fingerprints of files) are extended, or cryptographically folded, into the TPM.  Entries are also added to an informational log.  The measurement process generally follows the Chain of Trust model used in Measured Boot, where each stage of the system measures the next one, and extends its measurement into the TPM, before launching it.</t>
					<t>Once the device is running and has operational network connectivity, a separate, trusted server (called a Verifier in this document) can interrogate the network device to retrieve the logs and a copy of the digests collected by hashing each software object, signed by an attestation private key known only to the TPM.</t>
				</list></t>
				<t>The result is that the Verifier can verify the device's identity by checking the certificate corresponding to the TPM's attestation public key, and can validate the software that was launched by comparing digests in the log with known-good values, and verifying their correctness by comparing with the signed digests from the TPM.</t>
				<t>It should be noted that attestation and identity are inextricably linked; signed evidence that a particular version of software was loaded is of little value without cryptographic proof of the identity of the device producing the evidence.</t>
				
				
<figure align="center" title="TCG Attestation Model" anchor="TCG-Attestation-Model">
<artwork align="left"><![CDATA[
    +-------------------------------------------------------+
    | +--------+    +--------+   +--------+    +---------+  |
    | | BIOS   |--->| Loader |-->| Kernel |--->|Userland |  |
    | +--------+    +--------+   +--------+    +---------+  |
    |     |            |           |                        |
    |     |            |           |                        |
    |     +------------+-----------+-+                      |
    |                        Step 1  |                      |
    |                                V                      |
    |                            +--------+                 |
    |                            |  TPM   |                 |
    |                            +--------+                 |
    |   Router                       |                      |
    +--------------------------------|----------------------+
                                     |
                                     |  Step 2
                                     |    +-----------+
                                     +--->| Verifier  |
                                          +-----------+
    
    Reset---------------flow-of-time-during-boot--...------->
]]></artwork>
<postamble>In Step 1, measurements are "extended" into the TPM as processes start. In Step 2, signed PCR digests are retrieved from the TPM for off-box analysis after the system is operational.</postamble>

</figure> <!-- end Figure 1 -->

			</section> <!--end TCG Attestation -->
			<section title="RIV Keying">
				<t>TPM 1.2 and TPM 2.0 have a variety of rules separating the functions of identity and attestation, allowing for use cases where software configuration must be attested, but privacy must be maintained.</t>
				<t>To accommodate these mandatory rules in an environment where device privacy is not normally a requirement, the TCG Guidance for Securing Network Equipment <xref target="NetEq"/> suggests using separate keys for Identity (i.e., DevID) and Attestation (i.e., signing a quote of the contents of the PCRs), but including the same identity information in the certificates that correspond to these two keys.</t>
				<t>In this case, the device manufacturer should provision an Initial Attestation Key (IAK) and x.509 certificate that parallels the IDevID, with the same device ID information as the IDevID certificate (i.e., the same Subject Name and Subject Alt Name, even though the key pairs are different).  This allows a quote from the device, signed by the IAK, to be linked directly to the device that provided it, by examining the corresponding IAK certificate.</t>
				<t>Inclusion of an IAK by a vendor does not preclude a mechanism whereby an Administrator can define Local Attestation Keys (LAKs) if desired.</t>
			</section> <!--end RIV Keying -->
			<section title="RIV Information Flow">
				<t>RIV workflow for networking equipment is organized around a simple use case, where a network operator wishes to verify the integrity of software installed in specific, fielded devices.  This use case implies several components:</t>
				<t><list style="numbers">
					<t>A Device (e.g. a router or other embedded device, also known as an Attester) somewhere and the network operator wants to examine its boot state.</t>
					<t>A Verifier (which might be a network management station) somewhere separate from the Device that will retrieve the information and analyze it to pass judgement on the security posture of the device.</t>
					<t>A Relying Party, which has access to the Verifier to request attestation and to act on results.</t>
					<t>This document assumes that signed Reference Integrity Measurements (RIMs) (aka "golden measurements") can either be created by the device manufacturer and shipped along with the device as part of its software image, or alternatively, could be obtained a number of other ways (direct to the verifier from the manufacturer, from a third party, from the owner's observation of what's thought to be a "known good system", etc.).  Retrieving RIMs from the device itself allows attestation to be done in systems which may not have access to the public internet, or by other devices that are not management stations per-se (e.g., a peer device).  If reference measurements are obtained from multiple sources, the Verifier may need to evaluate the relative level of trust to be placed in each source in case of a discrepancy.</t>
				</list></t>
			<t>These components are illustrated in Figure 2.</t>
			<t>A more-detailed taxonomy of terms is given in [I-D.birkholz-rats-architecture]</t>
			
<figure align="center" title="RIV Reference Configuration for Network Equipment" anchor="RIV-Reference-Configuration">
<artwork align="left"><![CDATA[
+---------------+        +-------------+        +---------+--------+
|               |        | Attester    | Step 1 | Verifier|        |
| Asserter      |        | (Device     |<-------| (Network| Relying|
| (Device       |        | under       |------->| Mngmt   | Party  |
| Manufacturer  |        | attestation)| Step 2 | Station)|        |
| or other      |        |             |        |         |        |
| authority)    |        |             |        |         |        |
+---------------+        +-------------+        +---------+--------+
       |                                             /\
       |                  Step 0                      |
       -----------------------------------------------

]]></artwork>
<postamble>In Step 0, The Asserter (the device manufacturer) provides a Software Image accompanied by Reference Integrity Measurements (RIMs) to the Attester (the device under attestation) signed by the asserter. In Step 1, the Verifier (Network Management Station), on behalf of a Relying Party, requests Identity, Measurement Values (and possibly RIMs) from the Attester. In Step 2, the Attester responds to the request by providing a DevID, Quotes (measured values), and optionally RIMs, signed by the Attester.</postamble>
</figure> <!-- end Figure 2 -->

			<t>See Section 3.1.1 for more narrowly defined terms related to Attestation</t>
			</section> <!-- end RIV Information Flow -->
			<section title="RIV Simplifying Assumptions">
				<t>This document makes the following simplifying assumptions to reduce complexity:</t>
				<t><list style="symbols">
					<t>The product to be attested is shipped with an IEEE 802.1AR DevID and an Initial Attestation Key (IAK) with certificate.  The IAK cert contains the same identity information as the DevID (specifically, the same Subject Name and Subject Alt Name, signed by the manufacturer), but it's a type of key that can be used to sign a TPM Quote.  This convention is described in TCG Guidance for Securing Network Equipment <xref target="NetEq"/>. For network equipment, which is generally non-privacy-sensitive, shipping a device with both an IDevID and an IAK already provisioned substantially simplifies initial startup. Privacy-sensitive applications may use the TCG Platform Certificate and additional procedures to install identity credentials on the platform after manufacture.  (See Section 2.3.1 below for the Platform Certificate alternative)</t>
					<t>The product is equipped with a Root of Trust for Measurement, Root of Trust for Storage and Root of Trust for Reporting  that is capable of conforming to the TCG Trusted Attestation Protocol (TAP) Information Model <xref target="TAP"/>.</t>
					<t>The vendor will ship Reference Integrity Measurements (i.e., known-good measurements) in the form of signed CoSWID tags <xref target="I-D.ietf-sacm-coswid"/>, <xref target="SWID"/>, as described in TCG Reference Integrity Measurement Manifest <xref target="RIM"/>.</t>
					</list></t>
					<section title="DevID Alternatives">
						<t>Some situations may have privacy-sensitive requirements that preclude shipping every device with an Initial Device ID installed.  In these cases, the IDevID can be installed remotely using the TCG Platform Certificate <xref target="Platform-Certificates"/>.</t>  
						<t>Some security-sensitive administrators may want to install their own identity credentials to certify platform identity and attestation results.  IEEE 802.1AR <xref target="IEEE-802-1AR"/> allows for both Initial Device Identity credentials, installed by the manufacturer, or Local Device Identity credentials installed by the administrator of the platform.  TCG TPM 2.0 Keys documents <xref target="Platform-DevID-TPM-2.0"/> and <xref target="PC-Client-BIOS-TPM-2.0"/> specifies analogous Initial and Local Attestation Keys (IAK and LAK), and contains figures showing the relationship between IDevID, LDevID, IAK and LAK keys.</t>
						<t>Platform administrators are free to use any number of criteria to judge authenticity of a platform before installing local identity keys, as part of an on-boarding process.  The TCG TPM 2.0 Keys document <xref target="Platform-DevID-TPM-2.0"/> also outlines procedures for creating Local Attestation Keys and Local Device IDs (LDevIDs) rooted in the manufacturer's IDevID as a check to reduce the chances that counterfeit devices are installed in the network.</t>
						<t>Note that many networking devices are expected to self-configure (aka Zero Touch Provisioning).  Current standardized zero-touch mechanisms such as <xref target="RFC8572"/> assume that identity keys are already in place before network on-boarding can start.</t>
					</section> <!-- end DevID Alternatives -->
					
					<section title="Additional Attestation of Platform Characteristics">
						<t>The Platform Attribute Credential <xref target="Platform-Certificates"/> can also be used to convey additional information about a platform from the manufacturer or other entities in the supply chain.  While outside the scope of RIV, the Platform Attribute Credential can deliver information such as lists of serial numbers for components embedded in a device or security assertions related to the platform, signed by the manufacturer, system integrator or value-added-reseller.</t>  
						
					</section> <!-- end Additional Attestation of Platform Characteristics -->
					
					<section title="Root of Trust for Measurement">
						<t>The measurements needed for attestation require that the device being attested is equipped with a Root of Trust for Measurement, i.e., some trustworthy mechanism that can compute the first measurement in the chain of trust required to attest that each stage of system startup is verified, and a Root of Trust for Reporting to report the results <xref target="Roots-of-Trust"/>.</t>
						<t>While there are many complex aspects of a Root of Trust, two aspects that are important in the case of attestation are:</t>
						<t><list style="symbols">
							<t>The first measurement computed by the Root of Trust for Measurement, and stored in the TPM's Root of Trust for Storage, is presumed to be correct.</t>
							<t>There must not be a way to reset the RTS without re-entering the RTM code.</t>
						</list>
						The first measurement must be computed by code that must be implicitly trusted (it's the first, after all); if that first measurement can be subverted, none of the remaining measurements can be trusted. (See <xref target="NIST-SP-800-155"/></t>
					</section> <!--end Trusted Execution Environment -->
					
					<section title="Reference Integrity Measurements (RIMs)">
						<t>Much of attestation focuses on collecting and transmitting 'evidence' in the form of PCR measurements and attestation logs.  But the critical part of the process is enabling the verifier to decide whether the measured hashes are "the right ones" or not.</t>
						<t>While it must be up to network administrators to decide what they want on their networks, the software supplier should supply the Reference Integrity Measurements, (aka Golden Measurements or "known good" hash digests) that may be used by a verifier to determine if evidence shows known good, known bad or unknown software configurations.</t>
						<t>In general, there are two kinds of reference measurements:</t>
						<t><list style="numbers">
							<t>Measurements of early system startup (e.g., BIOS, boot loader, OS kernel) are essentially single threaded, and executed exactly once, in a known sequence, before any results could be reported.  In this case, while the method for computing the hash and extending relevant PCRs may be complicated, the net result is that the software (more likely, firmware) vendor will have one known good PCR value that "should" be present in the PCR after the box has booted.  In this case, the signed reference measurement simply lists the expected hash for the given version.</t>
							<t>Measurements taken later in operation of the system, once an OS has started (for example, Linux IMA[16.]), may be more complex, with unpredictable "final" PCR values.  In this case, the Verifier must have enough information to reconstruct the expected PCR values from logs and signed reference measurements from a trusted authority.</t>
						</list></t>
						<t>In both cases, the expected values can be expressed as signed CoSWID tags, but the SWID structure in the second case is somewhat more complex. An example of how CoSWIDs could be incorporated into a reference manifest can be found in the IETF Internet-Draft "A SUIT Manifest Extension for Concise Software Identifiers" <xref target="I-D.birkholz-suit-coswid-manifest"/>.</t>
						<t>The TCG has done exploratory work in defining formats for reference integrity manifests under the working title TCG Reference Integrity Manifest <xref target="RIM"/>.</t>
					</section> <!-- end Reference Integrity Measurements (RIMs) -->
					
					<section title="Attestation Logs">
						<t>Quotes from a TPM can provide evidence of the state of a device up to the time the evidence was recorded, but to make sense of the quote in most cases an event log of what software modules contributed which values to the quote during startup must also be provided.  The log must contain enough information to demonstrate its integrity by allowing exact reconstruction of the digest conveyed in the signed quote (e.g., PCR values). </t>
						<t>TCG has defined several event log formats:</t>
							<t><list style="symbols">
							<t>Legacy BIOS event log (TCG PC Client Specific Implementation Specification for Conventional BIOS, Section 11.3<xref target="PC-Client-BIOS-TPM-1.2"/>)</t>
							<t>UEFI BIOS event log (TCG EFI Platform Specification for TPM Family 1.1 or 1.2, Section 7 <xref target="EFI"/>)</t>
							<t>Canonical Event Log <xref target="Canonical-Event-Log"/></t>
							</list></t>
							<t>It should be noted that a given device might use more than one event log format (e.g., a UEFI log during initial boot, switching to Canonical Log when the host OS launches).</t>
							<t>The TCG SNMP Attestation MIB <xref target="SNMP-Attestation-MIB"/> will support any record-oriented log format, including the three TCG-defined formats, but it currently leaves figuring out which log(s) are in what format up to the Verifier.</t>
					</section> <!-- end Attestation Logs -->
			
				</section> <!-- end RIV Simplifying Assumptions-->
			
		</section><!-- end Section 2-->
		
		<section title="Standards Components">
			<section  title="Reference Models">
				<section title="IETF Reference Model for Challenge-Response Remote Attestation">
					<t>Initial work at IETF defines remote attestation as follows:</t>
					<t><list style="symbols">
							<t>The Reference Interaction Model for Challenge-Response-based Remote Attestation is based on the standard roles defined in <xref target="I-D.birkholz-rats-architecture"/>:</t>
								<t><list style="symbols">
										<t>Attester: The role that designates the subject of the remote attestation. A system entity that is the provider of evidence takes on the role of an Attester.</t>
										<t>Verifier: The role that designates the system entity and that is the appraiser of evidence provided by the Attester. A system entity that is the consumer of evidence takes on the role of a Verifier.</t>
										</list></t>
					</list></t>
<t>The following diagram illustrates a common information flow between a Verifier and an Attester, specified in    <xref target="I-D.birkholz-rats-reference-interaction-model"/>:</t>
<figure align="center" title="IETF Attestation Information Flow" anchor="IETF-Attestation-Information-Flow">
<artwork align="left"><![CDATA[
Attester                                                     Verifier
   |                                                               |
   | <------- requestAttestation(nonce, authSecID, claimSelection) |
   |                                                               |
collectAssertions(assertionsSelection)                             |
   | => assertions                                                 |
   |                                                               |
signAttestationEvidence(authSecID, assertions, nonce)              |
   | => signedAttestationEvidence                                  |
   |                                                               |
   | signedAttestationEvidence ----------------------------------> |
   |                                                               |
   | verifyAttestationEvidence(signedAttestationEvidence, refassertions)
   |                                          attestationResult <= |
   |                                                               |
]]></artwork>

</figure> <!-- end Figure 3 -->
					<t>The RIV approach outlined in this document aligns with the RATS reference model.</t>
				</section> <!-- end IETF Reference Model for Challenge-Response Remote Attestation-->
				
			</section> <!-- end Reference Models -->
			
			<section title="RIV Workflow">
				<t>The overall flow for an attestation session is shown in Figure 4.  In this diagram:</t>
				<t><list style="symbols">
					<t>Step 0, positioning of the signed reference measurements, may happen in two ways:</t>
					<t>Step 0A below shows a verifier obtaining reference measurements directly from a software configuration authority, whether it's the vendor or another authority chosen by the system administrator.  The reference measurements are signed by the Asserter (i.e., the software configuration authority).</t>
					<t> - Or - Step 0B, the reference measurements, signed by the Asserter, may be distributed as part of software installation, long before the attestation session begins.  Software installation is usually vendor-dependent, so there are no standards involved in this step.  However, the verifier can use the same protocol to obtain the reference measurements from the device as it would have used with an external reference authority</t>
					<t>In Step 1, the Verifier initiates an attestation session by opening a TLS session, validated using the DevID to prove that the connection is attesting the right box.</t>
					<t>In Step 2, measured values are retrieved from the Attester's TPM using a YANG or SNMP interface that implements the TCG TAP model (e.g. YANG Module for Basic Challenge-Response-based Remote Attestation Procedures <xref target="I-D.birkholz-yang-basic-remote-attestation"/>).</t>
					<t>In Step 3, the Attester also delivers a copy of the signed reference measurements, using Software Inventory YANG module based on Software Identifiers <xref target="I-D.birkholz-yang-swid"/>.</t>
				</list></t>
				

<figure align="center" title="RIV Protocol and Encoding Summary" anchor="RIV-Protocol-and-Encoding-Summary">
<artwork align="left"><![CDATA[
+---------------+        +-------------+        +---------+
|               |        |             | Step 1 |         |
|               |        | Attester    |<------>| Verifier|
| Asserter      |        | (Device     |<------>| (Network|
|(Configuration |------->| under       | Step 2 | Mngmt   |
| Authority)    | Step 0A| attestation)|        | Station)|
|               |        |             |------->|         |
+---------------+        +-------------+ Step 3 +---------+
        |                                           /|\
        |                                            |
        ----------------------------------------------
                        Step 0B

]]></artwork>
<postamble>Either CoSWID-encoded reference measurements are signed by a trusted authority and retrieved directly prior to attestation (as shown in Step 0A), or CoSWID-encoded reference measurements are signed by the device manufacturer, installed on the device by a proprietary installer, and delivered during attestation (as shown in Step 0B). In Step 1, the Verifier initiates a connection for attestation.  The Attester's identity is validated using DevID with TLS. In Step 2, a nonce, quotes (measured values) and measurement log are conveyed via TAP with a protocol-specific binding (e.g. SNMP). Logs are sent in the Canonical Log Format In Step 3, CoSWID-encoded reference measurements are retrieved from the Attester using the YANG (<xref target="I-D.birkholz-yang-swid"/>.
.</postamble>
				
			</figure> <!-- end Figure 4 -->
				
				<t>The following components are used:</t>
				<t><list style="numbers">
					<t>TPM Keys are configured according to <xref target="Platform-DevID-TPM-2.0"/>, <xref target="PC-Client-BIOS-TPM-1.2"/>, or <xref target="Platform-ID-TPM-1.2"/></t>
					<t>Measurements of bootable modules are taken according to TCG PC Client <xref target="PC-Client-BIOS-TPM-2.0"/> and Linux IMA <xref target="IMA"/></t>
					<t>Device Identity is managed by IEEE 802.1AR certificates <xref target="IEEE-802-1AR"/>, with keys protected by TPMs.</t>
					<t>Quotes are retrieved according to TCG TAP Information Model <xref target="TAP"/></t>
					<t>Reference Integrity Measurements are encoded as CoSWID tags, as defined in the TCG RIM document <xref target="RIM"/>, compatible with NIST IR 8060 <xref target="NIST-IR-8060"/> and the IETF CoSWID draft <xref target="I-D.ietf-sacm-coswid"/>.  Reference measurements are signed by the device manufacturer.</t>
				</list></t>
			</section> <!-- end RIV Workflow-->
			
			<section title="Layering Model for Network Equipment Attester and Verifier">
				<t>Retrieval of identity and attestation state uses one protocol stack, while retrieval of Reference Measurements uses a different set of protocols.  Figure 5 shows the components involved.</t>
				
				<!-- Placeholder for Figure 5 -->
				
<figure align="center" title="RIV Protocol Stacks" anchor="RIV-Protocol-Stacks">
<artwork align="left"><![CDATA[
+-----------------------+              +-------------------------+
|                       |              |                         |
|       Attester        |<-------------|        Verifier         |
|       (Device)        |------------->|   (Management Station)  |
|                       |      |       |                         |
+-----------------------+      |       +-------------------------+  
                               |
           -------------------- --------------------
           |                                        |
---------------------------------- ---------------------------------
|Reference Integrity Measurements| |         Attestation           |
---------------------------------- ---------------------------------

********************************************************************
*         IETF Attestation Reference Interaction Diagram           *
********************************************************************

    .......................         ....................... 
    . Reference Integrity .         . TAP  (PTS2.0) Info  .
    .     Measurement     .         . Model and Canonical .
    .      Manifest       .         .     Log Format      .     
    .......................         ....................... 

    *************************  .............. **********************
    * YANG SWID Module      *  . TCG        . * YANG Attestation   *
    * I-D.birkholz-yang-swid*  . Attestation. * Module             *
    *                       *  . MIB        . * I-D.birkholz-yang- *
    *                       *  .            . * basic-remote-      *
    *                       *  .            . * attestation        *
    *************************  .............. **********************

    *************************  ************ ************************
    * XML, JSON, CBOR (etc) *  *    UDP   * * XML, JSON, CBOR (etc)*
    *************************  ************ ************************
 
    *************************               ************************
    *   RESTCONF/NETCONF    *               *   RESTCONF/NETCONF   *
    ************************               *************************

    *************************               ************************
    *       TLS, SSH        *               *       TLS, SSH       *
    *************************               ************************

]]></artwork>
<postamble>IETF documents are captured in boxes surrounded by asterisks. TCG documents are shown in boxes surrounded by dots. The IETF Attestation Reference Interaction Diagram, Reference Integrity Measurement Manifest, TAP Information Model and Canonical Log Format, and both YANG modules are works in progress. Information Model layers describe abstract data objects that can be requested, and the corresponding response SNMP is still widely used, but the industry is transitioning to YANG, so in some cases, both will be required. TLS Authentication with TPM has been shown to work; SSH authentication using TPM-protected keys is not as easily done [as of 2019]</postamble>

</figure> <!-- end Figure 5 -->
				
			</section> <!-- end Layering Model for Attester and Verifier -->
			
			<!-- Guy, I (Jess) am leaving this blank for now. IETF has a very strict Reference strucutre, so the whole section will likely be deleted and reformated into Informative and Normative References. I'm inclinded to keep them all Informative, but we can talk about that. 
			<section title="Summary of Related Standards, by Organization">
			</section>  -->
			
		</section> <!-- end Section 3 -->
		
		<section title="Conclusion">
		<t>TCG technologies can play an important part in the implementation of Remote Integrity Verification.  Standards for many of the components needed for implementation of RIV already exist:</t>
		<t><list style="symbols">
			<t>Platform identity can be based on IEEE 802.1AR Device identity, coupled with careful supply-chain management by the manufacturer.</t>
			<t>Complex supply chains can be certified using TCG Platform Certificates <xref target="Platform-Certificates"/></t>
			<t>The TCG TAP mechanism can be used to retrieve attestation evidence.  Work is needed on a YANG model for this protocol.</t>
			<t>Reference Measurements must be conveyed from the software authority (e.g., the manufacturer) to the system in which verification will take place.  IETF CoSWID work forms the basis for this, but new work is needed to create an information model and YANG implementation.</t>
		</list></t>
		<t>Gaps still exist for implementation in Network Equipment (as of May 2019):</t>
		<t><list style="symbols">
			<t>Coordination of YANG model development with the IETF is still needed</t>
			<t>Specifications for management of signed Reference Integrity Measurements must still be completed</t>
		</list></t>
		
		</section> <!-- end Section 4 -->
		<section title="Appendix">
		<section title="Implementation Notes">
			<t>Table 1 summarizes many of the actions needed to complete an Attestation system, with links to relevant documents.  While documents are controlled by a number of standards organizations, the implied actions required for implementation are all the responsibility of the manufacturer of the device, unless otherwise noted.</t>
			<!-- Placeholder Table 1 -->
			
<figure align="center" title="Component Status" anchor="Component-Status">
<artwork align="left"><![CDATA[
+------------------------------------------------------------------+
|             Component                           |  Controlling   | 
|                                                 | Specification  |
--------------------------------------------------------------------
| Make a Secure execution environment             |   TCG RoT      |               
|   o Attestation depends on a secure root of     |   UEFI.org     |
|     of trust for measurement outside the TPM, as|                |
|     well as roots for storage and reporting     |                |
|     inside the TPM.                             |                |
|   o  Refer to TCG Root of Trust for Measurement.|                |
|   o  NIST SP 800-193 also provides guidelines   |                |
|      on Roots of Trust                          |                |
--------------------------------------------------------------------
| Get a TPM properly provisioned as described in  | TCG TPM DevID  |
|   TCG documents.                                | TCG Platform   |
|                                                 |   Certificate  |
--------------------------------------------------------------------
| Put a DevID or Platform Cert in the TPM         | TCG TPM DevID  |
|    o Install an Initial Attestation Key at the  | TCG Platform   |
|      same time so that Attestation can work out |   Certificate  |
|      of the box                                 |-----------------
|    o Equipment suppliers and owners may want to | IEEE 802.1AR   |
|      implement Local Device ID as well as       |                |
|      Initial Device ID                          |                |
--------------------------------------------------------------------
| Connect the TPM to the TLS stack                | Vendor TLS     |
|    o  Use the DevID in the TPM to authenticate  | stack (This    |
|       TAP connections, identifying the device   | action is      |
|                                                 | simply         |
|                                                 | configuring TLS|
|                                                 | to use the     |
|                                                 | DevID as its   |
|                                                 | trust anchor.) |
--------------------------------------------------------------------
| Make CoSWID tags for BIOS/LoaderLKernel objects | IETF CoSWID    |
|    o  Add reference measurements into SWID tags | ISO/IEC 19770-2|
|    o  Manufacturer should sign the SWID tags    | NIST IR 8060   |
|    o  This should be covered in a new TCG       | TagVault SWID  |
|       Reference Integrity Manifest document     |   Tag Signing  |
|       -  IWG should define the literal SWID     |   Guidance     |
|          format                                 |-----------------
|       -  IWG should evaluate whether IETF SUIT  | TCG RIM        |
|          is a suitable manifest when multiple   |                |
|          SWID tags are involved                 |                |
|       -  There could be a proof-of-concept      |                |
|          project to actually make sample SWID   |                |
|          tags (a gap might appear in the        |                |
|          process)                               |                |
--------------------------------------------------------------------
|  Package the SWID tags with a vendor software   | There is no    |
|  release                                        | need to specify|
|    o  A tag-generator plugin could help         | where the tags |
|      (i.e., a plugin for common development     | are stored in a|
|      environments.  NIST has something that     | vendor OS, as  |
|      plugs into Maven Build Environment)        | long as there  |
|                                                 | is a standards-|
|                                                 | based mechanism|
|                                                 | to retrieve    |
|                                                 | them.          |
|                                                 |-----------------
|                                                 | TCG RIM        |
--------------------------------------------------------------------
|  BIOS SWIDs might be hard to manage on an OS    |                |
|  disk-- maybe keep them in the BIOS flash?      | TCG RIM        |
|  o  Maybe a UEFI Var?  Would its name have to be|                |
|     specified by UEFI.org?                      |                |
|  o  How big is a BIOS SWID tag?  Do we need to  |                |
|     use a tag ID instead of an actual tag?      |                |
|  o  Note that the presence of Option ROMs turns |                |
|     the BIOS reference measurements into a      |                |
|     multi-vendor interoperability problem       |                |
--------------------------------------------------------------------
|  Use PC Client measurement definitions as a     | TCG PC Client  |
|  starting point to define the use of PCRs       | BIOS           |
|  (although Windows  OS is rare on Networking    |-----------------
|  Equipment)                                     | There have been|
|                                                 | proposals for  |
|                                                 | non-PC-Client  |
|                                                 | allocation of  |
|                                                 | PCRs, although |
|                                                 | no specific    |
|                                                 | document exists|
|                                                 | yet.           |
--------------------------------------------------------------------
|  Use TAP to retrieve measurements               |                |
|    o  Map TAP to SNMP                           | TCG SNMP MIB   |
|    o  Map to YANG                               | YANG Module for|
|    o  Complete Canonical Log Format             |   Basic        |
|                                                 |   Attestation  |
|                                                 | TCG Canonical  |
|                                                 |   Log Format   |
--------------------------------------------------------------------
| Posture Collection Server (as described in IETF |                |
|  SACMs ECP) would have to request the           |                |
|  attestation and analyze the result             |                |
| The Management application might be broken down |                |
|  to several more components:                    |                |
|    o  A Posture Manager Server                  |                |
|       which collects reports and stores them in |                |
|       a database                                |                |
|    o  One or more Analyzers that can look at the|                |
|       results and figure out what it means.     |                |
--------------------------------------------------------------------
]]></artwork>
				
			</figure> <!-- end Table 1 -->
		</section><!-- end Implementation Notes -->
		
		
		<section title="Comparison with TCG PTS / IETF NEA">
			<t>Some components of an Attestation system have been implemented for end-user machines such as PCs and laptops. Figure 7 shows the corresponding protocol stacks.</t>
			
			<!--Placeholder for Figure 7 -->
			
<figure align="center" title="Attestation for End User Computers" anchor="Attestation-for-End-User-Computers">
<artwork align="left"><![CDATA[
+-----------------------+              +-------------------------+
|                       |              |                         |
|       Attester        |<-------------|        Verifier         |
|       (Device)        |------------->|   (Management Station)  |
|                       |      |       |                         |
+-----------------------+      |       +-------------------------+  
                               |
           -------------------- --------------------
           |                                        |
---------------------------------- ---------------------------------
|Reference Integrity Measurements| |         Attestation           |
---------------------------------- ---------------------------------

--------------------------------------------------------------------
|         IETF Attestation Reference Interaction Diagram           |
-------------------------------------------------------------------

    .......................         --------------------------------
    . No Existing         .         |  TAP  (PTS2.0) Info Model and|
    . Reference Integrity .         |  Canonical Log Format        |
    . Measurement Manifest.         |                              |    
    . Protocols Exist     .         --------------------------------
    .                     .
    .                     .        ---------------------- ----------
    .                     .        | YANG Attestation   | |IETF NEA|
    .                     .        | Module             | | Msg and|
    .                     .        | I-D.birkholz-yang- | | Attrib.|
    .                     .        | basic-remote-      | | for PA-|
    .                     .        | attestation        | | TNC    |
    .                     .        ---------------------- ----------
    .                     .        ---------------------- ----------
    .                     .        | XML, JSON, CBOR    | | PT-TLS |
    .                     .        ---------------------- | (for   |
    .                     .        ---------------------- |endpoint|
    .                     .        | NETCONF, RESTCONF, | |mcahines|
    .                     .        | COAP               | |        |
    .......................        ---------------------- ----------
    ----------------------------------------------------------------
    |                       TLS, SSH                               |
    ----------------------------------------------------------------   
]]></artwork>
				
			</figure> <!-- end Figure 7 -->
		</section> <!-- end Comparison with PTS -->
		</section> <!-- end Section 5 -->

		<section anchor="IANA" title="IANA Considerations">
			<t>This memo includes no request to IANA.</t>
		</section> <!-- end IANA Considerations -->
		
		<section anchor="Security" title="Security Considerations">
			<t>Attestation results from the RIV procedure are subject to a number of attacks:</t>
	<t><list style="symbols">
<t>Keys may be compromised</t>
<t>A counterfeit device may attempt to impersonate (spoof) a known authentic device </t>
<t>Man-in-the-middle attacks may be used by a counterfeit device to attempt to deliver responses that originate in an actual authentic device</t>
<t>Replay attacks may be attempted by a compromised device </t>
		</list></t>

<t>Trustworthiness of RIV attestation depends strongly on the validity of keys used for identity and attestation reports.  RIV takes full advantage of TPM capabilities to ensure that results can be trusted.</t>

<t>Two sets of keys are relevant to RIV attestation</t>
	<t><list style="symbols">
<t>A DevID key is used to certify the identity of the device in which the TPM is installed.</t>
<t>An Attestation Key (AK) key signs attestation reports, (called 'quotes' in TCG documents), used to provide evidence for integrity of the software on the device.</t>
		</list></t>
<t>TPM practices require that these keys be different, as a way of ensuring that a general-purpose signing key cannot be used to spoof an attestation quote.</t>

<t>In each case, the private half of the key is known only to the TPM, and cannot be retrieved externally, even by a trusted party.  To ensure that's the case, private/public key-pairs are usually generated inside the TPM, where they're never exposed, and cannot be extracted.  Although TPM 2.0 has mechanisms to "inject" externally-generated keys, those keys are marked as such, so the device owner can exercise judgement in deciding if they're trustworthy.</t>

<t>Keeping keys safe is just part attestation security; knowing which keys are bound to the device in question is just as important.</t>
<t>While there are many ways to manage keys in a TPM (See TPM2Keys doc), RIV includes support for "zero touch" provisioning (also known as zero-touch onboarding) of fielded devices [e.g. KentW's sZTP], where keys which have predictable trust properties are provisioned by the device vendor.</t>

<t>Device identity in RIV is based on IEEE 802.1AR DevID. This specification provides several elements</t>
	<t><list style="symbols">
<t>A DevID requires a unique key pair for each device, accompanied by an x.509 certificate</t>
<t>The private portion of the DevID key is to be stored in the device, in a manner that provides confidentiality (Section 6.2.5 [IEEE802.1AR])</t>
		</list></t>
<t>The x.509 certificate contains several components</t>
	<t><list style="symbols">
<t>The public part of the unique DevID key assigned to that device </t>
<t>An identifying string that's unique to the manufacturer of the device.  This is normally the serial number of the unit, which might also be printed on label on the device.</t>
<t>The certificate must be signed by a key traceable to the manufacturer's root key.</t>
		</list></t>

<t>With these elements, the device's manufacturer and serial number can be identified by analyzing the DevID certificate, and the device can prove it's the legitimate holder of the cert by signing a nonce with its private key.</t>

<t>RIV uses the DevID to validate a TLS connection to the device as the attestation session begins.  Security of this process derives from TLS security, with the DevID providing proof that the TLS session terminates on the intended device. [xref].</t>

<t>Evidence of software integrity is delivered in the form of a quote signed by the TPM itself.  To prevent spoofing, the quote generated inside the TPM must by signed by a key that's different from the DevID, called an Attestation Key (AK).  But the binding between the AK and the same device must also be proven to prevent a man-in-the-middle attack (e.g. [Asokan]).</t>
<t>This is accomplished in RIV through use of an AK certificate with the same elements as the DevID (i.e., same manufacturer's serial number, signed by the same manufacturer's key), but containing the device's unique AK public key instead of the DevID public key.</t>
<t>[guy] go look at how 802.1AR says about "serial number"</t>
<t>These two keys and certificates are used together:</t>
	<t><list style="symbols">
<t>The DevID is used to validate a TLS connection terminating on the device with a known serial number.</t>
<t>The AK is used to sign attestation quotes, providing proof that the attestation evidence comes from the same device.</t>
		</list></t>

<t>Replay attacks of attestation results are usually ensured by inclusion of a nonce in the request to the TPM for a quote.  The resulting quote signed by the TPM contains the nonce, allowing the verifier to determine freshness.  [TUDA] provides an alternate time-based mechanism to verify freshness.</t>
<t>[guy] Ned asked to add a sentence or two on use of the nonce</t>

<t>Requiring results of attestation of the operating software to be signed by a key known only to the TPM also removes the need to trust the device's operating software (beyond the first measurement; see below); any changes to the quote made by malicious device software, or in the path back to the verifier, will invalidate the signature on the quote.</t>

<t>Although RIV recommends that device manufacturers pre-provision devices with easily-verified DevID and AK certs, use of those credentials is not mandatory.  IEEE 802.1AR incorporates the idea of an Initial Device ID (IDevID), provisioned by the manufacturer, and a Local Device ID (LDevID) provisioned by the owner of the device.  RIV extends that concept by defining an Initial Attestation Key (IAK) and Local Attestation Key (LAK) with the same properties.</t>

<t>Device owners can use any method to provision the Local credentials.</t>
	<t><list style="symbols">
<t>TCG doc [Tom's DevID; also Stan's Provisioning Doc] shows how the initial Attestation keys can be used to certify LDevID and LAK keys.  Use of the LDevID and LAK allows the device owner to use a uniform identity structure across device types from multiple manufacturers (in the same way that an "Asset Tag" is used by many enterprises use to identify devices they own).</t>
<t>But device owners can use any other mechanism they want to assure themselves that Local identity certificates are inserted into the intended device, including physical inspection and programming in a secure location, if they prefer to avoid placing trust in the manufacturer-provided keys.</t>
		</list></t>

<t>Clearly, Local keys can't be used for secure Zero Touch provisioning; installation of the Local keys can only be done by some process that runs before the device is configured for network operation.</t>

<t>On the other end of the device life cycle, provision should be made to wipe Local keys when a device is decommissioned, to indicate that the device is no longer owned by the enterprise.  The manufacturer's Initial identity keys must be preserved, as they contain no information that's not already printed on the device's serial number plate.</t>

<t>In addition to trustworthy provisioning of keys, RIV depends on other trust anchors</t>
	<t><list style="symbols">
<t>Secure identity depends on mechanisms to prevent per-device secret keys from being compromised.  The TPM provides this capability as a Root of Trust for Storage</t>
<t>Attestation depends on an unbroken chain of measurements, starting from the very first measurement.  That first measurement is made by code called the Root of Trust for Measurement, typically done by trusted firmware stored in boot flash.  Mechanisms for maintaining the trustworthiness of the RTM are out of scope for RIV, but could include immutable firmware, signed updates, or a vendor-specific hardware verification technique.</t>
<t>RIV assumes some level of physical defense for the device.  If a TPM that has already been programmed with an authentic DevID is stolen and inserted into a counterfeit device, attestation of that counterfeit device may become indistinguishable from an authentic device.</t>
		</list></t>

<t>RIV also depends on reliable reference measurements, as expressed by the RIM [xref].  The definition of trust procedures for RIMs is out of scope for RIV, and the device owner is free to use any policy to validate a set of reference measurements.  RIMs may be conveyed out-of-band or in-band, as part of the attestation process (see Section XX).  But for embedded devices, where software is usually shipped as a self-contained package, RIMs signed by the manufacturer and delivered in-band may be more convenient for the device owner.</t>

		</section> <!-- end Security Considerations -->
		
	</middle>

	<back>
		<references title="Informative References">
			&RFC8348;
			&RFC7049;
			&RFC2119;		
			&RFC8174;
            &RFC8572;			
			&I-D.birkholz-yang-basic-remote-attestation;
			&I-D.birkholz-rats-architecture;
			&I-D.birkholz-rats-reference-interaction-model;
			&I-D.birkholz-suit-coswid-manifest;
			&I-D.birkholz-yang-swid;
			&I-D.ietf-sacm-coswid;
			<reference anchor="TAP">
				<front>
					<title>DRAFT: TCG Trusted Attestation Protocol (TAP) Information Model for TPM Families 1.2 and 2.0 and DICE Family 1.0, Version 1.0, Revision 0.29</title>
					<author>
						<organization>Trusted Computing Group</organization>
					</author>
					<date month="October" year="2018" />
				</front>
			</reference> <!--end TAP reference -->
				
			<reference anchor="NIST-SP-800-155" target="https://csrc.nist.gov/csrc/media/publications/sp/800-155/draft/documents/draft-sp800-155_dec2011.pdf">
				<front>
					<title>BIOS Integrity Measurement Guidelines (Draft)</title>
					<author>
						<organization>National Institute for Standards and Technology</organization>
					</author>
					<date month="December" year="2011" />
				</front>
			</reference> <!--end NIST-SP-800-155 reference -->
			
			<reference anchor="SNMP-Attestation-MIB">
				<front>
					<title>DRAFT: SNMP MIB for TPM-Based Attestation, Specification Version 0.8, Revision 0.02</title>
					<author>
						<organization>Trusted Computing Group</organization>
					</author>
					<date month="May" year="2018" />
				</front>
			</reference> <!--end SNMP Attestation MIB reference -->
			
			<reference anchor="Canonical-Event-Log">
				<front>
					<title>DRAFT Canonical Event Log Format Version: 1.0, Revision: .12</title>
					<author>
						<organization>Trusted Computing Group</organization>
					</author>
					<date month="October" year="2018" />
				</front>
			</reference> <!--end Cononical Event Log reference -->
			
			<reference anchor="PC-Client-BIOS-TPM-1.2" target="https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementation_1-21_1_00.pdf">
				<front>
					<title>TCG PC Client Specific Implementation Specification for Conventional BIOS, Specification Version 1.21 Errata, Revision 1.00</title>
					<author>
						<organization>Trusted Computing Group</organization>
					</author>
					<date month="February" year="2012" />
				</front>
			</reference> <!--end PC Client BIOS reference -->
			
			<reference anchor="EFI" target="https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf">
				<front>
					<title>TCG EFI Platform Specification for TPM Family 1.1 or 1.2, Specification Version 1.22, Revision 15</title>
					<author>
						<organization>Trusted Computing Group</organization>
					</author>
					<date month="January" year="2014" />
				</front>
			</reference> <!--end EFI reference -->
			
			<reference anchor="RIM">
				<front>
					<title>DRAFT: TCG Reference Integrity Manifest </title>
					<author>
						<organization>Trusted Computing Group</organization>
					</author>
					<date month="June" year="2019" />
				</front>
			</reference> <!--end RIM reference -->
			
			<reference anchor="Platform-DevID-TPM-2.0">
				<front>
					<title>DRAFT: TPM Keys for Platform DevID for TPM2, Specification Version 0.7, Revision 0</title>
					<author>
						<organization>Trusted Computing Group</organization>
					</author>
					<date month="October" year="2018" />
				</front>
			</reference> <!--end Platform Dev ID reference -->
			
			<reference anchor="Platform-Certificates">
				<front>
					<title>DRAFT: TCG Platform Attribute Credential Profile, Specification Version 1.0, Revision 15, 07 December 2017</title>
					<author>
						<organization>Trusted Computing Group</organization>
					</author>
					<date month="December" year="2017" />
				</front>
			</reference> <!--end Platform Credentials reference -->
			
			<reference anchor="Platform-ID-TPM-1.2" target="https://trustedcomputinggroup.org/wp-content/uploads/TPM_Keys_for_Platform_Identity_v1_0_r3_Final.pdf">
				<front>
					<title>TPM Keys for Platform Identity for TPM 1.2, Specification Version 1.0, Revision 3</title>
					<author>
						<organization>Trusted Computing Group</organization>
					</author>
					<date month="August" year="2015" />
				</front>
			</reference> <!--end TPM Keys reference -->
			
			<reference anchor="Firmware-Profile" target="https://trustedcomputinggroup.org/pc-client-specific-platform-firmware-profile-specification/">
				<front>
					<title>Trusted Computing Group, PC Client Specific Platform Firmware Profile Specification Family "2.0", Level 00 Revision 1.03 Version 51</title>
					<author>
						<organization>Trusted Computing Group</organization>
					</author>
					<date month="June" year="2019" />
				</front>
			</reference> <!--end Firmware Profile reference -->
			
			<reference anchor="IEEE-802-1AR">
				<front>
					<title>802.1AR-2018 - IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity, IEEE Computer Society</title>
					<author initials="M" surname="Seaman">
						<organization>IEEE Computer Society</organization>
					</author>
					<date month="August" year="2018" />
				</front>
			</reference> <!--end 802.1AR reference -->
			
			<reference anchor="IMA" target="https://sourceforge.net/p/linux-ima/wiki/Home/">
				<front>
					<title>Integrity Measurement Architecture</title>
					<author surname="dsafford"/>
					<author surname="kds_etu"/>
					<author surname="mzohar"/>
					<author surname="reinersailer"/>
					<author surname="serge_hallyn"/>      
					<date month="June" year="2019" />
				</front>
			</reference> <!--end IMA reference -->
			
			<reference anchor="Roots-of-Trust" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf">
				<front>
					<title>TCG Roots of Trust Specification</title>
					<author>
						<organization>Trusted Computing Group</organization>
					</author>
					<date month="October" year="2018" />
				</front>
			</reference> <!--end Roots of Trust reference -->
			
			<reference anchor="NetEq" target="https://trustedcomputinggroup.org/wp-content/uploads/TCG_Guidance_for_Securing_NetEq_1_0r29.pdf">
				<front>
					<title>TCG Guidance for Securing Network Equipment</title>
					<author>
						<organization>Trusted Computing Group</organization>
					</author>
					<date month="January" year="2018" />
				</front>
			</reference> <!--end NetEq reference -->
		
			<reference anchor="NIST-IR-8060" target="https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf">
				<front>
					<title>Guidelines for the Creation of Interoperable Software Identification (SWID) Tags</title>
					<author>
						<organization>National Institute for Standards and Technology</organization>
					</author>
					<date month="April" year="2016" />
				</front>
			</reference> <!--end NISTIR8060 reference -->
			
			<reference anchor="SWID" target="https://www.iso.org/standard/65666.html">
				<front>
					<title>Information Technology Software Asset Management Part 2: Software Identification Tag, ISO/IEC 19770-2</title>
					<author>
						<organization>The International Organization for Standardization/International Electrotechnical Commission</organization>
					</author>
					<date month="October" year="2015" />
				</front>
			</reference> <!--end SWID reference -->
			
			<reference anchor="PC-Client-BIOS-TPM-2.0" target= "https://trustedcomputinggroup.org/pc-client-specific-platform-firmware-profile-specification">
				<front>
					<title>PC Client Specific Platform Firmware Profile Specification Family "2.0", Level 00 Revision 1.04</title>
					<author>
						<organization>Trusted Computing Group</organization>
					</author>
					<date month="June" year="2019" />
				</front>
			</reference> <!--end NetEq reference -->	
		</references> <!-- end Informative References -->
	</back>

</rfc>