rfc9683.original   rfc9683.txt 
RATS Working Group G. C. Fedorkow, Ed. Internet Engineering Task Force (IETF) G. C. Fedorkow, Ed.
Internet-Draft Juniper Networks, Inc. Request for Comments: 9683 Juniper Networks, Inc.
Intended status: Informational E. Voit Category: Informational E. Voit
Expires: 23 September 2022 Cisco ISSN: 2070-1721 Cisco
J. Fitzgerald-McKay J. Fitzgerald-McKay
National Security Agency National Security Agency
22 March 2022 November 2024
TPM-based Network Device Remote Integrity Verification Remote Integrity Verification of Network Devices Containing Trusted
draft-ietf-rats-tpm-based-network-device-attest-14 Platform Modules
Abstract Abstract
This document describes a workflow for remote attestation of the This document describes a workflow for remote attestation of the
integrity of firmware and software installed on network devices that integrity of firmware and software installed on network devices that
contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by contain Trusted Platform Modules (TPMs), as defined by the Trusted
the Trusted Computing Group (TCG)), or equivalent hardware Computing Group (TCG), or equivalent hardware implementations that
implementations that include the protected capabilities, as provided include the protected capabilities, as provided by TPMs.
by TPMs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 23 September 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9683.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology
1.3. Document Organization . . . . . . . . . . . . . . . . . . 5 1.3. Document Organization
1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Goals
1.5. Description of Remote Integrity Verification (RIV) . . . 6 1.5. Description of Remote Integrity Verification (RIV)
1.6. Solution Requirements . . . . . . . . . . . . . . . . . . 8 1.6. Solution Requirements
1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.7. Scope
1.7.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 9 1.7.1. Out of Scope
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9 2. Solution Overview
2.1. RIV Software Configuration Attestation using TPM . . . . 9 2.1. RIV Software Configuration Attestation Using TPM
2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 11 2.1.1. What Does RIV Attest?
2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 13 2.1.2. Notes on PCR Allocations
2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 15 2.2. RIV Keying
2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 16 2.3. RIV Information Flow
2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 18 2.4. RIV Simplifying Assumptions
2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 18 2.4.1. Reference Integrity Manifests (RIMs)
2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 20 2.4.2. Attestation Logs
3. Standards Components . . . . . . . . . . . . . . . . . . . . 20 3. Standards Components
3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 20 3.1. Prerequisites for RIV
3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 20 3.1.1. Unique Device Identity
3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.2. Keys
3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 21 3.1.3. Appraisal Policy for Evidence
3.2. Reference Model for Challenge-Response . . . . . . . . . 21 3.2. Reference Model for Challenge-Response
3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 23 3.2.1. Transport and Encoding
3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24 3.3. Centralized vs. Peer-to-Peer
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 4. Privacy Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations
5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 26 5.1. Keys Used in RIV
5.2. Prevention of Spoofing and Person-in-the-Middle 5.2. Prevention of Spoofing and Person-in-the-Middle Attacks
Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.3. Replay Attacks
5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29 5.4. Owner-Signed Keys
5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 30 5.5. Other Factors for Trustworthy Operation
5.5. Other Factors for Trustworthy Operation . . . . . . . . . 30 6. IANA Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. Conclusion
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. References
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Normative References
9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.2. Informative References
9.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 32 Appendix A. Supporting Materials
9.2. Root of Trust for Measurement . . . . . . . . . . . . . . 34 A.1. Using a TPM for Attestation
9.3. Layering Model for Network Equipment Attester and A.2. Root of Trust for Measurement (RTM)
Verifier . . . . . . . . . . . . . . . . . . . . . . . . 35 A.3. Layering Model for Network Equipment Attester and Verifier
A.4. Implementation Notes
9.4. Implementation Notes . . . . . . . . . . . . . . . . . . 37 Acknowledgements
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses
10.1. Normative References . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
There are many aspects to consider in fielding a trusted computing There are many aspects to consider in fielding a trusted computing
device, from operating systems to applications. Mechanisms to prove device, from operating systems to applications. Mechanisms to prove
that a device installed at a customer's site is authentic (i.e., not that a device installed at a customer's site is authentic (i.e., not
counterfeit) and has been configured with authorized software, all as counterfeit) and has been configured with authorized software, all as
part of a trusted supply chain, are just a few of the many aspects 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 that need to be considered concurrently to have confidence that a
device is truly trustworthy. device is truly trustworthy.
A generic architecture for remote attestation has been defined in A generic architecture for remote attestation has been defined in
[I-D.ietf-rats-architecture]. Additionally, use cases for remotely [RFC9334]. Additionally, use cases for remotely attesting networking
attesting networking devices are discussed within Section 6 of devices are discussed within Section 5 of [RATS-USECASES]. However,
[I-D.richardson-rats-usecases]. However, these documents do not these documents do not provide sufficient guidance for network
provide sufficient guidance for network equipment vendors and equipment vendors and operators to design, build, and deploy
operators to design, build, and deploy interoperable devices. interoperable devices.
The intent of this document is to provide such guidance. It does The intent of this document is to provide such guidance. It does
this by outlining the Remote Integrity Verification (RIV) problem, this by outlining the Remote Integrity Verification (RIV) problem and
and then identifies elements that are necessary to get the complete, then by identifying the necessary elements to get the complete,
scalable attestation procedure working with commercial networking scalable attestation procedure working with commercial networking
products such as routers, switches and firewalls. An underlying products such as routers, switches, and firewalls. An underlying
assumption will be the availability within the device of a Trusted assumption is the availability within the device of a cryptoprocessor
Platform Module [TPM1.2], [TPM2.0] compatible cryptoprocessor to that is compatible with the Trusted Platform Module specifications
enable the trustworthy remote assessment of the device's software and [TPM-1.2] [TPM-2.0] to enable the trustworthy, remote assessment of
hardware. the device's software and hardware.
1.1. Requirements notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Terminology 1.2. Terminology
A number of terms are reused from [I-D.ietf-rats-architecture]. A number of terms are reused from [RFC9334]. These include Appraisal
These include: Appraisal Policy for Evidence, Attestation Result, Policy for Evidence, Attestation Result, Attester, Evidence,
Attester, Evidence, Reference Value, Relying Party, Verifier, and Reference Value, Relying Party, Verifier, and Verifier Owner.
Verifier Owner.
Additionally, this document defines the following term: Additionally, this document defines the following term:
Attestation: the process of generating, conveying and appraising Attestation: The process of generating, conveying, and appraising
claims, backed by evidence, about device trustworthiness claims, backed by evidence, about device trustworthiness
characteristics, including supply chain trust, identity, device characteristics, including supply chain trust, identity, device
provenance, software configuration, device composition, compliance to provenance, software configuration, device composition, compliance
test suites, functional and assurance evaluations, etc. to test suites, functional and assurance evaluations, etc.
The goal of attestation is simply to assure an administrator or The goal of attestation is simply to assure an administrator or
auditor that the device configuration and software that was launched auditor that the device's configuration and software were authentic
when the device was last started is authentic and untampered-with. and unmodified when the device started. The determination of
The determination of software authenticity is not prescribed in this software authenticity is not prescribed in this document, but it's
document, but it's typically taken to mean a software image generated typically taken to mean a software image generated by an authority
by an authority trusted by the administrator, such as the device trusted by the administrator, such as the device manufacturer.
manufacturer.
Within the Trusted Computing Group (TCG) context, the scope of Within the context of the Trusted Computing Group (TCG), the scope of
attestation is typically narrowed to describe the process by which an attestation is typically narrowed to describe the process by which an
independent Verifier can obtain cryptographic proof as to the independent Verifier can obtain cryptographic proof as to the
identity of the device in question, and evidence of the integrity of identity of the device in question, evidence of the integrity of the
software loaded on that device when it started up, and then verify device's software that was loaded upon startup, and verification that
that what's there matches the intended configuration. For network the current configuration matches the intended configuration. For
equipment, a Verifier capability can be embedded in a Network network equipment, a Verifier capability can be embedded in a Network
Management Station (NMS), a posture collection server, or other Management Station, a posture collection server, or other network
network analytics tool (such as a software asset management solution, analytics tool (such as a software asset management solution, or a
or a threat detection and mitigation tool, etc.). While informally threat detection and mitigation tool, etc.). This document focuses
referred to as attestation, this document focuses on a specific on a specific subset of attestation tasks, defined here as Remote
subset of attestation tasks, defined here as Remote Integrity Integrity Verification (RIV), and informally referred to as
Verification (RIV). RIV in this document takes a network-equipment- attestation. RIV in this document takes a network-equipment-centric
centric perspective that includes a set of protocols and procedures perspective that includes a set of protocols and procedures for
for determining whether a particular device was launched with determining whether a particular device was launched with authentic
authentic software, starting from Roots of Trust. While there are software, starting from Roots of Trust. While there are many ways to
many ways to accomplish attestation, RIV sets out a specific set of accomplish attestation, RIV sets out a specific set of protocols and
protocols and tools that work in environments commonly found in tools that work in environments commonly found in network equipment.
network equipment. RIV does not cover other device characteristics RIV does not cover other device characteristics that could be
that could be attested (e.g., geographic location, connectivity; see attested (e.g., geographic location or connectivity; see
[I-D.richardson-rats-usecases]), although it does provide evidence of [RATS-USECASES]), although it does provide evidence of a secure
a secure infrastructure to increase the level of trust in other infrastructure to increase the level of trust in other device
device characteristics attested by other means (e.g., by Entity characteristics attested by other means (e.g., by Entity Attestation
Attestation Tokens [I-D.ietf-rats-eat]). Tokens [RATS-EAT]).
In line with [I-D.ietf-rats-architecture] definitions, this document In line with definitions found in [RFC9334], this document uses the
uses the term Endorser to refer to the role that signs identity and term Endorser to refer to the role that signs identity and
attestation certificates used by the Attester, while Reference Values attestation certificates used by the Attester, while Reference Values
are signed by a Reference Value Provider. Typically, the are signed by a Reference Value Provider. Typically, the
manufacturer of a network device would be accepted as both the manufacturer of a network device would be accepted as both the
Endorser and Reference Value Provider, although the choice is Endorser and Reference Value Provider, although the choice is
ultimately up to the Verifier Owner. ultimately up to the Verifier Owner.
1.3. Document Organization 1.3. Document Organization
The remainder of this document is organized into several sections: The remainder of this document is organized into several sections:
* The remainder of this section covers goals and requirements, plus * The remainder of this section covers goals and requirements, plus
a top-level description of RIV. a top-level description of RIV.
* The Solution Overview section outlines how Remote Integrity * The Solution Overview section (Section 2) outlines how RIV works.
Verification works.
* The Standards Components section links components of RIV to * The Standards Components section (Section 3) links components of
normative standards. RIV to normative standards.
* Privacy and Security shows how specific features of RIV contribute * The Privacy and Security Considerations sections (Sections 4 and
to the trustworthiness of the Attestation Result. 5) shows how specific features of RIV contribute to the
trustworthiness of the Attestation Result.
* Supporting material is in an appendix at the end. * Supporting material is in an appendix (Appendix A).
1.4. Goals 1.4. Goals
Network operators benefit from a trustworthy attestation mechanism Network operators benefit from a trustworthy attestation mechanism
that provides assurance that their network comprises authentic that provides assurance that their network comprises authentic
equipment, and has loaded software free of known vulnerabilities and equipment and has loaded software free of known vulnerabilities and
unauthorized tampering. In line with the overall goal of assuring unauthorized tampering. In line with the overall goal of assuring
integrity, attestation can be used to assist in asset management, integrity, attestation can be used to assist in asset management,
vulnerability and compliance assessment, plus configuration vulnerability and compliance assessment, plus configuration
management. management.
The RIV attestation workflow outlined in this document is intended to The RIV attestation workflow outlined in this document is intended to
meet the following high-level goals: meet the following high-level goals:
* Provable Device Identity - This specification requires that an * Provable Device Identity - This specification requires that an
Attester (i.e., the attesting device) includes a cryptographic Attester (i.e., the attesting device) includes a cryptographic
identifier unique to each device. Effectively this means that the identifier unique to each device. Effectively, this means that
device's TPM must be so provisioned during the manufacturing the device's TPM must be provisioned with this during the
cycle. manufacturing cycle.
* Software Inventory - A key goal is to identify the software * Software Inventory - Key goals are to identify the software
release(s) installed on the Attester, and to provide evidence that release(s) installed on the Attester and to provide evidence that
the software stored within hasn't been altered without the software stored within hasn't been altered without
authorization. authorization.
* Verifiability - Verification of software and configuration of the * Verifiability - Verification of the device's software and
device shows that the software that the administrator authorized configuration shows that the software that the administrator
for use was actually launched. authorized for use was actually launched.
In addition, RIV is designed to operate either in a centralized In addition, RIV is designed to operate either in a centralized
environment, such as with a central authority that manages and environment, such as with a central authority that manages and
configures a number of network devices, or 'peer-to-peer', where configures a number of network devices, or "peer-to-peer", where
network devices independently verify one another to establish a trust network devices independently verify one another to establish a trust
relationship. (See Section 3.3 below) relationship. (See Section 3.3.)
1.5. Description of Remote Integrity Verification (RIV) 1.5. Description of Remote Integrity Verification (RIV)
Attestation requires two interlocking mechanisms between the Attester Attestation requires two interlocking mechanisms between the Attester
network device and the Verifier: network device and the Verifier:
* Device Identity, the mechanism providing trusted identity, can * Device Identity is the mechanism that provides trusted identity,
reassure network managers that the specific devices they ordered which can reassure network managers that the specific devices they
from authorized manufacturers for attachment to their network are ordered from authorized manufacturers for attachment to their
those that were installed, and that they continue to be present in network are those that were installed and that they continue to be
their network. As part of the mechanism for Device Identity, present in their network. As part of the mechanism for Device
cryptographic proof of the identity of the manufacturer is also Identity, cryptographic proof of the manufacturer's identity is
provided. also provided.
* Software Measurement is the mechanism that reports the state of * Software Measurement is the mechanism that reports the state of
mutable software components on the device, and can assure mutable software components on the device and that can assure
administrators that they have known, authentic software configured administrators that they have known, authentic software configured
to run in their network. to run in their network.
Using these two interlocking mechanisms, RIV is a component in a By using these two interlocking mechanisms, RIV, which is a component
chain of procedures that can assure a network operator that the in a chain of procedures, can assure a network operator that the
equipment in their network can be reliably identified, and that equipment in their network can be reliably identified and that
authentic software of a known version is installed on each device. authentic software of a known version is installed on each device.
Equipment in the network includes devices that make up the network Equipment in the network includes devices that make up the network
itself, such as routers, switches and firewalls. itself, such as routers, switches, and firewalls.
Software used to boot a device can be identified by a chain of Software used to boot a device can be identified by a chain of
measurements, anchored at the start by a Root of Trust for measurements, anchored at the start by a Root of Trust for
Measurement (see Section 9.2), each measuring the next stage and Measurement (RTM) (see Appendix A.2). An attestation function
recording the result in tamper-resistant storage, normally ending embedded in each stage, verified by the previous stage, measures the
when the system software is fully loaded. A measurement signifies next stage and records the result in tamper-resistant storage. A
the identity, integrity and version of each software component measurement signifies the identity, integrity, and version of each
registered with an Attester's TPM [TPM1.2], [TPM2.0], so that a software component registered with an Attester's TPM [TPM-1.2]
subsequent verification stage can determine if the software installed [TPM-2.0] so that a subsequent verification stage can determine if
is authentic, up-to-date, and free of tampering. the software installed is authentic, up-to-date, and free of
tampering.
RIV includes several major processes, split between the Attester and RIV includes several major processes, which are split between the
Verifier: Attester and Verifier:
1. Generation of Evidence is the process whereby an Attester 1. Generation of Evidence is the process whereby an Attester
generates cryptographic proof (Evidence) of claims about device generates cryptographic proof (Evidence) of claims about device
properties. In particular, the device identity and its software properties. In particular, the device identity and its software
configuration are both of critical importance. configuration are both of critical importance.
2. Device Identification refers to the mechanism assuring the 2. Device Identification refers to the mechanism assuring the
Relying Party (ultimately, a network administrator) of the Relying Party (ultimately, a network administrator) of the
identity of devices that make up their network, and that their identities of devices, and the identities of their manufacturers,
manufacturers are known. that make up their network.
3. Conveyance of Evidence reliably transports the collected Evidence 3. Conveyance of Evidence reliably transports the collected Evidence
from Attester to a Verifier to allow a management station to from the Attester to a Verifier to allow a management station to
perform a meaningful appraisal in Step 4. The transport is perform a meaningful appraisal in Step 4. The transport is
typically carried out via a management network. While not typically carried out via a management network. Although not
required for reliable attestation, an encrypted channel may be required for reliable attestation, an encrypted channel may be
used to provide integrity, authenticity, or confidentiality once used to provide integrity, authenticity, or confidentiality once
attestation is complete. It should be noted that critical attestation is complete. It should be noted that critical
attestation evidence from the TPM is signed by a key known only attestation evidence from the TPM is signed by a key known only
to TPM, and is not dependent on encyption carried out as part of to TPM, and is not dependent on encryption carried out as part of
a reliable transport. a reliable transport.
4. Finally, Appraisal of Evidence occurs. This is the process of 4. Finally, appraisal of evidence occurs. This is the process of
verifying the Evidence received by a Verifier from the Attester, verifying the Evidence received by a Verifier from the Attester
and using an Appraisal Policy to develop an Attestation Result, and using an Appraisal Policy to develop an Attestation Result,
used to inform decision-making. In practice, this means which is used to inform decision-making. In practice, this means
comparing the Attester's measurements reported as Evidence with comparing the Attester's measurements reported as Evidence with
the device configuration expected by the Verifier. Subsequently, the device configuration expected by the Verifier. Subsequently,
the Appraisal Policy for Evidence might match Evidence found the Appraisal Policy for Evidence might match Evidence found
against Reference Values (aka Golden Measurements), which against Reference Values (aka Golden Measurements), which
represent the intended configured state of the connected device. represent the intended configured state of the connected device.
All implementations supporting this RIV specification require the All implementations supporting this RIV specification require the
support of the following three technologies: support of the following three technologies:
1. Identity: Device identity in RIV is based on IEEE 802.1AR Device 1. Identity: Device identity in RIV is based on Device Identity
Identity (DevID) [IEEE-802-1AR], coupled with careful supply- (DevID) defined by IEEE Std 802.1AR [IEEE-802-1AR], coupled with
chain management by the manufacturer. The Initial DevID (IDevID) careful supply-chain management by the manufacturer. The Initial
certificate contains a statement by the manufacturer that DevID (IDevID) certificate contains a statement by the
establishes the identity of the device as it left the factory. manufacturer that establishes the identity of the device as it
Some applications with a more-complex post-manufacture supply left the factory. Some applications with a more complex post-
chain (e.g., Value Added Resellers), or with different privacy manufacture supply chain (e.g., value added resellers), or with
concerns, may want to use alternative mechanisms for platform different privacy concerns, may want to use alternative
authentication (for example, TCG Platform Certificates mechanisms for platform authentication (for example, TCG Platform
[Platform-Certificates], or post-manufacture installation of Certificates [PLATFORM-CERTS] or post-manufacture installation of
Local Device ID (LDevID)). Local DevID (LDevID)).
2. Platform Attestation provides evidence of configuration of 2. Platform attestation provides evidence of configuration of
software elements present in the device. This form of software elements present in the device. This form of
attestation can be implemented with TPM Platform Configuration attestation can be implemented with TPM Platform Configuration
Registers (PCRs), Quote and Log mechanisms, which provide Registers (PCRs) and Quote and Log mechanisms, which provide
cryptographically authenticated evidence to report what software cryptographically authenticated evidence to report what software
was started on the device through the boot cycle. Successful was started on the device through the boot cycle. Successful
attestation requires an unbroken chain from a boot-time root of attestation requires an unbroken chain from a boot-time Root of
trust through all layers of software needed to bring the device Trust through all layers of software needed to bring the device
to an operational state, in which each stage computes the hash of to an operational state, in which each stage computes the hash of
components of the next stage, then updates the attestation log components of the next stage, then updates the attestation log
and the TPM. The TPM can then report the hashes of all the and the TPM. The TPM can then report the hashes of all the
measured hashes as signed evidence called a Quote (see measured hashes as signed evidence called a Quote (see
Section 9.1 for an overview of TPM operation, or [TPM1.2] and Appendix A.1 for an overview of TPM operation or [TPM-1.2] and
[TPM2.0] for many more details). [TPM-2.0] for many more details).
3. Signed Reference Values (aka Reference Integrity Measurements) 3. Signed Reference Values (aka reference integrity measurements)
must be conveyed from the Reference Value Provider (the entity must be conveyed from the Reference Value Provider (the entity
accepted as the software authority, often the manufacturer of the accepted as the software authority, often the manufacturer of the
network device) to the Verifier. network device) to the Verifier.
1.6. Solution Requirements 1.6. Solution Requirements
Remote Integrity Verification must address the "Lying Endpoint" RIV must address the "Lying Endpoint" problem, in which malicious
problem, in which malicious software on an endpoint may subvert the software on an endpoint may subvert the intended function and also
intended function, and also prevent the endpoint from reporting its prevent the endpoint from reporting its compromised status. (See
compromised status. (See Section 5 for further Security Section 5 for further Security Considerations.)
Considerations.)
RIV attestation is designed to be simple to deploy at scale. RIV 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 should work "out of the box" as far as possible, that is, with the
fewest possible provisioning steps or configuration databases needed fewest possible provisioning steps or configuration databases needed
at the end-user's site. Network equipment is often required to at the end user's site. Network equipment is often required to
"self-configure", to reliably reach out without manual intervention "self-configure", to reliably reach out without manual intervention
to prove its identity and operating posture, then download its own to prove its identity and operating posture, then download its own
configuration, a process which precludes pre-installation configuration, a process which precludes pre-installation
configuration. See [RFC8572] for an example of Secure Zero Touch configuration. See [RFC8572] for an example of Secure Zero Touch
Provisioning. Provisioning (SZTP).
1.7. Scope 1.7. Scope
The need for assurance of software integrity, addressed by Remote The need for assurance of software integrity, addressed by Remote
Attestation, is a very general problem that could apply to most Attestation, is a very general problem that could apply to most
network-connected computing devices. However, this document includes network-connected computing devices. However, this document includes
several assumptions that limit the scope to network equipment (e.g., several assumptions that limit the scope to network equipment (e.g.,
routers, switches and firewalls): routers, switches, and firewalls):
* This solution is for use in non-privacy-preserving applications * This solution is for use in non-privacy-preserving applications
(for example, networking, Industrial IoT), avoiding the need for a (for example, networking or industrial Internet of Things (IoT)
Privacy Certificate Authority (also called an Attestation CA) for applications), which avoids the need for a Privacy Certification
attestation keys [AK-Enrollment] or TCG Platform Certificates Authority (also called an Attestation CA) for Attestation Keys
[Platform-Certificates]. (AKs) [AIK-ENROLL] or TCG Platform Certificates [PLATFORM-CERTS].
* This document assumes network protocols that are common in network * This document assumes network protocols that are common in network
equipment such as YANG [RFC7950] and NETCONF [RFC6241], but not equipment such as YANG [RFC7950] and Network Configuration
generally used in other applications. Protocol (NETCONF) [RFC6241], but not generally used in other
applications.
* The approach outlined in this document mandates the use of a TPM * The approach outlined in this document mandates the use of a TPM
[TPM1.2], [TPM2.0], or a compatible cryptoprocessor. [TPM-1.2] [TPM-2.0] or a compatible cryptoprocessor.
1.7.1. Out of Scope 1.7.1. Out of Scope
* Run-Time Attestation: The Linux Integrity Measurement Architecture Run-Time Attestation: The Linux Integrity Measurement Architecture
[IMA] attests each process launched after a device is started (and [IMA] attests each process launched after a device is started (and
is in scope for RIV in general), but continuous run-time is in scope for RIV in general), but continuous run-time
attestation of Linux or other multi-threaded operating system attestation of Linux or other multi-threaded operating system
processes after the OS has started considerably expands the scope processes after the OS has started considerably expands the scope
of the problem. Many researchers are working on that problem, but of the problem. Many researchers are working on that problem, but
this document defers the problem of continuous, in-memory run-time this document defers the problem of continuous, in-memory run-time
attestation. attestation.
* Multi-Vendor Embedded Systems: Additional coordination would be Multi-Vendor Embedded Systems: Additional coordination would be
needed for devices that themselves comprise hardware and software needed for devices that themselves comprise hardware and software
from multiple vendors, integrated by the end user. Although out from multiple vendors and are integrated by the end user.
of scope for this document, these issues are accommodated in Although out of scope for this document, these issues are
[I-D.ietf-rats-architecture]. accommodated in [RFC9334].
* Processor Sleep Modes: Network equipment typically does not Processor Sleep Modes: Network equipment typically does not "sleep",
"sleep", so sleep and hibernate modes are not considered. so sleep and hibernate modes are not considered. Although out of
Although out of scope for RIV in this document, Trusted Computing scope for RIV in this document, TCG specifications do encompass
Group specifications do encompass sleep and hibernate states, sleep and hibernate states, which could be incorporated into
which could be incorporated into remote attestation for network remote attestation for network equipment in the future, given a
equipment in the future, given a compelling need. compelling need.
* Virtualization and Containerization: In a non-virtualized system, Virtualization and Containerization: In a non-virtualized system,
the host OS is responsible for measuring each User Space file or the host OS is responsible for measuring each user-space file or
process throughout the operational lifetime of the system. For process throughout the operational lifetime of the system. For
virtualized systems, the host OS must verify the hypervisor, but virtualized systems, the host OS must verify the hypervisor, but
then the hypervisor must manage its own chain of trust through the then the hypervisor must manage its own chain of trust through the
virtual machine. Virtualization and containerization technologies virtual machine. Virtualization and containerization technologies
are increasingly used in network equipment, but are not considered are increasingly used in network equipment, but are not considered
in this document. in this document.
2. Solution Overview 2. Solution Overview
2.1. RIV Software Configuration Attestation using TPM 2.1. RIV Software Configuration Attestation Using TPM
RIV Attestation is a process which can be used to determine the RIV Attestation is a process that can be used to determine the
identity of software running on a specifically-identified device. identity of software running on a specifically identified device.
The Remote Attestation steps of Section 1.5 are broken into two The Remote Attestation steps of Section 1.5 are split into two phases
phases, shown in Figure 1: as shown in Figure 1:
* During system startup, or boot phase, each distinct software * During system startup, or Boot Phase, each distinct software
object is "measured" by the Attester. The object's identity, hash object is "measured" by the Attester. The object's identity, hash
(i.e., cryptographic digest) and version information are recorded (i.e., cryptographic digest), and version information are recorded
in a log. Hashes are also extended into the TPM (see Section 9.1 in a log. Hashes are also extended into the TPM (see Appendix A.1
for more on 'extending hashes'), in a way that can be used to for more on extending hashes) in a way that can be used to
validate the log entries. The measurement process generally validate the log entries. The measurement process generally
follows the layered chain-of-trust model used in Measured Boot, follows the layered chain-of-trust model used in Measured Boot,
where each stage of the system measures the next one, and extends where each stage of the system measures the next one, and extends
its measurement into the TPM, before launching it. See its measurement into the TPM, before launching it. See
[I-D.ietf-rats-architecture], section "Layered Attestation Section 3.2 of [RFC9334], "Layered Attestation Environments", for
Environments," for an architectural definition of this model. an architectural definition of this model.
* Once the device is running and has operational network * Once the device is running and has operational network
connectivity, verification can take place. A separate Verifier, connectivity, verification can take place. A separate Verifier,
running in its own trusted environment, will interrogate the running in its own trusted environment, will interrogate the
network device to retrieve the logs and a copy of the digests network device to retrieve the logs and a copy of the digests
collected by hashing each software object, signed by an collected by hashing each software object, signed by an
attestation private key secured by, but never released by, the attestation private key secured by, but never released by, the
TPM. The YANG model described in [I-D.ietf-rats-yang-tpm-charra] TPM. The YANG model described in [RFC9684] facilitates this
facilitates this operation. operation.
The result is that the Verifier can verify the device's identity by The result is that the Verifier can verify the device's identity by
checking the subject[RFC5280] and signature of the certificate checking the subject [RFC5280] and signature of the certificate
containing the TPM's attestation public key, and can validate the containing the TPM's attestation public key. The Verifier can then
software that was launched by verifying the correctness of the logs verify the log's correctness by accumulating all the hashes in the
by comparing with the signed digests from the TPM, and comparing log and comparing that to the signed digests from the TPM. From
digests in the log with Reference Values. there, the Verifier can validate the launched software by comparing
the digests in the log with Reference Values.
It should be noted that attestation and identity are inextricably It should be noted that attestation and identity are inextricably
linked; signed Evidence that a particular version of software was linked; signed Evidence that a particular version of software was
loaded is of little value without cryptographic proof of the identity loaded is of little value without cryptographic proof of the identity
of the Attester producing the Evidence. of the Attester producing the Evidence.
+-------------------------------------------------------+ +-------------------------------------------------------+
| +---------+ +--------+ +--------+ +---------+ | | +---------+ +--------+ +--------+ +---------+ |
| |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | | | |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |
| +---------+ +--------+ +--------+ +---------+ | | +---------+ +--------+ +--------+ +---------+ |
skipping to change at page 11, line 29 skipping to change at line 485
| |
| Verification Phase | Verification Phase
| +-----------+ | +-----------+
+--->| Verifier | +--->| Verifier |
+-----------+ +-----------+
Reset---------------flow-of-time-during-boot...---------> Reset---------------flow-of-time-during-boot...--------->
Figure 1: Layered RIV Attestation Model Figure 1: Layered RIV Attestation Model
In the Boot phase, measurements are "extended", or hashed, into the In the Boot Phase, measurements are "extended", or hashed, into the
TPM as processes start, with the result that the TPM ends up TPM as processes start, which result in the TPM containing hashes of
containing hashes of all the measured hashes. Later, once the system all the measured hashes. Later, once the system is operational,
is operational, during the Verification phase, signed digests are signed digests are retrieved from the TPM during the Verification
retrieved from the TPM for off-box analysis. Phase for off-box analysis.
2.1.1. What Does RIV Attest? 2.1.1. What Does RIV Attest?
TPM attestation is focused on Platform Configuration Registers TPM attestation is focused on PCRs, but those registers are only
(PCRs), but those registers are only vehicles for certifying vehicles for certifying accompanying Evidence conveyed in log
accompanying Evidence, conveyed in log entries. It is the hashes in entries. It is the hashes in log entries that are extended into
log entries that are extended into PCRs, where the final PCR values PCRs, where the final PCR values can be retrieved in the form of a
can be retrieved in the form of a structure called a Quote, signed by structure called a Quote, which is signed by an AK known only to the
an Attestation key known only to the TPM. The use of multiple PCRs TPM. The use of multiple PCRs serves only to provide some
serves only to provide some independence between different classes of independence between different classes of object so that one class of
object, so that one class of objects can be updated without changing objects can be updated without changing the extended hash for other
the extended hash for other classes. Although PCRs can be used for classes. Although PCRs can be used for any purpose, this section
any purpose, this section outlines the objects within the scope of outlines the objects within the scope of this document that may be
this document which may be extended into the TPM. extended into the TPM.
In general, assignment of measurements to PCRs is a policy choice In general, assignment of measurements to PCRs is a policy choice
made by the device manufacturer, selected to independently attest made by the device manufacturer, selected to independently attest
three classes of object: three classes of object:
* Code, (i.e., instructions) to be executed by a CPU. Code: Instructions to be executed by a CPU.
* Configuration - Many devices offer numerous options controlled by Configuration: Many devices offer numerous options controlled by
non-volatile configuration variables which can impact the device's non-volatile configuration variables that can impact the device's
security posture. These settings may have vendor defaults, but security posture. These settings may have vendor defaults, but
often can be changed by administrators, who may want to verify via often can be changed by administrators, who may want to verify via
attestation that the operational state of the settings match their attestation that the operational state of the settings match their
intended state. intended state.
* Credentials - Administrators may wish to verify via attestation Credentials: Administrators may wish to verify via attestation that
that public keys and credentials outside the Root of Trust have public keys and credentials outside the Root of Trust have not
not been subject to unauthorized tampering. (By definition, keys been subject to unauthorized tampering. (By definition, keys
protecting the root of trust can't be verified independently.) protecting the Root of Trust can't be verified independently.)
The TCG PC Client Platform Firmware Profile Specification The "TCG PC Client Specific Platform Firmware Profile Specification"
[PC-Client-BIOS-TPM-2.0] gives considerable detail on what is to be [PC-CLIENT-BIOS-TPM-2.0] details what is to be measured during the
measured during the boot phase of platform startup using a UEFI BIOS Boot Phase of platform startup using a Unified Extensible Firmware
(www.uefi.org), but the goal is simply to measure every bit of code Interface (UEFI) BIOS (<www.uefi.org>), but the goal is simply to
executed in the process of starting the device, along with any measure every bit of code executed in the process of starting the
configuration information related to security posture, leaving no gap device, along with any configuration information related to security
for unmeasured code to remain undetected, potentially subverting the posture, leaving no gap for unmeasured code to remain undetected and
chain. potentially subverting the chain.
For devices using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] and For devices using a UEFI BIOS, [PC-CLIENT-BIOS-TPM-2.0] and
[PC-Client-EFI-TPM-1.2] give detailed normative requirements for PCR [PC-CLIENT-EFI-TPM-1.2] give detailed normative requirements for PCR
usage. For other platform architectures, where TCG normative usage. For other platform architectures, where TCG normative
requirements currently do not exist, the table in Figure 2 gives non- requirements currently do not exist, Table 1 gives non-normative
normative guidance for PCR assignment that generalizes the specific guidance for PCR assignment that generalizes the specific details of
details of [PC-Client-BIOS-TPM-2.0]. [PC-CLIENT-BIOS-TPM-2.0].
By convention, most PCRs are assigned in pairs, which the even- By convention, most PCRs are assigned in pairs, with the even-
numbered PCR used to measure executable code, and the odd-numbered numbered PCR used to measure executable code and the odd-numbered PCR
PCR used to measure whatever data and configuration are associated used to measure whatever data and configuration are associated with
with that code. It is important to note that each PCR may contain that code. It is important to note that each PCR may contain results
results from dozens (or even thousands) of individual measurements. from dozens (or even thousands) of individual measurements.
+------------------------------------------------------------------+ +===========================================+======================+
| | Assigned PCR # | | | Assigned PCR # |
| Function | Code | Configuration| +===========================================+======+===============+
-------------------------------------------------------------------- | Function | Code | Configuration |
| Firmware Static Root of Trust, (i.e., | 0 | 1 | +===========================================+======+===============+
| initial boot firmware and drivers) | | | | Firmware Static Root of Trust (i.e., | 0 | 1 |
-------------------------------------------------------------------- | initial boot firmware and drivers) | | |
| Drivers and initialization for optional | 2 | 3 | +-------------------------------------------+------+---------------+
| or add-in devices | | | | Drivers and initialization for optional | 2 | 3 |
-------------------------------------------------------------------- | or add-in devices | | |
| OS Loader code and configuration, (i.e., | 4 | 5 | +-------------------------------------------+------+---------------+
| the code launched by firmware) to load an | | | | OS loader code and configuration (i.e., | 4 | 5 |
| operating system kernel. These PCRs record | | | | the code launched by firmware) to load an | | |
| each boot attempt, and an identifier for | | | | operating system kernel. These PCRs | | |
| where the loader was found | | | | record each boot attempt, and an | | |
-------------------------------------------------------------------- | identifier for where the loader was found | | |
| Vendor Specific Measurements during boot | 6 | 6 | +-------------------------------------------+------+---------------+
-------------------------------------------------------------------- | Vendor-specific measurements during boot | 6 | 6 |
| Secure Boot Policy. This PCR records keys | | 7 | +-------------------------------------------+------+---------------+
| and configuration used to validate the OS | | | | Secure Boot Policy. This PCR records | | 7 |
| loader | | | | keys and configuration used to validate | | |
-------------------------------------------------------------------- | the OS loader | | |
| Measurements made by the OS Loader | 8 | 9 | +-------------------------------------------+------+---------------+
| (e.g. GRUB2 for Linux) | | | | Measurements made by the OS loader (e.g., | 8 | 9 |
-------------------------------------------------------------------- | GRUB2 for Linux) | | |
| Measurements made by OS (e.g., Linux IMA) | 10 | 10 | +-------------------------------------------+------+---------------+
+------------------------------------------------------------------+ | Measurements made by OS (e.g., Linux IMA) | 10 | 10 |
+-------------------------------------------+------+---------------+
Figure 2: Attested Objects Table 1: Attested Objects
2.1.2. Notes on PCR Allocations 2.1.2. Notes on PCR Allocations
It is important to recognize that PCR[0] is critical. The first It is important to recognize that PCR[0] is critical. The first
measurement into PCR[0] is taken by the Root of Trust for measurement into PCR[0] is taken by the Root of Trust for
Measurement, code which, by definition, cannot be verified by Measurement, which is code that, by definition, cannot be verified by
measurement. This measurement establishes the chain of trust for all measurement. This measurement establishes the chain of trust for all
subsequent measurements. If the PCR[0] measurement cannot be subsequent measurements. If the PCR[0] measurement cannot be
trusted, the validity of the entire chain is put into question. trusted, the validity of the entire chain is called into question.
Distinctions Between PCR[0], PCR[2], PCR[4] and PCR[8] are summarized Distinctions between PCR[0], PCR[2], PCR[4], and PCR[8] are
below: summarized below:
* PCR[0] typically represents a consistent view of rarely-changed PCR[0] typically represents a consistent view of rarely changed boot
Host Platform boot components, allowing Attestation policies to be components of the host platform, which allows Attestation policies
defined using the less changeable components of the transitive to be defined using the less changeable components of the
trust chain. This PCR typically provides a consistent view of the transitive trust chain. This PCR typically provides a consistent
platform regardless of user selected options. view of the platform regardless of user-selected options.
* PCR[2] is intended to represent a "user configurable" environment PCR[2] is intended to represent a "user-configurable" environment
where the user has the ability to alter the components that are where the user has the ability to alter the components that are
measured into PCR[2]. This is typically done by adding adapter measured into PCR[2]. This is typically done by adding adapter
cards, etc., into user-accessible PCI or other slots. In UEFI cards, etc., into user-accessible Peripheral Component
systems these devices may be configured by Option ROMs measured Interconnect (PCI) or other slots. In UEFI systems, these devices
into PCR[2] and executed by the UEFI BIOS. may be configured by Option ROMs measured into PCR[2] and executed
by the UEFI BIOS.
* PCR[4] is intended to represent the software that manages the PCR[4] is intended to represent the software that manages the
transition between the platform's Pre-Operating System start and transition between the platform's pre-OS start and the state of a
the state of a system with the Operating System present. This system with the OS present. This PCR, along with PCR[5],
PCR, along with PCR[5], identifies the initial operating system identifies the initial OS loader (e.g., GRUB for Linux).
loader (e.g., GRUB for Linux).
* PCR[8] is used by the OS loader (e.g. GRUB) to record PCR[8] is used by the OS loader (e.g., GRUB) to record measurements
measurements of the various components of the operating system. of the various components of the operating system.
Although the TCG PC Client document specifies the use of the first Although [PC-CLIENT-BIOS-TPM-2.0] specifies the use of the first
eight PCRs very carefully to ensure interoperability among multiple eight PCRs very carefully to ensure interoperability among multiple
UEFI BIOS vendors, it should be noted that embedded software vendors UEFI BIOS vendors, it should be noted that embedded software vendors
may have considerably more flexibility. Verifiers typically need to may have considerably more flexibility. Verifiers typically need to
know which log entries are consequential and which are not (possibly know which log entries are consequential and which are not (possibly
controlled by local policies) but the Verifier may not need to know controlled by local policies), but the Verifier may not need to know
what each log entry means or why it was assigned to a particular PCR. 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 Designers must recognize that some PCRs may cover log entries that a
particular Verifier considers critical and other log entries that are particular Verifier considers critical and other log entries that are
not considered important, so differing PCR values may not on their not considered important, so differing PCR values may not on their
own constitute a check for authenticity. For example, in a UEFI own constitute a check for authenticity. For example, in a UEFI
system, some administrators may consider booting an image from a system, some administrators may consider booting an image from a
removable drive, something recorded in a PCR, to be a security removable drive, something recorded in a PCR, to be a security
violation, while others might consider that operation an authorized violation, while others might consider that operation to be an
recovery procedure. authorized recovery procedure.
Designers may allocate particular events to specific PCRs in order to Designers may allocate particular events to specific PCRs in order to
achieve a particular objective with local attestation, (e.g., achieve a particular objective with local attestation (e.g., allowing
allowing a procedure to execute, or releasing a particular decryption a procedure to execute, or releasing a particular decryption key,
key, only if a given PCR is in a given state). It may also be only if a given PCR is in a given state). It may also be important
important to designers to consider whether streaming notification of to designers to consider whether streaming notification of PCR
PCR updates is required (see updates is required (see [RATS-NET-DEV-SUB]). Specific log entries
[I-D.birkholz-rats-network-device-subscription]). Specific log can only be validated if the Verifier receives every log entry
entries can only be validated if the Verifier receives every log affecting the relevant PCR, so (for example) a designer might want to
entry affecting the relevant PCR, so (for example) a designer might separate rare, high-value events, such as configuration changes, from
want to separate rare, high-value events such as configuration high-volume, routine measurements such as IMA logs [IMA].
changes, from high-volume, routine measurements such as IMA [IMA]
logs.
2.2. RIV Keying 2.2. RIV Keying
RIV attestation relies on two credentials: RIV attestation relies on two credentials:
* An identity key pair and matching certificate is required to * An identity key pair and matching certificate is required to
certify the identity of the Attester itself. RIV specifies the certify the identity of the Attester itself. RIV specifies the
use of an IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR], use of an IEEE 802.1AR DevID [IEEE-802-1AR] that is signed by the
signed by the device manufacturer, containing the device serial device manufacturer and contains the device serial number. This
number. This requirement goes slightly beyond 802.1AR; see requirement goes slightly beyond 802.1AR; see Section 2.4 for
Section 2.4 for notes. notes.
* An Attestation key pair and matching certificate is required to * An Attestation key pair and matching certificate is required to
sign the Quote generated by the TPM to report evidence of software sign the Quote generated by the TPM to report evidence of software
configuration. configuration.
In a TPM application, both the Attestation private key and the DevID In a TPM application, both the Attestation private key and the DevID
private key MUST be protected by the TPM. Depending on other TPM private key MUST be protected by the TPM. Depending on other TPM
configuration procedures, the two keys are likely to be different; configuration procedures, the two keys are likely to be different;
some of the considerations are outlined in TCG "TPM 2.0 Keys for some of the considerations are outlined in the "TPM 2.0 Keys for
Device Identity and Attestation" [Platform-DevID-TPM-2.0]. Device Identity and Attestation" document [PLATFORM-DEVID-TPM-2.0].
The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies The "TPM 2.0 Keys for Device Identity and Attestation" document
further conventions for these keys: [PLATFORM-DEVID-TPM-2.0] specifies further conventions for these
keys:
* When separate Identity and Attestation keys are used, the * When separate Identity and Attestation keys are used, the AK and
Attestation Key (AK) and its X.509 certificate should parallel the its X.509 certificate should parallel the DevID, with the same
DevID, with the same unique device identification as the DevID unique device identification as the DevID certificate (that is,
certificate (that is, the same subject and subjectAltName (if the same subject and subjectAltName (if present), even though the
present), even though the key pairs are different). This allows a key pairs are different). By examining the corresponding AK
quote from the device, signed by an AK, to be linked directly to certificate, the Verifier can directly link a device's quote,
the device that provided it, by examining the corresponding AK which was signed by an AK, to the device that provided it. If the
certificate. If the subject in the AK certificate doesn't match subject in the AK certificate doesn't match the corresponding
the corresponding DevID certificate, or they're signed by DevID certificate, or if they're signed by different authorities,
differing authorities the Verifier may signal the detection of an the Verifier may signal the detection of an Asokan-style person-
Asokan-style person-in-the-middle attack (see Section 5.2). in-the-middle attack (see Section 5.2).
* Network devices that are expected to use secure zero touch * Network devices that are expected to use SZTP as specified in
provisioning as specified in [RFC8572] MUST be shipped by the [RFC8572] MUST be shipped by the manufacturer with pre-provisioned
manufacturer with pre-provisioned keys (Initial DevID and Initial keys (Initial DevID and Initial AK, called IDevID and IAK,
AK, called IDevID and IAK). IDevID and IAK certificates MUST both respectively). IDevID and IAK certificates MUST both be signed by
be signed by the Endorser (typically the device manufacturer). the Endorser (typically the device manufacturer). Inclusion of an
Inclusion of an IDevID and IAK by a vendor does not preclude a IDevID and IAK by a vendor does not preclude a mechanism whereby
mechanism whereby an administrator can define Local Identity and an administrator can define LDevID and Local Attestation Keys
Attestation Keys (LDevID and LAK) if desired. (LAK) if desired.
2.3. RIV Information Flow 2.3. RIV Information Flow
RIV workflow for network equipment is organized around a simple use RIV workflow for network equipment is organized around a simple use
case where a network operator wishes to verify the integrity of case where a network operator wishes to verify the integrity of
software installed in specific, fielded devices. A normative software installed in specific, fielded devices. A normative
taxonomy of terms is given in [I-D.ietf-rats-architecture], but as a taxonomy of terms is given in [RFC9334], but as a reminder, this use
reminder, this use case implies several roles and objects: case implies several roles and objects:
1. The Attester, the device which the network operator wants to Attester: The device that the network operator wants to examine.
examine.
2. A Verifier (which might be a network management station) Verifier: Which might be a Network Management Station and is
somewhere separate from the Device that will retrieve the signed somewhat separate from the Device that will retrieve the signed
evidence and measurement logs, and analyze them to pass judgment evidence and measurement logs, and analyze them to pass judgment
on the security posture of the device. on the security posture of the device.
3. A Relying Party, which can act on Attestation Results. Relying Party: Can act on Attestation Results. Interaction between
Interaction between the Relying Party and the Verifier is the Relying Party and the Verifier is considered out of scope for
considered out of scope for RIV. RIV.
4. Signed Reference Integrity Manifests (RIMs), containing Reference Signed Reference Integrity Manifests (RIMs): Contains Reference
Values, can either be created by the device manufacturer and Values. RIMs can either be created by the device manufacturer and
shipped along with the device as part of its software image, or shipped along with the device as part of its software image, or
alternatively, could be obtained several other ways (direct to alternatively, could be obtained several other ways (direct to the
the Verifier from the manufacturer, from a third party, from the Verifier from the manufacturer, from a third party, from the
owner's observation of what's thought to be a "known good owner's concept of a "known good system", etc.). Retrieving RIMs
system", etc.). Retrieving RIMs from the device itself allows from the device itself allows attestation to be done in systems
attestation to be done in systems that may not have access to the that may not have access to the public Internet, or by other
public internet, or by other devices that are not management devices that are not management stations per se (e.g., a peer
stations per se (e.g., a peer device; see Section 3.1.3). If device; see Section 3.1.3). If Reference Values are obtained from
Reference Values are obtained from multiple sources, the Verifier multiple sources, the Verifier may need to evaluate the relative
may need to evaluate the relative level of trust to be placed in level of trust to be placed in each source in case of a
each source in case of a discrepancy. discrepancy.
These components are illustrated in Figure 3. These components are illustrated in Figure 2.
+----------------+ +-------------+ +---------+--------+ +----------------+ +-------------+ +---------+--------+
|Reference Value | | Attester | Step 1 | Verifier| | |Reference Value | | Attester | Step 1 | Verifier| |
|Provider | | (Device |<-------| (Network| Relying| |Provider | | (Device |<-------| (Network| Relying|
|(Device | | under |------->| Mngmt | Party | |(Device | | under |------->| Mgmt | Party |
|Manufacturer | | attestation)| Step 2 | Station)| | |Manufacturer | | attestation)| Step 2 | Station)| |
|or other | | | | | | |or other | | | | | |
|authority) | | | | | | |authority) | | | | | |
+----------------+ +-------------+ +---------+--------+ +----------------+ +-------------+ +---------+--------+
| /\ | /\
| Step 0 | | Step 0 |
----------------------------------------------- -----------------------------------------------
Figure 3: RIV Reference Configuration for Network Equipment Figure 2: RIV Reference Configuration for Network Equipment
* In Step 0, The Reference Value Provider (the device manufacturer Step 0: The Reference Value Provider (the device manufacturer or
or other authority) makes one or more Reference Integrity other authority) makes one or more RIMs, which correspond to
Manifests (RIMs), corresponding to the software image expected to the software image expected to be found on the device and
be found on the device, signed by the Reference Value Provider, are signed by the Reference Value Provider, available to the
available to the Verifier (see Section 3.1.3 for "in-band" and Verifier. (See Section 3.1.3 for "in-band" and "out of
"out of band" ways to make this happen). band" ways to make this happen.)
* In Step 1, the Verifier (Network Management Station), on behalf of Step 1: On behalf of a Relying Party, the Verifier (Network
a Relying Party, requests Identity, Measurement Values, and Management Station) requests DevID, Measurement Values, and
possibly RIMs, from the Attester. possibly RIMs from the Attester.
* In Step 2, the Attester responds to the request by providing a Step 2: The Attester responds to the request by providing a DevID,
DevID, quotes (measured values, signed by the Attester), and quotes (measured values that are signed by the Attester),
optionally RIMs. and optionally RIMs.
Use of the following standards components allows for The use of the following standards components allows for
interoperability: interoperability:
1. TPM Keys MUST be configured according to 1. TPM keys MUST be configured according to [PLATFORM-DEVID-TPM-2.0]
[Platform-DevID-TPM-2.0], or [Platform-ID-TPM-1.2]. or [PLATFORM-ID-TPM-1.2].
2. For devices using UEFI and Linux, measurements of firmware and 2. For devices using UEFI and Linux, measurements of firmware and
bootable modules MUST be taken according to TCG PC Client bootable modules MUST be taken according to "TCG EFI Platform
[PC-Client-EFI-TPM-1.2] or [PC-Client-BIOS-TPM-2.0], and Linux Specification" [PC-CLIENT-EFI-TPM-1.2] or "TCG PC Client Specific
IMA [IMA]. Platform Firmware Profile Specification"
[PC-CLIENT-BIOS-TPM-2.0], and Linux IMA [IMA].
3. Device Identity MUST be managed as specified in IEEE 802.1AR 3. DevID MUST be managed as DevID certificates as specified in IEEE
Device Identity certificates [IEEE-802-1AR], with keys protected Std 802.1AR [IEEE-802-1AR], with keys protected by TPMs.
by TPMs.
4. Attestation logs from Linux-based systems MUST be formatted 4. Attestation logs from Linux-based systems MUST be formatted
according to the Canonical Event Log format according to the "Canonical Event Log Format" [CEL]. UEFI-based
[Canonical-Event-Log]. UEFI-based systems MUST use the TCG UEFI systems MUST use the TCG UEFI BIOS event log
BIOS event log [PC-Client-EFI-TPM-1.2] for TPM1.2 systems, and [PC-CLIENT-EFI-TPM-1.2] for TPM 1.2 systems and the "TCG PC
TCG PC Client Platform Firmware Profile [PC-Client-BIOS-TPM-2.0] Client Specific Platform Firmware Profile"
for TPM2.0. [PC-CLIENT-BIOS-TPM-2.0] for TPM 2.0 systems.
5. Quotes MUST be retrieved from the TPM according to TCG TAP 5. Quotes MUST be retrieved from the TPM according to the TCG
Information Model [TAP] and the CHARRA YANG model Trusted Attestation Protocol Information Model (TAP IM) [TAP] and
[I-D.ietf-rats-yang-tpm-charra]. While the TAP IM gives a the Challenge-Response-based Remote Attestation (CHARRA) YANG
protocol-independent description of the data elements involved, model [RFC9684]. While the TAP IM gives a protocol-independent
it's important to note that quotes from the TPM are signed inside description of the data elements involved, it's important to note
the TPM, and MUST be retrieved in a way that does not invalidate that quotes from the TPM are signed inside the TPM and MUST be
the signature, to preserve the trust model. The retrieved in a way that does not invalidate the signature, to
[I-D.ietf-rats-yang-tpm-charra] is used for this purpose. (See preserve the trust model. The CHARRA YANG model [RFC9684] is
Section 5 Security Considerations). used for this purpose. (See Section 5, Security Considerations).
6. Reference Values MUST be encoded as defined in the TCG RIM 6. Reference Values MUST be encoded as defined in the TCG RIM
document [RIM], typically using SWID [SWID], [NIST-IR-8060] or document [RIM], typically using Software Identification (SWID)
CoSWID tags [I-D.ietf-sacm-coswid]. tags [SWID] [NIST-IR-8060] or Concise SWID (CoSWID) tags
[RFC9393].
2.4. RIV Simplifying Assumptions 2.4. RIV Simplifying Assumptions
This document makes the following simplifying assumptions to reduce This document makes the following simplifying assumptions to reduce
complexity: complexity:
* The product to be attested MUST be shipped by the equipment vendor * The product to be attested MUST be shipped by the equipment vendor
with both an IEEE 802.1AR Device Identity and an Initial with both a DevID as specified by IEEE Std 802.1AR and an IAK,
Attestation Key (IAK), with certificates in place. The IAK with certificates in place. The IAK certificate must contain the
certificate must contain the same identity information as the same identity information as the DevID (specifically, the same
DevID (specifically, the same subject and subjectAltName (if subject and subjectAltName (if used), signed by the manufacturer).
used), signed by the manufacturer). The IAK is a type of key that The IAK is a type of key that can be used to sign a TPM Quote, but
can be used to sign a TPM Quote, but not other objects (i.e., it's not other objects (i.e., it's marked as a TCG "Restricted" key;
marked as a TCG "Restricted" key; this convention is described in this convention is described in "TPM 2.0 Keys for Device Identity
"TPM 2.0 Keys for Device Identity and Attestation" and Attestation" [PLATFORM-DEVID-TPM-2.0]). For network
[Platform-DevID-TPM-2.0]). For network equipment, which is equipment, which is generally not privacy sensitive, shipping a
generally non-privacy-sensitive, shipping a device with both an device with both an IDevID and an IAK already provisioned
IDevID and an IAK already provisioned substantially simplifies substantially simplifies initial startup.
initial startup.
* IEEE 802.1AR does not require a product serial number as part of * IEEE Std 802.1AR does not require a product serial number as part
the subject, but RIV-compliant devices MUST include their serial of the subject, but RIV-compliant devices MUST include their
numbers in the DevID/IAK certificates to simplify tracking serial numbers in the DevID/IAK certificates to simplify tracking
logistics for network equipment users. All other optional 802.1AR logistics for network equipment users. All other optional 802.1AR
fields remain optional in RIV. fields remain optional in RIV.
It should be noted that 802.1AR use of X.509 certificate fields is It should be noted that the use of X.509 certificate fields as
not identical to those descsribed in [RFC6125] for representation specified by IEEE Std 802.1AR is not identical to that described
of application service identity. in [RFC9525] for representation of application service identity.
* The product MUST be equipped with a Root of Trust for Measurement * The product MUST be equipped with an RTM, a Root of Trust for
(RTM), Root of Trust for Storage and Root of Trust for Reporting Storage, and a Root of Trust for Reporting (as defined in
(as defined in [SP800-155]) which together are capable of [SP800-155]), which together are capable of conforming to the TCG
conforming to TCG Trusted Attestation Protocol Information Model TAP IM [TAP].
[TAP].
* The authorized software supplier MUST make available Reference * The authorized software supplier MUST make available Reference
Values in the form of signed SWID or CoSWID tags. Values in the form of signed SWID or CoSWID tags.
2.4.1. Reference Integrity Manifests (RIMs) 2.4.1. Reference Integrity Manifests (RIMs)
[I-D.ietf-rats-yang-tpm-charra] focuses on collecting and [RFC9684] focuses on collecting and transmitting evidence in the form
transmitting evidence in the form of PCR measurements and attestation of PCR measurements and attestation logs. But the critical part of
logs. But the critical part of the process is enabling the Verifier the process is enabling the Verifier to decide whether the
to decide whether the measurements are "the right ones" or not. measurements are "the right ones" or not.
While it must be up to network administrators to decide what they While it must be up to network administrators to decide what they
want on their networks, the software supplier should supply the want on their networks, the software supplier should supply the
Reference Values, in signed Reference Integrity Manifests, that may Reference Values, in signed RIMs, that may be used by a Verifier to
be used by a Verifier to determine if evidence shows known good, determine if evidence shows known good, known bad, or unknown
known bad or unknown software configurations. software configurations.
In general, there are two kinds of reference measurements: In general, there are two kinds of reference measurements:
1. Measurements of early system startup (e.g., BIOS, boot loader, OS 1. Measurements of early system startup (e.g., BIOS, boot loader, OS
kernel) are essentially single-threaded, and executed exactly kernel) are essentially single threaded and executed exactly
once, in a known sequence, before any results could be reported. once, in a known sequence, before any results can be reported.
In this case, while the method for computing the hash and In this case, while the method for computing the hash and
extending relevant PCRs may be complicated, the net result is extending relevant PCRs may be complicated, the net result is
that the software (more likely, firmware) vendor will have one that the software (more likely, firmware) vendor will have one
known good PCR value that "should" be present in the relevant known good PCR value that "should" be present in the relevant
PCRs after the box has booted. In this case, the signed PCRs after the box has booted. In this case, the signed
reference measurement could simply list the expected hashes for reference measurement could simply list the expected hashes for
the given version. However, a RIM that contains the intermediate the given version. However, a RIM that contains the intermediate
hashes can be useful in debugging cases where the expected final hashes can be useful in debugging cases where the expected final
hash is not the one reported. hash is not the one reported.
skipping to change at page 19, line 38 skipping to change at line 860
with unpredictable "final" PCR values. In this case, the with unpredictable "final" PCR values. In this case, the
Verifier must have enough information to reconstruct the expected Verifier must have enough information to reconstruct the expected
PCR values from logs and signed reference measurements from a PCR values from logs and signed reference measurements from a
trusted authority. trusted authority.
In both cases, the expected values can be expressed as signed SWID or 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 CoSWID tags, but the SWID structure in the second case is somewhat
more complex, as reconstruction of the extended hash in a PCR may more complex, as reconstruction of the extended hash in a PCR may
involve thousands of files and other objects. involve thousands of files and other objects.
TCG has published an information model defining elements of Reference TCG has published an information model defining elements of RIMs
Integrity Manifests under the title TCG Reference Integrity Manifest under the title "TCG Reference Integrity Manifest (RIM) Information
Information Model [RIM]. This information model outlines how SWID Model" [RIM]. This information model outlines how SWID tags should
tags should be structured to allow attestation, and defines "bundles" be structured to allow attestation, and it defines "bundles" of SWID
of SWID tags that may be needed to describe a complete software tags that may be needed to describe a complete software release. The
release. The RIM contains metadata relating to the software release RIM contains metadata relating to the software release it belongs to,
it belongs to, plus hashes for each individual file or other object plus hashes for each individual file or other object that could be
that could be attested. attested.
Many network equipment vendors use a UEFI BIOS to launch their Many network equipment vendors use a UEFI BIOS to launch their
network operating system. These vendors may want to also use the TCG network operating system. These vendors may want to also use the
PC Client Reference Integrity Measurement specification "TCG PC Client Reference Integrity Manifest Specification"
[PC-Client-RIM], which focuses specifically on a SWID-compatible [PC-CLIENT-RIM], which focuses specifically on a SWID-compatible
format suitable for expressing measurement values expected from a format suitable for expressing measurement values expected from a
UEFI BIOS. UEFI BIOS.
2.4.2. Attestation Logs 2.4.2. Attestation Logs
Quotes from a TPM can provide evidence of the state of a device up to 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 the time the evidence was recorded. However, to make sense of the
cases where several events are extended into one PCR an event log quote in cases where several events are extended into one PCR, an
that identifies which software modules contributed which values to event log that identifies which software modules contributed which
the quote during startup must also be provided. When required, the values to the quote during startup must also be provided. When
log MUST contain enough information to demonstrate its integrity by required, the log MUST contain enough information to demonstrate its
allowing exact reconstruction of the digest conveyed in the signed integrity by allowing exact reconstruction of the digest conveyed in
quote (that is, calculating the hash of all the hashes in the log the signed quote (that is, calculating the hash of all the hashes in
should produce the same values as contained in the PCRs; if they the log should produce the same values as contained in the PCRs; if
don't match, the log may have been tampered with. See Section 9.1). they don't match, the log may have been tampered with. See
Appendix A.1).
There are multiple event log formats which may be supported as viable There are multiple event log formats that may be supported as viable
formats of Evidence between the Attester and Verifier, but to formats of Evidence between the Attester and Verifier; however, to
simplify interoperability, RIV focuses on just three: simplify interoperability, RIV focuses on just three:
* TCG UEFI BIOS event log for TPM 2.0 (TCG PC Client Platform 1. TCG UEFI BIOS event log for TPM 2.0 ("TCG PC Client Specific
Firmware Profile) [PC-Client-BIOS-TPM-2.0] Platform Firmware Profile Specification")
[PC-CLIENT-BIOS-TPM-2.0]
* TCG UEFI BIOS event log for TPM 1.2 (TCG EFI Platform 2. TCG UEFI BIOS event log for TPM 1.2 ("TCG EFI Platform
Specification for TPM Family 1.1 or 1.2, Section 7) Specification" for TPM Family 1.1 or 1.2, Section 7)
[PC-Client-EFI-TPM-1.2] [PC-CLIENT-EFI-TPM-1.2]
* TCG Canonical Event Log [Canonical-Event-Log] 3. TCG "Canonical Event Log Format" [CEL]
3. Standards Components 3. Standards Components
3.1. Prerequisites for RIV 3.1. Prerequisites for RIV
The Reference Interaction Model for Challenge-Response-based Remote The Reference Interaction Model for Challenge-Response-based Remote
Attestation ([I-D.birkholz-rats-reference-interaction-model]) is Attestation ([RATS-INTERACTION-MODELS]) is based on the standard
based on the standard roles defined in [I-D.ietf-rats-architecture]. roles defined in [RFC9334]. However, additional prerequisites have
However, additional prerequisites have been established to allow for been established to allow for interoperable implementations of RIV
interoperable RIV use case implementations. These prerequisites are use cases. These prerequisites are intended to provide sufficient
intended to provide sufficient context information so that the context information so that the Verifier can acquire and evaluate
Verifier can acquire and evaluate measurements collected by the measurements collected by the Attester.
Attester.
3.1.1. Unique Device Identity 3.1.1. Unique Device Identity
A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID A DevID in the form of a DevID certificate as specified by IEEE Std
certificate [IEEE-802-1AR] must be provisioned in the Attester's 802.1AR [IEEE-802-1AR] must be provisioned in the Attester's TPMs.
TPMs.
3.1.2. Keys 3.1.2. Keys
The Attestation Key (AK) and certificate must also be provisioned on The AK and certificate must also be provisioned on the Attester
the Attester according to [Platform-DevID-TPM-2.0], or according to [PLATFORM-DEVID-TPM-2.0] or [PLATFORM-ID-TPM-1.2].
[Platform-ID-TPM-1.2].
It MUST be possible for the Verifier to determine that the Attester's It MUST be possible for the Verifier to determine that the Attester's
Attestation keys are resident in the same TPM as its DevID keys (see AKs are resident in the same TPM as its DevID keys (see Section 2.2
Section 2.2 and Section 5 Security Considerations). and Section 5, Security Considerations).
3.1.3. Appraisal Policy for Evidence 3.1.3. Appraisal Policy for Evidence
As noted in Section 2.3, the Verifier may obtain Reference Values As noted in Section 2.3, the Verifier may obtain Reference Values
from several sources. In addition, administrators may make from several sources. In addition, administrators may make
authorized, site-specific changes (e.g. keys in key databases) that authorized, site-specific changes (e.g., keys in key databases) that
could impact attestation results. As such, there could be conflicts, could impact attestation results. As such, there could be conflicts,
omissions or ambiguities between some Reference Values and collected omissions, or ambiguities between some Reference Values and collected
Evidence. Evidence.
The Verifier MUST have an Appraisal Policy for Evidence to evaluate The Verifier MUST have an Appraisal Policy for Evidence to evaluate
the significance of any discrepancies between different reference the significance of any discrepancies between different reference
sources, or between reference values and evidence from logs and sources, or between Reference Values and evidence from logs and
quotes. While there must be an Appraisal Policy, this document does quotes. While there must be an Appraisal Policy, this document does
not specify the format or mechanism to convey the intended policy, not specify the format or mechanism to convey the intended policy,
nor does RIV specify mechanisms by which the results of applying the nor does RIV specify mechanisms by which the results of applying the
policy are communicated to the Relying Party. policy are communicated to the Relying Party.
3.2. Reference Model for Challenge-Response 3.2. Reference Model for Challenge-Response
Once the prerequisites for RIV are met, a Verifier is able to acquire Once the prerequisites for RIV are met, a Verifier is able to acquire
Evidence from an Attester. The following diagram illustrates a RIV Evidence from an Attester. Figure 3 illustrates a RIV information
information flow between a Verifier and an Attester, derived from flow between a Verifier and an Attester, derived from Section 7.1 of
Section 7.1 of [I-D.birkholz-rats-reference-interaction-model]. In [RATS-INTERACTION-MODELS]. In this diagram, each event with its
this diagram, each event with its input and output parameters is input and output parameters is shown as "Event(input-
shown as "Event(input-params)=>(outputs)". Event times shown params)=>(outputs)". The event times shown correspond to the time
correspond to the time types described within Appendix A of types described within Appendix A of [RFC9334]:
[I-D.ietf-rats-architecture]:
.----------. .-----------------------. .----------. .-----------------------.
| Attester | | Relying Party/Verifier | | Attester | | Relying Party/Verifier |
'----------' '------------------------' '----------' '------------------------'
time(VG) | time(VG) |
generateClaims(attestingEnvironment) | generateClaims(attestingEnvironment) |
| => claims, eventLogs | | => claims, eventLogs |
| | | |
| time(NS) | time(NS)
| <-- requestAttestation(handle, authSecIDs, claimSelection) | | <-- requestAttestation(handle, authSecIDs, claimSelection) |
skipping to change at page 22, line 30 skipping to change at line 982
| => evidence | | => evidence |
| time(RG,RA) | time(RG,RA)
| evidence, eventLogs -------------------------------------> | | evidence, eventLogs -------------------------------------> |
| | | |
| appraiseEvidence(evidence, eventLogs, refValues) | appraiseEvidence(evidence, eventLogs, refValues)
| attestationResult <= | | attestationResult <= |
| | | |
~ ~ ~ ~
| time(RX) | time(RX)
Figure 4: IETF Attestation Information Flow Figure 3: IETF Attestation Information Flow
* Step 1 (time(VG)): One or more Attesting Network Device PCRs are Step 1 (time(VG)): One or more attesting network device PCRs are
extended with measurements. RIV provides no direct link between extended with measurements. RIV provides no direct link between
the time at which the event takes place and the time that it's the time at which the event takes place and the time that it's
attested, although streaming attestation as in attested, although streaming attestation as described in
[I-D.birkholz-rats-network-device-subscription] could. [RATS-NET-DEV-SUB] could.
* Step 2 (time(NS)): The Verifier generates a unique random nonce Step 2 (time(NS)): The Verifier generates a unique random nonce
("number used once"), and makes a request for one or more PCRs ("number used once") and makes a request for one or more PCRs from
from an Attester. For interoperability, this must be accomplished an Attester. For interoperability, this must be accomplished as
as specified in the YANG Data Model for Challenge-Response-based specified in "A YANG Data Model for Challenge-Response-Based
Remote Attestation Procedures using TPMs Remote Attestation (CHARRA) Procedures Using Trusted Platform
[I-D.ietf-rats-yang-tpm-charra]. TPM1.2 and TPM2.0 both allow Modules (TPMs)" [RFC9684]. Both TPM 1.2 and TPM 2.0 allow nonces
nonces as large as the operative digest size (i.e., 20 or 32 as large as the operative digest size (i.e., 20 or 32 bytes; see
bytes; see [TPM1.2] Part 2, Section 5.5 and [TPM2.0] Part 2, [TPM-1.2] Part 2, Section 5.5, and [TPM-2.0] Part 2,
Section 10.4.4). Section 10.4.4).
* Step 3 (time(EG)): On the Attester, measured values are retrieved Step 3 (time(EG)): On the Attester, measured values are retrieved
from the Attester's TPM. This requested PCR evidence, along with from the Attester's TPM. This requested PCR evidence along with
the Verifier's nonce, called a Quote, is signed by the Attestation the Verifier's nonce is called a Quote and is signed by the AK
Key (AK) associated with the DevID. Quotes are retrieved associated with the DevID. Quotes are retrieved according to the
according to CHARRA YANG model [I-D.ietf-rats-yang-tpm-charra]. CHARRA YANG model [RFC9684]. At the same time, the Attester
collects log evidence showing the values have been extended into
At the same time, the Attester collects log evidence showing the that PCR. Appendix A.1 gives more detail on how this works and
values have been extended into that PCR. Section 9.1 gives more includes references to the structure and contents of quotes in TPM
detail on how this works, including references to the structure documents.
and contents of quotes in TPM documents.
* Step 4: Collected Evidence is passed from the Attester to the Step 4: The collected Evidence is passed from the Attester to the
Verifier Verifier.
* Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes
action as needed. As the interaction between Relying Party and action as needed. As the interaction between Relying Party and
Verifier is out of scope for RIV, this can be described as one Verifier is out of scope for RIV, this can be described as one
step. step.
- If the signature covering TPM Evidence is not correct, the * If the signature covering TPM Evidence is not correct, the
device SHOULD NOT be trusted. device SHOULD NOT be trusted.
- If the nonce in the response doesn't match the Verifier's * If the nonce in the response doesn't match the Verifier's
nonce, the response may be a replay, and device SHOULD NOT be nonce, the response may be a replay, and the device SHOULD NOT
trusted. be trusted.
- If the signed PCR values do not match the set of log entries * If the signed PCR values do not match the set of log entries
which have extended a particular PCR, the device SHOULD NOT be that have extended a particular PCR, the device SHOULD NOT be
trusted. trusted.
- If the log entries that the Verifier considers important do not * If the log entries that the Verifier considers important do not
match known good values, the device SHOULD NOT be trusted. We match known good values, the device SHOULD NOT be trusted. We
note that the process of collecting and analyzing the log can note that the process of collecting and analyzing the log can
be omitted if the value in the relevant PCR is already a known- be omitted if the value in the relevant PCR is already a known-
good value. good value.
- If the set of log entries are not seen as acceptable by the * If the set of log entries are not seen as acceptable by the
Appraisal Policy for Evidence, the device SHOULD NOT be Appraisal Policy for Evidence, the device SHOULD NOT be
trusted. trusted.
- If time(RG)-time(NS) is greater than the Appraisal Policy for * If time(RG)-time(NS) is greater than the Appraisal Policy for
Evidence's threshold for assessing freshness, the Evidence is Evidence's threshold for assessing freshness, the Evidence is
considered stale and SHOULD NOT be trusted. considered stale and SHOULD NOT be trusted.
3.2.1. Transport and Encoding 3.2.1. Transport and Encoding
Network Management systems may retrieve signed PCR based Evidence Network Management systems may retrieve signed PCR-based Evidence
using NETCONF or RESTCONF with [I-D.ietf-rats-yang-tpm-charra]. In using NETCONF or RESTCONF with [RFC9684]. In either case,
either case, implementatations must do so using a secure tunnel. implementations must do so using a secure tunnel.
Log Evidence MUST be retrieved via log interfaces specified in Log Evidence MUST be retrieved via log interfaces specified in
[I-D.ietf-rats-yang-tpm-charra]. [RFC9684].
3.3. Centralized vs Peer-to-Peer 3.3. Centralized vs. Peer-to-Peer
Figure 4 above assumes that the Verifier is trusted, while the Figure 3 assumes that the Verifier is trusted, while the Attester is
Attester is not. In a Peer-to-Peer application such as two routers not. In a peer-to-peer application such as two routers negotiating a
negotiating a trust relationship, the two peers can each ask the trust relationship, the two peers can each ask the other to prove
other to prove software integrity. In this application, the software integrity. In this application, the information flow is the
information flow is the same, but each side plays a role both as an same, but each side plays a role both as an Attester and a Verifier.
Attester and a Verifier. Each device issues a challenge, and each Each device issues a challenge, and each device responds to the
device responds to the other's challenge, as shown in Figure 5. other's challenge, as shown in Figure 4. Peer-to-peer challenges,
Peer-to-peer challenges, particularly if used to establish a trust particularly if used to establish a trust relationship between
relationship between routers, require devices to carry their own routers, require devices to carry their own signed reference
signed reference measurements (RIMs). Devices may also have to carry measurements (RIMs). Devices may also have to carry an appraisal
Appraisal Policy for Evidence for each possible peer device so that policy for evidence for each possible peer device so that each device
each device has everything needed for remote attestation, without has everything needed for remote attestation, without having to
having to resort to a central authority. resort to a central authority.
+---------------+ +---------------+ +---------------+ +---------------+
| RefVal | | RefVal | | RefVal | | RefVal |
| Provider A | | Provider B | | Provider A | | Provider B |
| Firmware | | Firmware | | Firmware | | Firmware |
| Configuration | | Configuration | | Configuration | | Configuration |
| Authority | | Authority | | Authority | | Authority |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
| | | |
skipping to change at page 24, line 49 skipping to change at line 1096
| | | | | | | | | |
| | | | | | | | | |
| | Step 1 | | | \ | | Step 1 | | | \
| Verifier |<------>| Attester |<-+ | Router A | Verifier |<------>| Attester |<-+ | Router A
| |<------>| | |- Challenges | |<------>| | |- Challenges
| | Step 2 | | | Router B | | Step 2 | | | Router B
| | | | | | | | | |
| |<-------| | | | |<-------| | |
+------------+ Step 3 +------------+ / +------------+ Step 3 +------------+ /
Figure 5: Peer-to-Peer Attestation Information Flow Figure 4: Peer-to-Peer Attestation Information Flow
In this application, each device may need to be equipped with signed 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 RIMs to act as an Attester, and to allow each device to act as a
and a selection of trusted X.509 root certificates, to allow the Verifier, each may need to be equipped with an Appraisal Policy for
device to act as a Verifier. An existing link layer protocol such as Evidence and a selection of trusted X.509 root certificates also. An
802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being existing link layer protocol such as 802.1X [IEEE-802.1X] or 802.1AE
enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable [IEEE-802.1AE], with Evidence being enclosed over a variant of the
methods for such an exchange. Details of peer-to-peer operation are Extensible Authentication Protocol (EAP) [RFC3748] or Link Layer
out of scope for this document. Discovery Protocol (LLDP) [LLDP], are suitable methods for such an
exchange. Details of peer-to-peer operation are out of scope for
this document.
4. Privacy Considerations 4. Privacy Considerations
Network equipment, such as routers, switches and firewalls, has a key Network equipment, such as routers, switches, and firewalls, has a
role to play in guarding the privacy of individuals using the key role to play in guarding the privacy of individuals using the
network. Network equipment generally adheres to several rules to network. Network equipment generally adheres to several rules to
protect privacy: protect privacy:
* Packets passing through the device must not be sent to * Packets passing through the device must not be sent to
unauthorized destinations. For example: unauthorized destinations. For example:
- Routers often act as Policy Enforcement Points, where - Routers often act as Policy Enforcement Points, where
individual subscribers may be checked for authorization to individual subscribers may be checked for authorization to
access a network. Subscriber login information must not be access a network. Subscriber login information must not be
released to unauthorized parties. released to unauthorized parties.
skipping to change at page 25, line 43 skipping to change at line 1138
must not be leaked to unauthorized neighbors. must not be leaked to unauthorized neighbors.
* If configured, encryption and decryption of traffic must be * If configured, encryption and decryption of traffic must be
carried out reliably, while protecting keys and credentials. carried out reliably, while protecting keys and credentials.
Functions that protect privacy are implemented as part of each layer Functions that protect privacy are implemented as part of each layer
of hardware and software that makes up the networking device. In of hardware and software that makes up the networking device. In
light of these requirements for protecting the privacy of users of light of these requirements for protecting the privacy of users of
the network, the network equipment must identify itself, and its boot the network, the network equipment must identify itself, and its boot
configuration and measured device state (for example, PCR values), to configuration and measured device state (for example, PCR values), to
the equipment's administrator, so there's no uncertainty as to what the equipment's administrator so there's no uncertainty about the
function each device and configuration is configured to carry out. device's function and configuration. Attestation is a component that
Attestation is a component that allows the administrator to ensure allows the administrator to ensure that the network provides
that the network provides individual and peer privacy guarantees, individual and peer privacy guarantees, even though the device itself
even though the device itself may not have a right to keep its may not have a right to keep its identity secret.
identity secret.
See [NetEq] for more context on privacy in networking devices. See [NET-EQ] for more context on privacy in networking devices.
While attestation information from network devices is not likely to While attestation information from network devices is not likely to
contain privacy-sensitive content regarding network users, contain privacy-sensitive content regarding network users,
administrators may want to keep attestation records confidential to administrators may want to keep attestation records confidential to
avoid disclosing versions of software loaded on the device, avoid disclosing versions of software loaded on the device, which is
information which could facilitate attacks against known information that could facilitate attacks against known
vulnerabilities. vulnerabilities.
5. Security Considerations 5. Security Considerations
Specifications such as [RFC8446] (TLS) and [RFC7950] (YANG) contain Specifications such as TLS [RFC8446] and YANG [RFC7950] contain
considerable advice on keeping network-connected systems secure. considerable advice on keeping network-connected systems secure.
This section outlines specific risks and mitigations related to This section outlines specific risks and mitigations related to
attestation. attestation.
Attestation Evidence obtained by the RIV procedure is subject to a Attestation Evidence obtained by the RIV procedure is subject to a
number of attacks: number of attacks:
* Keys may be compromised. * Keys may be compromised.
* A counterfeit device may attempt to impersonate (spoof) a known * A counterfeit device may attempt to impersonate (spoof) a known
skipping to change at page 26, line 39 skipping to change at line 1180
device. device.
* Replay attacks may be attempted by a compromised device. * Replay attacks may be attempted by a compromised device.
5.1. Keys Used in RIV 5.1. Keys Used in RIV
Trustworthiness of RIV attestation depends strongly on the validity Trustworthiness of RIV attestation depends strongly on the validity
of keys used for identity and attestation reports. RIV takes full of keys used for identity and attestation reports. RIV takes full
advantage of TPM capabilities to ensure that evidence can be trusted. advantage of TPM capabilities to ensure that evidence can be trusted.
Two sets of key-pairs are relevant to RIV attestation: Two sets of key pairs are relevant to RIV attestation:
* A DevID key-pair is used to certify the identity of the device in * A DevID key pair is used to certify the identity of the device in
which the TPM is installed. which the TPM is installed.
* An Attestation Key-pair (AK) key is used to certify attestation * An AK key pair is used to certify attestation Evidence (i.e.,
Evidence (called 'quotes' in TCG documents), used to provide quotes) and to provide evidence for integrity of the device
evidence for integrity of the software on the device software.
TPM practices usually require that these keys be different, as a way TPM practices usually require that these keys be different to ensure
of ensuring that a general-purpose signing key cannot be used to that a general-purpose signing key cannot be used to spoof an
spoof an attestation quote. attestation quote.
In each case, the private half of the key is known only to the TPM, 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 and cannot be retrieved externally, even by a trusted party. To
ensure that's the case, specification-compliant private/public key- ensure that's the case, specification-compliant private/public key
pairs are generated inside the TPM, where they are never exposed, and pairs are generated inside the TPM, where they are never exposed and
cannot be extracted (See [Platform-DevID-TPM-2.0]). cannot be extracted (see [PLATFORM-DEVID-TPM-2.0]).
Keeping keys safe is a critical enabler of trustworthiness, but it's Keeping keys safe is a critical enabler of trustworthiness, but it's
just part of attestation security; knowing which keys are bound to just part of attestation security; knowing which keys are bound to
the device in question is just as important in an environment where the device in question is just as important in an environment where
private keys are never exposed. private keys are never exposed.
While there are many ways to manage keys in a TPM (see While there are many ways to manage keys in a TPM (see
[Platform-DevID-TPM-2.0]), RIV includes support for "zero touch" [PLATFORM-DEVID-TPM-2.0]), RIV includes support for "zero touch"
provisioning (also known as zero-touch onboarding) of fielded devices provisioning (also known as zero touch onboarding) of fielded devices
(e.g., Secure ZTP, [RFC8572]), where keys which have predictable (e.g., SZTP [RFC8572]), where keys that have predictable trust
trust properties are provisioned by the device vendor. properties are provisioned by the device vendor.
Device identity in RIV is based on IEEE 802.1AR Device Identity Device identity in RIV is based on DevID defined by IEEE Std 802.1AR.
(DevID). This specification provides several elements: This specification provides several elements:
* A DevID requires a unique key pair for each device, accompanied by * A DevID requires a unique key pair for each device, accompanied by
an X.509 certificate, an X.509 certificate.
* The private portion of the DevID key is to be stored in the * The private portion of the DevID key is to be stored in the
device, in a manner that provides confidentiality (Section 6.2.5 device, in a manner that provides confidentiality (Section 6.2.5
[IEEE-802-1AR]) of [IEEE-802-1AR]).
The X.509 certificate contains several components: The X.509 certificate contains several components:
* The public part of the unique DevID key assigned to that device * The public part of the unique DevID key assigned to that device
allows a challenge of identity. allows a challenge of identity.
* An identifying string that's unique to the manufacturer of the * An identifying string that's unique to the manufacturer of the
device. This is normally the serial number of the unit, which device. This is normally the serial number of the unit, which
might also be printed on a label on the device. might also be printed on a label on the device.
skipping to change at page 28, line 7 skipping to change at line 1241
With these elements, the device's manufacturer and serial number can With these elements, the device's manufacturer and serial number can
be identified by analyzing the DevID certificate plus the chain of be identified by analyzing the DevID certificate plus the chain of
intermediate certificates leading back to the manufacturer's root intermediate certificates leading back to the manufacturer's root
certificate. As is conventional in TLS or SSH connections, a random certificate. As is conventional in TLS or SSH connections, a random
nonce must be signed by the device in response to a challenge, nonce must be signed by the device in response to a challenge,
proving possession of its DevID private key. proving possession of its DevID private key.
RIV uses the DevID to validate a TLS or SSH connection to the device RIV uses the DevID to validate a TLS or SSH connection to the device
as the attestation session begins. Security of this process derives as the attestation session begins. Security of this process derives
from TLS or SSH security, with the DevID, containing a device serial from TLS or SSH security, with the DevID, which contains a device
number, providing proof that the session terminates on the intended serial number, providing proof that the session terminates on the
device. See [RFC8446], [RFC4253]. intended device. See [RFC8446] [RFC4253].
Evidence of software integrity is delivered in the form of a quote Evidence of software integrity is delivered in the form of a quote
signed by the TPM itself, accompanied by an IAK certificate that is signed by the TPM itself and accompanied by an IAK
containing the same identity information as the DevID. Because the certificate containing the same identity information as the DevID.
contents of the quote are signed inside the TPM, any external Because the contents of the quote are signed inside the TPM, any
modification (including reformatting to a different data format) external modification (including reformatting to a different data
after measurements have been taken will be detected as tampering. An format) after measurements have been taken will be detected as
unbroken chain of trust is essential to ensuring that blocks of code tampering. An unbroken chain of trust is essential for ensuring that
that are taking measurements have been verified before execution (see blocks of code that are taking measurements have been verified before
Figure 1). execution (see Figure 1).
Requiring measurements of the operating software to be signed by a Requiring measurements of the operating software to be signed by a
key known only to the TPM also removes the need to trust the device's key known only to the TPM also removes the need to trust the device's
operating software (beyond the first measurement in the RTM; see operating software (beyond the first measurement in the RTM; see
below); any changes to the quote, generated and signed by the TPM below). If malicious software makes any changes to a quote in the
itself, made by malicious device software, or in the path back to the device itself, or in the path back to the Verifier, the signature on
Verifier, will invalidate the signature on the quote. the quote will be invalidated.
A critical feature of the YANG model described in A critical feature of the YANG model described in [RFC9684] is the
[I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data ability to carry TPM data structures in their TCG-defined format,
structures in their TCG-defined format, without requiring any changes without requiring any changes to the structures as they were signed
to the structures as they were signed and delivered by the TPM. and delivered by the TPM. While alternate methods of conveying TPM
While alternate methods of conveying TPM quotes could compress out quotes could reduce redundant information, or add another layer of
redundant information, or add another layer of signing using external signing using external keys, the implementation MUST preserve the TPM
keys, the implementation MUST preserve the TPM signing, so that signing so that tampering anywhere in the path between the TPM itself
tampering anywhere in the path between the TPM itself and the and the Verifier can be detected.
Verifier can be detected.
5.2. Prevention of Spoofing and Person-in-the-Middle Attacks 5.2. Prevention of Spoofing and Person-in-the-Middle Attacks
Prevention of spoofing attacks against attestation systems is also Prevention of spoofing attacks against attestation systems is also
important. There are several cases to consider: important. There are several cases to consider:
* The entire device could be spoofed. If the Verifier goes to * The entire device could be spoofed. If the Verifier goes to
appraise a specific Attester, it might be redirected to a appraise a specific Attester, it might be redirected to a
different Attester. different Attester.
* A compromised device could have a valid DevID, but substitute a * A compromised device could have a valid DevID, but substitute a
quote from a knonwn-good device, instead of returning its own, as quote from a known-good device instead of returning its own, as
described in [RFC6813]. described in [RFC6813].
* A device with a compromised OS could return a fabricated quote * A device with a compromised OS could return a fabricated quote
providing spoofed attestation Evidence. providing spoofed attestation Evidence.
Use of the 802.1AR Device Identity (DevID) in the TPM provides Use of the 802.1AR DevID in the TPM provides protection against the
protection against the case of a spoofed device, by ensuring that the case of a spoofed device by ensuring that the Verifier's TLS or SSH
Verifier's TLS or SSH session is in fact terminating on the right session is in fact terminating on the right device.
device.
Protection against spoofed quotes from a device with valid identity Protection against spoofed quotes from a device with valid identity
is a bit more complex. An identity key must be available to sign any is a bit more complex. An identity key must be available to sign any
kind of nonce or hash offered by the Verifier, and consequently, kind of nonce or hash offered by the Verifier, and consequently,
could be used to sign a fabricated quote. To block a spoofed could be used to sign a fabricated quote. To block a spoofed
Attestation Result, the quote generated inside the TPM must be signed Attestation Result, the quote generated inside the TPM must be signed
by a key that's different from the DevID, called an Attestation Key by a key, known as an AK, that's different from the DevID.
(AK).
Given separate Attestation and DevID keys, the binding between the AK Given separate Attestation and DevID keys, the binding between the AK
and the same device must also be proven to prevent a person-in-the- and the same device must also be proven to prevent a person-in-the-
middle attack (e.g., the 'Asokan Attack' [RFC6813]). middle attack (e.g., the "Asokan Attack" [RFC6813]).
This is accomplished in RIV through use of an AK certificate with the This is accomplished in RIV through use of an AK certificate with the
same elements as the DevID (same manufacturer's serial number, signed same elements as the DevID (same manufacturer's serial number and
by the same manufacturer's key), but containing the device's unique signed by the same manufacturer's key), but containing the device's
AK public key instead of the DevID public key. This binding between unique AK public key instead of the DevID public key. This binding
DevID and AK certificates is critical to reliable attestation. between DevID and AK certificates is critical to reliable
attestation.
The TCG document TPM 2.0 Keys for Device Identity and Attestation The TCG document "TPM 2.0 Keys for Device Identity and Attestation"
[Platform-DevID-TPM-2.0] specifies OIDs for Attestation Certificates [PLATFORM-DEVID-TPM-2.0] specifies OIDs for Attestation Certificates
that allow the CA to mark a key as specifically known to be an that allow the CA to mark a key as specifically known to be an AK.
Attestation key.
These two key-pairs and certificates are used together: These two key pairs and certificates are used together:
* The DevID is used to validate a TLS connection terminating on the * The DevID is used to validate a TLS connection terminating on the
device with a known serial number. device with a known serial number.
* The AK is used to sign attestation quotes, providing proof that * The AK is used to sign attestation quotes, which provides proof
the attestation evidence comes from the same device. that the attestation evidence comes from the same device.
5.3. Replay Attacks 5.3. Replay Attacks
Replay attacks, where results of a previous attestation are submitted Replay attacks, where the results of a previous attestation are
in response to subsequent requests, are usually prevented by submitted in response to subsequent requests, are usually prevented
inclusion of a random nonce in the request to the TPM for a quote. by the inclusion of a random nonce in the request to the TPM for a
Each request from the Verifier includes a new random number (a quote. Each request from the Verifier includes a new random number
nonce). The resulting quote signed by the TPM contains the same (a nonce). The resulting quote signed by the TPM contains the same
nonce, allowing the Verifier to determine freshness, (i.e., that the nonce, which allows the Verifier to determine freshness (i.e., that
resulting quote was generated in response to the Verifier's specific the resulting quote was generated in response to the Verifier's
request). Time-Based Uni-directional Attestation specific request). "Time-Based Uni-Directional Attestation"
[I-D.birkholz-rats-tuda] provides an alternate mechanism to verify [RATS-TUDA] provides an alternate mechanism to verify freshness
freshness without requiring a request/response cycle. without requiring a request/response cycle.
5.4. Owner-Signed Keys 5.4. Owner-Signed Keys
Although device manufacturers must pre-provision devices with easily Although device manufacturers must pre-provision devices with easily
verified DevID and AK certificates if zero-touch provisioning such as verified DevID and AK certificates if SZTP such as described in
described in [RFC8572] is to be supported, use of those credentials [RFC8572] is to be supported, use of those credentials is not
is not mandatory. IEEE 802.1AR incorporates the idea of an Initial mandatory. IEEE Std 802.1AR incorporates the idea of an IDevID,
Device ID (IDevID), provisioned by the manufacturer, and a Local which is provisioned by the manufacturer, and a LDevID, which is
Device ID (LDevID) provisioned by the owner of the device. RIV and provisioned by the owner of the device. RIV and
[Platform-DevID-TPM-2.0] extends that concept by defining an Initial [PLATFORM-DEVID-TPM-2.0] extend that concept by defining an IAK and
Attestation Key (IAK) and Local Attestation Key (LAK) with the same LAK with the same properties.
properties.
Device owners can use any method to provision the Local credentials. Device owners can use any method to provision the local credentials.
* TCG document [Platform-DevID-TPM-2.0] shows how the initial * The TCG document [PLATFORM-DEVID-TPM-2.0] shows how the IAKs can
Attestation keys can be used to certify LDevID and LAK keys. Use be used to certify LDevID and LAK keys. The use of the LDevID and
of the LDevID and LAK allows the device owner to use a uniform LAK allows the device owner to use a uniform identity structure
identity structure across device types from multiple manufacturers across device types from multiple manufacturers (in the same way
(in the same way that an "Asset Tag" is used by many enterprises that an "Asset Tag" is used by many enterprises to identify
to identify devices they own). TCG document devices they own). The TCG document [PROV-TPM-2.0] also contains
[Provisioning-TPM-2.0] also contains guidance on provisioning guidance on provisioning local identity keys in TPM 2.0. Owners
Local identity keys in TPM 2.0. Owners should follow the same should follow the same practice of binding LDevID and LAK as the
practice of binding Local DevID and Local AK as the manufacturer manufacturer would for IDevID and IAK. See Section 2.2.
would for IDevID and IAK. See Section Section 2.2.
* Device owners, however, can use any other mechanism they want to * Device owners, however, can use any other mechanism they want,
assure themselves that local identity certificates are inserted including physical inspection and programming in a secure
into the intended device, including physical inspection and location, to assure themselves that local identity certificates
programming in a secure location, if they prefer to avoid placing are inserted into the intended device if they prefer to avoid
trust in the manufacturer-provided keys. placing trust in the manufacturer-provided keys.
Clearly, local keys can't be used for secure Zero Touch provisioning; Clearly, local keys can't be used for SZTP; installation of the local
installation of the local keys can only be done by some process that keys can only be done by some process that runs before the device is
runs before the device is installed for network operation, or using installed for network operation, or by using procedures such as those
procedures such as those outlined in Bootstrapping Remote Secure Key outlined in Bootstrapping Remote Secure Key Infrastructure (BRSKI)
Infrastructure (BRSKI) [RFC8995]. [RFC8995].
On the other end of the device life cycle, provision should be made On the other end of the device lifecycle, provision should be made to
to wipe local keys when a device is decommissioned, to indicate that wipe local keys when a device is decommissioned to indicate that the
the device is no longer owned by the enterprise. The manufacturer's device is no longer owned by the enterprise. The manufacturer's
Initial identity keys must be preserved, as they contain no initial identity keys must be preserved, as they contain no
information that's not already printed on the device's serial number information that's not already printed on the device's serial number
plate. plate.
5.5. Other Factors for Trustworthy Operation 5.5. Other Factors for Trustworthy Operation
In addition to trustworthy provisioning of keys, RIV depends on a In addition to the trustworthy provisioning of keys, RIV depends on a
number of other factors for trustworthy operation. number of other factors for trustworthy operation.
* Secure identity depends on mechanisms to prevent per-device secret * Secure identity depends on mechanisms to prevent per-device secret
keys from being compromised. The TPM provides this capability as keys from being compromised. The TPM provides this capability as
a Root of Trust for Storage. a Root of Trust for Storage.
* Attestation depends on an unbroken chain of measurements, starting * Attestation depends on an unbroken chain of measurements, starting
from the very first measurement. See Section 9.1 for background from the very first measurement. See Appendix A.1 for background
on TPM practices. on TPM practices.
* That first measurement is made by code called the Root of Trust * That first measurement is made by code called the RTM, typically
for Measurement, typically done by trusted firmware stored in boot done by trusted firmware stored in boot flash. Mechanisms for
flash. Mechanisms for maintaining the trustworthiness of the RTM maintaining the trustworthiness of the RTM are out of scope for
are out of scope for RIV, but could include immutable firmware, RIV, but could include immutable firmware, signed updates, or a
signed updates, or a vendor-specific hardware verification vendor-specific hardware verification technique. See Appendix A.2
technique. See Section 9.2 for background on roots of trust. for background on Roots of Trust.
* The device owner SHOULD provide some level of physical defense for * The device owner SHOULD provide some level of physical defense for
the device. If a TPM that has already been programmed with an the device. If a TPM that has already been programmed with an
authentic DevID is stolen and inserted into a counterfeit device, authentic DevID is stolen and is inserted into a counterfeit
attestation of that counterfeit device may become device, attestation of that counterfeit device may become
indistinguishable from an authentic device. indistinguishable from an authentic device.
RIV also depends on reliable Reference Values, as expressed by the RIV also depends on reliable Reference Values, as expressed by the
RIM [RIM]. The definition of trust procedures for RIMs is out of 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 scope for RIV, and the device owner is free to use any policy to
validate a set of reference measurements. It should also be noted validate a set of reference measurements. It should also be noted
that, while RIV can provide a reliable indication that a known that, while RIV can provide a reliable indication that a known
software package is in use by the device, and that the package has software package is in use by the device and that the package has not
not been tampered, it is the device owner's responsibility to been tampered with, it is the device owner's responsibility to
determine that it's the correct package for the application. determine that it's the correct package for the application.
RIMs may be conveyed out-of-band or in-band, as part of the RIMs may be conveyed either out-of-band or in-band as part of the
attestation process (see Section 3.1.3). But for network devices, attestation process (see Section 3.1.3). However, for network
where software is usually shipped as a self-contained package, RIMs devices, where software is usually shipped as a self-contained
signed by the manufacturer and delivered in-band may be more package, RIMs signed by the manufacturer and delivered in-band may be
convenient for the device owner. more convenient for the device owner.
The validity of RIV attestation results is also influenced by The validity of RIV attestation results is also influenced by
procedures used to create Reference Values: procedures used to create Reference Values:
* While the RIM itself is signed, supply-chains SHOULD be carefully * While the RIM itself is signed, supply chains SHOULD be carefully
scrutinized to ensure that the values are not subject to scrutinized to ensure that the values are not subject to
unexpected manipulation prior to signing. Insider-attacks against unexpected manipulation prior to signing. Insider attacks against
code bases and build chains are particularly hard to spot. code bases and build chains are particularly hard to spot.
* Designers SHOULD guard against hash collision attacks. Reference * Designers SHOULD guard against hash collision attacks. RIMs often
Integrity Manifests often give hashes for large objects of give hashes for large objects of indeterminate size. If one of
indeterminate size; if one of the measured objects can be replaced the measured objects can be replaced with an implant engineered to
with an implant engineered to produce the same hash, RIV will be produce the same hash, RIV will be unable to detect the
unable to detect the substitution. TPM1.2 uses SHA-1 hashes only, substitution. TPM 1.2 only uses SHA-1 hashes, which have been
which have been shown to be susceptible to collision attack. shown to be susceptible to collision attack. TPM 2.0 will produce
TPM2.0 will produce quotes with SHA-256, which so far has resisted quotes with SHA-256, which so far has resisted such attacks.
such attacks. Consequently, RIV implementations SHOULD use Consequently, RIV implementations SHOULD use TPM 2.0.
TPM2.0.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. Conclusion 7. Conclusion
TCG technologies can play an important part in the implementation of TCG technologies can play an important part in the implementation of
Remote Integrity Verification. Standards for many of the components RIV. Standards for many of the components needed for implementation
needed for implementation of RIV already exist: of RIV already exist:
* Platform identity can be based on IEEE 802.1AR Device Identity, * Platform identity can be based on IEEE 802.1AR DevID, coupled with
coupled with careful supply-chain management by the manufacturer. careful supply-chain management by the manufacturer.
* Complex supply chains can be certified using TCG Platform * Complex supply chains can be certified using TCG Platform
Certificates [Platform-Certificates]. Certificates [PLATFORM-CERTS].
* The TCG TAP mechanism coupled with [I-D.ietf-rats-yang-tpm-charra] * The TCG TAP mechanism coupled with [RFC9684] can be used to
can be used to retrieve attestation evidence. retrieve attestation evidence.
* Reference Values must be conveyed from the software authority * Reference Values must be conveyed from the software authority
(e.g., the manufacturer) in Reference Integrity Manifests, to the (e.g., the manufacturer) in RIMs to the system in which
system in which verification will take place. IETF and TCG SWID verification will take place. IETF and TCG SWID and CoSWID work
and CoSWID work ([I-D.ietf-sacm-coswid], [RIM]) forms the basis ([RFC9393] [RIM]) forms the basis for this function.
for this function.
8. Acknowledgements
The authors wish to thank numerous reviewers for generous assistance,
including William Bellingrath, Mark Baushke, Ned Smith, Henk
Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas
Hardjono, Bill Sulzen, Willard (Monty) Wiseman, Kathleen Moriarty,
Nancy Cam-Winget and Shwetha Bhandari
9. Appendix
9.1. Using a TPM for Attestation
The Trusted Platform Module and surrounding ecosystem provide three
interlocking capabilities to enable secure collection of evidence
from a remote device, Platform Configuration Registers (PCRs), a
Quote mechanism, and a standardized Event Log.
Each TPM has at least eight and at most twenty-four PCRs (depending
on the profile and vendor choices), each one large enough to hold one
hash value (SHA-1, SHA-256, and other hash algorithms can be used,
depending on TPM version). PCRs can't be accessed directly from
outside the chip, but the TPM interface provides a way to "extend" a
new security measurement hash into any PCR, a process by which the
existing value in the PCR is hashed with the new security measurement
hash, and the result placed back into the same PCR. The result is a
composite fingerprint comprising the hash of all the security
measurements extended into each PCR since the system 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 which event generated
the security measurement. The Event Log itself is protected against
accidental manipulation, but it is implicitly tamper-evident - any
verification process can read the security measurement hash from the
log events, compute the composite value and compare that to what
ended up in the PCR. If there's no discrepancy, the logs do provide
an accurate view of what was placed into the PCR.
Note that the composite hash-of-hashes recorded in PCRs is order-
dependent, resulting in different PCR values for different ordering
of the same set of events (e.g. Event A followed by Event B yields a
different PCR value than B followed by A). For single-threaded code,
where both the events and their order are fixed, a Verifier may
validate a single PCR value, and use the log only to diagnose a
mismatch from Reference Values. However, operating system code is
usually non-deterministic, meaning that there may never be a single
"known good" PCR value. In this case, the Verifier may have to
verify that the log is correct, and then analyze each item in the log
to determine if it represents an authorized event.
In a conventional TPM Attestation environment, the first measurement
must be made and extended into the TPM by trusted device code (called
the Root of Trust for Measurement, RTM). That first measurement
should cover the segment of code that is run immediately after the
RTM, which then measures the next code segment before running it, and
so on, forming an unbroken chain of trust. See [TCGRoT] for more on
Mutable vs Immutable roots of trust.
The TPM provides another mechanism called a Quote that can read the
current value of the PCRs and package them, along with the Verifier's
nonce, into a TPM-specific data structure signed by an Attestation
private key, known only to the TPM.
As noted above in Section 5 Security Considerations, it's important
to note that the Quote data structure is signed inside the TPM. The
trust model is preserved by retrieving the Quote in a way that does
not invalidate the signature, as specified in
[I-D.ietf-rats-yang-tpm-charra]. The structure of the command and
response for a quote, including its signature, as generated by the
TPM, can be seen in [TPM1.2] Part 3, Section 16.5, and [TPM2.0]
Section 18.4.2.
The Verifier uses the Quote and Log together. The Quote contains the
composite hash of the complete sequence of security measurement
hashes, signed by the TPM's private Attestation Key. The Log
contains a record of each measurement extended into the TPM's PCRs.
By computing the composite hash of all the measurements, the Verifier
can verify the integrity of the Event Log, even though the Event Log
itself is not signed. Each hash in the validated Event Log can then
be compared to corresponding expected values in the set of Reference
Values to validate overall system integrity.
A summary of information exchanged 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].
9.2. 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, that is,
some trustworthy mechanism that can compute the first measurement in
the chain of trust required to attest that each stage of system
startup is verified, 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.
While there are many complex aspects of Roots of Trust ( [TCGRoT],
[SP800-155], [SP800-193]), two aspects that are important in the case
of attestation are:
* The first measurement computed by the Root of Trust for
Measurement, and stored in the TPM's Root of Trust for Storage,
must be assumed to be correct.
* 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 [SP800-155])
It's important to note that the trustworthiness of the RTM code
cannot be assured by the TPM or TPM supplier - code or procedures
external to the TPM must guarantee the security of the RTM.
9.3. Layering Model for Network Equipment Attester and Verifier
Retrieval of identity and attestation state uses one protocol stack,
while retrieval of Reference Values uses a different set of
protocols. Figure 5 shows the components involved.
+-----------------------+ +-------------------------+
| | | |
| Attester |<-------------| Verifier |
| (Device) |------------->| (Management Station) |
| | | | |
+-----------------------+ | +-------------------------+
|
-------------------- --------------------
| |
------------------------------- ---------------------------------
|Reference Values | | Attestation |
------------------------------- ---------------------------------
********************************************************************
* IETF Attestation Reference Interaction Diagram *
********************************************************************
......................... .........................
. Reference Integrity . . TAP (PTS2.0) Info .
. Manifest . . Model and Canonical .
. . . Log Format .
......................... .........................
************************* *************************
* YANG SWID Module * * YANG Attestation *
* I-D.ietf-sacm-coswid * * Module *
* * * I-D.ietf-rats- *
* * * yang-tpm-charra *
************************* *************************
************************* *************************
* XML, JSON, CBOR (etc) * * XML, JSON, CBOR (etc) *
************************* *************************
************************* *************************
* RESTCONF/NETCONF * * RESTCONF/NETCONF *
************************* *************************
************************* *************************
* TLS, SSH * * TLS, SSH *
************************* *************************
Figure 6: RIV Protocol Stacks
IETF documents are captured in boxes surrounded by asterisks. TCG
documents are shown in boxes surrounded by dots.
9.4. Implementation Notes
Figure 7 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.
As noted, SWID tags can be generated many ways, but one possible tool
is [SWID-Gen]
+------------------------------------------------------------------+
| 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 |[Platform-DevID-TPM-2.0]|
| 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 |
| | configuring TLS|
| | to use the DevID |
| | as its client |
| | certificate) |
--------------------------------------------------------------------
| Make CoSWID tags for BIOS/Loader/Kernel 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 | I-D.ietf-sacm-coswid|
| 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 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 7: Component Status
10. References
10.1. Normative References
[Canonical-Event-Log]
Trusted Computing Group, "Canonical Event Log Format
Version 1.0 Revision .41, February 25, 2022", December
2020, <https://trustedcomputinggroup.org/resource/
canonical-event-log-format/>.
[I-D.ietf-rats-architecture] 8. References
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", Work
in Progress, Internet-Draft, draft-ietf-rats-architecture-
15, 8 February 2022, <https://www.ietf.org/archive/id/
draft-ietf-rats-architecture-15.txt>.
[I-D.ietf-rats-yang-tpm-charra] 8.1. Normative References
Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen,
B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A
YANG Data Model for Challenge-Response-based Remote
Attestation Procedures using TPMs", Work in Progress,
Internet-Draft, draft-ietf-rats-yang-tpm-charra-18, 20
March 2022, <https://www.ietf.org/archive/id/draft-ietf-
rats-yang-tpm-charra-18.txt>.
[I-D.ietf-sacm-coswid] [CEL] Trusted Computing Group, "Canonical Event Log Format",
Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Version 1.0, Revision 0.41, February 2022,
Waltermire, "Concise Software Identification Tags", Work <https://trustedcomputinggroup.org/wp-content/uploads/
in Progress, Internet-Draft, draft-ietf-sacm-coswid-21, 7 TCG_IWG_CEL_v1_r0p41_pub.pdf>.
March 2022, <https://www.ietf.org/archive/id/draft-ietf-
sacm-coswid-21.txt>.
[IEEE-802-1AR] [IEEE-802-1AR]
Seaman, M., "802.1AR-2018 - IEEE Standard for Local and IEEE, "IEEE Standard for Local and Metropolitan Area
Metropolitan Area Networks - Secure Device Identity, IEEE Networks - Secure Device Identity", IEEE Std 802.1AR-2018,
Computer Society", August 2018. DOI 10.1109/IEEESTD.2018.8423794, August 2018,
<https://doi.org/10.1109/IEEESTD.2018.8423794>.
[IMA] dsafford, kds_etu, mzohar, reinersailer, and serge_hallyn, [IMA] The kernel development community, "dm-ima", Linux Kernel
"Integrity Measurement Architecture", June 2019, 6.11, 15 September 2024,
<https://sourceforge.net/p/linux-ima/wiki/Home/>. <https://www.kernel.org/doc/html/v6.11/admin-guide/device-
mapper/dm-ima.html>. The latest version can be found at
https://docs.kernel.org/admin-guide/device-mapper/dm-
ima.html.
[PC-Client-BIOS-TPM-2.0] [PC-CLIENT-BIOS-TPM-2.0]
Trusted Computing Group, "PC Client Specific Platform Trusted Computing Group, "TCG PC Client Specific Platform
Firmware Profile Specification Family "2.0", Level 00 Firmware Profile Specification", Family "2.0", Level 00,
Revision 1.05 Revision 23, May 7, 2021", May 2021, Version 1.05, Revision 23, May 2021,
<https://trustedcomputinggroup.org/resource/pc-client- <https://trustedcomputinggroup.org/resource/pc-client-
specific-platform-firmware-profile-specification/>. specific-platform-firmware-profile-specification/>.
[PC-Client-EFI-TPM-1.2] [PC-CLIENT-EFI-TPM-1.2]
Trusted Computing Group, "TCG EFI Platform Specification Trusted Computing Group, "TCG EFI Platform Specification",
for TPM Family 1.1 or 1.2, Specification Version 1.22, For TPM Family 1.1 or 1.2, Version 1.22, Revision 15,
Revision 15", January 2014, January 2014, <https://trustedcomputinggroup.org/resource/
<https://trustedcomputinggroup.org/resource/tcg-efi- tcg-efi-platform-specification/>.
platform-specification/>.
[PC-Client-RIM] [PC-CLIENT-RIM]
Trusted Computing Group, "TCG PC Client Reference Trusted Computing Group, "TCG PC Client Reference
Integrity Manifest Specification, v1.04, Nov 4, 2020", Integrity Manifest Specification", Version 1.04, November
December 2019, 2020, <https://trustedcomputinggroup.org/resource/tcg-pc-
<https://trustedcomputinggroup.org/resource/tcg-pc-client- client-reference-integrity-manifest-specification/>.
reference-integrity-manifest-specification/>.
[Platform-DevID-TPM-2.0] [PLATFORM-DEVID-TPM-2.0]
Trusted Computing Group, "TPM 2.0 Keys for Device Identity Trusted Computing Group, "TPM 2.0 Keys for Device Identity
and Attestation, Specification Version 1.0, Revision 2", and Attestation", Version 1.00, Revision 12, October 2021,
September 2020,
<https://trustedcomputinggroup.org/resource/tpm-2-0-keys- <https://trustedcomputinggroup.org/resource/tpm-2-0-keys-
for-device-identity-and-attestation/>. for-device-identity-and-attestation/>.
[Platform-ID-TPM-1.2] [PLATFORM-ID-TPM-1.2]
Trusted Computing Group, "TPM Keys for Platform Identity Trusted Computing Group, "TCG Infrastructure WG TPM Keys
for TPM 1.2, Specification Version 1.0, Revision 3", for Platform Identity for TPM 1.2", Specification Version
August 2015, <https://trustedcomputinggroup.org/resource/ 1.0, Revision 3, August 2015,
tpm-keys-for-platform-identity-for-tpm-1-2-2/>. <https://trustedcomputinggroup.org/resource/tpm-keys-for-
platform-identity-for-tpm-1-2-2/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>. January 2006, <https://www.rfc-editor.org/info/rfc4253>.
skipping to change at page 41, line 5 skipping to change at line 1540
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC9393] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
Waltermire, "Concise Software Identification Tags",
RFC 9393, DOI 10.17487/RFC9393, June 2023,
<https://www.rfc-editor.org/info/rfc9393>.
[RFC9684] Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen,
B., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data
Model for Challenge-Response-Based Remote Attestation
(CHARRA) Procedures Using Trusted Platform Modules
(TPMs)", RFC 9684, DOI 10.17487/RFC9684, October 2024,
<https://www.rfc-editor.org/info/rfc9684>.
[RIM] Trusted Computing Group, "TCG Reference Integrity Manifest [RIM] Trusted Computing Group, "TCG Reference Integrity Manifest
(RIM) Information Model, v1.0, Revision 0.16, Nov 12, (RIM) Information Model", Version 1.01, Revision 0.16,
2020", June 2019, November 2020,
<https://trustedcomputinggroup.org/resource/tcg-reference- <https://trustedcomputinggroup.org/resource/tcg-reference-
integrity-manifest-rim-information-model/>. integrity-manifest-rim-information-model/>.
[SWID] The International Organization for Standardization/ [SWID] ISO/IEC, "Information technology - IT asset management -
International Electrotechnical Commission, "Information Part 2: Software identification tag", ISO/
Technology Software Asset Management Part 2: Software IEC 19770-2:2015, October 2015,
Identification Tag, ISO/IEC 19770-2", October 2015,
<https://www.iso.org/standard/65666.html>. <https://www.iso.org/standard/65666.html>.
[TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol [TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol
(TAP) Information Model for TPM Families 1.2 and 2.0 and (TAP) Information Model for TPM Families 1.2 and 2.0 and
DICE Family 1.0, Version 1.0, Revision 0.36", October DICE Family 1.0", Version 1.0, Revision 0.36, October
2018, <https://trustedcomputinggroup.org/resource/tcg-tap- 2018, <https://trustedcomputinggroup.org/wp-
information-model/>. content/uploads/
TNC_TAP_Information_Model_v1.00_r0.36-FINAL.pdf>.
10.2. Informative References 8.2. Informative References
[AK-Enrollment] [AIK-ENROLL]
Trusted Computing Group, "TCG Infrastructure Working Group Trusted Computing Group, "TCG Infrastructure Working Group
- A CMC Profile for AIK Certificate Enrollment Version A CMC Profile for AIK Certificate Enrollment", Version
1.0, Revision 7", March 2011, 1.0, Revision 7, March 2011,
<https://trustedcomputinggroup.org/resource/tcg- <https://trustedcomputinggroup.org/resource/tcg-
infrastructure-working-group-a-cmc-profile-for-aik- infrastructure-working-group-a-cmc-profile-for-aik-
certificate-enrollment/>. certificate-enrollment/>.
[I-D.birkholz-rats-network-device-subscription]
Birkholz, H., Voit, E., and W. Pan, "Attestation Event
Stream Subscription", Work in Progress, Internet-Draft,
draft-birkholz-rats-network-device-subscription-03, 17
August 2021, <https://www.ietf.org/archive/id/draft-
birkholz-rats-network-device-subscription-03.txt>.
[I-D.birkholz-rats-reference-interaction-model]
Birkholz, H., Eckel, M., Newton, C., and L. Chen,
"Reference Interaction Models for Remote Attestation
Procedures", Work in Progress, Internet-Draft, draft-
birkholz-rats-reference-interaction-model-03, 7 July 2020,
<https://www.ietf.org/archive/id/draft-birkholz-rats-
reference-interaction-model-03.txt>.
[I-D.birkholz-rats-tuda]
Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann,
"Time-Based Uni-Directional Attestation", Work in
Progress, Internet-Draft, draft-birkholz-rats-tuda-06, 12
January 2022, <https://www.ietf.org/archive/id/draft-
birkholz-rats-tuda-06.txt>.
[I-D.ietf-rats-eat]
Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity
Attestation Token (EAT)", Work in Progress, Internet-
Draft, draft-ietf-rats-eat-12, 24 February 2022,
<https://www.ietf.org/archive/id/draft-ietf-rats-eat-
12.txt>.
[I-D.richardson-rats-usecases]
Richardson, M., Wallace, C., and W. Pan, "Use cases for
Remote Attestation common encodings", Work in Progress,
Internet-Draft, draft-richardson-rats-usecases-08, 2
November 2020, <https://www.ietf.org/archive/id/draft-
richardson-rats-usecases-08.txt>.
[IEEE-802.1AE] [IEEE-802.1AE]
Seaman, M., "802.1AE MAC Security (MACsec)", 2018, IEEE, "IEEE Standard for Local and metropolitan area
<https://1.ieee802.org/security/802-1ae/>. networks - Media Access Control (MAC) Security", IEEE Std
802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, 2018,
<https://doi.org/10.1109/IEEESTD.2018.8585421>.
[IEEE-802.1X] [IEEE-802.1X]
IEEE Computer Society, "802.1X-2020 - IEEE Standard for IEEE, "IEEE Standard for Local and Metropolitan Area
Local and Metropolitan Area Networks--Port-Based Network Networks - Port-Based Network Access Control", IEEE Std
Access Control", February 2020, 802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, February
<https://standards.ieee.org/standard/802_1X-2020.html>. 2020, <https://doi.org/10.1109/IEEESTD.2020.9018454>.
[LLDP] IEEE Computer Society, "802.1AB-2016 - IEEE Standard for [LLDP] IEEE, "IEEE Standard for Local and metropolitan area
Local and metropolitan area networks - Station and Media networks - Station and Media Access Control Connectivity
Access Control Connectivity Discovery", March 2016, Discovery", IEEE Std 802.1AB-2016,
<https://standards.ieee.org/standard/802_1AB-2016.html>. DOI 10.1109/IEEESTD.2016.7433915, March 2016,
<https://doi.org/10.1109/IEEESTD.2016.7433915>.
[NetEq] Trusted Computing Group, "TCG Guidance for Securing [NET-EQ] Trusted Computing Group, "TCG Guidance for Securing
Network Equipment, Version 1.0, Revision 29", January Network Equipment Using TCG Technology", Version 1.0,
2018, <https://trustedcomputinggroup.org/resource/tcg- Revision 29, January 2018,
guidance-securing-network-equipment/>. <https://trustedcomputinggroup.org/resource/tcg-guidance-
securing-network-equipment/>.
[NIST-IR-8060] [NIST-IR-8060]
National Institute for Standards and Technology, Waltermire, D., Cheikes, B. A., Feldman, L., and G. Witte,
"Guidelines for the Creation of Interoperable Software "Guidelines for the Creation of Interoperable Software
Identification (SWID) Tags", April 2016, Identification (SWID) Tags", NIST NISTIR 8060,
DOI 10.6028/NIST.IR.8060, April 2016,
<https://nvlpubs.nist.gov/nistpubs/ir/2016/ <https://nvlpubs.nist.gov/nistpubs/ir/2016/
NIST.IR.8060.pdf>. NIST.IR.8060.pdf>.
[Platform-Certificates] [PLATFORM-CERTS]
Trusted Computing Group, "TCG Platform Attribute Trusted Computing Group, "TCG Platform Attribute
Credential Profile, Specification Version 1.0, Revision Credential Profile", Specification Version 1.0, Revision
16", January 2018, 16, January 2018,
<https://trustedcomputinggroup.org/resource/tcg-platform- <https://trustedcomputinggroup.org/resource/tcg-platform-
attribute-credential-profile/>. attribute-credential-profile/>.
[Provisioning-TPM-2.0] [PROV-TPM-2.0]
Trusted Computing Group, "TCG TPM v2.0 Provisioning Trusted Computing Group, "TCG TPM v2.0 Provisioning
Guidance, Version 1.0, Revision 1.0", March 2015, Guidance", Version 1.0, Revision 1.0, March 2017,
<https://trustedcomputinggroup.org/wp-content/uploads/TCG- <https://trustedcomputinggroup.org/wp-content/uploads/TCG-
TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf>. TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf>.
[RATS-EAT] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", Work in
Progress, Internet-Draft, draft-ietf-rats-eat-31, 6
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-eat-31>.
[RATS-INTERACTION-MODELS]
Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference
Interaction Models for Remote Attestation Procedures",
Work in Progress, Internet-Draft, draft-ietf-rats-
reference-interaction-models-11, 22 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
reference-interaction-models-11>.
[RATS-NET-DEV-SUB]
Birkholz, H., Voit, E., and W. Pan, "Attestation Event
Stream Subscription", Work in Progress, Internet-Draft,
draft-ietf-rats-network-device-subscription-05, 7 July
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
rats-network-device-subscription-05>.
[RATS-TUDA]
Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
"Time-Based Uni-Directional Attestation", Work in
Progress, Internet-Draft, draft-birkholz-rats-tuda-07, 10
July 2022, <https://datatracker.ietf.org/doc/html/draft-
birkholz-rats-tuda-07>.
[RATS-USECASES]
Richardson, M., Wallace, C., and W. Pan, "Use cases for
Remote Attestation common encodings", Work in Progress,
Internet-Draft, draft-richardson-rats-usecases-08, 2
November 2020, <https://datatracker.ietf.org/doc/html/
draft-richardson-rats-usecases-08>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment [RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment
(NEA) Asokan Attack Analysis", RFC 6813, (NEA) Asokan Attack Analysis", RFC 6813,
DOI 10.17487/RFC6813, December 2012, DOI 10.17487/RFC6813, December 2012,
<https://www.rfc-editor.org/info/rfc6813>. <https://www.rfc-editor.org/info/rfc6813>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572, Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019, DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>. <https://www.rfc-editor.org/info/rfc8572>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>. May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[SP800-155] [SP800-155]
National Institute of Standards and Technology, "BIOS NIST, "BIOS Integrity Measurement Guidelines (Draft)",
Integrity Measurement Guidelines (Draft)", December 2011, NIST SP 800-155 (Draft), December 2011,
<https://csrc.nist.gov/csrc/media/publications/sp/800- <https://csrc.nist.gov/files/pubs/sp/800/155/ipd/docs/
155/draft/documents/draft-sp800-155_dec2011.pdf>. draft-sp800-155_dec2011.pdf>.
[SP800-193] [SP800-193]
National Institute for Standards and Technology, "NIST NIST, "Platform Firmware Resiliency Guidelines", NIST
Special Publication 800-193: Platform Firmware Resiliency SP 800-193, DOI 10.6028/NIST.SP.800-193, May 2018,
Guidelines", April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-193.pdf>. NIST.SP.800-193.pdf>.
[SWID-Gen] Labs64, Munich, Germany, "SoftWare IDentification (SWID) [SWID-GEN] Labs64, "SoftWare IDentification (SWID) Tags Generator
Tags Generator (Maven Plugin)", n.d., (Maven Plugin)",
<https://github.com/Labs64/swid-maven-plugin>. <https://github.com/Labs64/swid-maven-plugin>.
[TCGRoT] Trusted Computing Group, "DRAFT: TCG Roots of Trust [TCG-RT] Trusted Computing Group, "TCG Roots of Trust
Specification", October 2018, Specification", (Draft), Family "1.0", Level 00, Revision
<https://trustedcomputinggroup.org/wp-content/uploads/ 0.20, July 2018, <https://trustedcomputinggroup.org/wp-
content/uploads/
TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf>. TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf>.
[TPM1.2] Trusted Computing Group, "TPM Main Specification Level 2 [TPM-1.2] Trusted Computing Group, "TPM 1.2 Main Specification",
Version 1.2, Revision 116", March 2011, Level 2, Version 1.2, Revision 116, March 2011,
<https://trustedcomputinggroup.org/resource/tpm-main- <https://trustedcomputinggroup.org/resource/tpm-main-
specification/>. specification/>.
[TPM2.0] Trusted Computing Group, "Trusted Platform Module Library [TPM-2.0] Trusted Computing Group, "Trusted Platform Module
Specification, Family "2.0", Level 00, Revision 01.59", Library", Family "2.0", Level 00, Revision 01.83, March
November 2019, 2024, <https://trustedcomputinggroup.org/resource/tpm-
<https://trustedcomputinggroup.org/resource/tpm-library- library-specification/>.
specification/>.
Appendix A. Supporting Materials
A.1. Using a TPM for Attestation
The TPM and surrounding ecosystem provide three interlocking
capabilities to enable secure collection of evidence from a remote
device: PCRs, a Quote mechanism, and a standardized Event Log.
Each TPM has at least eight and at most twenty-four PCRs (depending
on the profile and vendor choices), each one large enough to hold one
hash value (SHA-1, SHA-256, and other hash algorithms can be used,
depending on TPM version). PCRs can't be accessed directly from
outside the chip, but the TPM interface provides a way to "extend" a
new security measurement hash into any PCR, a process by which the
existing value in the PCR is hashed with the new security measurement
hash, and the result placed back into the same PCR. The result is a
composite fingerprint comprising the hash of all the security
measurements extended into each PCR since the system 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 which event generated
the security measurement. The Event Log itself is protected against
accidental manipulation, but it is implicitly tamper-evident: Any
verification process can read the security measurement hash from the
log events, compute the composite value, and compare that to what is
in the PCR. If there's no discrepancy, the logs do provide an
accurate view of what was placed into the PCR.
Note that the composite hash-of-hashes recorded in PCRs is order-
dependent, resulting in different PCR values for different ordering
of the same set of events (e.g., Event A followed by Event B yields a
different PCR value than B followed by A). For single-threaded code,
where both the events and their order are fixed, a Verifier may
validate a single PCR value, and use the log only to diagnose a
mismatch from Reference Values. However, operating system code is
usually nondeterministic, meaning that there may never be a single
"known good" PCR value. In this case, the Verifier may have to
verify that the log is correct, and then analyze each item in the log
to determine if it represents an authorized event.
In a conventional TPM Attestation environment, the first measurement
must be made and extended into the TPM by trusted device code (called
the RTM). That first measurement should cover the segment of code
that is run immediately after the RTM, which then measures the next
code segment before running it, and so on, forming an unbroken chain
of trust. See [TCG-RT] for more on Mutable vs. Immutable Roots of
Trust.
The TPM provides another mechanism called a Quote that can read the
current value of the PCRs and package them, along with the Verifier's
nonce, into a TPM-specific data structure signed by an Attestation
private key, known only to the TPM.
It's important to note that the Quote data structure is signed inside
the TPM (see Section 5, Security Considerations). The trust model is
preserved by retrieving the Quote in a way that does not invalidate
the signature, as specified in [RFC9684]. The structure of the
command and response for a quote, including its signature, as
generated by the TPM, can be seen in Part 3, Section 16.5, of
[TPM-1.2] and Section 18.4.2 of [TPM-2.0].
The Verifier uses the Quote and Log together. The Quote contains the
composite hash of the complete sequence of security measurement
hashes, signed by the TPM's private AK. The Log contains a record of
each measurement extended into the TPM's PCRs. By computing the
composite hash of all the measurements, the Verifier can verify the
integrity of the Event Log, even though the Event Log itself is not
signed. Each hash in the validated Event Log can then be compared to
corresponding expected values in the set of Reference Values to
validate overall system integrity.
A summary of information exchanged in obtaining quotes from TPM 1.2
and TPM 2.0 can be found in [TAP], Section 4. Detailed information
about PCRs and Quote data structures can be found in [TPM-1.2],
[TPM-2.0]. Recommended log formats include [PC-CLIENT-BIOS-TPM-2.0],
and [CEL].
A.2. Root of Trust for Measurement (RTM)
The measurements needed for attestation require that the device being
attested is equipped with an RTM, that is, some trustworthy mechanism
that can compute the first measurement in the chain of trust required
to attest that each stage of system startup is verified, 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.
While there are many complex aspects of Roots of Trust ([TCG-RT]
[SP800-155] [SP800-193]), two aspects that are important in the case
of attestation are:
* The first measurement computed by the RTM and stored in the TPM's
Root of Trust for Storage must be assumed to be correct.
* There must not be a way to reset the Root of Trust for Storage
without re-entering the RTM 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 [SP800-155].)
It's important to note that the trustworthiness of the RTM code
cannot be assured by the TPM or TPM supplier -- code or procedures
external to the TPM must guarantee the security of the RTM.
A.3. Layering Model for Network Equipment Attester and Verifier
Retrieval of identity and attestation state uses one protocol stack,
while retrieval of Reference Values uses a different set of
protocols. Figure 5 shows the components involved.
+-----------------------+ +-------------------------+
| | | |
| Attester |<-------------| Verifier |
| (Device) |------------->| (Management Station) |
| | | | |
+-----------------------+ | +-------------------------+
|
-------------------- --------------------
| |
------------------------------- ---------------------------------
| Reference Values | | Attestation |
------------------------------- ---------------------------------
********************************************************************
* IETF Remote Attestation Conceptual Data Flow *
* RFC9334, Figure 1 *
********************************************************************
......................... .........................
. Reference Integrity . . TAP Info .
. Manifest . . Model and Canonical .
. . . Log Format .
......................... .........................
************************* *************************
* YANG SWID Module * * YANG Attestation *
* RFC9393 * * Module *
* * * RFC9684 *
* * * *
************************* *************************
************************* *************************
* XML, JSON, CBOR, etc. * * XML, JSON, CBOR, etc. *
************************* *************************
************************* *************************
* RESTCONF/NETCONF * * RESTCONF/NETCONF *
************************* *************************
************************* *************************
* TLS, SSH * * TLS, SSH *
************************* *************************
Figure 5: RIV Protocol Stacks
IETF documents are captured in boxes surrounded by asterisks. TCG
documents are shown in boxes surrounded by dots.
A.4. Implementation Notes
Table 2 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.
As noted, SWID tags can be generated many ways, but one possible tool
is [SWID-GEN].
+========================================+==========================+
| Component | Controlling |
| | Specification |
+========================================+==========================+
| Make a Secure execution environment: | [TCG-RT] |
| | |
| * Attestation depends on a secure | <www.uefi.org> |
| RTM outside the TPM, as well as | |
| Roots for Storage and Reporting | |
| inside the TPM. | |
| | |
| * Refer to "TCG Roots of Trust | |
| Specification" [TCG-RT]. | |
| | |
| * [SP800-193] also provides | |
| guidelines on Roots of Trust. | |
+----------------------------------------+--------------------------+
| Provision the TPM as described in the | [PLATFORM-DEVID-TPM-2.0] |
| TCG documents. | |
| | [PLATFORM-CERTS] |
+----------------------------------------+--------------------------+
| Put a DevID or Platform Certificate | [PLATFORM-DEVID-TPM-2.0] |
| in the TPM: | |
| | [PLATFORM-CERTS] |
| * Install an IAK at the same time so +--------------------------+
| that Attestation can work out of | [IEEE-802-1AR] |
+----------------------------------------+--------------------------+
| Connect the TPM to the TLS stack: | Vendor TLS stack (This |
| | action configures TLS to |
| * Use the DevID in the TPM to | use the DevID as its |
| authenticate TAP connections, | client certificate) |
| identifying the device | |
+----------------------------------------+--------------------------+
| Make CoSWID tags for BIOS/Loader/ | [RFC9393] |
| Kernel objects: | |
| | [SWID] |
| * Add reference measurements into | |
| SWID tags. | [NIST-IR-8060] |
| | |
| * Manufacturer should sign the SWID | |
| tags. | |
| | |
| * The TCG RIM-IM [RIM] identifies | |
| further procedures to create | |
| signed RIM documents that provide | |
| the necessary reference | |
| information. | |
+----------------------------------------+--------------------------+
| Package the SWID tags with a vendor | Retrieve tags with |
| software release: | [RFC9393]. |
| +--------------------------+
| * A tag-generator plugin such as | [PC-CLIENT-RIM] |
+----------------------------------------+--------------------------+
| Use PC Client measurement definitions | [PC-CLIENT-BIOS-TPM-2.0] |
| to define the use of PCRs (although | |
| Windows OS is rare on Networking | |
| Equipment, UEFI BIOS is not). | |
+----------------------------------------+--------------------------+
| Use TAP to retrieve measurements: | [RFC9684] |
| | |
| * Map to YANG. | [CEL] |
| | |
| * Use Canonical Log Format. | |
+----------------------------------------+--------------------------+
| A Verifier (as described in | |
| [RFC9334], Section 3) should request | |
| the attestation and analyze the | |
| result. The Verifier application | |
| might be broken down to several more | |
| components: | |
| | |
| * A Posture Manager Server that | |
| collects reports and stores them | |
| in a database. | |
| | |
| * One or more Analyzers that can | |
| look at the results and figure out | |
| what it means. | |
+----------------------------------------+--------------------------+
Table 2: Component Status
Acknowledgements
The authors wish to thank numerous reviewers for generous assistance,
including William Bellingrath, Mark Baushke, Ned Smith, Henk
Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas
Hardjono, Bill Sulzen, Willard (Monty) Wiseman, Kathleen Moriarty,
Nancy Cam-Winget, and Shwetha Bhandari.
Authors' Addresses Authors' Addresses
Guy Fedorkow (editor) Guy C. Fedorkow (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
United States of America United States of America
Email: gfedorkow@juniper.net Email: gfedorkow@juniper.net
Eric Voit Eric Voit
Cisco Systems Cisco Systems
Email: evoit@cisco.com Email: evoit@cisco.com
Jessica Fitzgerald-McKay Jessica Fitzgerald-McKay
National Security Agency National Security Agency
9800 Savage Road 9800 Savage Road
Ft. Meade, Maryland 20755 Ft. Meade, Maryland 20755
United States of America United States of America
Email: jmfitz2@nsa.gov Email: jmfitz2@nsa.gov
 End of changes. 245 change blocks. 
1153 lines changed or deleted 1139 lines changed or added

This html diff was produced by rfcdiff 1.48.