draft-ietf-rats-tpm-based-network-device-attest-04.txt   draft-ietf-rats-tpm-based-network-device-attest-05.txt 
RATS Working Group G. Fedorkow, Ed. RATS Working Group G. Fedorkow, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Informational E. Voit Intended status: Informational E. Voit
Expires: March 22, 2021 Cisco Systems, Inc. Expires: April 29, 2021 Cisco Systems, Inc.
J. Fitzgerald-McKay J. Fitzgerald-McKay
National Security Agency National Security Agency
September 18, 2020 October 26, 2020
TPM-based Network Device Remote Integrity Verification TPM-based Network Device Remote Integrity Verification
draft-ietf-rats-tpm-based-network-device-attest-04 draft-ietf-rats-tpm-based-network-device-attest-05
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]. contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by
the Trusted Computing Group (TCG).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 22, 2021. This Internet-Draft will expire on April 29, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1.2. Document Organization . . . . . . . . . . . . . . . . . . 4 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4
1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Description of Remote Integrity Verification (RIV) . . . 5 1.4. Description of Remote Integrity Verification (RIV) . . . 5
1.5. Solution Requirements . . . . . . . . . . . . . . . . . . 7 1.5. Solution Requirements . . . . . . . . . . . . . . . . . . 7
1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8 1.6.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9
2.1. RIV Software Configuration Attestation using TPM . . . . 9 2.1. RIV Software Configuration Attestation using TPM . . . . 9
2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 10 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 10
2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 12 2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 12
2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 14 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 15
2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 16 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 17
2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 17 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 18
2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 18 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 19
3. Standards Components . . . . . . . . . . . . . . . . . . . . 19 3. Standards Components . . . . . . . . . . . . . . . . . . . . 19
3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 19 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 19
3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 19 3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 20
3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 19 3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 20
3.2. Reference Model for Challenge-Response . . . . . . . . . 20 3.2. Reference Model for Challenge-Response . . . . . . . . . 21
3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 22 3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 23
3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 23 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 25 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 26
5.2. Prevention of Spoofing and Man-in-the-Middle Attacks . . 27 5.2. Prevention of Spoofing and Man-in-the-Middle Attacks . . 28
5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 28 5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29
5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 28 5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 29
5.5. Other Trust Anchors . . . . . . . . . . . . . . . . . . . 29 5.5. Other Factors for Trustworthy Operation . . . . . . . . . 30
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 30 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 30 8.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 32
8.2. Root of Trust for Measurement . . . . . . . . . . . . . . 32 8.2. Root of Trust for Measurement . . . . . . . . . . . . . . 33
8.3. Layering Model for Network Equipment Attester and 8.3. Layering Model for Network Equipment Attester and
Verifier . . . . . . . . . . . . . . . . . . . . . . . . 32 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 34
8.3.1. Why is OS Attestation Different? . . . . . . . . . . 34 8.4. Implementation Notes . . . . . . . . . . . . . . . . . . 36
8.4. Implementation Notes . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.1. Normative References . . . . . . . . . . . . . . . . . . 37
9.1. Normative References . . . . . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . . . . . 40
9.2. Informative References . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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 which need to be considered concurrently to have confidence that a
device is truly trustworthy. device is truly trustworthy.
skipping to change at page 3, line 37 skipping to change at page 3, line 37
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 will be the availability within the device of a Trusted
Platform Module [TPM1.2], [TPM2.0] compliant cryptoprocessor to Platform Module [TPM1.2], [TPM2.0] compliant cryptoprocessor to
enable the trustworthy remote assessment of the device's software and enable the trustworthy remote assessment of the device's software and
hardware. hardware.
1.1. Terminology 1.1. Terminology
A number of terms are reused from [I-D.ietf-rats-architecture]. A number of terms are reused from [I-D.ietf-rats-architecture].
These include: Appraisal Policy for Attestation Results, Attestation These include: Appraisal Policy for Evidence, Attestation Result,
Result, Attester, Evidence, Relying Party, Verifier, and Verifier Attester, Evidence, Reference Value, Relying Party, Verifier, and
Owner. Verifier Owner.
Additionally, this document defines the following terms:
Remote Attestation: the process of creating, conveying and appraising Additionally, this document defines the following term:
claims about device trustworthiness characteristics, including supply
chain trust, identity, device provenance, software configuration,
hardware configuration, device composition, compliance to test
suites, functional and assurance evaluations, etc.
This document uses the term Endorser to refer to the trusted Attestation: the process of generating, conveying and appraising
authority for any signed object relating to the device, such as claims, backed by evidence, about device trustworthiness
certificates or reference measurement. Typically, the manufacturer characteristics, including supply chain trust, identity, device
of an embedded device would be accepted as an Endorser. provenance, software configuration, device composition, compliance to
test suites, functional and assurance evaluations, etc.
The goal of attestation is simply to assure an administrator that the The goal of attestation is simply to assure an administrator that the
software that was launched when the device was last started is an device configuration and software that was launched when the device
authentic and untampered-with copy of the software that the device was last started is authentic and untampered-with.
vendor shipped.
Within the Trusted Computing Group context, attestation is the Within the Trusted Computing Group (TCG) context, attestation is the
process by which an independent Verifier can obtain cryptographic process by which an independent Verifier can obtain cryptographic
proof as to the identity of the device in question, and evidence of proof as to the identity of the device in question, and evidence of
the integrity of software loaded on that device when it started up, the integrity of software loaded on that device when it started up,
and then verify that what's there is what's supposed to be there. and then verify that what's there matches the intended configuration.
For networking equipment, a Verifier capability can be embedded in a For network equipment, a Verifier capability can be embedded in a
Network Management Station (NMS), a posture collection server, or Network Management Station (NMS), a posture collection server, or
other network analytics tool (such as a software asset management other network analytics tool (such as a software asset management
solution, or a threat detection and mitigation tool, etc.). While solution, or a threat detection and mitigation tool, etc.). While
informally referred to as attestation, this document focuses on a informally referred to as attestation, this document focuses on a
subset defined here as Remote Integrity Verification (RIV). RIV subset defined here as Remote Integrity Verification (RIV). RIV
takes a network equipment centric perspective that includes a set of takes a network equipment centric perspective that includes a set of
protocols and procedures for determining whether a particular device protocols and procedures for determining whether a particular device
was launched with authentic software, starting from Roots of Trust. was launched with authentic software, starting from Roots of Trust.
While there are many ways to accomplish attestation, RIV sets out a While there are many ways to accomplish attestation, RIV sets out a
specific set of protocols and tools that work in environments specific set of protocols and tools that work in environments
commonly found in Networking Equipment. RIV does not cover other commonly found in network equipment. RIV does not cover other device
device characteristics that could be attested (e.g., geographic characteristics that could be attested (e.g., geographic location,
location, connectivity; see [I-D.richardson-rats-usecases]), although connectivity; see [I-D.richardson-rats-usecases]), although it does
it does provide evidence of a secure infrastructure to increase the provide evidence of a secure infrastructure to increase the level of
level of trust in other device characteristics attested by other trust in other device characteristics attested by other means (e.g.,
means (e.g., by Entity Attestation Tokens [I-D.ietf-rats-eat]). by Entity Attestation Tokens [I-D.ietf-rats-eat]).
In line with [I-D.ietf-rats-architecture] definitions, this document
uses the term Endorser to refer to the role that signs identity and
attestation certificates used by the Attester, while Reference Values
are signed by a Reference Value Provider. Typically, the
manufacturer of an embedded device would be accepted as both the
Endorser and Reference Value Provider, although the choice is
ultimately up to the Verifier Owner.
1.2. Document Organization 1.2. Document Organization
The remainder of this document is organized into several sections: The remainder of this document is organized into several sections:
o The remainder of this section covers goals and requirements, plus o The remainder of this section covers goals and requirements, plus
a top-level description of RIV. a top-level description of RIV.
o The Solution Overview section outlines how Remote Integrity o The Solution Overview section outlines how Remote Integrity
Verification works. Verification works.
skipping to change at page 5, line 19 skipping to change at page 5, line 19
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:
o Provable Device Identity - This specification requires that an o Provable Device Identity - This specification requires that an
attesting device includes a cryptographic identifier unique to Attester (i.e., the attesting device) includes a cryptographic
each device. Effectively this means that the TPM must be so identifier unique to each device. Effectively this means that the
provisioned during the manufacturing cycle. TPM must be so provisioned during the manufacturing cycle.
o Software Inventory - A key goal is to identify the software o Software Inventory - A key goal is to identify the software
release(s) installed on the attesting device, and to provide release(s) installed on the Attester, and to provide evidence that
evidence that the software stored within hasn't been altered the software stored within hasn't been altered without
without authorization. authorization.
o Verifiability - Verification of software and configuration of the o Verifiability - Verification of software and configuration of the
device shows that the software that was authorized for device shows that the software that was authorized for
installation by the administrator has actually been launched. installation by the administrator has actually been 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, and also relationship. (See Section 3.3 below, and also
[I-D.voit-rats-trusted-path-routing]) [I-D.voit-rats-trusted-path-routing])
1.4. Description of Remote Integrity Verification (RIV) 1.4. Description of Remote Integrity Verification (RIV)
Attestation requires two interlocking services between the Attester Attestation requires two interlocking mechanisms between the Attester
network device and the Verifier: network device and the Verifier:
o Device Identity, the mechanism providing trusted identity, can o Device Identity, the mechanism providing trusted identity, can
reassure network managers that the specific devices they ordered reassure network managers that the specific devices they ordered
from authorized manufacturers for attachment to their network are from authorized manufacturers for attachment to their network are
those that were installed, and that they continue to be present in those that were installed, and that they continue to be present in
their network. As part of the mechanism for Device Identity, their network. As part of the mechanism for Device Identity,
cryptographic proof of the identity of the manufacturer is also cryptographic proof of the identity of the manufacturer is also
provided. provided.
o Software Measurement is the mechanism that reports the state of o Software Measurement is the mechanism that reports the state of
mutable software components on the device, and can assure network mutable software components on the device, and can assure network
managers that they have known, authentic software configured to managers that they have known, authentic software configured to
run in their network. run in their network.
Using these two interlocking services, RIV is a component in a chain Using these two interlocking mechanisms, RIV is a component in a
of procedures that can assure a network operator that the equipment chain of procedures that can assure a network operator that the
in their network can be reliably identified, and that authentic equipment in their network can be reliably identified, and that
software of a known version is installed on each device. Equipment authentic software of a known version is installed on each device.
in the network includes devices that make up the network itself, such Equipment in the network includes devices that make up the network
as routers, switches and firewalls. itself, such as routers, switches and firewalls.
Software used to boot a device can be described as recording a chain
of measurements, anchored at the start by a Root of Trust for
Measurement (see Section 8.2), each measuring the next stage, that
normally ends when the system software is loaded. A measurement
signifies the identity, integrity and version of each software
component registered with an Attester's TPM [TPM1.2], [TPM2.0], so
that a subsequent verification stage can determine if the software
installed is authentic, up-to-date, and free of tampering.
RIV includes several major processes: RIV includes several major processes:
1. Creation of Evidence is the process whereby an Attester generates 1. Generation of Evidence is the process whereby an Attester
cryptographic proof (Evidence) of claims about device properties. generates cryptographic proof (Evidence) of claims about device
In particular, the device identity and its software configuration properties. In particular, the device identity and its software
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 identity of devices that make up their network, and that their
manufacturers are known. manufacturers are known.
3. Software used to boot a device can be described as a chain of 3. Conveyance of Evidence reliably transports the collected Evidence
measurements, anchored at the start by a Root of Trust for from Attester to a Verifier to allow a management station to
Measurement, that normally ends when the system software is perform a meaningful appraisal in Step 4. The transport is
loaded. A measurement signifies the identity, integrity and typically carried out via a management network. The channel must
version of each software component registered with an attesting provide integrity and authenticity, and, in some use cases, may
device's TPM [TPM1.2], [TPM2.0], so that the subsequent appraisal also require confidentiality.
stage can determine if the software installed is authentic, up-
to-date, and free of tampering.
4. Conveyance of Evidence reliably transports at least the minimum
amount of Evidence from Attester to a Verifier to allow a
management station to perform a meaningful appraisal in Step 5.
The transport is typically carried out via a management network.
The channel must provide integrity and authenticity, and, in some
use cases, may also require confidentiality.
5. Finally, Appraisal of Evidence occurs. As the Verifier and 4. Finally, Appraisal of Evidence occurs. This is the process of
Relying Party roles are often combined within RIV, this is the verifying the Evidence received by a Verifier from the Attester,
process of verifying the Evidence received by a Verifier from the and using an Appraisal Policy to develop an Attestation Result,
Attesting device, and using an Appraisal Policy to develop an used to inform decision making. In practice, this means
Attestation Result, used to inform decision making. In practice, comparing the Attester's measurements reported as Evidence with
this means comparing the device measurements reported as Evidence the device configuration expected by the Verifier. Subsequently
with the Attester configuration expected by the Verifier. the Appraisal Policy for Evidence might match Evidence found
Subsequently the Appraisal Policy for Attestation Results might against Reference Values (aka Golden Measurements), which
match what was found against Reference Integrity Measurements represent the intended configured state of the connected device.
(aka Golden Measurements) which 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 MUST be based on IEEE 802.1AR Device 1. Identity: Device identity MUST be based on IEEE 802.1AR Device
Identity (DevID) [IEEE-802-1AR], coupled with careful supply- Identity (DevID) [IEEE-802-1AR], coupled with careful supply-
chain management by the manufacturer. The DevID certificate chain management by the manufacturer. The Initial DevID (IDevID)
contains a statement by the manufacturer that establishes the certificate contains a statement by the manufacturer that
identity of the device as it left the factory. Some applications establishes the identity of the device as it left the factory.
with a more-complex post-manufacture supply chain (e.g., Value Some applications with a more-complex post-manufacture supply
Added Resellers), or with different privacy concerns, may want to chain (e.g., Value Added Resellers), or with different privacy
use alternative mechanisms for platform authentication (for concerns, may want to use alternative mechanisms for platform
example, TCG Platform Certificates [Platform-Certificates]). authentication (for example, TCG Platform Certificates
[Platform-Certificates], or post-manufacture installation of
Local Device ID (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), 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 measures components to an operational state, in which each stage measures components
of the next stage, updates the attestation log, and extends of the next stage, updates the attestation log, and extends
hashes into a PCR. The TPM can then report the hashes of all the hashes into a PCR. 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 8.1 for an overview of TPM operation, or [TPM1.2] and Section 8.1 for an overview of TPM operation, or [TPM1.2] and
[TPM2.0] for many more details). [TPM2.0] for many more details).
3. Reference Integrity Measurements must be conveyed from the 3. Signed Reference Values (aka Reference Integrity Measurements)
Endorser (the entity accepted as the software authority, often must be conveyed from the Reference Value Provider (the entity
the manufacturer for embedded systems) to the system in which accepted as the software authority, often the manufacturer for
verification will take place. embedded systems) to the Verifier.
1.5. Solution Requirements 1.5. Solution Requirements
Remote Integrity Verification must address the "Lying Endpoint" Remote Integrity Verification must address the "Lying Endpoint"
problem, in which malicious software on an endpoint may subvert the problem, in which malicious software on an endpoint may subvert the
intended function, and also prevent the endpoint from reporting its intended function, and also prevent the endpoint from reporting its
compromised status. (See Section 5 for further Security compromised status. (See 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, as 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. See [RFC8572] for an example of Secure Zero Touch configuration. See [RFC8572] for an example of Secure Zero Touch
Provisioning. Provisioning.
1.6. Scope 1.6. Scope
Remote Attestation is a very general problem that could apply to most The need for assurance of software integrity, addressed by Remote
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):
o This solution is for use in non-privacy-preserving applications o This solution is for use in non-privacy-preserving applications
(for example, networking, Industrial IoT), avoiding the need for a (for example, networking, Industrial IoT), avoiding the need for a
Privacy Certificate Authority for attestation keys Privacy Certificate Authority for attestation keys [AK-Enrollment]
[AIK-Enrollment] or TCG Platform Certificates or TCG Platform Certificates [Platform-Certificates].
[Platform-Certificates]
o This document assumes network protocols that are common in o This document assumes network protocols that are common in network
networking equipment such as YANG [RFC7950] and NETCONF [RFC6241], equipment such as YANG [RFC7950] and NETCONF [RFC6241], but not
but not generally used in other applications. generally used in other applications.
o The approach outlined in this document mandates the use of a o The approach outlined in this document mandates the use of a
compliant TPM [TPM1.2], [TPM2.0]. compliant TPM [TPM1.2], [TPM2.0].
1.6.1. Out of Scope 1.6.1. Out of Scope
o Run-Time Attestation: Run-time attestation of Linux or other o Run-Time Attestation: The Linux Integrity Measurement Architecture
multi-threaded operating system processes considerably expands the attests each process launched after a device is started (and is in
scope of the problem. Many researchers are working on that scope for RIV), but continuous run-time attestation of Linux or
problem, but this document defers the run-time attestation other multi-threaded operating system processes after they've
problem. started considerably expands the scope of the problem. Many
researchers are working on that problem, but this document defers
the problem of continuous, in-memory run-time attestation.
o Multi-Vendor Embedded Systems: Additional coordination would be o 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. from multiple vendors, integrated by the end user. Although out
of scope for this document, these issues are accommodated in
[I-D.ietf-rats-architecture].
o Processor Sleep Modes: Network equipment typically does not o Processor Sleep Modes: Network equipment typically does not
"sleep", so sleep and hibernate modes are not considered. "sleep", so sleep and hibernate modes are not considered.
Although out of scope for RIV, Trusted Computing Group Although out of scope for RIV, Trusted Computing Group
specifications do encompass sleep and hibernate states. specifications do encompass sleep and hibernate states.
o Virtualization and Containerization: In a non-virtualized system, o 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, but that't the end of the boot process. For virtualized process, but that's the end of the boot process. For virtualized
systems, the host OS must verify the hypervisor, which then systems, the host OS must verify the hypervisor, which then
manages its own chain of trust through the virtual machine. manages its own chain of trust through the virtual machine.
Virtualization and containerization technologies are increasingly Virtualization and containerization technologies are increasingly
used in Network equipment, but are not considered in this revision used in network equipment, but are not considered in this
of the document. 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 which can be used to determine the
identity of software running on a specifically-identified device. identity of software running on a specifically-identified device.
Remote Attestation is broken into two phases, shown in Figure 1: Remote Attestation is broken into two phases, shown in Figure 1:
o During system startup, each distinct software object is o During system startup, each distinct software object is "measured"
"measured". Its identity, hash (i.e., cryptographic digest) and by the Attester. The object's identity, hash (i.e., cryptographic
version information are recorded in a log. Hashes are also digest) and version information are recorded in a log. Hashes are
extended, or cryptographically folded, into the TPM, in a way that also extended, or cryptographically folded, into the TPM, in a way
can be used to validate the log entries. The measurement process that can be used to validate the log entries. The measurement
generally follows the Chain of Trust model used in Measured Boot, process generally follows the layered chain-of-trust model used in
where each stage of the system measures the next one, and extends Measured Boot, where each stage of the system measures the next
its measurement into the TPM, before launching it. one, and extends its measurement into the TPM, before launching
it. See [I-D.ietf-rats-architecture], section "Layered
Attestation Environments," for an architectural definition of this
model.
o Once the device is running and has operational network o Once the device is running and has operational network
connectivity, a separate, trusted Verifier will interrogate the connectivity, a separate, trusted Verifier 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 known only to the TPM. attestation private key secured by, but never released by, the
TPM. The YANG model described in [I-D.ietf-rats-yang-tpm-charra]
facilitates this 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 Field and signature of certificate containing checking the Subject Field and signature of certificate containing
the TPM's attestation public key, and can validate the software that the TPM's attestation public key, and can validate the software that
was launched by verifying the correctness of the logs by comparing was launched by verifying the correctness of the logs by comparing
with the signed digests from the TPM, and comparing digests in the with the signed digests from the TPM, and comparing digests in the
log with known-good values. 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.
+-------------------------------------------------------+ +-------------------------------------------------------+
| +--------+ +--------+ +--------+ +---------+ | | +--------+ +--------+ +--------+ +---------+ |
| | BIOS |--->| Loader |-->| Kernel |--->|Userland | | | | BIOS |--->| Loader |-->| Kernel |--->|Userland | |
| +--------+ +--------+ +--------+ +---------+ | | +--------+ +--------+ +--------+ +---------+ |
skipping to change at page 10, line 27 skipping to change at page 10, line 27
| Router | | | Router | |
+--------------------------------|----------------------+ +--------------------------------|----------------------+
| |
| Step 2 | Step 2
| +-----------+ | +-----------+
+--->| Verifier | +--->| Verifier |
+-----------+ +-----------+
Reset---------------flow-of-time-during-boot--...-------> Reset---------------flow-of-time-during-boot--...------->
Figure 1: RIV Attestation Model Figure 1: Layered RIV Attestation Model
In Step 1, measurements are "extended", or hashed, into the TPM as In Step 1, measurements are "extended", or hashed, into the TPM as
processes start, with the result that the PCR ends up containing a processes start, with the result that the PCR ends up containing a
hash of all the measured hashes. In Step 2, signed PCR digests are hash of all the measured hashes. In Step 2, signed PCR digests are
retrieved from the TPM for off-box analysis after the system is retrieved from the TPM for off-box analysis after the system is
operational. operational.
2.1.1. What Does RIV Attest? 2.1.1. What Does RIV Attest?
TPM attestation is strongly focused on Platform Configuration TPM attestation is strongly focused on Platform Configuration
Registers (PCRs), but those registers are only vehicles for Registers (PCRs), but those registers are only vehicles for
certifying accompanying Evidence, conveyed in log entries. It is the certifying accompanying Evidence, conveyed in log entries. It is the
hashes in log entries that are extended into PCRs, where the final hashes in log entries that are extended into PCRs, where the final
PCR values can be retrieved in the form of a structured called a PCR values can be retrieved in the form of a structure called a
Quote, signed by an Attestation key known only to the TPM. The use Quote, signed by an Attestation key known only to the TPM. The use
of multiple PCRs serves only to provide some independence between of multiple PCRs serves only to provide some independence between
different classes of object, so that one class of objects can be different classes of object, so that one class of objects can be
updated without changing the extended hash for other classes. updated without changing the extended hash for other classes.
Although PCRs can be used for any purpose, this section outlines the Although PCRs can be used for any purpose, this section outlines the
objects within the scope of this document which may be extended into objects within the scope of this document which may be extended into
the TPM. 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:
o Code, (i.e., instructions) to be executed by a CPU. o Code, (i.e., instructions) to be executed by a CPU.
o Configuration - Many devices offer numerous options controlled by o Configuration - Many devices offer numerous options controlled by
non-volatile configuration variables which can impact the device's non-volatile configuration variables which 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 settings they intend are still in place. attestation that the operational state of the settings match their
intended state.
o Credentials - Administrators may wish to verify via attestation o Credentials - Administrators may wish to verify via attestation
that keys (and other credentials) outside the Root of Trust have that public keys (and other credentials) outside the Root of Trust
not been subject to unauthorized tampering. (By definition, keys have not been subject to unauthorized tampering. (By definition,
inside the root of trust can't be verified independently). keys protecting the root of trust can't be verified
independently.)
The TCG PC Client Platform Firmware Profile Specification The TCG PC Client Platform Firmware Profile Specification
[PC-Client-BIOS-TPM-2.0] gives considerable detail on what is to be [PC-Client-BIOS-TPM-2.0] gives considerable detail on what is to be
measured during the boot phase of platform startup using a UEFI BOIS measured during the boot phase of platform startup using a UEFI BIOS
(www.uefi.org), but the goal is simply to measure every bit of code (www.uefi.org), but the goal is simply to measure every bit of code
executed in the process of starting the device, along with any executed in the process of starting the device, along with any
configuration information related to security posture, leaving no gap configuration information related to security posture, leaving no gap
for unmeasured code to remain undetected and subvert the chain. for unmeasured code to remain undetected, potentially subverting the
chain.
For devices using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] gives For devices using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] gives
detailed normative requirements for PCR usage. But for other detailed normative requirements for PCR usage. For other platform
platform architectures, the table in Figure 2 gives guidance for PCR architectures, the table in Figure 2 gives non-normative guidance for
assignment that generalizes the specific details of PCR assignment that generalizes the specific 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, which 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 used to measure whatever data and configuration are associated PCR used to measure whatever data and configuration are associated
with that code. It is important to note that each PCR may contain with that code. It is important to note that each PCR may contain
results from dozens (or even thousands) of individual measurements. results from dozens (or even thousands) of individual measurements.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| | Assigned PCR # | | | Assigned PCR # |
skipping to change at page 12, line 38 skipping to change at page 12, line 38
| (e.g GRUB2 for Linux) | | | | (e.g 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 Figure 2: 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] taken by the Root of Trust for Measurement, measurement into PCR[0] is taken by the Root of Trust for
is critical to establishing the chain of trust for all subsequent Measurement, code which, by definition, cannot be verified by
measurements. If the PCR[0] measurement cannot be trusted, the measurement. This measurement establishes the chain of trust for all
validity of the entire chain is put into question. subsequent measurements. If the PCR[0] measurement cannot be
trusted, the validity of the entire chain is put into question.
Distinctions Between PCR[0], PCR[2], PCR[4] and PCR[8] are summarized Distinctions Between PCR[0], PCR[2], PCR[4] and PCR[8] are summarized
below: below:
o PCR[0] typically represents a consistent view of the Host Platform o PCR[0] typically represents a consistent view of rarely-changed
between boot cycles, allowing Attestation and Sealed Storage Host Platform boot components, allowing Attestation policies to be
policies to be defined using the less changeable components of the defined using the less changeable components of the transitive
transitive trust chain. This PCR typically provides a consistent trust chain. This PCR typically provides a consistent view of the
view of the platform regardless of user selected options. platform regardless of user selected options.
o PCR[2] is intended to represent a "user configurable" environment o 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 PCI or other slots. In UEFI
systems these devices may be configured by Option ROMs measured systems these devices may be configured by Option ROMs measured
into PCR[2] and executed by the BIOS. into PCR[2] and executed by the BIOS.
o PCR[4] is intended to represent the software that manages the o 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-Operating System start and
the state of a system with the Operating System present. This the state of a system with the Operating System present. This
PCR, along with PCR[5], identifies the initial operating system PCR, along with PCR[5], identifies the initial operating system
loader (e.g., GRUB for Linux). loader (e.g., GRUB for Linux).
o PCR[8] is used by the OS loader to record measurements of the o PCR[8] is used by the OS loader (e.g. GRUB) to record
various components of the operating system. measurements of the various components of the operating system.
Although the TCG PC Client document specifies the use of the first Although the TCG PC Client document 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. own constitute a check for authenticity. For example, in a UEFI
system, some administrators may consider booting an image from a
removable drive, something recorded in a PCR, to be a security
violation, while others might consider that operation an 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 a procedure to execute only if a given PCR is in a given allowing a procedure to execute, or releasing a paricular decryption
state). It may also be important to designers to consider whether key, only if a given PCR is in a given state). It may also be
streaming notification of PCR updates is required (see important to designers to consider whether streaming notification of
PCR updates is required (see
[I-D.birkholz-rats-network-device-subscription]). Specific log [I-D.birkholz-rats-network-device-subscription]). Specific log
entries can only be validated if the Verifier receives every log entries can only be validated if the Verifier receives every log
entry affecting the relevant PCR, so (for example) a designer might entry affecting the relevant PCR, so (for example) a designer might
want to separate rare, high-value events such as configuration want to separate rare, high-value events such as configuration
changes, from high-volume, routine measurements such as IMA [IMA] changes, from high-volume, routine measurements such as IMA [IMA]
logs. logs.
2.2. RIV Keying 2.2. RIV Keying
RIV attestation relies on two keys: RIV attestation relies on two credentials:
o An identity key is required to certify the identity of the o An identity key pair and matching certificate is required to
Attester itself. RIV specifies the use of an IEEE 802.1AR Device certify the identity of the Attester itself. RIV specifies the
Identity (DevID) [IEEE-802-1AR], signed by the device use of an IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR],
manufacturer, containing the device serial number. signed by the device manufacturer, containing the device serial
number.
o An Attestation Key is required to sign the Quote generated by the o An Attestation key pair and matching certificate is required to
TPM to report evidence of software configuration. sign the Quote generated by the TPM to report evidence of software
configuration.
In TPM application, the Attestation key MUST be protected by the TPM, In TPM application, both the Attestation private key and the DevID
and the DevID SHOULD be as well. Depending on other TPM private key MUST be protected by the TPM. Depending on other TPM
configuration procedures, the two keys are likely be different; some configuration procedures, the two keys are likely be different; some
of the considerations are outlined in TCG Guidance for Securing of the considerations are outlined in TCG "TPM 2.0 Keys for Device
Network Equipment [NetEq]. Identity and Attestation" [Platform-DevID-TPM-2.0].
TCG Guidance for Securing Network Equipment specifies further The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies
conventions for these keys: further conventions for these keys:
o When separate Identity and Attestation keys are used, the o When separate Identity and Attestation keys are used, the
Attestation Key (AK) and its X.509 certificate should parallel the Attestation Key (AK) and its X.509 certificate should parallel the
DevID, with the same device ID information as the DevID DevID, with the same device ID information as the DevID
certificate (i.e., the same Subject Name and Subject Alt Name, certificate (that is, the same Subject Name and Subject Alt Name,
even though the key pairs are different). This allows a quote even though the key pairs are different). This allows a quote
from the device, signed by an AK, to be linked directly to the from the device, signed by an AK, to be linked directly to the
device that provided it, by examining the corresponding AK device that provided it, by examining the corresponding AK
certificate. certificate. If the Subject and Subject Alt Names in the AK
certificate don't match the corresponding DevID certifcate, or
they're signed by differing authorities the Verifier may signal
the detection of an Asokan-style man-in-the-middle attack (see
Section 5.2).
o Network devices that are expected to use secure zero touch o Network devices that are expected to use secure zero touch
provisioning as specified in [RFC8572]) MUST be shipped by the provisioning as specified in [RFC8572]) MUST be shipped by the
manufacturer with pre-provisioned keys (Initial DevID and AK, manufacturer with pre-provisioned keys (Initial DevID and Initial
called IDevID and IAK). Inclusion of an IDevID and IAK by a AK, called IDevID and IAK). IDevID and IAK certificates MUST both
vendor does not preclude a mechanism whereby an Administrator can be signed by the Endorser (typically the device manufacturer).
define Local Identity and Attestation Keys (LDevID and LAK) if Inclusion of an IDevID and IAK by a vendor does not preclude a
desired. IDevID and IAK certificates MUST both be signed by the mechanism whereby an administrator can define Local Identity and
Endorser (typically the device manufacturer). Attestation Keys (LDevID and LAK) if desired.
2.3. RIV Information Flow 2.3. RIV Information Flow
RIV workflow for networking equipment is organized around a simple RIV workflow for network equipment is organized around a simple use
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. This use case software installed in specific, fielded devices. This use case
implies several components: implies several components:
1. The Attesting Device, which the network operator wants to 1. The Attester, the device which the network operator wants to
examine. examine.
2. A Verifier (which might be a network management station) 2. A Verifier (which might be a network management station)
somewhere separate from the Device that will retrieve the somewhere separate from the Device that will retrieve the signed
information and analyze it to pass judgment on the security evidence and measurement logs, and analyze them to pass judgment
posture of the device. on the security posture of the device.
3. A Relying Party, which can act on Attestation Results. 3. A Relying Party, which can act on Attestation Results.
Interaction between the Relying Party and the Verifier is Interaction between the Relying Party and the Verifier is
considered out of scope for RIV. considered out of scope for RIV.
4. Signed Reference Integrity Manifests (RIMs), containing Reference 4. Signed Reference Integrity Manifests (RIMs), containing Reference
Integrity Measurements, can either be created by the device Values, can either be created by the device manufacturer and
manufacturer and shipped along with the device as part of its shipped along with the device as part of its software image, or
software image, or alternatively, could be obtained several other alternatively, could be obtained several other ways (direct to
ways (direct to the Verifier from the manufacturer, from a third the Verifier from the manufacturer, from a third party, from the
party, from the owner's observation of what's thought to be a owner's observation of what's thought to be a "known good
"known good system", etc.). Retrieving RIMs from the device system", etc.). Retrieving RIMs from the device itself allows
itself allows attestation to be done in systems that may not have attestation to be done in systems that may not have access to the
access to the public internet, or by other devices that are not public internet, or by other devices that are not management
management stations per se (e.g., a peer device; see stations per se (e.g., a peer device; see Section 3.1.3). If
Section 3.1.3). If Reference Integrity Measurements are obtained Reference Values are obtained from multiple sources, the Verifier
from multiple sources, the Verifier may need to evaluate the may need to evaluate the relative level of trust to be placed in
relative 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 3.
A more-detailed taxonomy of terms is given in A more-detailed taxonomy of terms is given in
[I-D.ietf-rats-architecture] [I-D.ietf-rats-architecture]
+----------------+ +-------------+ +---------+--------+
+---------------+ +-------------+ +---------+--------+ |Reference Value | | Attester | Step 1 | Verifier| |
| | | Attester | Step 1 | Verifier| | |Provider | | (Device |<-------| (Network| Relying|
| Endorser | | (Device |<-------| (Network| Relying| |(Device | | under |------->| Mngmt | Party |
| (Device | | under |------->| Mngmt | 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 3: RIV Reference Configuration for Network Equipment
In Step 0, The Endorser (the device manufacturer or other authority) o In Step 0, The Reference Value Provider (the device manufacturer
provides a software image to the Attester (the device under or other authority) makes one or more Reference Integrity
attestation), and makes one or more Reference Integrity Manifests Manifests (RIMs), corresponding to the software image expected to
(RIMs) signed by the Endorser, available to the Verifier (see be found on the device, signed by the Reference Value Provider,
Section 3.1.3 for "in-band" and "out of band" ways to make this available to the Verifier (see Section 3.1.3 for "in-band" and
happen). In Step 1, the Verifier (Network Management Station), on "out of band" ways to make this happen).
behalf of a Relying Party, requests Identity, Measurement Values, and
possibly RIMs, from the Attester. In Step 2, the Attester responds o In Step 1, the Verifier (Network Management Station), on behalf of
to the request by providing a DevID, quotes (measured values, signed a Relying Party, requests Identity, Measurement Values, and
by the Attester), and optionally RIMs. possibly RIMs, from the Attester.
o In Step 2, the Attester responds to the request by providing a
DevID, quotes (measured values, signed by the Attester), and
optionally RIMs.
To achieve interoperability, the following standards components To achieve interoperability, the following standards components
SHOULD be used: SHOULD be used:
1. TPM Keys MUST be configured according to 1. TPM Keys MUST be configured according to
[Platform-DevID-TPM-2.0], [PC-Client-BIOS-TPM-1.2], or [Platform-DevID-TPM-2.0], or [Platform-ID-TPM-1.2].
[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 SHOULD be taken according to TCG PC Client bootable modules SHOULD be taken according to TCG PC Client
[PC-Client-BIOS-TPM-2.0] and Linux IMA [IMA] [PC-Client-BIOS-TPM-1.2] or [PC-Client-BIOS-TPM-2.0], and Linux
IMA [IMA]
3. Device Identity MUST be managed as specified in IEEE 802.1AR 3. Device Identity MUST be managed as specified in IEEE 802.1AR
Device Identity certificates [IEEE-802-1AR], with keys protected Device Identity certificates [IEEE-802-1AR], with keys protected
by TPMs. by TPMs.
4. Attestation logs SHOULD be formatted according to the Canonical 4. Attestation logs SHOULD be formatted according to the Canonical
Event Log format [Canonical-Event-Log], although other Event Log format [Canonical-Event-Log], although other
specialized formats may be used. UEFI-based systems MAY use the specialized formats may be used. UEFI-based systems MAY use the
TCG UEFI BIOS event log [EFI-TPM]). TCG UEFI BIOS event log [EFI-TPM].
5. Quotes are retrieved from the TPM according to the TCG TAP 5. Quotes are retrieved from the TPM according to TCG TAP
Information Model [TAP]. While the TAP IM gives a protocol- Information Model [TAP]. While the TAP IM gives a protocol-
independent description of the data elements involved, it's independent description of the data elements involved, it's
important to note that quotes from the TPM are signed inside the important to note that quotes from the TPM are signed inside the
TPM, so MUST be retrieved in a way that does not invalidate the TPM, so MUST be retrieved in a way that does not invalidate the
signature, as specified in [I-D.ietf-rats-yang-tpm-charra], to signature, as specified in [I-D.ietf-rats-yang-tpm-charra], to
preserve the trust model. (See Section 5 Security preserve the trust model. (See Section 5 Security
Considerations). Considerations).
6. Reference Integrity Measurements SHOULD be encoded as CoSWID 6. Reference Values SHOULD be encoded as SWID or CoSWID tags, as
tags, as defined in the TCG RIM document [RIM], compatible with defined in the TCG RIM document [RIM], compatible with NIST IR
NIST IR 8060 [NIST-IR-8060] and the IETF CoSWID draft 8060 [NIST-IR-8060] and the IETF CoSWID draft
[I-D.ietf-sacm-coswid]. See Section 2.4.1. [I-D.ietf-sacm-coswid]. See Section 2.4.1.
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:
o The product to be attested MUST be shipped with an IEEE 802.1AR o The product to be attested MUST be shipped with an IEEE 802.1AR
Device Identity and an Initial Attestation Key (IAK) with Device Identity and an Initial Attestation Key (IAK) with
certificate. The IAK cert contains the same identity information certificate. The IAK certificate MUST contain the same identity
as the DevID (specifically, the same Subject Name and Subject Alt information as the DevID (specifically, the same Subject Name and
Name, signed by the manufacturer), but it's a type of key that can Subject Alt Name, signed by the manufacturer), but it's a type of
be used to sign a TPM Quote. This convention is described in TCG key that can be used to sign a TPM Quote, but not other objects
Guidance for Securing Network Equipment [NetEq]. For network (i.e., it's marked as a TCG "Restricted" key; this convention is
equipment, which is generally non-privacy-sensitive, shipping a described in "TPM 2.0 Keys for Device Identity and Attestation"
device with both an IDevID and an IAK already provisioned [Platform-DevID-TPM-2.0]). For network equipment, which is
substantially simplifies initial startup. Privacy-sensitive generally non-privacy-sensitive, shipping a device with both an
applications may use the TCG Platform Certificate and additional IDevID and an IAK already provisioned substantially simplifies
procedures to install identity credentials into the device after initial startup. Privacy-sensitive applications may use the TCG
manufacture. Platform Certificate or other procedures to install identity
credentials into the device after manufacture.
o The product MUST be equipped with a Root of Trust for Measurement, o The product MUST be equipped with a Root of Trust for Measurement
Root of Trust for Storage and Root of Trust for Reporting (as (RTM), Root of Trust for Storage and Root of Trust for Reporting
defined in [SP800-155]) that are capable of conforming to the TCG (as defined in [SP800-155]) that are capable of conforming to TCG
Trusted Attestation Protocol (TAP) Information Model [TAP]. Trusted Attestation Protocol (TAP) Information Model [TAP].
o The authorized software supplier MUST make available Reference o The authorized software supplier MUST make available Reference
Integrity Measurements (i.e., known-good measurements) in the form Values in the form of signed SWID or CoSWID tags
of signed CoSWID tags [I-D.ietf-sacm-coswid], [SWID], as described [I-D.ietf-sacm-coswid], [SWID], as described in TCG Reference
in TCG Reference Integrity Measurement Manifest Information Model Integrity Measurement Manifest Information Model [RIM].
[RIM].
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 [I-D.ietf-rats-yang-tpm-charra] focuses on collecting and
transmitting evidence in the form of PCR measurements and attestation transmitting evidence in the form of PCR measurements and attestation
logs. But the critical part of the process is enabling the Verifier logs. But the critical part of the process is enabling the Verifier
to decide whether the measurements are "the right ones" or not. to decide whether the 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 Integrity Measurements that may be used by a Verifier to Reference Values, in signed Reference Integrity Manifests, that may
determine if evidence shows known good, known bad or unknown software be used by a Verifier to determine if evidence shows known good,
configurations. known bad or unknown 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 could 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.
2. Measurements taken later in operation of the system, once an OS 2. Measurements taken later in operation of the system, once an OS
has started (for example, Linux IMA[IMA]), may be more complex, has started (for example, Linux IMA [IMA]), may be more complex,
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.
The TCG has published an information model defining elements of TCG has published an information model defining elements of Reference
reference integrity manifests under the title TCG Reference Integrity Integrity Manifests under the title TCG Reference Integrity Manifest
Manifest Information Model [RIM]. This information model outlines Information Model [RIM]. This information model outlines how SWID
how SWID tags should be structured to allow attestation, and defines tags should be structured to allow attestation, and defines "bundles"
"bundles" of SWID tags that may be needed to describe a complete of SWID tags that may be needed to describe a complete software
software release. The RIM contains metadata relating to the software release. The RIM contains metadata relating to the software release
release it belongs to, plus hashes for each individual file or other it belongs to, plus hashes for each individual file or other object
object that could be attested. that could be attested.
TCG has also published the PC Client Reference Integrity Measurement TCG has also published the PC Client Reference Integrity Measurement
specification [PC-Client-RIM], which focuses on a SWID-compatible specification [PC-Client-RIM], which focuses on a SWID-compatible
format suitable for expressing expected measurement values in the format suitable for expressing expected measurement values in the
specific case of a UEFI-compatible BIOS, where the SWID focus on specific case of a UEFI-compatible BIOS, where the SWID focus on
files and file systems is not a direct fit. While the PC Client RIM files and file systems is not a direct fit. While the PC Client RIM
is not directly applicable to network equipment, many vendors do use is not directly applicable to network equipment, many vendors do use
a conventional UEFI BIOS to launch their network OS. a conventional UEFI BIOS to launch their network OS.
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, but to make sense of the quote in
most cases an event log that identifies which software modules most cases an event log that identifies which software modules
contributed which values to the quote during startup MUST also be contributed which values to the quote during startup MUST also be
provided. The log MUST contain enough information to demonstrate its provided. The log MUST contain enough information to demonstrate its
integrity by allowing exact reconstruction of the digest conveyed in integrity by allowing exact reconstruction of the digest conveyed in
the signed quote (i.e., PCR values). the signed quote (that is, calculating the hash of all the hashes in
the log should produce the same values as contained in the PCRs; if
they don't match, the log may have been tampered with. See
Section 8.1).
There are multiple event log formats which may be supported as viable There are multiple event log formats which may be supported as viable
formats of Evidence between the Attester and Verifier: formats of Evidence between the Attester and Verifier:
o Event log exports from [I-D.ietf-rats-yang-tpm-charra]
o IMA Event log file exports [IMA] o IMA Event log file exports [IMA]
o TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM o TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM
Family 1.1 or 1.2, Section 7) [EFI-TPM]) Family 1.1 or 1.2, Section 7) [EFI-TPM]
o TCG Canonical Event Log [Canonical-Event-Log] o TCG Canonical Event Log [Canonical-Event-Log]
Devices which use UEFI BIOS and Linux SHOULD use TCG Canonical Event Attesters which use UEFI BIOS and Linux SHOULD use TCG Canonical
Log [Canonical-Event-Log] and TCG UEFI BIOS event log [EFI-TPM]) Event Log [Canonical-Event-Log] and TCG UEFI BIOS event log
[EFI-TPM], although the CHARRA YANG model
[I-D.ietf-rats-yang-tpm-charra] has no dependence on the format of
the log.
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 is based on the standard roles defined in Attestation ([I-D.birkholz-rats-reference-interaction-model]) is
[I-D.ietf-rats-architecture]. However additional prerequisites have based on the standard roles defined in [I-D.ietf-rats-architecture].
been established to allow for interoperable RIV use case However additional prerequisites have been established to allow for
implementations. These prerequisites are intended to provide interoperable RIV use case implementations. These prerequisites are
sufficient context information so that the Verifier can acquire and intended to provide sufficient context information so that the
evaluate Attester measurements. Verifier can acquire and evaluate measurements collected by the
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 secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID
certificate [IEEE-802-1AR] MUST be provisioned in the Attester's certificate [IEEE-802-1AR] MUST be provisioned in the Attester's
TPMs. TPMs.
3.1.2. Keys 3.1.2. Keys
The Attestation Identity Key (AIK) and certificate MUST also be The Attestation Key (AK) and certificate MUST also be provisioned on
provisioned on the Attester according to [Platform-DevID-TPM-2.0], the Attester according to [Platform-DevID-TPM-2.0],
[PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2]. [PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2].
The Attester's TPM Keys MUST be associated with the DevID on the The Attester's TPM Keys MUST be associated with the DevID on the
Verifier (see [Platform-DevID-TPM-2.0] and Section 5 Security Verifier (see [Platform-DevID-TPM-2.0] and Section 5 Security
Considerations, below). Considerations, below).
3.1.3. Appraisal Policy for Evidence 3.1.3. Appraisal Policy for Evidence
The Verifier MUST obtain trustworthy Endorsements in the form of The Verifier MUST obtain trustworthy Reference Values (encoded as
reference measurements (e.g., Known Good Values, encoded as CoSWID SWID or CoSWID tags [I-D.birkholz-yang-swid]). These reference
tags [I-D.birkholz-yang-swid]). These reference measurements will measurements will eventually be compared to signed PCR Evidence
eventually be compared to signed PCR Evidence acquired from an ('quotes') acquired from an Attester's TPM using Attestation Policies
Attester's TPM using Attestation Policies chosen by the administrator chosen by the administrator or owner of the device.
or owner of the device.
This document does not specify the format or contents for the This document does not specify the format or contents for the
Appraisal Policy for Evidence, but Endorsements may be acquired in Appraisal Policy for Evidence, but Reference Values may be acquired
one of two ways: in one of two ways:
1. a Verifier may obtain reference measurements directly from an 1. a Verifier may obtain reference measurements directly from an
Endorser chosen by the Verifier administrator (e.g., through a Reference Value Provider chosen by the Verifier administrator
web site). (e.g., through a web site).
2. Signed reference measurements may be distributed by the Endorser 2. Signed reference measurements may be distributed by the Reference
to the Attester, as part of a software update. From there, the Value Provider to the Attester, as part of a software update.
reference measurement may be acquired by the Verifier. From there, the reference measurement may be acquired by the
Verifier.
In either case, the Verifier Owner MUST select the source of trusted In either case, the Verifier Owner MUST select the source of trusted
endorsements through the Appraisal Policy for Evidence. Reference Values through the Appraisal Policy for Evidence.
************* .-------------. .-----------. ****************** .-------------. .-----------.
* Endorser * | Attester | | Verifier/ | *Reference Value * | Attester | | Verifier/ |
* * | | | Relying | *Provider * | | | Relying |
*(Device *----2--->| (Network |----2--->| Party | *(Device *----2--->| (Network |----2--->| Party |
* config * | Device) | |(Ntwk Mgmt | *config * | Device) | |(Ntwk Mgmt |
* Authority)* | | | Station) | *Authority) * | | | Station) |
************* '-------------' '-----------' ****************** '-------------' '-----------'
| ^ | ^
| | | |
'----------------1--------------------------' '----------------1----------------------------'
Figure 4: Appraisal Policy for Evidence Prerequisites Figure 4: Appraisal Policy for Evidence Prerequisites
In either case the Endorsements must be generated, acquired and In either case the Reference Values must be generated, acquired and
delivered in a secure way, including reference measurements of delivered in a secure way, including reference measurements of
firmware and bootable modules taken according to TCG PC Client firmware and bootable modules taken according to TCG PC Client
[PC-Client-BIOS-TPM-2.0] and Linux IMA [IMA]. Endorsementa MUST be [PC-Client-BIOS-TPM-2.0] and Linux IMA [IMA]. Reference Values MUST
encoded as SWID or CoSWID tags, signed by the device manufacturer, as be encoded as SWID or CoSWID tags, signed by the device manufacturer,
defined in the TCG RIM document [RIM], compatible with NIST IR 8060 as defined in the TCG RIM document [RIM], compatible with NIST IR
[NIST-IR-8060] or the IETF CoSWID draft [I-D.ietf-sacm-coswid]. 8060 [NIST-IR-8060] or the IETF CoSWID draft [I-D.ietf-sacm-coswid].
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. The following diagram illustrates a RIV
information flow between a Verifier and an Attester, derived from information flow between a Verifier and an Attester, derived from
Section 8.1 of [I-D.birkholz-rats-reference-interaction-model]. Section 8.1 of [I-D.birkholz-rats-reference-interaction-model].
Event times shown correspond to the time types described within Event times shown correspond to the time types described within
Appendix A of [I-D.ietf-rats-architecture]: Appendix A of [I-D.ietf-rats-architecture]:
.----------. .--------------------------. .---------. .--------------------------.
| Attester | | Relying Party / Verifier | | Atteser | | Relying Party / Verifier |
'----------' '--------------------------' '---------' '--------------------------'
time(VG) | time(VG) |
valueGeneration(targetEnvironment) | valueGeneration(targetEnvironment) |
| => claims | | => claims |
| | | |
| <--------------requestEvidence(nonce, PcrSelection)-----time(NS) | <-----------requestEvidence(nonce, PcrSelection)----time(NS)
| | | |
time(EG) | time(EG) |
evidenceGeneration(nonce, PcrSelection, collectedClaims) | evidenceGeneration(nonce, PcrSelection, collectedClaims) |
| => SignedPcrEvidence(nonce, PcrSelection) | | => SignedPcrEvidence(nonce, PcrSelection) |
| => LogEvidence(collectedClaims) | | => LogEvidence(collectedClaims) |
| | | |
| returnSignedPcrEvidence----------------------------------> | | returnSignedPcrEvidence-------------------------------> |
| returnLogEvidence----------------------------------------> | | returnLogEvidence-------------------------------------> |
| | | |
| time(RG,RA) | time(RG,RA)
| evidenceAppraisal(SignedPcrEvidence, eventLog, refClaims) | evidenceAppraisal(SignedPcrEvidence, eventLog, refClaims)
| attestationResult <= | | attestationResult <= |
~ ~ ~ ~
| time(RX) | time(RX)
Figure 5: IETF Attestation Information Flow Figure 5: IETF Attestation Information Flow
o Step 1 (time(VG)): One or more Attesting Network Device PCRs are o 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 in
[I-D.birkholz-rats-network-device-subscription] could. [I-D.birkholz-rats-network-device-subscription] could.
o Step 2 (time(NS)): The Verifier generates a unique nonce ("number o Step 2 (time(NS)): The Verifier generates a unique random nonce
used once"), and makes a request attestation data for one or more ("number used once"), and makes a request attestation data for one
PCRs from an Attester. For interoperability, this MUST be or more PCRs from an Attester. For interoperability, this MUST be
accomplished via a YANG [RFC7950] interface that implements the accomplished via a YANG [RFC7950] interface that implements the
TCG TAP model (e.g., YANG Module for Basic Challenge-Response- TCG TAP model (e.g., YANG Module for Basic Challenge-Response-
based Remote Attestation Procedures based Remote Attestation Procedures
[I-D.ietf-rats-yang-tpm-charra]). [I-D.ietf-rats-yang-tpm-charra]).
o Step 3 (time(EG)): On the Attester, measured values are retrieved o Step 3 (time(EG)): On the Attester, measured values are retrieved
from the Attester's TPM. This requested PCR evidence is signed by from the Attester's TPM. This requested PCR evidence, along with
the Attestation Identity Key (AIK) associated with the DevID. the Verifier's nonce, called a Quote, is signed by the Attestation
Quotes are retrieved according to TCG TAP Information Model [TAP]. Key (AK) associated with the DevID. Quotes are retrieved
While the TAP IM gives a protocol-independent description of the according to TCG TAP Information Model [TAP]. At the same time,
data elements involved, it's important to note that quotes from the Attester collects log evidence showing the values have been
the TPM are signed inside the TPM, so must be retrieved in a way extended into that PCR. Section 8.1 gives more detail on how this
that does not invalidate the signature, as specified in works.
[I-D.ietf-rats-yang-tpm-charra], to preserve the trust model.
(See Section 5 Security Considerations). At the same time, the
Attester collects log evidence showing what values have been
extended into that PCR.
o Step 4: Collected Evidence is passed from the Attester to the o Step 4: Collected Evidence is passed from the Attester to the
Verifier Verifier
o Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes o 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 happen in one step. Verifier is out of scope for RIV, this can be described as one
step.
* If the signature covering TPM Evidence is not correct, the
device SHOULD NOT be trusted.
* If the nonce in the response doesn't match the Verifier's
nonce, the response may be a replay, and device SHOULD NOT 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 which 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 the AIK signature is not correct, or freshness such as that * If time(RG)-time(NS) is greater than the Appraisal Policy for
provided by the nonce is not included in the response, the Evidence's threshold for assessing freshness, the Evidence is
device SHOULD NOT be trusted. considered stale and SHOULD NOT be trusted.
* If time(RG)-time(NS) is greater than the threshold in the
Appraisal Policy for Evidence, the Evidence is 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 as Network Management systems may retrieve signed PCR based Evidence as
shown in Figure 5, and can be accomplished via NETCONF or RESTCONF, shown in Figure 5, and can be accomplished via NETCONF or RESTCONF,
with XML, JSON, or CBOR encoded Evidence. with XML, JSON, or CBOR encoded Evidence.
Implementations that use NETCONF MUST do so over a TLS or SSH secure Implementations that use NETCONF MUST do so over a TLS or SSH secure
tunnel. Implementations that use RESTCONF transport MAY do so over a tunnel. Implementations that use RESTCONF transport MUST do so over
TLS or SSH secure tunnel. a TLS or SSH secure tunnel.
Retrieval of Log Evidence SHOULD be via log interfaces on the network Retrieval of Log Evidence SHOULD be done via log interfaces specified
device. (For example, see [I-D.ietf-rats-yang-tpm-charra]). in [I-D.ietf-rats-yang-tpm-charra]).
3.3. Centralized vs Peer-to-Peer 3.3. Centralized vs Peer-to-Peer
Figure 5 above assumes that the Verifier is implicitly trusted, while Figure 5 above assumes that the Verifier is trusted, while the
the Attesting device is not. In a Peer-to-Peer application such as Attester is not. In a Peer-to-Peer application such as two routers
two routers negotiating a trust relationship negotiating a trust relationship
[I-D.voit-rats-trusted-path-routing], the two peers can each ask the [I-D.voit-rats-trusted-path-routing], the two peers can each ask the
other to prove software integrity. In this application, the other to prove software integrity. In this application, the
information flow is the same, but each side plays a role both as an information flow is the same, but each side plays a role both as an
Attester and a Verifier. Each device issues a challenge, and each Attester and a Verifier. Each device issues a challenge, and each
device responds to the other's challenge, as shown in Figure 6. device responds to the other's challenge, as shown in Figure 6.
Peer-to-peer challenges, particularly if used to establish a trust Peer-to-peer challenges, particularly if used to establish a trust
relationship between routers, require devices to carry their own relationship between routers, require devices to carry their own
signed reference measurements (RIMs). Devices may also have to carry signed reference measurements (RIMs). Devices may also have to carry
Appraisal Policy for Evidence for each possible peer device so that Appraisal Policy for Evidence for each possible peer device so that
each device has everything needed for attestation, without having to each device has everything needed for remote attestation, without
resort to a central authority. having to resort to a central authority.
+---------------+ +---------------+ +---------------+ +---------------+
| | | | | RefVal | | RefVal |
| Endorser A | | Endorser B | | Provider A | | Provider B |
| Firmware | | Firmware | | Firmware | | Firmware |
| Configuration | | Configuration | | Configuration | | Configuration |
| Authority | | Authority | | Authority | | Authority |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
| | | |
| +-------------+ +------------+ | | +------------+ +------------+ |
| | | Step 1 | | | \ | | | Step 1 | | | \
| | Attester |<------>| Verifier | | | | | Attester |<------>| Verifier | | |
| | |<------>| | | | Router B | | |<------>| | | | Router B
+------>| | Step 2 | | | |- Challenges +------>| | Step 2 | | | |- Challenges
Step 0A| | | | | | Router A Step 0A| | | | | | Router A
| |------->| | | | | |------->| | | |
|- Router A --| Step 3 |- Router B -| | / |- Router A -| Step 3 |- Router B -| | /
| | | | | | | | | |
| | | | | | | | | |
| | 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 6: Peer-to-Peer Attestation Information Flow Figure 6: 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 also an Appraisal Policy for Evidence
and a selection of trusted X.509 root certificates, to allow the and a selection of trusted X.509 root certificates, to allow the
device to act as a Verifier. An existing link layer protocol such as device to act as a Verifier. An existing link layer protocol such as
802.1x [IEEE-802.1x] or 802.1AE [IEEE-802.1ae], with Evidence being 802.1x [IEEE-802.1x] or 802.1AE [IEEE-802.1AE], with Evidence being
enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable
methods for such an exchange. methods for such an exchange.
4. Privacy Considerations 4. Privacy Considerations
Networking Equipment, such as routers, switches and firewalls, has a Network equipment, such as routers, switches and firewalls, has a key
key role to play in guarding the privacy of individuals using the role to play in guarding the privacy of individuals using the
network: network. Network equipment generally adheres to several rules to
protect privacy:
o Packets passing through the device must not be sent to o 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.
* Networking Equipment is often called upon to block access to * Network equipment is often called upon to block access to
protected resources from unauthorized users. protected resources from unauthorized users.
o Routing information, such as the identity of a router's peers, o Routing information, such as the identity of a router's peers,
must not be leaked to unauthorized neighbors. must not be leaked to unauthorized neighbors.
o If configured, encryption and decryption of traffic must be o 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 as to what
function each device and configuration is configured to carry out. function each device and configuration is configured to carry out.
This allows the administrator to ensure that the network provides Attestation is a component that allows the administrator to ensure
individual and peer privacy guarantees. that the network provides individual and peer privacy guarantees,
even though the device itself may not have a right to keep its
identity secret.
RIV specifically addresses the collection of information from RIV specifically addresses the collection of information from
enterprise network devices by authorized agents of the enterprise. enterprise network devices by authorized agents of the enterprise.
As such, privacy is a fundamental concern for those deploying this As such, privacy is a fundamental concern for those deploying this
solution, given EU GDPR, California CCPA, and many other privacy solution, given EU GDPR, California CCPA, and many other privacy
regulations. The enterprise SHOULD implement and enforce their duty regulations. The enterprise SHOULD implement and enforce their duty
of care. of care.
See [NetEq] for more context on privacy in networking devices. See [NetEq] for more context on privacy in networking devices.
5. Security Considerations 5. Security Considerations
Attestation Results from the RIV procedure are subject to a number of Attestation Evidence from the RIV procedure are subject to a number
attacks: of attacks:
o Keys may be compromised. o Keys may be compromised.
o A counterfeit device may attempt to impersonate (spoof) a known o A counterfeit device may attempt to impersonate (spoof) a known
authentic device. authentic device.
o Man-in-the-middle attacks may be used by a counterfeit device to o Man-in-the-middle attacks may be used by a counterfeit device to
attempt to deliver responses that originate in an actual authentic attempt to deliver responses that originate in an actual authentic
device. device.
o Replay attacks may be attempted by a compromised device. o 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 results can be trusted. advantage of TPM capabilities to ensure that evidence can be trusted.
Two sets of keys are relevant to RIV attestation: Two sets of key-pairs are relevant to RIV attestation:
o A DevID key is used to certify the identity of the device in which o A DevID key-pair is used to certify the identity of the device in
the TPM is installed. which the TPM is installed.
o An Attestation Key (AK) key signs attestation reports (called o An Attestation Key-pair (AK) key is used to certify attestation
'quotes' in TCG documents), used to provide evidence for integrity Evidence (called 'quotes' in TCG documents), used to provide
of the software on the device. evidence for integrity of the software on the device
TPM practices usually require that these keys be different, as a way TPM practices usually require that these keys be different, as a way
of ensuring that a general-purpose signing key cannot be used to of ensuring that a general-purpose signing key cannot be used to
spoof an attestation quote. spoof an 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're never exposed, and pairs are generated inside the TPM, where they're 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 just part of attestation security; knowing which Keeping keys safe is a critical enabler of trustworthiness, but it's
keys are bound to the device in question is just as important. just part of attestation security; knowing which keys are bound to
the device in question is just as important in an environment where
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., Secure ZTP, [RFC8572]), where keys which have predictable
trust properties are provisioned by the device vendor. trust 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 IEEE 802.1AR Device Identity
(DevID). This specification provides several elements: (DevID). This specification provides several elements:
skipping to change at page 26, line 33 skipping to change at page 27, line 38
o An identifying string that's unique to the manufacturer of the o 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.
o The certificate must be signed by a key traceable to the o The certificate must be signed by a key traceable to the
manufacturer's root key. manufacturer's root key.
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 nonce certificate. As is conventional in TLS or SSH connections, a random
must be signed by the device in response to a challenge, proving nonce must be signed by the device in response to a challenge,
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 providing proof that the from TLS or SSH security, with the DevID providing proof that the
session terminates on the intended device. See [RFC8446], [RFC4253]. session terminates on the 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. Because the contents of the quote are signed by the TPM itself. Because the contents of the quote are
signed inside the TPM, any external modification (including signed inside the TPM, any external modification (including
reformatting to a different data format) after measurements have been reformatting to a different data format) after measurements have been
taken will be detected as tampering. An unbroken chain of trust is taken will be detected as tampering. An unbroken chain of trust is
essential to ensuring that blocks of code that are taking essential to ensuring that blocks of code that are taking
measurements have been verified before execution (see Figure 1. measurements have been verified before execution (see Figure 1).
Requiring results of attestation of the operating software to be Requiring measurements of the operating software to be signed by a
signed by a key known only to the TPM also removes the need to trust key known only to the TPM also removes the need to trust the device's
the device's operating software (beyond the first measurement; see operating software (beyond the first measurement in the RTM; see
below); any changes to the quote, generated and signed by the TPM below); any changes to the quote, generated and signed by the TPM
itself, made by malicious device software, or in the path back to the itself, made by malicious device software, or in the path back to the
Verifier, will invalidate the signature on the quote. Verifier, will invalidate the signature on the quote.
A critical feature of the YANG model described in A critical feature of the YANG model described in
[I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data
structures in their native format, without requiring any changes to structures in their native format, without requiring any changes to
the structures as they were signed and delivered by the TPM. While the structures as they were signed and delivered by the TPM. While
alternate methods of conveying TPM quotes could compress out alternate methods of conveying TPM quotes could compress out
redundant information, or add an additional layer of signing using redundant information, or add an additional layer of signing using
external keys, the implementation MUST preserve the TPM signing, so external keys, the implementation MUST preserve the TPM signing, so
that tampering anywhere in the path between the TPM itself and the that tampering anywhere in the path between the TPM itself and the
Verifier can be detected. Verifier can be detected.
5.2. Prevention of Spoofing and Man-in-the-Middle Attacks 5.2. Prevention of Spoofing and Man-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 two cases to consider: important. There are two cases to consider:
o The entire device could be spoofed, that is, when the Verifier o The entire device could be spoofed. If the Verifier goes to
goes to verify a specific device, it might be redirected to a appraise a specific Attester, it might be redirected to a
different device. Use of the 802.1AR Device Identity (DevID) in different Attester. Use of the 802.1AR Device Identity (DevID) in
the TPM ensures that the Verifier's TLS or SSH session is in fact the TPM ensures that the Verifier's TLS or SSH session is in fact
terminating on the right device. terminating on the right device.
o A compromised device could respond with a spoofed Attestation o A device with a compromised OS could return a fabricated quote
Result, that is, a compromised OS could return a fabricated quote. providing spoofed attestation Evidence.
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 that's different from the DevID, called an Attestation Key
(AK). (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 man-in-the- and the same device must also be proven to prevent a man-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 (i.e., same manufacturer's serial number, same elements as the DevID (same manufacturer's serial number, signed
signed by the same manufacturer's key), but containing the device's by the same manufacturer's key), but containing the device's unique
unique AK public key instead of the DevID public key. AK public key instead of the DevID public key.
[Editor's Note: does this require an OID that says the key is known The TCG document TPM 2.0 Keys for Device Identity and Attestation
by the CA to be an Attestation key?] [Platform-DevID-TPM-2.0] specifies OIDs for Attestation Certificates
These two keys and certificates are used together: that allow the CA to mark a key as specifically known to be an
Attestation key.
These two key-pairs and certificates are used together:
o The DevID is used to validate a TLS connection terminating on the o The DevID is used to validate a TLS connection terminating on the
device with a known serial number. device with a known serial number.
o The AK is used to sign attestation quotes, providing proof that o The AK is used to sign attestation quotes, providing proof that
the attestation evidence comes from the same device. 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 results of a previous attestation are submitted
in response to subsequent requests, are usually prevented by in response to subsequent requests, are usually prevented by
inclusion of a nonce in the request to the TPM for a quote. Each inclusion of a random nonce in the request to the TPM for a quote.
request from the Verifier includes a new random number (a nonce). Each request from the Verifier includes a new random number (a
The resulting quote signed by the TPM contains the same nonce, nonce). The resulting quote signed by the TPM contains the same
allowing the Verifier to determine freshness, (i.e., that the nonce, allowing the Verifier to determine freshness, (i.e., that the
resulting quote was generated in response to the Verifier's specific resulting quote was generated in response to the Verifier's specific
request). Time-Based Uni-directional Attestation request). Time-Based Uni-directional Attestation
[I-D.birkholz-rats-tuda] provides an alternate mechanism to verify [I-D.birkholz-rats-tuda] provides an alternate mechanism to verify
freshness without requiring a request/response cycle. freshness 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, use of those credentials is not verified DevID and AK certificates if zero-touch provisioning such as
mandatory. IEEE 802.1AR incorporates the idea of an Initial Device described in [RFC8572] is to be supported, use of those credentials
ID (IDevID), provisioned by the manufacturer, and a Local Device ID is not mandatory. IEEE 802.1AR incorporates the idea of an Initial
(LDevID) provisioned by the owner of the device. RIV and Device ID (IDevID), provisioned by the manufacturer, and a Local
Device ID (LDevID) provisioned by the owner of the device. RIV and
[Platform-DevID-TPM-2.0] extends that concept by defining an Initial [Platform-DevID-TPM-2.0] extends that concept by defining an Initial
Attestation Key (IAK) and Local Attestation Key (LAK) with the same Attestation Key (IAK) and Local Attestation Key (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.
o The TCG document [Platform-DevID-TPM-2.0] shows how the initial o TCG document [Platform-DevID-TPM-2.0] shows how the initial
Attestation keys can be used to certify LDevID and LAK keys. Use Attestation keys can be used to certify LDevID and LAK keys. Use
of the LDevID and LAK allows the device owner to use a uniform of the LDevID and LAK allows the device owner to use a uniform
identity structure across device types from multiple manufacturers identity structure across device types from multiple manufacturers
(in the same way that an "Asset Tag" is used by many enterprises (in the same way that an "Asset Tag" is used by many enterprises
to identify devices they own). The TCG document to identify devices they own). TCG document
[Provisioning-TPM-2.0] also contains guidance on provisioning [Provisioning-TPM-2.0] also contains guidance on provisioning
identity keys in TPM 2.0. Initial and Local identity keys in TPM 2.0.
o Device owners, however, can use any other mechanism they want to o Device owners, however, can use any other mechanism they want to
assure themselves that Local identity certificates are inserted assure themselves that local identity certificates are inserted
into the intended device, including physical inspection and into the intended device, including physical inspection and
programming in a secure location, if they prefer to avoid placing programming in a secure location, if they prefer to avoid placing
trust in the manufacturer-provided keys. 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 secure Zero Touch provisioning;
installation of the Local keys can only be done by some process that installation of the local keys can only be done by some process that
runs before the device is installed for network operation. runs before the device is installed for network operation.
On the other end of the device life cycle, provision should be made On the other end of the device life cycle, provision should be made
to wipe Local keys when a device is decommissioned, to indicate that to wipe local keys when a device is decommissioned, to indicate that
the device is no longer owned by the enterprise. The manufacturer's the 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 Trust Anchors 5.5. Other Factors for Trustworthy Operation
In addition to trustworthy provisioning of keys, RIV depends on other In addition to trustworthy provisioning of keys, RIV depends on a
trust anchors. (See [SP800-155] for definitions of Roots of Trust.) number of other factors for trustworthy operation.
o Secure identity depends on mechanisms to prevent per-device secret o 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.
o Attestation depends on an unbroken chain of measurements, starting o Attestation depends on an unbroken chain of measurements, starting
from the very first measurement. That first measurement is made from the very first measurement. See Section 8.1 for background
by code called the Root of Trust for Measurement, typically done on TPM practices.
by trusted firmware stored in boot flash. Mechanisms for
maintaining the trustworthiness of the RTM are out of scope for o That first measurement is made by code called the Root of Trust
RIV, but could include immutable firmware, signed updates, or a for Measurement, typically done by trusted firmware stored in boot
vendor-specific hardware verification technique. See Section 8.1 flash. Mechanisms for maintaining the trustworthiness of the RTM
for background on TPM practices. are out of scope for RIV, but could include immutable firmware,
signed updates, or a vendor-specific hardware verification
technique. See Section 8.2 for background on roots of trust.
o The device owner SHOULD provide some level of physical defense for o 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 inserted into a counterfeit device,
attestation of that counterfeit device may become attestation of that counterfeit device may become
indistinguishable from an authentic device. indistinguishable from an authentic device.
RIV also depends on reliable reference measurements, as expressed by RIV also depends on reliable Reference Values, as expressed by the
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. RIMs may be conveyed out- validate a set of reference measurements. RIMs may be conveyed out-
of-band or in-band, as part of the attestation process (see of-band or in-band, as part of the attestation process (see
Section 3.1.3). But for embedded devices, where software is usually Section 3.1.3). But for embedded devices, where software is usually
shipped as a self-contained package, RIMs signed by the manufacturer shipped as a self-contained package, RIMs signed by the manufacturer
and delivered in-band may be more convenient for the device owner. and delivered in-band may be 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 measurements: procedures used to create Reference Values:
o While the RIM itself is signed, supply-chains SHOULD be carefully o 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.
o Designers SHOULD guard against hash collision attacks. Reference o Designers SHOULD guard against hash collision attacks. Reference
Integrity Measurements often give hashes for large objects of Integrity Manifests often give hashes for large objects of
indeterminate size; if one of the measured objects can be replaced indeterminate size; if one of the measured objects can be replaced
with an implant engineered to produce the same hash, RIV will be with an implant engineered to produce the same hash, RIV will be
unable to detect the substitution. TPM1.2 uses SHA-1 hashes only, unable to detect the substitution. TPM1.2 uses SHA-1 hashes only,
which have been shown to be susceptible to collision attack. which have been shown to be susceptible to collision attack.
TPM2.0 will produce quotes with SHA-256, which so far has resisted TPM2.0 will produce quotes with SHA-256, which so far has resisted
such attacks. Consequently RIV implementations SHOULD use TPM2.0. such attacks. Consequently, RIV implementations SHOULD use
TPM2.0.
6. Conclusion 6. 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 Remote Integrity Verification. Standards for many of the components
needed for implementation of RIV already exist: needed for implementation of RIV already exist:
o Platform identity can be based on IEEE 802.1AR Device Identity, o Platform identity can be based on IEEE 802.1AR Device Identity,
coupled with careful supply-chain management by the manufacturer. coupled with careful supply-chain management by the manufacturer.
o Complex supply chains can be certified using TCG Platform o Complex supply chains can be certified using TCG Platform
Certificates [Platform-Certificates]. Certificates [Platform-Certificates].
o The TCG TAP mechanism can be used to retrieve attestation o The TCG TAP mechanism couple with [I-D.ietf-rats-yang-tpm-charra]
evidence. Work is needed on a YANG model for this protocol. can be used to retrieve attestation evidence.
o Reference Integrity Measurements must be conveyed from the o Reference Values must be conveyed from the software authority
software authority (e.g., the manufacturer) to the system in which (e.g., the manufacturer) in Reference Integrity Manifests, to the
verification will take place. IETF CoSWID work forms the basis system in which verification will take place. IETF and TCG SWID
for this, but new work is needed to create an information model and CoSWID work ([I-D.birkholz-yang-swid], [RIM])) forms the basis
and YANG implementation. for this function.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Appendix 8. Appendix
8.1. Using a TPM for Attestation 8.1. Using a TPM for Attestation
The Trusted Platform Module and surrounding ecosystem provide three The Trusted Platform Module and surrounding ecosystem provide three
interlocking capabilities to enable secure collection of evidence interlocking capabilities to enable secure collection of evidence
from a remote device, Platform Configuration Registers (PCRs), a from a remote device, Platform Configuration Registers (PCRs), a
Quote mechanism, and a standardized Event Log. Quote mechanism, and a standardized Event Log.
Each TPM has at least between eight and twenty-four PCRs (depending 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 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, hash value (SHA-1, SHA-256, and other hash algorithms can be used,
depending on TPM version). PCRs can't be accessed directly from depending on TPM version). PCRs can't be accessed directly from
outside the chip, but the TPM interface provides a way to "extend" a 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 new security measurement hash into any PCR, a process by which the
existing value in the PCR is hashed with the new security measurement 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 hash, and the result placed back into the same PCR. The result is a
composite fingerprint of all the security measurements extended into composite fingerprint of all the security measurements extended into
each PCR since the system was reset. each PCR since the system was reset.
Every time a PCR is extended, an entry should be added to the Every time a PCR is extended, an entry should be added to the
corresponding Event Log. Logs contain the security measurement hash corresponding Event Log. Logs contain the security measurement hash
plus informative fields offering hints as to what event it was that plus informative fields offering hints as to which event generated
generated the security measurement. the security measurement. The Event Log itself is protected against
The Event Log itself is protected against accidental manipulation, accidental manipulation, but it is implicitly tamper-evident - any
but it is implicitly tamper-evident - any verification process can verification process can read the security measurement hash from the
read the security measurement hash from the log events, compute the log events, compute the composite value and compare that to what
composite value and compare that to what ended up in the PCR. If ended up in the PCR. If there's no discrepancy, the logs do provide
there's a discrepancy, the logs do not provide an accurate view of an accurate view of what was placed into the PCR.
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 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 In a conventional TPM Attestation environment, the first measurement
must be made and extended into the TPM by trusted device code (called must be made and extended into the TPM by trusted device code (called
the Root of Trust for Measurement, RTM). That first measurement the Root of Trust for Measurement, RTM). That first measurement
should cover the segment of code that is run immediately after the should cover the segment of code that is run immediately after the
RTM, which then measures the next code segment before running it, and 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 so on, forming an unbroken chain of trust. See [TCGRoT] for more on
Mutable vs Immutable roots of trust. Mutable vs Immutable roots of trust.
The TPM provides another mechanism called a Quote that can read the The TPM provides another mechanism called a Quote that can read the
current value of the PCRs and package them into a data structure current value of the PCRs and package them, along with the Verifier's
signed by an Attestation Key (which is private key that is known only nonce, into a TPM-specific data structure signed by an Attestation
to the TPM). private key, known only to the TPM.
The Verifier uses the Quote and Log together. The Quote, containing As noted above in Section 5 Security Considerations, it's important
the composite hash of the complete sequence of security measurement to note that the Quote data structure is signed inside the TPM. The
hashes, is used to verify the integrity of the Event Log. Each hash trust model is preserved by retrieving the Quote in a way that does
in the validated Quote can then be compared to corresponding expected not invalidate the signature, as specified in
values in the set of Reference Integrity Measurements to validate [I-D.ietf-rats-yang-tpm-charra].
overall system integrity.
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 A summary of information exchanged in obtaining quotes from TPM1.2
and TPM2.0 can be found in [TAP], Section 4. Detailed information and TPM2.0 can be found in [TAP], Section 4. Detailed information
about PCRs and Quote data structures can be found in [TPM1.2], about PCRs and Quote data structures can be found in [TPM1.2],
[TPM2.0]. Recommended log formats include [PC-Client-BIOS-TPM-2.0] [TPM2.0]. Recommended log formats include [PC-Client-BIOS-TPM-2.0]
and [Canonical-Event-Log]. and [Canonical-Event-Log].
8.2. Root of Trust for Measurement 8.2. Root of Trust for Measurement
The measurements needed for attestation require that the device being The measurements needed for attestation require that the device being
attested is equipped with a Root of Trust for Measurement, that is, attested is equipped with a Root of Trust for Measurement, that is,
some trustworthy mechanism that can compute the first measurement in some trustworthy mechanism that can compute the first measurement in
the chain of trust required to attest that each stage of system 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) 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 to record the results, and a Root of Trust for Reporting to report
the results [TCGRoT], [SP800-155]. the results [TCGRoT], [SP800-155], [SP800-193].
While there are many complex aspects of a Root of Trust, two aspects While there are many complex aspects of a Root of Trust, two aspects
that are important in the case of attestation are: that are important in the case of attestation are:
o The first measurement computed by the Root of Trust for o The first measurement computed by the Root of Trust for
Measurement, and stored in the TPM's Root of Trust for Storage, is Measurement, and stored in the TPM's Root of Trust for Storage,
presumed to be correct. must be assumed to be correct.
o There must not be a way to reset the Root of Trust for Storage o There must not be a way to reset the Root of Trust for Storage
without re-entering the Root of Trust for Measurement code. without re-entering the Root of Trust for Measurement code.
The first measurement must be computed by code that is implicitly The first measurement must be computed by code that is implicitly
trusted; if that first measurement can be subverted, none of the trusted; if that first measurement can be subverted, none of the
remaining measurements can be trusted. (See [NIST-SP-800-155]) 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.
8.3. Layering Model for Network Equipment Attester and Verifier 8.3. Layering Model for Network Equipment Attester and Verifier
Retrieval of identity and attestation state uses one protocol stack, Retrieval of identity and attestation state uses one protocol stack,
while retrieval of Reference Measurements uses a different set of while retrieval of Reference Values uses a different set of
protocols. Figure 5 shows the components involved. protocols. Figure 5 shows the components involved.
+-----------------------+ +-------------------------+ +-----------------------+ +-------------------------+
| | | | | | | |
| Attester |<-------------| Verifier | | Attester |<-------------| Verifier |
| (Device) |------------->| (Management Station) | | (Device) |------------->| (Management Station) |
| | | | | | | | | |
+-----------------------+ | +-------------------------+ +-----------------------+ | +-------------------------+
| |
-------------------- -------------------- -------------------- --------------------
| | | |
---------------------------------- --------------------------------- ------------------------------- ---------------------------------
|Reference Integrity Measurements| | Attestation | |Reference Values | | Attestation |
---------------------------------- --------------------------------- ------------------------------- ---------------------------------
******************************************************************** ********************************************************************
* IETF Attestation Reference Interaction Diagram * * IETF Attestation Reference Interaction Diagram *
******************************************************************** ********************************************************************
....................... ....................... ....................... .......................
. Reference Integrity . . TAP (PTS2.0) Info . . Reference Integrity . . TAP (PTS2.0) Info .
. Manifest . . Model and Canonical . . Manifest . . Model and Canonical .
. . . Log Format . . . . Log Format .
....................... ....................... ....................... .......................
************************* .............. ********************** ************************* .............. **********************
* YANG SWID Module * . TCG . * YANG Attestation * * YANG SWID Module * . TCG . * YANG Attestation *
* I-D.birkholz-yang-swid* . Attestation. * Module * * I-D.birkholz-yang-swid* . Attestation. * Module *
* * . MIB . * I-D.ietf-rats- * * * . MIB . * I-D.ietf-rats- *
* * . . * yang-tpm-charra * * * . . * yang-tpm-charra *
************************* .............. ********************** ************************* .............. **********************
************************* ************ ************************ ************************* ************ ************************
* XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)* * XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)*
skipping to change at page 34, line 5 skipping to change at page 36, line 5
************************* ************************ ************************* ************************
* TLS, SSH * * TLS, SSH * * TLS, SSH * * TLS, SSH *
************************* ************************ ************************* ************************
Figure 7: RIV Protocol Stacks Figure 7: RIV Protocol Stacks
IETF documents are captured in boxes surrounded by asterisks. TCG IETF documents are captured in boxes surrounded by asterisks. TCG
documents are shown in boxes surrounded by dots. documents are shown in boxes surrounded by dots.
8.3.1. Why is OS Attestation Different?
Even in embedded systems, adding Attestation at the OS level (e.g.,
Linux IMA, Integrity Measurement Architecture [IMA]) increases the
number of objects to be attested by one or two orders of magnitude,
involves software that's updated and changed frequently, and
introduces processes that begin in an unpredictable order.
TCG and others (including the Linux community) are working on methods
and procedures for attesting the operating system and application
software, but standardization is still in process.
8.4. Implementation Notes 8.4. Implementation Notes
Figure 8 summarizes many of the actions needed to complete an Figure 8 summarizes many of the actions needed to complete an
Attestation system, with links to relevant documents. While Attestation system, with links to relevant documents. While
documents are controlled by several standards organizations, the documents are controlled by several standards organizations, the
implied actions required for implementation are all the implied actions required for implementation are all the
responsibility of the manufacturer of the device, unless otherwise responsibility of the manufacturer of the device, unless otherwise
noted. It should be noted that, while the YANG model is RECOMMENDED noted. It should be noted that, while the YANG model is RECOMMENDED
for attestation, this table identifies an optional SNMP MIB as well, for attestation, this table identifies an optional SNMP MIB as well,
[Attest-MIB]. [Attest-MIB].
skipping to change at page 34, line 41 skipping to change at page 36, line 29
-------------------------------------------------------------------- --------------------------------------------------------------------
| Make a Secure execution environment | TCG RoT | | Make a Secure execution environment | TCG RoT |
| o Attestation depends on a secure root of | UEFI.org | | o Attestation depends on a secure root of | UEFI.org |
| trust for measurement outside the TPM, as | | | trust for measurement outside the TPM, as | |
| well as roots for storage and reporting | | | well as roots for storage and reporting | |
| inside the TPM. | | | inside the TPM. | |
| o Refer to TCG Root of Trust for Measurement.| | | o Refer to TCG Root of Trust for Measurement.| |
| o NIST SP 800-193 also provides guidelines | | | o NIST SP 800-193 also provides guidelines | |
| on Roots of Trust | | | on Roots of Trust | |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Provision the TPM as described in | TCG TPM DevID | | Provision the TPM as described in |[Platform-DevID-TPM-2.0]|
| TCG documents. | TCG Platform | | TCG documents. | TCG Platform |
| | Certificate | | | Certificate |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Put a DevID or Platform Cert in the TPM | TCG TPM DevID | | Put a DevID or Platform Cert in the TPM | TCG TPM DevID |
| o Install an Initial Attestation Key at the | TCG Platform | | o Install an Initial Attestation Key at the | TCG Platform |
| same time so that Attestation can work out | Certificate | | same time so that Attestation can work out | Certificate |
| of the box |----------------- | of the box |-----------------
| o Equipment suppliers and owners may want to | IEEE 802.1AR | | o Equipment suppliers and owners may want to | IEEE 802.1AR |
| implement Local Device ID as well as | | | implement Local Device ID as well as | |
| Initial Device ID | | | Initial Device ID | |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Connect the TPM to the TLS stack | Vendor TLS | | Connect the TPM to the TLS stack | Vendor TLS |
| o Use the DevID in the TPM to authenticate | stack (This | | o Use the DevID in the TPM to authenticate | stack (This |
| TAP connections, identifying the device | action is | | TAP connections, identifying the device | action is |
| | simply | | | simply |
| | configuring TLS| | | configuring TLS|
| | to use the | | | to use the DevID |
| | DevID as its | | | as its client |
| | trust anchor.) | | | certificate) |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Make CoSWID tags for BIOS/LoaderLKernel objects | IETF CoSWID | | Make CoSWID tags for BIOS/LoaderLKernel objects | IETF CoSWID |
| o Add reference measurements into SWID tags | ISO/IEC 19770-2| | o Add reference measurements into SWID tags | ISO/IEC 19770-2|
| o Manufacturer should sign the SWID tags | NIST IR 8060 | | o Manufacturer should sign the SWID tags | NIST IR 8060 |
| o The TCG RIM-IM identifies further | | | o The TCG RIM-IM identifies further | |
| procedures to create signed RIM | | | procedures to create signed RIM | |
| documents that provide the necessary | | | documents that provide the necessary | |
| reference information | | | reference information | |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Package the SWID tags with a vendor software | Retrieve tags | | Package the SWID tags with a vendor software | Retrieve tags |
skipping to change at page 36, line 20 skipping to change at page 38, line 11
[Canonical-Event-Log] [Canonical-Event-Log]
Trusted Computing Group, "DRAFT Canonical Event Log Format Trusted Computing Group, "DRAFT Canonical Event Log Format
Version: 1.0, Revision: .12", October 2018. Version: 1.0, Revision: .12", October 2018.
[I-D.birkholz-yang-swid] [I-D.birkholz-yang-swid]
Birkholz, H., "Software Inventory YANG module based on Birkholz, H., "Software Inventory YANG module based on
Software Identifiers", draft-birkholz-yang-swid-02 (work Software Identifiers", draft-birkholz-yang-swid-02 (work
in progress), October 2018. in progress), October 2018.
[I-D.ietf-rats-yang-tpm-charra] [I-D.ietf-rats-yang-tpm-charra]
Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit, Birkholz, H., Eckel, M., Voit, E., Bhandari, S., Sulzen,
E., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data B., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data
Model for Challenge-Response-based Remote Attestation Model for Challenge-Response-based Remote Attestation
Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-02 Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-03
(work in progress), June 2020. (work in progress), September 2020.
[I-D.ietf-sacm-coswid] [I-D.ietf-sacm-coswid]
Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
Waltermire, "Concise Software Identification Tags", draft- Waltermire, "Concise Software Identification Tags", draft-
ietf-sacm-coswid-15 (work in progress), May 2020. ietf-sacm-coswid-15 (work in progress), May 2020.
[IEEE-802-1AR] [IEEE-802-1AR]
Seaman, M., "802.1AR-2018 - IEEE Standard for Local and Seaman, M., "802.1AR-2018 - IEEE Standard for Local and
Metropolitan Area Networks - Secure Device Identity, IEEE Metropolitan Area Networks - Secure Device Identity, IEEE
Computer Society", August 2018. Computer Society", August 2018.
skipping to change at page 37, line 12 skipping to change at page 39, line 6
<https://trustedcomputinggroup.org/pc-client-specific- <https://trustedcomputinggroup.org/pc-client-specific-
platform-firmware-profile-specification>. platform-firmware-profile-specification>.
[PC-Client-RIM] [PC-Client-RIM]
Trusted Computing Group, "DRAFT: TCG PC Client Reference Trusted Computing Group, "DRAFT: TCG PC Client Reference
Integrity Manifest Specification, v.09", December 2019, Integrity Manifest Specification, v.09", December 2019,
<https://trustedcomputinggroup.org/wp-content/uploads/ <https://trustedcomputinggroup.org/wp-content/uploads/
TCG_PC_Client_RIM_r0p15_15june2020.pdf>. TCG_PC_Client_RIM_r0p15_15june2020.pdf>.
[Platform-DevID-TPM-2.0] [Platform-DevID-TPM-2.0]
Trusted Computing Group, "DRAFT: TPM Keys for Platform Trusted Computing Group, "TPM 2.0 Keys for Device Identity
DevID for TPM2, Specification Version 0.7, Revision 0", and Attestation, Specification Version 1.0, Revision 2",
October 2018. September 2020,
<https://trustedcomputinggroup.org/resource/tpm-2-0-keys-
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, "TPM Keys for Platform Identity
for TPM 1.2, Specification Version 1.0, Revision 3", for TPM 1.2, Specification Version 1.0, Revision 3",
August 2015, <https://trustedcomputinggroup.org/resource/ August 2015, <https://trustedcomputinggroup.org/resource/
tpm-keys-for-platform-identity-for-tpm-1-2-2/>. tpm-keys-for-platform-identity-for-tpm-1-2-2/>.
[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 38, line 19 skipping to change at page 40, line 13
<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/resource/tcg-tap-
information-model/>. information-model/>.
9.2. Informative References 9.2. Informative References
[AIK-Enrollment] [AK-Enrollment]
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/>.
[Attest-MIB] [Attest-MIB]
Trusted Computing Group, "SNMP MIB for TPM-Based Trusted Computing Group, "SNMP MIB for TPM-Based
Attestation, Version 0.8Revision 0.02", May 2018, Attestation, Version 0.8Revision 0.02", May 2018,
skipping to change at page 38, line 43 skipping to change at page 40, line 37
[EFI-TPM] Trusted Computing Group, "TCG EFI Platform Specification [EFI-TPM] 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, Specification Version 1.22,
Revision 15", January 2014, Revision 15", January 2014,
<https://trustedcomputinggroup.org/resource/tcg-efi- <https://trustedcomputinggroup.org/resource/tcg-efi-
platform-specification/>. platform-specification/>.
[I-D.birkholz-rats-network-device-subscription] [I-D.birkholz-rats-network-device-subscription]
Birkholz, H., Voit, E., and W. Pan, "Attestation Event Birkholz, H., Voit, E., and W. Pan, "Attestation Event
Stream Subscription", draft-birkholz-rats-network-device- Stream Subscription", draft-birkholz-rats-network-device-
subscription-00 (work in progress), June 2020. subscription-01 (work in progress), October 2020.
[I-D.birkholz-rats-reference-interaction-model] [I-D.birkholz-rats-reference-interaction-model]
Birkholz, H., Eckel, M., Newton, C., and L. Chen, Birkholz, H., Eckel, M., Newton, C., and L. Chen,
"Reference Interaction Models for Remote Attestation "Reference Interaction Models for Remote Attestation
Procedures", draft-birkholz-rats-reference-interaction- Procedures", draft-birkholz-rats-reference-interaction-
model-03 (work in progress), July 2020. model-03 (work in progress), July 2020.
[I-D.birkholz-rats-tuda] [I-D.birkholz-rats-tuda]
Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
"Time-Based Uni-Directional Attestation", draft-birkholz- "Time-Based Uni-Directional Attestation", draft-birkholz-
rats-tuda-03 (work in progress), July 2020. rats-tuda-03 (work in progress), July 2020.
[I-D.ietf-rats-architecture] [I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", W. Pan, "Remote Attestation Procedures Architecture",
draft-ietf-rats-architecture-06 (work in progress), draft-ietf-rats-architecture-07 (work in progress),
September 2020. October 2020.
[I-D.ietf-rats-eat] [I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Ballesteros, M., and J. Mandyam, G., Lundblade, L., Ballesteros, M., and J.
O'Donoghue, "The Entity Attestation Token (EAT)", draft- O'Donoghue, "The Entity Attestation Token (EAT)", draft-
ietf-rats-eat-04 (work in progress), August 2020. ietf-rats-eat-04 (work in progress), August 2020.
[I-D.richardson-rats-usecases] [I-D.richardson-rats-usecases]
Richardson, M., Wallace, C., and W. Pan, "Use cases for Richardson, M., Wallace, C., and W. Pan, "Use cases for
Remote Attestation common encodings", draft-richardson- Remote Attestation common encodings", draft-richardson-
rats-usecases-07 (work in progress), March 2020. rats-usecases-07 (work in progress), March 2020.
[I-D.voit-rats-trusted-path-routing] [I-D.voit-rats-trusted-path-routing]
Voit, E., "Trusted Path Routing", draft-voit-rats-trusted- Voit, E., "Trusted Path Routing", draft-voit-rats-trusted-
path-routing-02 (work in progress), June 2020. path-routing-02 (work in progress), June 2020.
[IEEE-802.1ae] [IEEE-802.1AE]
Seaman, M., "802.1AE MAC Security (MACsec)", 2018, Seaman, M., "802.1AE MAC Security (MACsec)", 2018,
<https://1.ieee802.org/security/802-1ae/>. <https://1.ieee802.org/security/802-1ae/>.
[IEEE-802.1x] [IEEE-802.1x]
IEEE Computer Society, "802.1X-2020 - IEEE Standard for IEEE Computer Society, "802.1X-2020 - IEEE Standard for
Local and Metropolitan Area Networks--Port-Based Network Local and Metropolitan Area Networks--Port-Based Network
Access Control", February 2020, Access Control", February 2020,
<https://standards.ieee.org/standard/802_1X-2020.html>. <https://standards.ieee.org/standard/802_1X-2020.html>.
[IMA] and , "Integrity Measurement Architecture", June 2019, [IMA] and , "Integrity Measurement Architecture", June 2019,
skipping to change at page 40, line 12 skipping to change at page 42, line 12
2018, <https://trustedcomputinggroup.org/resource/tcg- 2018, <https://trustedcomputinggroup.org/resource/tcg-
guidance-securing-network-equipment/>. guidance-securing-network-equipment/>.
[NIST-IR-8060] [NIST-IR-8060]
National Institute for Standards and Technology, National Institute for Standards and Technology,
"Guidelines for the Creation of Interoperable Software "Guidelines for the Creation of Interoperable Software
Identification (SWID) Tags", April 2016, Identification (SWID) Tags", April 2016,
<https://nvlpubs.nist.gov/nistpubs/ir/2016/ <https://nvlpubs.nist.gov/nistpubs/ir/2016/
NIST.IR.8060.pdf>. NIST.IR.8060.pdf>.
[NIST-SP-800-155]
National Institute for Standards and Technology, "BIOS
Integrity Measurement Guidelines (Draft)", December 2011,
<https://csrc.nist.gov/csrc/media/publications/sp/800-
155/draft/documents/draft-sp800-155_dec2011.pdf>.
[Platform-Certificates] [Platform-Certificates]
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] [Provisioning-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 2015,
skipping to change at page 40, line 47 skipping to change at page 42, line 41
(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>.
[SP800-155] [SP800-155]
National Institute of Standards and Technology, "BIOS National Institute of Standards and Technology, "BIOS
Integrity Measurement Guidelines (Draft)", December 2011, Integrity Measurement Guidelines (Draft)", December 2011,
<https://csrc.nist.gov/csrc/media/publications/sp/800- <https://csrc.nist.gov/csrc/media/publications/sp/800-
155/draft/documents/draft-sp800-155_dec2011.pdf>. 155/draft/documents/draft-sp800-155_dec2011.pdf>.
[SP800-193]
National Institute for Standards and Technology, "NIST
Special Publication 800-193: Platform Firmware Resiliency
Guidelines", April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-193.pdf>.
[SWID-Gen] [SWID-Gen]
Labs64, Munich, Germany, "SoftWare IDentification (SWID) Labs64, Munich, Germany, "SoftWare IDentification (SWID)
Tags Generator (Maven Plugin)", n.d., Tags Generator (Maven Plugin)", n.d.,
<https://github.com/Labs64/swid-maven-plugin>. <https://github.com/Labs64/swid-maven-plugin>.
[TCGRoT] Trusted Computing Group, "DRAFT: TCG Roots of Trust [TCGRoT] Trusted Computing Group, "DRAFT: TCG Roots of Trust
Specification", October 2018, Specification", October 2018,
<https://trustedcomputinggroup.org/wp-content/uploads/ <https://trustedcomputinggroup.org/wp-content/uploads/
TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf>. TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf>.
 End of changes. 160 change blocks. 
533 lines changed or deleted 593 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/