RATS Working Group G. Fedorkow, Ed. Internet-Draft Juniper Networks, Inc. Intended status: Informational E. Voit Expires:February 14,March 22, 2021 Cisco Systems, Inc. J. Fitzgerald-McKay National Security AgencyAugust 13,September 18, 2020 TPM-based Network Device Remote Integrity Verificationdraft-ietf-rats-tpm-based-network-device-attest-03draft-ietf-rats-tpm-based-network-device-attest-04 Abstract This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules[TPM].[TPM1.2], [TPM2.0]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onFebruary 14,March 22, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . .45 1.4. Description of Remote Integrity Verification (RIV) . . . 5 1.5. Solution Requirements . . . . . . . . . . . . . . . . . . 7 1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . .78 1.6.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . .89 2.1. RIV Software Configuration Attestation using TPM . . . .89 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 10 2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 12 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . .1213 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . .1314 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . .1516 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . .1617 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . .1718 3. Standards Components . . . . . . . . . . . . . . . . . . . .1719 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . .1819 3.1.1. Unique Device Identity . . . . . . . . . . . . . . .1819 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . .1819 3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . .1819 3.2. Reference Model for Challenge-Response . . . . . . . . .1920 3.2.1. Transport and Encoding . . . . . . . . . . . . . . .2122 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . .2123 4. Privacy Considerations . . . . . . . . . . . . . . . . . . .2324 5. Security Considerations . . . . . . . . . . . . . . . . . . .2325 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . .2425 5.2. Prevention of Spoofing and Man-in-the-Middle Attacks . .2627 5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . .2728 5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . .2728 5.5. Other Trust Anchors . . . . . . . . . . . . . . . . . . .2829 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . .2930 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .2930 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . .2930 8.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 30 8.2. Root of Trust for Measurement . . . . . . . . . . . . . . 32 8.3. Layering Model for Network Equipment Attester and Verifier . . . . . . . . . . . . . . . . . . . . . . . .29 8.1.1.32 8.3.1. Why is OS Attestation Different? . . . . . . . . . .31 8.2.34 8.4. Implementation Notes . . . . . . . . . . . . . . . . . .31 8.3. Root of Trust for Measurement34 9. References . . . . . . . . . . . . . .33 9. Informative. . . . . . . . . . . 36 9.1. Normative References . . . . . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . . . . .3338 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .3841 1. Introduction There are many aspects to consider in fielding a trusted computing device, from operating systems to applications. Mechanisms to prove that a device installed at a customer's site is authentic (i.e., not counterfeit) and has been configured with authorized software, all as part of a trusted supply chain, are just a few of the many aspects which need to be considered concurrently to have confidence that a device is truly trustworthy. A generic architecture for remote attestation has been defined in [I-D.ietf-rats-architecture]. Additionally, the usecasecases for remotely attesting networking devicesisare discussed within Section 6 of [I-D.richardson-rats-usecases]. However, these documents do not provide sufficient guidance for network equipment vendors andnetworkoperators to design, build, and deploy interoperableplatforms.devices. The intent of this document is to provide such guidance. It does this by outlining the Remote Integrity Verification (RIV) problem, and then identifies elements that are necessary to get the complete, scalable attestation procedure working with commercial networking products such as routers, switches and firewalls. An underlying assumption will be the availability within the device of a Trusted Platform Module[TPM][TPM1.2], [TPM2.0] compliant cryptoprocessor to enable theremotetrustworthy remote assessment of the device's software and hardware. 1.1. Terminology A number of terms are reused from [I-D.ietf-rats-architecture]. These include: Appraisal Policy for AttestationResult,Results, Attestation Result, Attester,Endorser,Evidence, Relying Party, Verifier, and Verifier Owner. Additionally, this document defines the following terms: Remote Attestation: the process of creating, conveying and appraisingassertionsclaims aboutPlatformdevice trustworthiness characteristics, including supply chain trust, identity,platformdevice provenance, software configuration, hardware configuration,platformdevice composition, compliance to test suites, functional and assurance evaluations, etc. This document uses the term Endorser to refer to the trusted authority for any signed object relating to the device, such as certificates or reference measurement. Typically, the manufacturer of an embedded device would be accepted as an Endorser. The goal of attestation is simply to assure an administrator that the software that was launched when the device was last started is an authentic anduntampereduntampered-with copy of the software that the device vendor shipped. 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, and 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, averifierVerifier 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 withuntamperedauthentic 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 otherplatformdevice characteristics that could be attested(e.g.(e.g., geographic location, connectivity; see [I-D.richardson-rats-usecases]), although it does provide evidence of a secure infrastructure to increase the level of trust in otherplatformdevice characteristics attested by other means (e.g., by Entity Attestation Tokens [I-D.ietf-rats-eat]). 1.2. Document Organization The remainder of this document is organized into several sections: o The remainder of this section covers goals and requirements, plus a top-level description ofRIVRIV. o The Solution Overview section outlines howRIV worksRemote Integrity Verification works. o The Standards Components section links components of RIV to normative standards. o Privacy and Security shows how specific features of RIV contribute to the trustworthiness of theattestation resultAttestation Result. o Supporting material is in an appendix at the end. 1.3. Goals Network operators 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. In line with the overall goal of assuring integrity, attestation can be usedforto assist in asset management, vulnerability and compliance assessment, plus configuration management.As a part of a trusted supply chain, theThe RIV attestation workflow outlined in this document is intended to meet the followinghigh- levelhigh-level goals: o Provable Device Identity - This specification requires that an attesting device includes a cryptographic identifier unique to each device. Effectively this means that the TPM must be so provisioned during the manufacturing cycle. o Software Inventory - A key goal is to identify the softwarereleaserelease(s) installed on the attesting device, and to provide evidence that the software stored within hasn't been altered without authorization. o Verifiability - Verification of software and configuration of the device shows that the software that was authorized for installation by the administrator has actually been launched. In addition, RIV is designed to operate either in a centralized environment, such as with a central authority that manages and configures a number of network devices, or 'peer-to-peer', where network devices independently verify one another to establish a trust relationship. (See Section 3.3 below, and also [I-D.voit-rats-trusted-path-routing]) 1.4. Description of Remote Integrity Verification (RIV) Attestation requires two interlocking services between the Attester network device and the Verifier: oPlatformDevice 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 forPlatformDevice Identity, cryptographic proof of the identity of the manufacturer is also provided. o Software Measurement is the mechanism that reports the state of mutable software components on the device, and can assure network managers that they have known,untamperedauthentic software configured to run in their network. Using these two interlocking services, RIVprovidesis aprocedurecomponent in a chain of procedures thatassurescan assure a network operator that the equipment in their network can be reliably identified, and thatuntamperedauthentic software of a known version is installed on eachendpoint.device. Equipment in the network includes devices that make up the network itself, such as routers, switches and firewalls. RIV includes several major processes: 1. Creation of Evidence is the process whereby an Attester generates cryptographic proof (Evidence) of claims aboutplatformdevice properties. In particular, theplatformdevice identity and its software configuration are both of criticalimportanceimportance. 2.PlatformDevice Identification refers to the mechanism assuring the Relying Party (ultimately, a network administrator) of the identity of devices that make up their network, and that their manufacturers are known. 3. Software used to boot aplatformdevice can be described as a chain of measurements,startedanchored at the start 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 an attesting device's TPM[TPM],[TPM1.2], [TPM2.0], so that the subsequent appraisal stage can determine if the software installed is authentic,up-to-date,up- to-date, and free of tampering. 4. Conveyance of Evidence reliably transports at least the minimum amount of Evidence from Attester to a Verifier to allow a management station to perform a meaningful appraisal in Step 5. 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. 5. Finally, Appraisal of Evidence occurs. As the Verifier and Relying Party roles are often combined within RIV, this is the process of verifying the Evidence received by a Verifier from the Attesting device, and using an Appraisal Policy to develop an Attestation Result, used to inform decision making. In practice, this means comparing the device measurements reported as Evidence with the Attester configuration expected by the Verifier. Subsequently the Appraisal Policy for Attestation Results might match what was found against Reference Integrity Measurements (aka Golden Measurements) which represent the intended configured state of the connected device. All implementations supporting this RIV specification require the support of the following three technologies: 1. Identity:PlatformDevice identitycanMUST be based on IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR], coupled with carefulsupply-chainsupply- chain management by the manufacturer. The DevID certificate contains a statement by the manufacturer that establishes the identity of the device as it left the factory. Some applications with a more-complex post-manufacture supply chain(e.g.(e.g., Value Added Resellers), or with different privacy concerns, may want to use alternative mechanisms for platform authentication (for example, TCG Platform Certificates [Platform-Certificates]).1.2. Platform Attestation provides evidence of configuration of software elements present in the device. This form of attestation can be implemented with TPM Platform Configuration Registers (PCRs), Quote and Log mechanisms, which provideancryptographically authenticatedmechanismevidence to report what software was started on the device through the boot cycle. Successful attestation requires an unbroken chain from a boot-time root of trust through all layers of software needed to bring the device to an operational state, in which each stage measures components of the next stage, updates the attestation log, and extends hashes into a PCR. The TPM can then report the hashes of all the measured hashes asasigned evidence called a Quote (see[TPM]Section 8.1 for an overview of TPM operation, or [TPM1.2] and [TPM2.0] for many more details).2.3. Reference Integrity Measurements must be conveyed from the Endorser (the entity accepted as the software authority, often the manufacturer for embedded systems) to the system in which verification will takeplaceplace. 1.5. Solution Requirements Remote Integrity Verification must address the "Lying Endpoint" problem, in which malicious software on an endpoint may subvert the intended function, and also prevent the endpoint from reporting its compromised status. (See Section 5 for further Security Considerations) RIV attestation is designed to be simple to deploy at scale. RIV should work "out of the box" as far as possible, that is, with the fewest possible provisioning steps or configuration databases needed at the end-user's site, as 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 [RFC8572] for an example of Secure Zero Touch Provisioning. 1.6. Scope Remote Attestation is a very general problem that could apply to most network-connected computing devices. However, this document includes several assumptions that limit the scope to Network Equipment(e.g.(e.g., routers, switches and firewalls): o 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 [AIK-Enrollment] or TCG Platform Certificates [Platform-Certificates] o This document assumes network protocols that are common in networking equipment such as YANG [RFC7950] and NETCONF [RFC6241], but not generally used in other applications. o The approach outlined in this document mandates the use of a compliant TPM[TPM]. Other roots of trust could be used with the same information flow, although they're out of scope for this document.[TPM1.2], [TPM2.0]. 1.6.1. Out of Scope o 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. o 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. o Processor Sleep Modes: Network equipment typically does not "sleep", so sleep and hibernate modes are not considered. Although out of scope for RIV, Trusted Computing Group specifications do encompass sleep and hibernate states. o Virtualization and Containerization: In a non-virtualized system, the host OS is responsible for measuring eachUserlandUser Space file or process, but that't the end of thechain of trust.boot process. For virtualized systems, the host OS must verify the hypervisor, which then manages its own chain of trust through the virtual machine. Virtualization and containerization technologies are increasingly used in Network equipment, but are not considered in this revision of the document. 2. Solution Overview 2.1. RIV Software Configuration Attestation using TPM RIV Attestation is a process which can be used to determine the identity of software running on a specifically-identified device. Remote Attestation is broken into two phases, shown in Figure 1: o During system startup, each distinct software object is "measured". Its identity, hash(i.e.(i.e., cryptographic digest) and version information are recorded in a log. Hashes are also extended, or cryptographically folded, into the TPM, in a way that can be used to validate the log entries. 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. o Once the device is running and has operational network connectivity, a separate, trusted Verifier will 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. The result is that the Verifier can verify the device's identity by checking the Subject Field and signature of certificate containing the TPM's attestation public key, and can validate the software that was launched bycomparing digests in the log with known-good values, andverifyingtheirthe correctness of the logs by comparing with the signed digests from theTPM.TPM, and comparing digests in the log with known-good values. 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 Attester producing the Evidence. +-------------------------------------------------------+ | +--------+ +--------+ +--------+ +---------+ | | | BIOS |--->| Loader |-->| Kernel |--->|Userland | | | +--------+ +--------+ +--------+ +---------+ | | | | | | | | | | | | +------------+-----------+-+ | | Step 1 | | | V | | +--------+ | | | TPM | | | +--------+ | | Router | | +--------------------------------|----------------------+ | | Step 2 | +-----------+ +--->| Verifier | +-----------+ Reset---------------flow-of-time-during-boot--...-------> Figure 1: RIV Attestation Model In Step 1, measurements are"extended""extended", or hashed, into the TPM as processesstart.start, with the result that the PCR ends up containing a hash of all the measured hashes. In Step 2, signed PCR digests are retrieved from the TPM for off-box analysis after the system is operational. 2.1.1. What Does RIV Attest? TPM attestation is strongly focused on Platform Configuration Registers (PCRs), but those registers are only vehicles for certifying accompanying Evidence, conveyed in log entries. It is the hashes in log entries that are extended into PCRs, where the finaldigestsPCR values can be retrieved in the form of aQuotestructured called a Quote, signed byaan Attestation key known only to the TPM. The use of multiple PCRs serves only to provide some independence between different classes of object, so that one class of objects can be updated without changing the extended hash for other classes. Although PCRs can be used for any purpose, this section outlines the objects within the scope of this document which may be extended into the TPM. In general, assignment of measurements to PCRsare organizedis a policy choice made by the device manufacturer, selected to independently attest three classes of object: o Code,i.e., instructions(i.e., instructions) to be executed by a CPU. o Configuration - Many devices offer numerous options controlled by non-volatile configuration variables which can impact the device's security posture. These settings may have vendor defaults, but often can be changed by administrators, who may want to verify via attestation that the settings they intend are still in place. o Credentials - Administrators may wish to verify via attestation that keys (and other credentials) outside the Root of Trust have not been subject to unauthorized tampering. (By definition, keys inside the root of trust can't be verifiedindependently)independently). The TCG PC Client Platform Firmware Profile Specification [PC-Client-BIOS-TPM-2.0] gives considerable detail on what is to be measured during the boot phase ofaplatformbootstartup using a UEFI BOIS (www.uefi.org), but the goal is simply to measure every bit of code executed in the process of starting the device, along with any configuration information related to security posture, leaving no gap for unmeasured code to remain undetected and subvert the chain. Forplatformsdevices using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] gives detailed normative requirements for PCR usage. But for other platform architectures, the table in Figure 2 gives guidance for PCR assignment that generalizes the specific details of [PC-Client-BIOS-TPM-2.0]. By convention, most PCRs areallocatedassigned in pairs, which the even- numbered PCR used to measure executable code, and the odd-numbered PCR used to measure whatever data and configuration are associated with that code. It is important to note that each PCR may contain results from dozens (or even thousands) of individual measurements. +------------------------------------------------------------------+ | |AllocatedAssigned PCR # | | Function | Code | Configuration| -------------------------------------------------------------------- | Firmware Static Root of Trust,i.e.,(i.e., | 0 | 1 | | initial boot firmware anddriversdrivers) | | | -------------------------------------------------------------------- | Drivers and initialization for optional | 2 | 3 | | or add-in devices | | | -------------------------------------------------------------------- | OS Loader code and configuration,i.e.,(i.e., | 4 | 5 | | the code launched byfirmwarefirmware) to load an | | | | operating system kernel. These PCRs record | | | | each boot attempt, and an identifier for | | | | where the loader was found | | | -------------------------------------------------------------------- | Vendor Specific Measurements during boot | 6 | 6 | -------------------------------------------------------------------- | Secure Boot Policy. This PCR records keys | | 7 | | and configuration used to validate the OS | | | | loader | | | -------------------------------------------------------------------- | Measurements made by the OS Loader | 8 | 9 | | (e.g GRUB2 for Linux) | | | -------------------------------------------------------------------- | Measurements made by OS(e.g.(e.g., Linux IMA) | 10 | 10 | +------------------------------------------------------------------+ Figure 2: Attested Objects 2.1.2. Notes on PCR Allocations It is important to recognize that PCR[0] is critical. The first measurement into PCR[0] taken by the Root of Trust for Measurement, is critical to establishing the chain of trust for all subsequent measurements. If the PCR[0] measurement cannot be trusted, the validity of the entire chain is put into question. Distinctions Between PCR[0], PCR[2], PCR[4] and PCR[8] are summarized below: o PCR[0] typically represents a consistent view of the Host Platform between boot cycles, allowing Attestation and Sealed Storage policies to be defined using the less changeable components of the transitive trust chain. This PCR typically provides a consistent view of the platform regardless of user selected options. o PCR[2] is intended to represent a "user configurable" environment where the user has the ability to alter the components that are measured into PCR[2]. This is typically done by adding adapter cards, etc., into user-accessible PCI or other slots. In UEFI systems these devices may be configured by OptionROMsm easuredROMs measured into PCR[2] and executed by the BIOS. o PCR[4] is intended to represent the software that manages the transition between the platform's Pre-Operating System Start and the state of a system with the Operating System present. This PCR, along with PCR[5], identifies the initial operating system loader(e.g.(e.g., GRUB forLinux)Linux). o PCR[8] is used by the OS loader to record measurements of the various components of the operating system. Although the TCG PC Client document specifies the use of the first eight PCRs very carefully to ensure interoperability among multiple UEFI BIOS vendors, it should be noted that embedded software vendors may have considerably more flexibility. Verifiers typically need to know which log entries are consequential and which are not (possibly controlled by local policies) but theverifierVerifier may not need to know what each log entry means or why it was assigned to a particular PCR. Designers must recognize that some PCRs may cover log entries that a particularverifierVerifier considers critical and other log entries that are not considered important, so differing PCR values may not on their own constitute a check for authenticity. Designers may allocate particular events to specific PCRs in order to achieve a particular objective with Local Attestation,i.e.,(e.g., allowing a procedure to execute only if a given PCR is in a givenstate.state). It may also be important to designers to consider whether streaming notification of PCR updates is required (seeID Rats Streaming).[I-D.birkholz-rats-network-device-subscription]). Specific log entries can only be validated if theverifierVerifier receives every log entry affecting the relevant PCR, so (for example) a designer might want to separate rare, high-value events such as configuration changes, from high-volume, routine measurements such as IMA [IMA] logs. 2.2. RIV Keying RIV attestation relies on two keys: o An identity key is required to certify the identity of the Attester itself. RIV specifies the use of an IEEE 802.1ARDevIDDevice Identity (DevID) [IEEE-802-1AR], signed by the device manufacturer, containing the device serial number. o An Attestation Key is required to sign the Quote generated by the TPM to report evidence of software configuration. In TPM application, the Attestation keymustMUST be protected by the TPM, and the DevIDshouldSHOULD be as well. Depending on other TPM configuration procedures, the two keysmayare likely bedifferent. Somedifferent; some of the considerations are outlined in TCG Guidance for Securing Network Equipment [NetEq]. TCG Guidance for Securing Network Equipment specifies further conventions for these keys: o When separate Identity and Attestation keys are used, the Attestation Key (AK) and itsx.509X.509 certificate should parallel the DevID, with the same device ID information as the DevID 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 an AK, to be linked directly to the device that provided it, by examining the corresponding AK certificate. o Network devices that are expected to use secure zero touch provisioning as specified in [RFC8572])mustMUST be shipped by the manufacturer with pre-provisioned keys (Initial DevID and AK, called IDevID and IAK). Inclusion of anDevIDIDevID and IAK by a vendor does not preclude a mechanism whereby an Administrator can define Local Identity and Attestation Keys (LDevID and LAK) if desired. IDevID and IAK certificates MUST both be signed by the Endorser (typically the device manufacturer). 2.3. RIV Information Flow RIV workflow for networking equipment is organized around a simpleuse-case,use case where a network operator wishes to verify the integrity of software installed in specific, fielded devices. Thisuse-caseuse case implies several components: 1. The Attesting Device, which the network operator wants to examine. 2. A Verifier (which might be a network management station) somewhere separate from the Device that will retrieve the information and analyze it to pass judgment on the security posture of the device. 3. A Relying Party, which can act on Attestationresults.Results. Interaction between the Relying Party and the Verifier is considered out of scope for RIV. 4. Signed Reference Integrity Manifests (RIMs), containing Reference Integrity 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 several 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 systemswhichthat may not have access to the public internet, or by other devices that are not management stationsper-seper se (e.g., a peer device;Seesee Section 3.1.3). Ifreference measurementsReference Integrity 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. These components are illustrated in Figure2.3. A more-detailed taxonomy of terms is given in [I-D.ietf-rats-architecture] +---------------+ +-------------+ +---------+--------+ | | | Attester | Step 1 | Verifier| | | Endorser | | (Device |<-------| (Network| Relying| | (Device | | under |------->| Mngmt | Party | | Manufacturer | | attestation)| Step 2 | Station)| | | or other | | | | | | | authority) | | | | | | +---------------+ +-------------+ +---------+--------+ | /\ | Step 0 | ----------------------------------------------- Figure 3: RIV Reference Configuration for Network Equipment In Step 0, The Endorser (the devicemanufacturer)manufacturer or other authority) provides aSoftware Imagesoftware image to the Attester (the device under attestation), and makes one or more Reference Integrity Manifests (RIMs) signed by the Endorser, available to the Verifier (see Section 3.1.3 for "in-band" and "out of band" ways to make this happen). In Step 1, the Verifier (Network Management Station), on behalf of a Relying Party, requests Identity, MeasurementValues (andValues, and possiblyRIMs)RIMs, from the Attester. In Step 2, the Attester responds to the request by providing a DevID, quotes (measuredvalues), and optionally RIMs,values, signed by theAttester. TheAttester), and optionally RIMs. To achieve interoperability, the following standards componentsmaySHOULD be used: 1. TPM KeysareMUST be configured according to [Platform-DevID-TPM-2.0], [PC-Client-BIOS-TPM-1.2], or[Platform-ID-TPM-1.2][Platform-ID-TPM-1.2]. 2.MeasurementsFor devices using UEFI and Linux, measurements of firmware and bootable modulesmaySHOULD be taken according to TCG PC Client [PC-Client-BIOS-TPM-2.0] and Linux IMA [IMA] 3. Device IdentityisMUST be managedbyas specified in IEEE 802.1AR Device Identity certificates [IEEE-802-1AR], with keys protected by TPMs. 4. Attestation logsmaySHOULD be formatted according to the Canonical Event Log format [Canonical-Event-Log], although other specialized formats may be used. UEFI-based systems MAY use the TCG UEFI BIOS event log [EFI-TPM]). 5. Quotes are retrieved from the TPM according to the TCG TAP Information Model [TAP]. While the TAP IM gives a protocol- independent description of the data elements involved, it's important to note that quotes from the TPM are signed inside the TPM, somustMUST be retrieved in a way that does not invalidate the signature, as specified in [I-D.ietf-rats-yang-tpm-charra], to preserve the trust model. (See Section 5 Security Considerations). 6. Reference Integrity MeasurementsmaySHOULD be encoded as CoSWID tags, as defined in the TCG RIM document [RIM], compatible with NIST IR 8060 [NIST-IR-8060] and the IETF CoSWID draft [I-D.ietf-sacm-coswid]. See Section 2.4.1. 2.4. RIV Simplifying Assumptions This document makes the following simplifying assumptions to reduce complexity: o The product to be attestedisMUST be shipped with an IEEE 802.1ARDevIDDevice Identity 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 [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 credentialsoninto theplatformdevice after manufacture. o The productisMUST be equipped with a Root of Trust for Measurement, Root of Trust for Storage and Root of Trust for Reporting (as defined in [SP800-155]) that are capable of conforming to the TCG Trusted Attestation Protocol (TAP) Information Model [TAP]. o Thevendor will shipauthorized software supplier MUST make available Reference Integrity Measurements (i.e., known-good measurements) in the form of signed CoSWID tags [I-D.ietf-sacm-coswid], [SWID], as described in TCG Reference Integrity Measurement Manifest Information Model [RIM]. 2.4.1. Reference Integrity Manifests (RIMs) [I-D.ietf-rats-yang-tpm-charra] focuses on collecting and transmitting evidence in the form of PCR measurements and attestation logs. But the critical part of the process is enabling theverifierVerifier to decide whether the measurements are "the right ones" or not. 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 that may be used by averifierVerifier to determine if evidence shows known good, known bad or unknown software configurations. In general, there are two kinds of reference measurements: 1. Measurements of early system startup (e.g., BIOS, boot loader, OS kernel) are essentiallysingle threaded,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 relevant PCRs after the box has booted. In this case, the signed reference measurement could simply list the expected hashes for the given version. However, a RIM that contains the intermediate hashes can be useful in debugging cases where the expected final hash is not the one reported. 2. Measurements taken later in operation of the system, once an OS has started (for example, Linux IMA[IMA]), 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. In both cases, the expected values can be expressed as signed SWID or CoSWID tags, but the SWID structure in the second case is somewhat more complex, as reconstruction of the extended hash in a PCR may involve thousands of files and other objects. The TCG has published an information model defining elements of reference integrity manifests under the title TCG Reference Integrity Manifest Information Model [RIM]. This information model outlines how SWID tags should be structured to allow attestation, and defines "bundles" of SWID tags that may be needed to describe a complete software release. The RIM contains metadata relating to the software release it belongs to, plus hashes for each individual file or other object that could be attested. TCG has also published the PC Client Reference Integrity Measurement specification [PC-Client-RIM], which focuses on a SWID-compatible format suitable for expressing expected measurement values in the specific case of a UEFI-compatible BIOS, where the SWID focus on files and file systems is not a direct fit. While the PC Client RIM is not directly applicable to network equipment, many vendors do use a conventional UEFI BIOS to launch their network OS. 2.4.2. Attestation Logs 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 that identifies which software modules contributed which values to the quote during startupmustMUST also be provided. The logmustMUST contain enough information to demonstrate its integrity by allowing exact reconstruction of the digest conveyed in the signed quote (i.e., PCR values). There are multiple event log formats which may be supported as viable formats of Evidence between the Attester and Verifier: o Event log exports from [I-D.ietf-rats-yang-tpm-charra] o IMA Event log file exports [IMA] o TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM Family 1.1 or 1.2, Section77) [EFI-TPM]) o TCG Canonical Event Log [Canonical-Event-Log] Devices which use UEFI BIOS and Linux SHOULD use TCG Canonical Event Log [Canonical-Event-Log] and TCG UEFI BIOS event log [EFI-TPM]) 3. Standards Components 3.1. Prerequisites for RIV The Reference Interaction Model for Challenge-Response-based Remote Attestation is based on the standard roles defined in [I-D.ietf-rats-architecture]. However additional prerequisitesmust behave been established to allow for interoperable RIV use case implementations. These prerequisites are intended to provide sufficient context information so that the Verifier can acquire and evaluate Attester measurements. 3.1.1. Unique Device Identity ASecure devicesecure Device Identity (DevID) in the form of an IEEE 802.1AR DevID certificate [IEEE-802-1AR]mustMUST be provisioned in the Attester's TPMs. 3.1.2. Keys The Attestation Identity Key (AIK) and certificatemustMUST also be provisioned on the Attester according to [Platform-DevID-TPM-2.0], [PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2]. The Attester's TPM KeysmustMUST be associated with the DevID on the Verifier (see [Platform-DevID-TPM-2.0] and Section 5 SecurityConsiderations).Considerations, below). 3.1.3. Appraisal Policy for Evidence(Editor's Note - terminology in this section must be brought back into line with the RATS Architecture definitions)The VerifiermustMUST obtainthe Appraisal Policy for Evidence. This policy may betrustworthy Endorsements in the form of reference measurements (e.g., Known Good Values, encoded as CoSWID tags [I-D.birkholz-yang-swid]). These reference measurements will eventually be compared to signed PCR Evidence acquired from an Attester'sTPM.TPM using Attestation Policies chosen by the administrator or owner of the device. This document does not specify the format or contents for the Appraisal Policy forEvidence. But acquiring this policyEvidence, but Endorsements mayhappenbe acquired in one of two ways: 1. a Verifierobtainsmay obtain reference measurements directly froma Verifier Owner (i.e., a Device Configuration Authority)an Endorser chosen by the Verifieradministrator.administrator (e.g., through a web site). 2. Signed reference measurements may be distributed by theVerifier OwnerEndorser to theAttester.Attester, as part of a software update. From there, the reference measurement may be acquired by the Verifier. In either case, the Verifier Owner MUST select the source of trusted endorsements through the Appraisal Policy for Evidence. ************* .-------------. .-----------. *VerifierEndorser * | Attester | | Verifier/ | *Owner* | | | Relying | *(Device *----2--->| (Network |----2--->| Party | * config * | Device) | |(Ntwk Mgmt | * Authority)* | | | Station) | ************* '-------------' '-----------' | ^ | | '----------------1--------------------------' Figure 4: Appraisal Policy for Evidence Prerequisites In either case theAppraisal Policy for EvidenceEndorsements must be generated, acquired and delivered in a secureway. This includesway, including reference measurementsof: oof firmware and bootable modules taken according to TCG PC Client [PC-Client-BIOS-TPM-2.0] and Linux IMA[IMA] o[IMA]. Endorsementa MUST be encoded as SWID or CoSWIDtagstags, signed by the device manufacturer,areas defined in the TCG RIM document [RIM], compatible with NIST IR 8060 [NIST-IR-8060]andor the IETF CoSWID draft [I-D.ietf-sacm-coswid]. 3.2. Reference Model for Challenge-Response Once the prerequisites for RIV are met, a Verifiermayis able to acquire Evidence from an Attester. The following diagram illustrates a RIV information flow between a Verifier and an Attester, derived from Section 8.1 of [I-D.birkholz-rats-reference-interaction-model]. Event times shown correspond to the time types described within Appendix A of [I-D.ietf-rats-architecture]: .----------. .--------------------------. | Attester | | Relying Party / Verifier | '----------' '--------------------------' time(VG) | valueGeneration(targetEnvironment) | | => claims | | | | <--------------requestEvidence(nonce, PcrSelection)-----time(NS) | | time(EG) | evidenceGeneration(nonce, PcrSelection, collectedClaims) | | => SignedPcrEvidence(nonce, PcrSelection) | | => LogEvidence(collectedClaims) | | | | returnSignedPcrEvidence----------------------------------> | | returnLogEvidence----------------------------------------> | | | | time(RG,RA) | evidenceAppraisal(SignedPcrEvidence, eventLog, refClaims) | attestationResult <= | ~ ~ | time(RX) Figure 5: IETF Attestation Information Flow otime(VG):Step 1 (time(VG)): One or more Attesting Network Device PCRs are extended with measurements. RIV provides no direct link between the time at which the event takes place and the time that it's attested, although streaming attestation as in [I-D.birkholz-rats-network-device-subscription] could. otime(NS):Step 2 (time(NS)): The Verifier generates a unique nonce ("number used once"), and makes a request attestation data for one or more PCRs from an Attester.This canFor interoperability, this MUST be accomplished via a YANG [RFC7950] interface that implements the TCG TAP model(e.g.(e.g., YANG Module for BasicChallenge-Response-basedChallenge-Response- based Remote Attestation Procedures [I-D.ietf-rats-yang-tpm-charra]). otime(EG):Step 3 (time(EG)): On the Attester, measured values are retrieved from the Attester's TPM. This requested PCR evidence is signed by the Attestation Identity Key (AIK) associated with the DevID. Quotes are retrieved according to TCG TAP Information Model [TAP]. While the TAP IM gives a protocol-independent description of the data elements involved, it's important to note that quotes from the TPM are signed inside the TPM, so must be retrieved in a way that does not invalidate the signature, as specified in [I-D.ietf-rats-yang-tpm-charra], to preserve the trust model. (See Section 5 Security Considerations). At the same time, the Attester collects log evidence showing what values have been extended into that PCR. o Step 4: Collected Evidence is passed from the Attester to the Verifier otime(RG,RA):Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes action as needed. As the interaction between Relying Party and Verifierare assumed co- resident,is out of scope for RIV, this can happen in one step. * If the signed PCR values do not match the set of log entries which have extended a particular PCR, the deviceshould notSHOULD NOT be trusted. * If the log entries that theverifierVerifier considers important do not match known good values, the deviceshould notSHOULD NOT be trusted. We note that the process of collecting and analyzing the log can be omitted if the value in the relevant PCR is already a known- good value. * If the set of log entries are not seen as acceptable by the Appraisal Policy for Evidence, the deviceshould notSHOULD NOT be trusted. * If the AIK signature is not correct, or freshness such as that provided by the nonce is not included in the response, the deviceshould notSHOULD NOT be trusted.o time(RX): At some point after* If time(RG)-time(NS) is greater than theverification ofthreshold in the Appraisal Policy for Evidence, theAttester can no longer beEvidence is consideredAttested as trustworthy.stale and SHOULD NOT be trusted. 3.2.1. Transport and Encoding Network Management systems may retrieve signed PCR based Evidence as shown in Figure 5, and can be accomplishedvia: ovia NETCONF or RESTCONF, with XML, JSON, or CBOR encodedEvidence, using o RESTCONF orEvidence. Implementations that use NETCONFtransport,MUST do so over aoTLS or SSH securetunneltunnel. Implementations that use RESTCONF transport MAY do so over a TLS or SSH secure tunnel. Retrieval of Log EvidencewillSHOULD be via log interfaces on the network device. (For example, see [I-D.ietf-rats-yang-tpm-charra]). 3.3. Centralized vs Peer-to-Peer Figure 5 above assumes that the Verifier is implicitly trusted, while the Attesting device is not. In a Peer-to-Peer application such as two routers negotiating a trust relationship [I-D.voit-rats-trusted-path-routing], the two peers can each ask the other to prove software integrity. In this application, the information flow is the same, but each side plays a role both as an Attester and a Verifier. Each device issues a challenge, and each device responds to the other's challenge, as shown in Figure 6. Peer-to-peer challenges, particularly if used to establish a trust relationship between routers, require devices to carry their own signed reference measurements(RIMs)(RIMs). Devices may also have to carry Appraisal Policy for Evidence for each possible peer device so that each device has everything needed for attestation, without having to resort to a central authority. +---------------+ +---------------+ | | | | | Endorser A | | Endorser B | | Firmware | | Firmware | | Configuration | | Configuration | | Authority | | Authority | | | | | +---------------+ +---------------+ | | | +-------------+ +------------+ | | | | Step 1 | | | \ | | Attester |<------>| Verifier | | | | | |<------>| | | | Router B +------>| | Step 2 | | | |- Challenges Step 0A| | | | | | Router A | |------->| | | | |- Router A --| Step 3 |- Router B -| | / | | | | | | | | | | | | Step 1 | | | \ | Verifier |<------>| Attester |<-+ | Router A | |<------>| | |- Challenges | | Step 2 | | | Router B | | | | | | |<-------| | | +-------------+ Step 3 +------------+ / Figure 6: Peer-to-Peer Attestation Information Flow In this application, each device may need to be equipped with signed RIMs to act as an Attester, and also an Appraisal Policy for Evidence and a selection of trustedx.509X.509 rootcertificatescertificates, to allow the device to act as a Verifier. An existing link layer protocol such as 802.1x [IEEE-802.1x] or 802.1AE [IEEE-802.1ae], with Evidence being enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable methods for such an exchange. 4. Privacy Considerations Networking Equipment, such as routers, switches and firewalls, has a key role to play in guarding the privacy of individuals using the network: o Packets passing through the device must not be sent to unauthorized destinations. For example: * Routers often act as Policy Enforcement Points, where individual subscribers may be checked for authorization to access a network. Subscriber login information must not be released to unauthorized parties. * Networking Equipment is often called upon to block access to protected resources from unauthorized users. o Routing information, such as the identity of a router's peers, must not be leaked to unauthorized neighbors. o If configured, encryption and decryption of traffic must be carried out reliably, while protecting keys and credentials. Functions that protect privacy are implemented as part of each layer of hardware and software that makes up the networking device. In light of these requirements for protecting the privacy of users of the network, the Network Equipment must identify itself, and its boot configuration and measured device state (for example, PCR values), to the Equipment's Administrator, so there's no uncertainty as to what function each device and configuration is configured to carry out. This allows the administrator to ensure that the network provides individual and peer privacy guarantees. RIV specifically addresses the collection of information from enterprise network devices by authorized agents of the enterprise. As such, privacy is a fundamental concern for those deploying this solution, given EU GDPR, California CCPA, and many other privacy regulations. The enterpriseshouldSHOULD implement and enforce their duty of care. See [NetEq] for more context on privacy in networkingdevicesdevices. 5. Security Considerations AttestationresultsResults from the RIV procedure are subject to a number of attacks: o Keys may becompromisedcompromised. o A counterfeit device may attempt to impersonate (spoof) a known authenticdevicedevice. o Man-in-the-middle attacks may be used by a counterfeit device to attempt to deliver responses that originate in an actual authenticdevicedevice. o Replay attacks may be attempted by a compromiseddevicedevice. 5.1. Keys Used in RIV 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. Two sets of keys are relevant to RIVattestationattestation: o A DevID key is used to certify the identity of the device in which the TPM is installed. o An Attestation Key (AK) key signs attestationreports,reports (called 'quotes' in TCG documents), used to provide evidence for integrity of the software on the device. TPM practices usually 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. 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, specification-compliant private/public key- pairs are generated inside the TPM, where they're never exposed, and cannot be extracted (See [Platform-DevID-TPM-2.0]). Keeping keys safe is just part of attestation security; knowing which keys are bound to the device in question is just as important. While there are many ways to manage keys in a TPM(See(see [Platform-DevID-TPM-2.0]), RIV includes support for "zero touch" provisioning (also known as zero-touch onboarding) of fielded devices(e.g.(e.g., Secure ZTP, [RFC8572]), where keys which have predictable trust properties are provisioned by the device vendor. Device identity in RIV is based on IEEE 802.1ARDevID.Device Identity (DevID). This specification provides severalelementselements: o A DevID requires a unique key pair for each device, accompanied by anx.509 certificateX.509 certificate, o The private portion of the DevID key is to be stored in the device, in a manner that provides confidentiality (Section 6.2.5 [IEEE-802-1AR]) Thex.509X.509 certificate contains severalcomponentscomponents: o The public part of the unique DevID key assigned to that device allows a challenge of identity. o 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 a label on the device. o The certificate must be signed by a key traceable to the manufacturer's root key. With these elements, the device's manufacturer and serial number can be identified by analyzing the DevID certificate plus the chain of intermediatecertscertificates leading back to the manufacturer's root certificate. As is conventional in TLS or SSH connections, a nonce must be signed by the device in response to a challenge, proving possession of its DevID private key. RIV uses the DevID to validate a TLS or SSH connection to the device as the attestation session begins. Security of this process derives from TLS or SSH security, with the DevID providing proof that theTLSsession terminates on the intended device.[RFC8446].See [RFC8446], [RFC4253]. Evidence of software integrity is delivered in the form of a quote signed by the TPM itself. Because the contents of the quote are signed inside the TPM, any external modification (including reformatting to a different data format) after measurements have been taken will be detected as tampering. An unbroken chain of trust is essential to ensuring that blocks of code that are taking measurements have been verified before execution (see Figure 1. 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, generated and signed by the TPM itself, made by malicious device software, or in the path back to theverifier,Verifier, will invalidate the signature on the quote. A critical feature of the YANG model described in [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data structures in their native format, without requiring any changes to the structures as they were signed and delivered by the TPM. While alternate methods of conveying TPM quotes could compress out redundant information, or add an additional layer of signing using external keys, theimportant part is toimplementation MUST preserve the TPM signing, so that tampering anywhere in the path between the TPM itself and the Verifier can be detected. 5.2. Prevention of Spoofing and Man-in-the-Middle Attacks Prevention of spoofing attacks against attestation systems is also important. There are two cases to consider: o The entire device could be spoofed, that is, when the Verifier goes to verify a specific device, it might be redirected to a different device. Use of the 802.1ARidentityDevice Identity (DevID) in the TPM ensures that the Verifier's TLS or SSH session is in fact terminating on the right device. o A compromised device could respond with a spoofedattestation result,Attestation Result, that is, a compromised OS could return a fabricated quote. Protection against spoofed quotes from a device with valid identity is a bit more complex. An identity key must be available to sign any kind of nonce or hash offered by theverifier,Verifier, and consequently, could be used to sign a fabricated quote. To block a spoofedattestation result,Attestation Result, the quote generated inside the TPM must be signed by a key that's different from the DevID, called an Attestation Key (AK). Given separate Attestation and DevID keys, the binding between the AK and the same device must also be proven to prevent a man-in-the- middle attack(e.g.(e.g., the 'Asokan Attack' [RFC6813]). 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. [Editor's Note: does this require an OID that says the key is known by the CA to be an Attestation key?] These two keys and certificates are used together: o The DevID is used to validate a TLS connection terminating on the device with a known serial number. o The AK is used to sign attestation quotes, providing proof that the attestation evidence comes from the same device. 5.3. Replay Attacks Replay attacks, where results of a previous attestation are submitted in response to subsequent requests, are usually prevented by inclusion of a nonce in the request to the TPM for a quote. Each request from the Verifier includes a new random number (a nonce). The resulting quote signed by the TPM contains the same nonce, allowing theverifierVerifier to determine freshness,i.e.,(i.e., that the resulting quote was generated in response to theverifier'sVerifier's specificrequest.request). Time-Based Uni-directional Attestation [I-D.birkholz-rats-tuda] provides an alternate mechanism to verify freshness without requiring a request/response cycle. 5.4. Owner-Signed Keys AlthoughRIV recommends thatdevice manufacturers MUST pre-provision devices witheasily-verifiedeasily verified DevID and AKcerts,certificates, 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 and [Platform-DevID-TPM-2.0] extends that concept by defining an Initial Attestation Key (IAK) and Local Attestation Key (LAK) with the same properties. Device owners can use any method to provision the Local credentials. o The TCG document [Platform-DevID-TPM-2.0] 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 to identify devices they own). The TCGdocdocument [Provisioning-TPM-2.0] also contains guidance on provisioning identity keys in TPM 2.0. oBut device ownersDevice owners, however, 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. 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 isconfiguredinstalled for network operation. 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. 5.5. Other Trust Anchors In addition to trustworthy provisioning of keys, RIV depends on other trust anchors. (See [SP800-155] for definitions of Roots of Trust.) o Secure identity depends on mechanisms to prevent per-device secret keys from being compromised. The TPM provides this capability as a Root of Trust forStorageStorage. o 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. See Section 8.1 for background on TPM practices. oRIV assumesThe device owner SHOULD provide 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. RIV also depends on reliable reference measurements, as expressed by the RIM [RIM]. 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 3.1.3). 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. The validity of RIV attestation results is also influenced by procedures used to create reference measurements: o While the RIM itself is signed, supply-chainsmustSHOULD be carefully scrutinized to ensure that the values are not subject to unexpected manipulation prior to signing. Insider-attacks against code bases and build chains are particularly hard to spot. o DesignersmustSHOULD guard against hash collision attacks. ReferencemeasurementsIntegrity Measurements often give hashes for large objects of indeterminate size; if one of the measured objects can be replaced with an implant engineered to produce the same hash, RIV will be unable to detect the substitution. TPM1.2 uses SHA-1 hashes only, which have been shown to be susceptible to collision attack. TPM2.0 will produce quotes with SHA-256, which so far has resisted suchattacks, and consequently is preferred.attacks. Consequently RIV implementations SHOULD use TPM2.0. 6. Conclusion 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: o Platform identity can be based on IEEE 802.1AR Deviceidentity,Identity, coupled with careful supply-chain management by the manufacturer. o Complex supply chains can be certified using TCG Platform Certificates[Platform-Certificates][Platform-Certificates]. o The TCG TAP mechanism can be used to retrieve attestation evidence. Work is needed on a YANG model for this protocol. o Reference Integrity 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. 7. IANA Considerations This memo includes no request to IANA. 8. Appendix 8.1.Layering ModelUsing a TPM forNetwork Equipment AttesterAttestation The Trusted Platform Module andVerifier Retrievalsurrounding ecosystem provide three interlocking capabilities to enable secure collection ofidentityevidence from a remote device, Platform Configuration Registers (PCRs), a Quote mechanism, andattestation state uses one protocol stack, while retrieval of Reference Measurements usesadifferent set of protocols. Figure 5 showsstandardized Event Log. Each TPM has at least between eight and twenty-four PCRs (depending on thecomponents involved. +-----------------------+ +-------------------------+ | | | | | Attester |<-------------| Verifier | | (Device) |------------->| (Management Station) | | | | | | +-----------------------+ | +-------------------------+ | -------------------- -------------------- | | ---------------------------------- --------------------------------- |Reference Integrity Measurements| | Attestation | ---------------------------------- --------------------------------- ******************************************************************** * IETF Attestation Reference Interaction Diagram * ******************************************************************** ....................... ....................... . Reference Integrity . . TAP (PTS2.0) Info . . Manifest . . Model and Canonical . . . . Log Format . ....................... ....................... ************************* .............. ********************** * YANG SWID Module * . TCG . * YANG Attestation * * I-D.birkholz-yang-swid* . Attestation. * Module * * * . MIB . * I-D.ietf-rats- * * * . . * yang-tpm-charra * ************************* .............. ********************** ************************* ************ ************************ * XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)* ************************* ************ ************************ ************************* ************************ * RESTCONF/NETCONF * * RESTCONF/NETCONF * ************************ ************************* ************************* ************************ * TLS, SSH * * TLS, SSH * ************************* ************************ Figure 7: RIV Protocol Stacks 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 Manifest, TAP Information Modelprofile andCanonical Log Format,vendor choices), each one large enough to hold one hash value (SHA-1, SHA-256, andboth YANG modules are works in progress. Information Model layers describe abstract data objects thatother hash algorithms can berequested, and the corresponding response SNMP is still widelyused, depending on TPM version). PCRs can't be accessed directly from outside the chip, but theindustry is transitioning to YANG, so in some cases, both will be required. TLS Authentication withTPMhas been showninterface provides a way towork; SSH authentication using TPM-protected keys is not as easily done [as of 2019] 8.1.1. Why is OS Attestation Different? Even"extend" a new security measurement hash into any PCR, a process by which the existing value inembedded systems, adding Attestation attheOS level (e.g. Linux IMA, Integrity Measurement Architecture [IMA]) increasesPCR is hashed with thenumber 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 an unpredictable order. TCGnew security measurement hash, andothers (includingtheLinux community) are working on methods and procedures for attestingresult placed back into the same PCR. The result is a composite fingerprint of all the security measurements extended into each PCR since theoperatingsystemand application software,was reset. Every time a PCR is extended, an entry should be added to the corresponding Event Log. Logs contain the security measurement hash plus informative fields offering hints as to what event it was that generated the security measurement. The Event Log itself is protected against accidental manipulation, butstandardizationit isstill in process. 8.2. Implementation Notes Table 1 summarizes many ofimplicitly tamper-evident - any verification process can read theactions neededsecurity measurement hash from the log events, compute the composite value and compare that tocompletewhat ended up in the PCR. If there's a discrepancy, the logs do not provide an accurate view of what was placed into the PCR. In a conventional TPM Attestationsystem, with links to relevant documents. While documents are controlledenvironment, the first measurement must be made and extended into the TPM byseveral standards organizations,trusted device code (called theimplied actions requiredRoot of Trust forimplementation are allMeasurement, RTM). That first measurement should cover theresponsibilitysegment of code that is run immediately after themanufacturer of the device, unless otherwise noted. +------------------------------------------------------------------+ | Component | Controlling | | | Specification | -------------------------------------------------------------------- | Make a Secure execution environment | TCG RoT | | o Attestation depends on a secure root of | UEFI.org | | trust for measurement outsideRTM, which then measures theTPM, as | | | well as roots for storagenext code segment before running it, andreporting | | | inside the TPM. | | | o Refer to TCG Rootso on, forming an unbroken chain ofTrusttrust. See [TCGRoT] forMeasurement.| | | o NIST SP 800-193 also provides guidelines | | |more onRootsMutable vs Immutable roots ofTrust | | -------------------------------------------------------------------- | Provision the TPM as described in | TCGtrust. The TPMDevID | | TCG documents. | TCG Platform | | | Certificate | -------------------------------------------------------------------- | Putprovides another mechanism called aDevID or Platform Cert in the TPM | TCG TPM DevID | | o Install an Initial Attestation Key at the | TCG Platform | | same time soQuote thatAttestationcanwork out | Certificate | |read the current value of thebox |----------------- | o Equipment suppliersPCRs andowners may wantpackage them into a data structure signed by an Attestation Key (which is private key that is known only to| IEEE 802.1AR | | implement Local Device ID as well as | | | Initial Device ID | | -------------------------------------------------------------------- | ConnecttheTPM toTPM). The Verifier uses theTLS stack | Vendor TLS | | o UseQuote and Log together. The Quote, containing theDevID incomposite hash of theTPM to authenticate | stack (This | | TAP connections, identifying the device | actioncomplete sequence of security measurement hashes, is| | | simply | | | configuring TLS| | |used touseverify 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 signintegrity of theSWID tags | NIST IR 8060 | | o The TCG RIM-IM identifies further | | | proceduresEvent Log. Each hash in the validated Quote can then be compared tocreate signed RIM | | | documents that providecorresponding expected values in thenecessary | | | referenceset of Reference Integrity Measurements to validate overall system integrity. A summary of information| | -------------------------------------------------------------------- | Packageexchanged in obtaining quotes from TPM1.2 and TPM2.0 can be found in [TAP], Section 4. Detailed information about PCRs and Quote data structures can be found in [TPM1.2], [TPM2.0]. Recommended log formats include [PC-Client-BIOS-TPM-2.0] and [Canonical-Event-Log]. 8.2. Root of Trust for Measurement The measurements needed for attestation require that theSWID tagsdevice being attested is equipped with avendor software | Retrieve tags | | release | with | | o A tag-generator plugin such | {{I-D.birkholz-yang-swid}}| | as https://github.com/Labs64/swid-maven-plugin | |Root of Trust for Measurement, that is, some trustworthy mechanism that canbe used |----------------| | | TCG PC Client | | | RIM | -------------------------------------------------------------------- | Use PC Clientcompute the first measurementdefinitions | TCG PC Client | | to definein theuse of PCRs | BIOS | | (although Windows OS is rare on Networking | | | Equipment, UEFI BIOS is not) | | -------------------------------------------------------------------- | Use TAP to retrieve measurements | | | o Map TAP to SNMP | TCG SNMP MIB | | o Map to YANG | YANG Module for| | Use Canonical Log Format | Basic | | | Attestation | | | TCG Canonical | | | Log Format | -------------------------------------------------------------------- | Posture Collection Server (as described in IETF | | | SACMs ECP) should 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. | | -------------------------------------------------------------------- Figure 8: Component Status 8.3. Root of Trust for Measurement 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 chainchain of trust required to attest that each stage of system startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs) to record the results, and a Root of Trust for Reporting to report the results [TCGRoT], [SP800-155]. While there are many complex aspects of a Root of Trust, two aspects that are important in the case of attestation are: o 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. o There must not be a way to reset the Root of Trust for Storage without re-entering the Root of Trust for Measurement code. The first measurement must be computed by code that is implicitly trusted; if that first measurement can be subverted, none of the remaining measurements can be trusted. (See [NIST-SP-800-155])9.8.3. Layering Model for Network Equipment Attester and Verifier 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. +-----------------------+ +-------------------------+ | | | | | Attester |<-------------| Verifier | | (Device) |------------->| (Management Station) | | | | | | +-----------------------+ | +-------------------------+ | -------------------- -------------------- | | ---------------------------------- --------------------------------- |Reference Integrity Measurements| | Attestation | ---------------------------------- --------------------------------- ******************************************************************** * IETF Attestation Reference Interaction Diagram * ******************************************************************** ....................... ....................... . Reference Integrity . . TAP (PTS2.0) Info . . Manifest . . Model and Canonical . . . . Log Format . ....................... ....................... ************************* .............. ********************** * YANG SWID Module * . TCG . * YANG Attestation * * I-D.birkholz-yang-swid* . Attestation. * Module * * * . MIB . * I-D.ietf-rats- * * * . . * yang-tpm-charra * ************************* .............. ********************** ************************* ************ ************************ * XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)* ************************* ************ ************************ ************************* ************************ * RESTCONF/NETCONF * * RESTCONF/NETCONF * ************************ ************************* ************************* ************************ * TLS, SSH * * TLS, SSH * ************************* ************************ Figure 7: RIV Protocol Stacks IETF documents are captured in boxes surrounded by asterisks. TCG documents are shown in boxes surrounded by dots. 8.3.1. Why is OS Attestation Different? Even in embedded systems, adding Attestation at the OS level (e.g., Linux IMA, Integrity Measurement Architecture [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 an unpredictable order. 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. 8.4. Implementation Notes Figure 8 summarizes many of the actions needed to complete an Attestation system, with links to relevant documents. While documents are controlled by several standards organizations, the implied actions required for implementation are all the responsibility of the manufacturer of the device, unless otherwise noted. It should be noted that, while the YANG model is RECOMMENDED for attestation, this table identifies an optional SNMP MIB as well, [Attest-MIB]. +------------------------------------------------------------------+ | Component | Controlling | | | Specification | -------------------------------------------------------------------- | Make a Secure execution environment | TCG RoT | | o Attestation depends on a secure root of | UEFI.org | | 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 | | -------------------------------------------------------------------- | Provision the TPM 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 The TCG RIM-IM identifies further | | | procedures to create signed RIM | | | documents that provide the necessary | | | reference information | | -------------------------------------------------------------------- | Package the SWID tags with a vendor software | Retrieve tags | | release | with | | o A tag-generator plugin such | draft-birkholz-yang-swid| | as [SWID-Gen] can be used |----------------| | | TCG PC Client | | | RIM | -------------------------------------------------------------------- | Use PC Client measurement definitions | TCG PC Client | | to define the use of PCRs | BIOS | | (although Windows OS is rare on Networking | | | Equipment, UEFI BIOS is not) | | -------------------------------------------------------------------- | Use TAP to retrieve measurements | | | o Map TAP to SNMP | TCG SNMP MIB | | o Map to YANG | YANG Module for| | Use Canonical Log Format | Basic | | | Attestation | | | TCG Canonical | | | Log Format | -------------------------------------------------------------------- | Posture Collection Server (as described in IETF | | | SACMs ECP) should 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. | | -------------------------------------------------------------------- Figure 8: Component Status 9. References 9.1. Normative References [Canonical-Event-Log] Trusted Computing Group, "DRAFT Canonical Event Log Format Version: 1.0, Revision: .12", October 2018. [I-D.birkholz-yang-swid] Birkholz, H., "Software Inventory YANG module based on Software Identifiers", draft-birkholz-yang-swid-02 (work in progress), October 2018. [I-D.ietf-rats-yang-tpm-charra] Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit, E., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-02 (work in progress), June 2020. [I-D.ietf-sacm-coswid] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Waltermire, "Concise Software Identification Tags", draft- ietf-sacm-coswid-15 (work in progress), May 2020. [IEEE-802-1AR] Seaman, M., "802.1AR-2018 - IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity, IEEE Computer Society", August 2018. [PC-Client-BIOS-TPM-1.2] Trusted Computing Group, "TCG PC Client Specific Implementation Specification for Conventional BIOS, Specification Version 1.21 Errata, Revision 1.00", February 2012, <https://trustedcomputinggroup.org/resource/pc-client- work-group-specific-implementation-specification-for- conventional-bios/>. [PC-Client-BIOS-TPM-2.0] Trusted Computing Group, "PC Client Specific Platform Firmware Profile Specification Family "2.0", Level 00 Revision 1.04", June 2019, <https://trustedcomputinggroup.org/pc-client-specific- platform-firmware-profile-specification>. [PC-Client-RIM] Trusted Computing Group, "DRAFT: TCG PC Client Reference Integrity Manifest Specification, v.09", December 2019, <https://trustedcomputinggroup.org/wp-content/uploads/ TCG_PC_Client_RIM_r0p15_15june2020.pdf>. [Platform-DevID-TPM-2.0] Trusted Computing Group, "DRAFT: TPM Keys for Platform DevID for TPM2, Specification Version 0.7, Revision 0", October 2018. [Platform-ID-TPM-1.2] Trusted Computing Group, "TPM Keys for Platform Identity for TPM 1.2, Specification Version 1.0, Revision 3", August 2015, <https://trustedcomputinggroup.org/resource/ tpm-keys-for-platform-identity-for-tpm-1-2-2/>. [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero Touch Provisioning (SZTP)", RFC 8572, DOI 10.17487/RFC8572, April 2019, <https://www.rfc-editor.org/info/rfc8572>. [RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity Manifest Information Model", June 2019, <https://trustedcomputinggroup.org/wp-content/uploads/ TCG_RIM_Model_v1-r13_2feb20.pdf>. [SWID] The International Organization for Standardization/ International Electrotechnical Commission, "Information Technology Software Asset Management Part 2: Software Identification Tag, ISO/IEC 19770-2", October 2015, <https://www.iso.org/standard/65666.html>. [TAP] Trusted Computing Group, "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.36", October 2018, <https://trustedcomputinggroup.org/resource/tcg-tap- information-model/>. 9.2. Informative References [AIK-Enrollment] Trusted Computing Group, "TCG Infrastructure Working Group - A CMC Profile for AIK Certificate Enrollment Version 1.0, Revision 7", March 2011, <https://trustedcomputinggroup.org/resource/tcg- infrastructure-working-group-a-cmc-profile-for-aik- certificate-enrollment/>.[Canonical-Event-Log][Attest-MIB] Trusted Computing Group,"DRAFT Canonical Event Log Format Version: 1.0, Revision: .12", October 2018."SNMP MIB for TPM-Based Attestation, Version 0.8Revision 0.02", May 2018, <https://trustedcomputinggroup.org/wp-content/uploads/ TCG_SNMP_MIB_for_TPM- Based_Attestation_v0.8r2_PUBLIC_REVIEW.pdf>. [EFI-TPM] Trusted Computing Group, "TCG EFI Platform Specification for TPM Family 1.1 or 1.2, Specification Version 1.22, Revision 15", January 2014, <https://trustedcomputinggroup.org/resource/tcg-efi- platform-specification/>. [I-D.birkholz-rats-network-device-subscription] Birkholz, H., Voit, E., and W. Pan, "Attestation Event Stream Subscription", draft-birkholz-rats-network-device- subscription-00 (work in progress), June 2020. [I-D.birkholz-rats-reference-interaction-model] Birkholz, H., Eckel, M., Newton, C., and L. Chen, "Reference Interaction Models for Remote Attestation Procedures", draft-birkholz-rats-reference-interaction- model-03 (work in progress), July 2020. [I-D.birkholz-rats-tuda] Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, "Time-Based Uni-Directional Attestation", draft-birkholz- rats-tuda-03 (work in progress), July 2020.[I-D.birkholz-yang-swid] Birkholz, H., "Software Inventory YANG module based on Software Identifiers", draft-birkholz-yang-swid-02 (work in progress), October 2018.[I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture",draft-ietf-rats-architecture-05draft-ietf-rats-architecture-06 (work in progress),JulySeptember 2020. [I-D.ietf-rats-eat] Mandyam, G., Lundblade, L., Ballesteros, M., and J. O'Donoghue, "The Entity Attestation Token (EAT)", draft-ietf-rats-eat-03 (work in progress), February 2020. [I-D.ietf-rats-yang-tpm-charra] Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit, E., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-02 (work in progress), June 2020. [I-D.ietf-sacm-coswid] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Waltermire, "Concise Software Identification Tags", draft- ietf-sacm-coswid-15ietf-rats-eat-04 (work in progress),MayAugust 2020. [I-D.richardson-rats-usecases] Richardson, M., Wallace, C., and W. Pan, "Use cases for Remote Attestation common encodings", draft-richardson- rats-usecases-07 (work in progress), March 2020. [I-D.voit-rats-trusted-path-routing] Voit, E., "Trusted Path Routing", draft-voit-rats-trusted- path-routing-02 (work in progress), June 2020.[IEEE-802-1AR] Seaman, M., "802.1AR-2018 - IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity, IEEE Computer Society", August 2018.[IEEE-802.1ae] Seaman, M., "802.1AE MAC Security (MACsec)", 2018, <https://1.ieee802.org/security/802-1ae/>. [IEEE-802.1x] IEEE Computer Society, "802.1X-2020 - IEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access Control", February 2020, <https://standards.ieee.org/standard/802_1X-2020.html>. [IMA] and , "Integrity Measurement Architecture", June 2019, <https://sourceforge.net/p/linux-ima/wiki/Home/>. [LLDP] IEEE Computer Society, "802.1AB-2016 - IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery", March 2016, <https://standards.ieee.org/standard/802_1AB-2016.html>. [NetEq] Trusted Computing Group, "TCG Guidance for Securing Network Equipment, Version 1.0, Revision 29", January 2018, <https://trustedcomputinggroup.org/resource/tcg- guidance-securing-network-equipment/>. [NIST-IR-8060] National Institute for Standards and Technology, "Guidelinesfor the Creation of Interoperable Software Identification (SWID) Tags", April 2016, <https://nvlpubs.nist.gov/nistpubs/ir/2016/ NIST.IR.8060.pdf>. [NIST-SP-800-155] National Institute for Standards and Technology, "BIOS Integrity Measurement Guidelines (Draft)", December 2011, <https://csrc.nist.gov/csrc/media/publications/sp/800- 155/draft/documents/draft-sp800-155_dec2011.pdf>. [PC-Client-BIOS-TPM-1.2] Trusted Computing Group, "TCG PC Client Specific Implementation Specification for Conventional BIOS, Specification Version 1.21 Errata, Revision 1.00", February 2012, <https://trustedcomputinggroup.org/resource/pc-client- work-group-specific-implementation-specification-for- conventional-bios/>. [PC-Client-BIOS-TPM-2.0] Trusted Computing Group, "PC Client Specific Platform Firmware Profile Specification Family "2.0", Level 00 Revision 1.04", June 2019, <https://trustedcomputinggroup.org/pc-client-specific- platform-firmware-profile-specification>. [PC-Client-RIM] Trusted Computing Group, "DRAFT: TCG PC Client Referencefor the Creation of Interoperable Software Identification (SWID) Tags", April 2016, <https://nvlpubs.nist.gov/nistpubs/ir/2016/ NIST.IR.8060.pdf>. [NIST-SP-800-155] National Institute for Standards and Technology, "BIOS IntegrityManifest Specification, v.09",Measurement Guidelines (Draft)", December2019, <https://trustedcomputinggroup.org/wp-content/uploads/ TCG_PC_Client_RIM_r0p15_15june2020.pdf>.2011, <https://csrc.nist.gov/csrc/media/publications/sp/800- 155/draft/documents/draft-sp800-155_dec2011.pdf>. [Platform-Certificates] Trusted Computing Group, "TCG Platform Attribute Credential Profile, Specification Version 1.0, Revision 16", January 2018, <https://trustedcomputinggroup.org/resource/tcg-platform- attribute-credential-profile/>.[Platform-DevID-TPM-2.0] Trusted Computing Group, "DRAFT: TPM Keys for Platform DevID for TPM2, Specification Version 0.7, Revision 0", October 2018. [Platform-ID-TPM-1.2] Trusted Computing Group, "TPM Keys for Platform Identity for TPM 1.2, Specification Version 1.0, Revision 3", August 2015, <https://trustedcomputinggroup.org/resource/ tpm-keys-for-platform-identity-for-tpm-1-2-2/>.[Provisioning-TPM-2.0] Trusted Computing Group, "TCG TPM v2.0 Provisioning Guidance, Version 1.0, Revision 1.0", March 2015, <https://trustedcomputinggroup.org/wp-content/uploads/TCG- TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf>. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>.[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.[RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment (NEA) Asokan Attack Analysis", RFC 6813, DOI 10.17487/RFC6813, December 2012, <https://www.rfc-editor.org/info/rfc6813>.[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero Touch Provisioning (SZTP)", RFC 8572, DOI 10.17487/RFC8572, April 2019, <https://www.rfc-editor.org/info/rfc8572>. [RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity Manifest Information Model", June 2019, <https://trustedcomputinggroup.org/wp-content/uploads/ TCG_RIM_Model_v1-r13_2feb20.pdf>.[SP800-155] National Institute of Standards and Technology, "BIOS Integrity Measurement Guidelines (Draft)", December 2011, <https://csrc.nist.gov/csrc/media/publications/sp/800- 155/draft/documents/draft-sp800-155_dec2011.pdf>.[SWID] The International Organization for Standardization/ International Electrotechnical Commission, "Information Technology Software Asset Management Part 2: Software Identification Tag, ISO/IEC 19770-2", October 2015, <https://www.iso.org/standard/65666.html>. [TAP] Trusted Computing Group, "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.36", October 2018, <https://trustedcomputinggroup.org/resource/tcg-tap- information-model/>.[SWID-Gen] Labs64, Munich, Germany, "SoftWare IDentification (SWID) Tags Generator (Maven Plugin)", n.d., <https://github.com/Labs64/swid-maven-plugin>. [TCGRoT] Trusted Computing Group, "DRAFT: TCG Roots of Trust Specification", October 2018, <https://trustedcomputinggroup.org/wp-content/uploads/ TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf>.[TPM] ISO/IEC JTC 1 Information technology, "ISO/IEC 11889-1:2015 Information technology --[TPM1.2] Trustedplatform module library -- Part 1: Architecture", August 2015, <https://www.iso.org/standard/66510.html>.Computing Group, "TPM Main Specification Level 2 Version 1.2, Revision 116", March 2011, <https://trustedcomputinggroup.org/resource/tpm-main- specification/>. [TPM2.0] Trusted Computing Group, "Trusted Platform Module Library Specification, Family "2.0", Level 00, Revision 01.59", November 2019, <https://trustedcomputinggroup.org/resource/tpm-library- specification/>. Authors' Addresses Guy Fedorkow (editor) Juniper Networks, Inc. US Email: gfedorkow@juniper.net Eric Voit Cisco Systems, Inc. US Email: evoit@cisco.com Jessica Fitzgerald-McKay National Security Agency US Email: jmfitz2@nsa.gov