draft-ietf-rats-tpm-based-network-device-attest-07.txt   draft-ietf-rats-tpm-based-network-device-attest-08.txt 
RATS Working Group G. Fedorkow, Ed. RATS Working Group G.C. Fedorkow, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Informational E. Voit Intended status: Informational E. Voit
Expires: December 12, 2021 Cisco Systems, Inc. Expires: 27 January 2022 Cisco Systems, Inc.
J. Fitzgerald-McKay J. Fitzgerald-McKay
National Security Agency National Security Agency
June 10, 2021 26 July 2021
TPM-based Network Device Remote Integrity Verification TPM-based Network Device Remote Integrity Verification
draft-ietf-rats-tpm-based-network-device-attest-07 draft-ietf-rats-tpm-based-network-device-attest-08
Abstract Abstract
This document describes a workflow for remote attestation of the This document describes a workflow for remote attestation of the
integrity of firmware and software installed on network devices that integrity of firmware and software installed on network devices that
contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by
the Trusted Computing Group (TCG). the Trusted Computing Group (TCG).
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 December 12, 2021. This Internet-Draft will expire on 27 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
1.2. Document Organization . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Document Organization . . . . . . . . . . . . . . . . . . 5
1.4. Description of Remote Integrity Verification (RIV) . . . 5 1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Solution Requirements . . . . . . . . . . . . . . . . . . 7 1.5. Description of Remote Integrity Verification (RIV) . . . 6
1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.6. Solution Requirements . . . . . . . . . . . . . . . . . . 8
1.6.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8 1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 9
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? . . . . . . . . . . . . . . . . 11
2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 12 2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 13
2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 14 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 15 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 15
2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 17 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 17
2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 18 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 18
2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 19 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 19
3. Standards Components . . . . . . . . . . . . . . . . . . . . 19 3. Standards Components . . . . . . . . . . . . . . . . . . . . 20
3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 19 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 20
3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 20 3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 20
3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 20 3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 21
3.2. Reference Model for Challenge-Response . . . . . . . . . 21 3.2. Reference Model for Challenge-Response . . . . . . . . . 22
3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 23 3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 23
3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 26 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 27
5.2. Prevention of Spoofing and Man-in-the-Middle Attacks . . 28 5.2. Prevention of Spoofing and Man-in-the-Middle Attacks . . 29
5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29 5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 30
5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 29 5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 30
5.5. Other Factors for Trustworthy Operation . . . . . . . . . 30 5.5. Other Factors for Trustworthy Operation . . . . . . . . . 31
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 32 9.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 33
9.2. Root of Trust for Measurement . . . . . . . . . . . . . . 33 9.2. Root of Trust for Measurement . . . . . . . . . . . . . . 34
9.3. Layering Model for Network Equipment Attester and 9.3. Layering Model for Network Equipment Attester and
Verifier . . . . . . . . . . . . . . . . . . . . . . . . 34 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 35
9.4. Implementation Notes . . . . . . . . . . . . . . . . . . 36 9.4. Implementation Notes . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . 37 10.1. Normative References . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . 40 10.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
There are many aspects to consider in fielding a trusted computing There are many aspects to consider in fielding a trusted computing
device, from operating systems to applications. Mechanisms to prove device, from operating systems to applications. Mechanisms to prove
that a device installed at a customer's site is authentic (i.e., not that a device installed at a customer's site is authentic (i.e., not
counterfeit) and has been configured with authorized software, all as counterfeit) and has been configured with authorized software, all as
part of a trusted supply chain, are just a few of the many aspects part of a trusted supply chain, are just a few of the many aspects
which need to be considered concurrently to have confidence that a 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 34 skipping to change at page 3, line 41
The intent of this document is to provide such guidance. It does The intent of this document is to provide such guidance. It does
this by outlining the Remote Integrity Verification (RIV) problem, this by outlining the Remote Integrity Verification (RIV) problem,
and then identifies elements that are necessary to get the complete, and then identifies elements that are necessary to get the complete,
scalable attestation procedure working with commercial networking scalable attestation procedure working with commercial networking
products such as routers, switches and firewalls. An underlying products such as routers, switches and firewalls. An underlying
assumption will be the availability within the device of a Trusted assumption 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. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. 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 Evidence, Attestation Result, These include: Appraisal Policy for Evidence, Attestation Result,
Attester, Evidence, Reference Value, Relying Party, Verifier, and Attester, Evidence, Reference Value, Relying Party, Verifier, and
Verifier Owner. Verifier Owner.
Additionally, this document defines the following term: Additionally, this document defines the following term:
Attestation: the process of generating, conveying and appraising Attestation: the process of generating, conveying and appraising
claims, backed by evidence, about device trustworthiness claims, backed by evidence, about device trustworthiness
skipping to change at page 4, line 36 skipping to change at page 5, line 13
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 In line with [I-D.ietf-rats-architecture] definitions, this document
uses the term Endorser to refer to the role that signs identity and uses the term Endorser to refer to the role that signs identity and
attestation certificates used by the Attester, while Reference Values attestation certificates used by the Attester, while Reference Values
are signed by a Reference Value Provider. Typically, the are signed by a Reference Value Provider. Typically, the
manufacturer of an embedded device would be accepted as both the manufacturer of an embedded device would be accepted as both the
Endorser and Reference Value Provider, although the choice is Endorser and Reference Value Provider, although the choice is
ultimately up to the Verifier Owner. ultimately up to the Verifier Owner.
1.2. Document Organization 1.3. Document Organization
The remainder of this document is organized into several sections: The remainder of this document is organized into several sections:
o The remainder of this section covers goals and requirements, plus * The remainder of this section covers goals and requirements, plus
a top-level description of RIV. a top-level description of RIV.
o The Solution Overview section outlines how Remote Integrity * The Solution Overview section outlines how Remote Integrity
Verification works. Verification works.
o The Standards Components section links components of RIV to * The Standards Components section links components of RIV to
normative standards. normative standards.
o Privacy and Security shows how specific features of RIV contribute * Privacy and Security shows how specific features of RIV contribute
to the trustworthiness of the Attestation Result. to the trustworthiness of the Attestation Result.
o Supporting material is in an appendix at the end. * Supporting material is in an appendix at the end.
1.3. Goals 1.4. Goals
Network operators benefit from a trustworthy attestation mechanism Network operators benefit from a trustworthy attestation mechanism
that provides assurance that their network comprises authentic that provides assurance that their network comprises authentic
equipment, and has loaded software free of known vulnerabilities and equipment, and has loaded software free of known vulnerabilities and
unauthorized tampering. In line with the overall goal of assuring unauthorized tampering. In line with the overall goal of assuring
integrity, attestation can be used to assist in asset management, integrity, attestation can be used to assist in asset management,
vulnerability and compliance assessment, plus configuration vulnerability and compliance assessment, plus configuration
management. management.
The RIV attestation workflow outlined in this document is intended to The RIV attestation workflow outlined in this document is intended to
meet the following high-level goals: meet the following high-level goals:
o Provable Device Identity - This specification requires that an * Provable Device Identity - This specification requires that an
Attester (i.e., the attesting device) includes a cryptographic Attester (i.e., the attesting device) includes a cryptographic
identifier unique to each device. Effectively this means that the identifier unique to each device. Effectively this means that the
TPM must be so 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 * Software Inventory - A key goal is to identify the software
release(s) installed on the Attester, and to provide evidence that release(s) installed on the Attester, and to provide evidence that
the software stored within hasn't been altered without the software stored within hasn't been altered without
authorization. authorization.
o Verifiability - Verification of software and configuration of the * 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)
[I-D.voit-rats-trusted-path-routing])
1.4. Description of Remote Integrity Verification (RIV) 1.5. Description of Remote Integrity Verification (RIV)
Attestation requires two interlocking mechanisms between the Attester Attestation requires two interlocking mechanisms between the Attester
network device and the Verifier: network device and the Verifier:
o Device Identity, the mechanism providing trusted identity, can * 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 * 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 mechanisms, RIV is a component in a Using these two interlocking mechanisms, RIV is a component in a
chain of procedures that can assure a network operator that the chain of procedures that can assure a network operator that the
equipment in their network can be reliably identified, and that equipment in their network can be reliably identified, and that
authentic software of a known version is installed on each device. authentic software of a known version is installed on each device.
Equipment in the network includes devices that make up the network Equipment in the network includes devices that make up the network
itself, such as routers, switches and firewalls. itself, such as routers, switches and firewalls.
skipping to change at page 7, line 42 skipping to change at page 8, line 18
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 9.1 for an overview of TPM operation, or [TPM1.2] and Section 9.1 for an overview of TPM operation, or [TPM1.2] and
[TPM2.0] for many more details). [TPM2.0] for many more details).
3. Signed Reference Values (aka Reference Integrity Measurements) 3. Signed Reference Values (aka Reference Integrity Measurements)
must be conveyed from the Reference Value Provider (the entity must be conveyed from the Reference Value Provider (the entity
accepted as the software authority, often the manufacturer for accepted as the software authority, often the manufacturer for
embedded systems) to the Verifier. embedded systems) to the Verifier.
1.5. Solution Requirements 1.6. 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. Network equipment is often required to at the end-user's site. Network equipment is often required to
"self-configure", to reliably reach out without manual intervention "self-configure", to reliably reach out without manual intervention
to prove its identity and operating posture, then download its own to prove its identity and operating posture, then download its own
configuration, a process which precludes pre-installation configuration, a process which precludes pre-installation
configuration. See [RFC8572] for an example of Secure Zero Touch configuration. See [RFC8572] for an example of Secure Zero Touch
Provisioning. Provisioning.
1.6. Scope 1.7. Scope
The need for assurance of software integrity, addressed by Remote The need for assurance of software integrity, addressed by Remote
Attestation, is a very general problem that could apply to most Attestation, is a very general problem that could apply to most
network-connected computing devices. However, this document includes network-connected computing devices. However, this document includes
several assumptions that limit the scope to network equipment (e.g., several assumptions that limit the scope to network equipment (e.g.,
routers, switches and firewalls): routers, switches and firewalls):
o This solution is for use in non-privacy-preserving applications * This solution is for use in non-privacy-preserving applications
(for example, networking, Industrial IoT), avoiding the need for a (for example, networking, Industrial IoT), avoiding the need for a
Privacy Certificate Authority for attestation keys [AK-Enrollment] Privacy Certificate Authority for attestation keys [AK-Enrollment]
or TCG Platform Certificates [Platform-Certificates]. or TCG Platform Certificates [Platform-Certificates].
o This document assumes network protocols that are common in network * This document assumes network protocols that are common in network
equipment such as YANG [RFC7950] and NETCONF [RFC6241], but not equipment such as YANG [RFC7950] and NETCONF [RFC6241], but not
generally used in other applications. generally used in other applications.
o The approach outlined in this document mandates the use of a * 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.7.1. Out of Scope
o Run-Time Attestation: The Linux Integrity Measurement Architecture * Run-Time Attestation: The Linux Integrity Measurement Architecture
attests each process launched after a device is started (and is in attests each process launched after a device is started (and is in
scope for RIV), but continuous run-time attestation of Linux or scope for RIV), but continuous run-time attestation of Linux or
other multi-threaded operating system processes after they've other multi-threaded operating system processes after they've
started considerably expands the scope of the problem. Many started considerably expands the scope of the problem. Many
researchers are working on that problem, but this document defers researchers are working on that problem, but this document defers
the problem of continuous, in-memory run-time attestation. the problem of continuous, in-memory run-time attestation.
o Multi-Vendor Embedded Systems: Additional coordination would be * Multi-Vendor Embedded Systems: Additional coordination would be
needed for devices that themselves comprise hardware and software needed for devices that themselves comprise hardware and software
from multiple vendors, integrated by the end user. Although out from multiple vendors, integrated by the end user. Although out
of scope for this document, these issues are accommodated in of scope for this document, these issues are accommodated in
[I-D.ietf-rats-architecture]. [I-D.ietf-rats-architecture].
o Processor Sleep Modes: Network equipment typically does not * 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, * 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's 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 used in network equipment, but are not considered in this
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 "measured" * During system startup, each distinct software object is "measured"
by the Attester. The object's identity, hash (i.e., cryptographic by the Attester. The object's identity, hash (i.e., cryptographic
digest) and version information are recorded in a log. Hashes are digest) and version information are recorded in a log. Hashes are
also extended, or cryptographically folded, into the TPM, in a way also extended, or cryptographically folded, into the TPM, in a way
that can be used to validate the log entries. The measurement that can be used to validate the log entries. The measurement
process generally follows the layered chain-of-trust model used in process generally follows the layered chain-of-trust model used in
Measured Boot, where each stage of the system measures the next Measured Boot, where each stage of the system measures the next
one, and extends its measurement into the TPM, before launching one, and extends its measurement into the TPM, before launching
it. See [I-D.ietf-rats-architecture], section "Layered it. See [I-D.ietf-rats-architecture], section "Layered
Attestation Environments," for an architectural definition of this Attestation Environments," for an architectural definition of this
model. model.
o Once the device is running and has operational network * 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 secured by, but never released by, the attestation private key secured by, but never released by, the
TPM. The YANG model described in [I-D.ietf-rats-yang-tpm-charra] TPM. The YANG model described in [I-D.ietf-rats-yang-tpm-charra]
facilitates this operation. 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
skipping to change at page 11, line 5 skipping to change at page 11, line 30
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. * Code, (i.e., instructions) to be executed by a CPU.
o Configuration - Many devices offer numerous options controlled by * Configuration - Many devices offer numerous options controlled by
non-volatile configuration variables which can impact the device's non-volatile configuration variables 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 operational state of the settings match their attestation that the operational state of the settings match their
intended state. intended state.
o Credentials - Administrators may wish to verify via attestation * Credentials - Administrators may wish to verify via attestation
that public keys (and other credentials) outside the Root of Trust that public keys (and other credentials) outside the Root of Trust
have not been subject to unauthorized tampering. (By definition, have not been subject to unauthorized tampering. (By definition,
keys protecting the root of trust can't be verified keys protecting the root of trust can't be verified
independently.) 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 BIOS 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
skipping to change at page 12, line 33 skipping to change at page 12, line 45
| Secure Boot Policy. This PCR records keys | | 7 | | Secure Boot Policy. This PCR records keys | | 7 |
| and configuration used to validate the OS | | | | and configuration used to validate the OS | | |
| loader | | | | loader | | |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Measurements made by the OS Loader | 8 | 9 | | Measurements made by the OS Loader | 8 | 9 |
| (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] is taken by the Root of Trust for measurement into PCR[0] is taken by the Root of Trust for
Measurement, code which, by definition, cannot be verified by Measurement, code which, by definition, cannot be verified by
measurement. This measurement establishes the chain of trust for all measurement. This measurement establishes the chain of trust for all
subsequent measurements. If the PCR[0] measurement cannot be subsequent measurements. If the PCR[0] measurement cannot be
trusted, the validity of the entire chain is put into question. trusted, the validity of the entire chain is 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 rarely-changed * PCR[0] typically represents a consistent view of rarely-changed
Host Platform boot components, allowing Attestation policies to be Host Platform boot components, allowing Attestation policies to be
defined using the less changeable components of the transitive defined using the less changeable components of the transitive
trust chain. This PCR typically provides a consistent view of the trust chain. This PCR typically provides a consistent 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 * 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 * 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 (e.g. GRUB) to record * PCR[8] is used by the OS loader (e.g. GRUB) to record
measurements of the 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
skipping to change at page 14, line 9 skipping to change at page 14, line 38
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 credentials: RIV attestation relies on two credentials:
o An identity key pair and matching certificate is required to * An identity key pair and matching certificate is required to
certify the identity of the Attester itself. RIV specifies the certify the identity of the Attester itself. RIV specifies the
use of an IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR], use of an IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR],
signed by the device manufacturer, containing the device serial signed by the device manufacturer, containing the device serial
number. number.
o An Attestation key pair and matching certificate is required to * An Attestation key pair and matching certificate is required to
sign the Quote generated by the TPM to report evidence of software sign the Quote generated by the TPM to report evidence of software
configuration. configuration.
In TPM application, both the Attestation private key and the DevID In TPM application, both the Attestation private key and the DevID
private key MUST be protected by the TPM. Depending on other TPM private key MUST be protected by the TPM. Depending on other TPM
configuration procedures, the two keys are likely be different; some configuration procedures, the two keys are likely be different; some
of the considerations are outlined in TCG "TPM 2.0 Keys for Device of the considerations are outlined in TCG "TPM 2.0 Keys for Device
Identity and Attestation" [Platform-DevID-TPM-2.0]. Identity and Attestation" [Platform-DevID-TPM-2.0].
The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies
further conventions for these keys: further conventions for these keys:
o When separate Identity and Attestation keys are used, the * 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 (that is, 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. If the Subject and Subject Alt Names in the AK certificate. If the Subject and Subject Alt Names in the AK
certificate don't match the corresponding DevID certifcate, or certificate don't match the corresponding DevID certifcate, or
they're signed by differing authorities the Verifier may signal they're signed by differing authorities the Verifier may signal
the detection of an Asokan-style man-in-the-middle attack (see the detection of an Asokan-style man-in-the-middle attack (see
Section 5.2). Section 5.2).
o Network devices that are expected to use secure zero touch * 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 Initial manufacturer with pre-provisioned keys (Initial DevID and Initial
AK, called IDevID and IAK). IDevID and IAK certificates MUST both AK, called IDevID and IAK). IDevID and IAK certificates MUST both
be signed by the Endorser (typically the device manufacturer). be signed by the Endorser (typically the device manufacturer).
Inclusion of an IDevID and IAK by a vendor does not preclude a Inclusion of an IDevID and IAK by a vendor does not preclude a
mechanism whereby an administrator can define Local Identity and mechanism whereby an administrator can define Local Identity and
Attestation Keys (LDevID and LAK) if desired. Attestation Keys (LDevID and LAK) if desired.
2.3. RIV Information Flow 2.3. RIV Information Flow
skipping to change at page 16, line 18 skipping to change at page 16, line 33
|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
o In Step 0, The Reference Value Provider (the device manufacturer * In Step 0, The Reference Value Provider (the device manufacturer
or other authority) makes one or more Reference Integrity or other authority) makes one or more Reference Integrity
Manifests (RIMs), corresponding to the software image expected to Manifests (RIMs), corresponding to the software image expected to
be found on the device, signed by the Reference Value Provider, be found on the device, signed by the Reference Value Provider,
available to the Verifier (see Section 3.1.3 for "in-band" and available to the Verifier (see Section 3.1.3 for "in-band" and
"out of band" ways to make this happen). "out of band" ways to make this happen).
o In Step 1, the Verifier (Network Management Station), on behalf of * In Step 1, the Verifier (Network Management Station), on behalf of
a Relying Party, requests Identity, Measurement Values, and a Relying Party, requests Identity, Measurement Values, and
possibly RIMs, from the Attester. possibly RIMs, from the Attester.
o In Step 2, the Attester responds to the request by providing a * In Step 2, the Attester responds to the request by providing a
DevID, quotes (measured values, signed by the Attester), and DevID, quotes (measured values, signed by the Attester), and
optionally RIMs. 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], or [Platform-ID-TPM-1.2]. [Platform-DevID-TPM-2.0], or [Platform-ID-TPM-1.2].
2. For devices using UEFI and Linux, measurements of firmware and 2. For devices using UEFI and Linux, measurements of firmware and
skipping to change at page 17, line 26 skipping to change at page 18, line 5
6. Reference Values SHOULD be encoded as SWID or CoSWID tags, as 6. Reference Values SHOULD be encoded as SWID or CoSWID tags, as
defined in the TCG RIM document [RIM], compatible with NIST IR defined in the TCG RIM document [RIM], compatible with 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 * 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 certificate MUST contain the same identity certificate. The IAK certificate MUST contain the same identity
information as the DevID (specifically, the same Subject Name and information as the DevID (specifically, the same Subject Name and
Subject Alt Name, signed by the manufacturer), but it's a type of Subject Alt Name, signed by the manufacturer), but it's a type of
key that can be used to sign a TPM Quote, but not other objects key that can be used to sign a TPM Quote, but not other objects
(i.e., it's marked as a TCG "Restricted" key; this convention is (i.e., it's marked as a TCG "Restricted" key; this convention is
described in "TPM 2.0 Keys for Device Identity and Attestation" described in "TPM 2.0 Keys for Device Identity and Attestation"
[Platform-DevID-TPM-2.0]). For network equipment, which is [Platform-DevID-TPM-2.0]). For network equipment, which is
generally non-privacy-sensitive, shipping a device with both an generally non-privacy-sensitive, shipping a device with both an
IDevID and an IAK already provisioned substantially simplifies IDevID and an IAK already provisioned substantially simplifies
initial startup. Privacy-sensitive applications may use the TCG initial startup. Privacy-sensitive applications may use the TCG
Platform Certificate or other procedures to install identity Platform Certificate or other procedures to install identity
credentials into the device after manufacture. credentials into the device after manufacture.
o The product MUST be equipped with a Root of Trust for Measurement * The product MUST be equipped with a Root of Trust for Measurement
(RTM), Root of Trust for Storage and Root of Trust for Reporting (RTM), Root of Trust for Storage and Root of Trust for Reporting
(as defined in [SP800-155]) that are capable of conforming to 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 * The authorized software supplier MUST make available Reference
Values in the form of signed SWID or CoSWID tags Values in the form of signed SWID or CoSWID tags
[I-D.ietf-sacm-coswid], [SWID], as described in TCG Reference [I-D.ietf-sacm-coswid], [SWID], as described in TCG Reference
Integrity Measurement Manifest Information Model [RIM]. Integrity Measurement Manifest Information Model [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.
skipping to change at page 19, line 29 skipping to change at page 20, line 8
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 (that is, calculating the hash of all the hashes in 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 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 they don't match, the log may have been tampered with. See
Section 9.1). Section 9.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 IMA Event log file exports [IMA] * IMA Event log file exports [IMA]
o TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM * 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] * TCG Canonical Event Log [Canonical-Event-Log]
Attesters which use UEFI BIOS and Linux SHOULD use TCG Canonical Attesters which use UEFI BIOS and Linux SHOULD use TCG Canonical
Event Log [Canonical-Event-Log] and TCG UEFI BIOS event log Event Log [Canonical-Event-Log] and TCG UEFI BIOS event log
[EFI-TPM], although the CHARRA YANG model [EFI-TPM], although the CHARRA YANG model
[I-D.ietf-rats-yang-tpm-charra] has no dependence on the format of [I-D.ietf-rats-yang-tpm-charra] has no dependence on the format of
the log. the log.
3. Standards Components 3. Standards Components
3.1. Prerequisites for RIV 3.1. Prerequisites for RIV
skipping to change at page 22, line 30 skipping to change at page 22, line 39
| 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 * 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 random nonce * Step 2 (time(NS)): The Verifier generates a unique random nonce
("number used once"), and makes a request attestation data for one ("number used once"), and makes a request attestation data for one
or more 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 * Step 3 (time(EG)): On the Attester, measured values are retrieved
from the Attester's TPM. This requested PCR evidence, along with from the Attester's TPM. This requested PCR evidence, along with
the Verifier's nonce, called a Quote, is signed by the Attestation the Verifier's nonce, called a Quote, is signed by the Attestation
Key (AK) associated with the DevID. Quotes are retrieved Key (AK) associated with the DevID. Quotes are retrieved
according to TCG TAP Information Model [TAP]. At the same time, according to TCG TAP Information Model [TAP]. At the same time,
the Attester collects log evidence showing the values have been the Attester collects log evidence showing the values have been
extended into that PCR. Section 9.1 gives more detail on how this extended into that PCR. Section 9.1 gives more detail on how this
works. works.
o Step 4: Collected Evidence is passed from the Attester to the * 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 * Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes
action as needed. As the interaction between Relying Party and action as needed. As the interaction between Relying Party and
Verifier is out of scope for RIV, this can be described as one Verifier is out of scope for RIV, this can be described as one
step. step.
* If the signature covering TPM Evidence is not correct, the - If the signature covering TPM Evidence is not correct, the
device SHOULD NOT be trusted. device SHOULD NOT be trusted.
* If the nonce in the response doesn't match the Verifier's - If the nonce in the response doesn't match the Verifier's
nonce, the response may be a replay, and device SHOULD NOT be nonce, the response may be a replay, and device SHOULD NOT be
trusted. 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 time(RG)-time(NS) is greater than the Appraisal Policy for - If time(RG)-time(NS) is greater than the Appraisal Policy for
Evidence's threshold for assessing freshness, the Evidence is Evidence's threshold for assessing freshness, the Evidence is
considered stale and SHOULD NOT be trusted. considered stale and SHOULD NOT be trusted.
3.2.1. Transport and Encoding 3.2.1. Transport and Encoding
Network Management systems may retrieve signed PCR based Evidence 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 MUST do so over tunnel. Implementations that use RESTCONF transport MUST do so over
a TLS or SSH secure tunnel. a TLS or SSH secure tunnel.
Retrieval of Log Evidence SHOULD be done via log interfaces specified Retrieval of Log Evidence SHOULD be done via log interfaces specified
in [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 trusted, while the Figure 5 above assumes that the Verifier is trusted, while the
Attester is not. In a Peer-to-Peer application such as two routers Attester is not. In a Peer-to-Peer application such as two routers
negotiating a trust relationship negotiating a trust relationship, 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 remote attestation, without each device has everything needed for remote attestation, without
having to resort to a central authority. having to resort to a central authority.
skipping to change at page 25, line 20 skipping to change at page 25, line 49
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
Network equipment, such as routers, switches and firewalls, has a key Network equipment, such as routers, switches and firewalls, has a 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 equipment generally adheres to several rules to network. Network equipment generally adheres to several rules to
protect privacy: protect privacy:
o Packets passing through the device must not be sent to * Packets passing through the device must not be sent to
unauthorized destinations. For example: unauthorized destinations. For example:
* Routers often act as Policy Enforcement Points, where - Routers often act as Policy Enforcement Points, where
individual subscribers may be checked for authorization to individual subscribers may be checked for authorization to
access a network. Subscriber login information must not be access a network. Subscriber login information must not be
released to unauthorized parties. released to unauthorized parties.
* Network 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, * 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 * 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.
Attestation is a component that allows the administrator to ensure Attestation is a component that allows the administrator to ensure
skipping to change at page 26, line 14 skipping to change at page 26, line 45
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 Evidence from the RIV procedure are subject to a number Attestation Evidence from the RIV procedure are subject to a number
of attacks: of attacks:
o Keys may be compromised. * Keys may be compromised.
o A counterfeit device may attempt to impersonate (spoof) a known * 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 * 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. * Replay attacks may be attempted by a compromised device.
5.1. Keys Used in RIV 5.1. Keys Used in RIV
Trustworthiness of RIV attestation depends strongly on the validity Trustworthiness of RIV attestation depends strongly on the validity
of keys used for identity and attestation reports. RIV takes full of keys used for identity and attestation reports. RIV takes full
advantage of TPM capabilities to ensure that evidence can be trusted. advantage of TPM capabilities to ensure that evidence can be trusted.
Two sets of key-pairs are relevant to RIV attestation: Two sets of key-pairs are relevant to RIV attestation:
o A DevID key-pair is used to certify the identity of the device in * A DevID key-pair is used to certify the identity of the device in
which the TPM is installed. which the TPM is installed.
o An Attestation Key-pair (AK) key is used to certify attestation * An Attestation Key-pair (AK) key is used to certify attestation
Evidence (called 'quotes' in TCG documents), used to provide Evidence (called 'quotes' in TCG documents), used to provide
evidence for integrity 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-
skipping to change at page 27, line 16 skipping to change at page 27, line 46
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:
o A DevID requires a unique key pair for each device, accompanied by * A DevID requires a unique key pair for each device, accompanied by
an X.509 certificate, an X.509 certificate,
o The private portion of the DevID key is to be stored in the * The private portion of the DevID key is to be stored in the
device, in a manner that provides confidentiality (Section 6.2.5 device, in a manner that provides confidentiality (Section 6.2.5
[IEEE-802-1AR]) [IEEE-802-1AR])
The X.509 certificate contains several components: The X.509 certificate contains several components:
o The public part of the unique DevID key assigned to that device * The public part of the unique DevID key assigned to that device
allows a challenge of identity. allows a challenge of identity.
o An identifying string that's unique to the manufacturer of the * An identifying string that's unique to the manufacturer of the
device. This is normally the serial number of the unit, which device. This is normally the serial number of the unit, which
might also be printed on a label on the device. might also be printed on a label on the device.
o The certificate must be signed by a key traceable to the * 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 random certificate. As is conventional in TLS or SSH connections, a random
nonce must be signed by the device in response to a challenge, nonce must be signed by the device in response to a challenge,
proving possession of its DevID private key. proving possession of its DevID private key.
RIV uses the DevID to validate a TLS or SSH connection to the device RIV uses the DevID to validate a TLS or SSH connection to the device
skipping to change at page 28, line 29 skipping to change at page 29, line 10
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. If the Verifier goes to * The entire device could be spoofed. If the Verifier goes to
appraise a specific Attester, it might be redirected to a appraise a specific Attester, it might be redirected to a
different Attester. 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 device with a compromised OS could return a fabricated quote * A device with a compromised OS could return a fabricated quote
providing spoofed attestation Evidence. providing spoofed attestation Evidence.
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).
skipping to change at page 29, line 14 skipping to change at page 29, line 43
by the same manufacturer's key), but containing the device's unique by the same manufacturer's key), but containing the device's unique
AK public key instead of the DevID public key. AK public key instead of the DevID public key.
The TCG document TPM 2.0 Keys for Device Identity and Attestation The TCG document TPM 2.0 Keys for Device Identity and Attestation
[Platform-DevID-TPM-2.0] specifies OIDs for Attestation Certificates [Platform-DevID-TPM-2.0] specifies OIDs for Attestation Certificates
that allow the CA to mark a key as specifically known to be an that allow the CA to mark a key as specifically known to be an
Attestation key. Attestation key.
These two key-pairs and certificates are used together: These two key-pairs and certificates are used together:
o The DevID is used to validate a TLS connection terminating on the * The DevID is used to validate a TLS connection terminating on the
device with a known serial number. device with a known serial number.
o The AK is used to sign attestation quotes, providing proof that * 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 random nonce in the request to the TPM for a quote. inclusion of a random nonce in the request to the TPM for a quote.
Each request from the Verifier includes a new random number (a Each request from the Verifier includes a new random number (a
nonce). The resulting quote signed by the TPM contains the same nonce). The resulting quote signed by the TPM contains the same
nonce, allowing the Verifier to determine freshness, (i.e., that the nonce, allowing the Verifier to determine freshness, (i.e., that the
skipping to change at page 29, line 47 skipping to change at page 30, line 32
described in [RFC8572] is to be supported, use of those credentials described in [RFC8572] is to be supported, use of those credentials
is not mandatory. IEEE 802.1AR incorporates the idea of an Initial is not mandatory. IEEE 802.1AR incorporates the idea of an Initial
Device ID (IDevID), provisioned by the manufacturer, and a Local Device ID (IDevID), provisioned by the manufacturer, and a Local
Device ID (LDevID) provisioned by the owner of the device. RIV and 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 TCG document [Platform-DevID-TPM-2.0] shows how the initial * 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). 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
Initial and Local 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 * 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
skipping to change at page 30, line 30 skipping to change at page 31, line 17
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 Factors for Trustworthy Operation 5.5. Other Factors for Trustworthy Operation
In addition to trustworthy provisioning of keys, RIV depends on a In addition to trustworthy provisioning of keys, RIV depends on a
number of other factors for trustworthy operation. number of other factors for trustworthy operation.
o Secure identity depends on mechanisms to prevent per-device secret * Secure identity depends on mechanisms to prevent per-device secret
keys from being compromised. The TPM provides this capability as keys from being compromised. The TPM provides this capability as
a Root of Trust for Storage. a Root of Trust for Storage.
o Attestation depends on an unbroken chain of measurements, starting * Attestation depends on an unbroken chain of measurements, starting
from the very first measurement. See Section 9.1 for background from the very first measurement. See Section 9.1 for background
on TPM practices. on TPM practices.
o That first measurement is made by code called the Root of Trust * That first measurement is made by code called the Root of Trust
for Measurement, typically done by trusted firmware stored in boot for Measurement, typically done by trusted firmware stored in boot
flash. Mechanisms for maintaining the trustworthiness of the RTM flash. Mechanisms for maintaining the trustworthiness of the RTM
are out of scope for RIV, but could include immutable firmware, are out of scope for RIV, but could include immutable firmware,
signed updates, or a vendor-specific hardware verification signed updates, or a vendor-specific hardware verification
technique. See Section 9.2 for background on roots of trust. technique. See Section 9.2 for background on roots of trust.
o The device owner SHOULD provide some level of physical defense for * The device owner SHOULD provide some level of physical defense for
the device. If a TPM that has already been programmed with an the device. If a TPM that has already been programmed with an
authentic DevID is stolen and inserted into a counterfeit device, authentic DevID is stolen and 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 Values, as expressed by the RIV also depends on reliable Reference Values, as expressed by the
RIM [RIM]. The definition of trust procedures for RIMs is out of RIM [RIM]. The definition of trust procedures for RIMs is out of
scope for RIV, and the device owner is free to use any policy to scope for RIV, and the device owner is free to use any policy to
validate a set of reference measurements. 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 Values: procedures used to create Reference Values:
o While the RIM itself is signed, supply-chains SHOULD be carefully * While the RIM itself is signed, supply-chains SHOULD be carefully
scrutinized to ensure that the values are not subject to scrutinized to ensure that the values are not subject to
unexpected manipulation prior to signing. Insider-attacks against unexpected manipulation prior to signing. Insider-attacks against
code bases and build chains are particularly hard to spot. code bases and build chains are particularly hard to spot.
o Designers SHOULD guard against hash collision attacks. Reference * Designers SHOULD guard against hash collision attacks. Reference
Integrity Manifests 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 such attacks. Consequently, RIV implementations SHOULD use
TPM2.0. 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, * 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 * Complex supply chains can be certified using TCG Platform
Certificates [Platform-Certificates]. Certificates [Platform-Certificates].
o The TCG TAP mechanism couple with [I-D.ietf-rats-yang-tpm-charra] * The TCG TAP mechanism couple with [I-D.ietf-rats-yang-tpm-charra]
can be used to retrieve attestation evidence. can be used to retrieve attestation evidence.
o Reference Values must be conveyed from the software authority * Reference Values must be conveyed from the software authority
(e.g., the manufacturer) in Reference Integrity Manifests, to the (e.g., the manufacturer) in Reference Integrity Manifests, to the
system in which verification will take place. IETF and TCG SWID system in which verification will take place. IETF and TCG SWID
and CoSWID work [I-D.ietf-sacm-coswid], [RIM])) forms the basis and CoSWID work [I-D.ietf-sacm-coswid], [RIM])) forms the basis
for this function. for this function.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Acknowledgements 8. Acknowledgements
skipping to change at page 34, line 10 skipping to change at page 35, line 5
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], [SP800-193]. 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 * The first measurement computed by the Root of Trust for
Measurement, and stored in the TPM's Root of Trust for Storage, Measurement, and stored in the TPM's Root of Trust for Storage,
must be assumed to be correct. must be assumed to be correct.
o There must not be a way to reset the Root of Trust for Storage * 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 [SP800-155]) remaining measurements can be trusted. (See [SP800-155])
It's important to note that the trustworthiness of the RTM code It's important to note that the trustworthiness of the RTM code
cannot be assured by the TPM or TPM supplier - code or procedures cannot be assured by the TPM or TPM supplier - code or procedures
external to the TPM must guarantee the security of the RTM. external to the TPM must guarantee the security of the RTM.
skipping to change at page 37, line 41 skipping to change at page 38, line 41
| attestation and analyze the result | | | attestation and analyze the result | |
| The Management application might be broken down | | | The Management application might be broken down | |
| to several more components: | | | to several more components: | |
| o A Posture Manager Server | | | o A Posture Manager Server | |
| which collects reports and stores them in | | | which collects reports and stores them in | |
| a database | | | a database | |
| o One or more Analyzers that can look at the| | | o One or more Analyzers that can look at the| |
| results and figure out what it means. | | | results and figure out what it means. | |
-------------------------------------------------------------------- --------------------------------------------------------------------
Figure 8: Component Status Figure 8: Component Status
10. References 10. References
10.1. Normative References 10.1. Normative References
[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.ietf-rats-yang-tpm-charra] [I-D.ietf-rats-yang-tpm-charra]
Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen, Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen,
B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A
YANG Data Model for Challenge-Response-based Remote YANG Data Model for Challenge-Response-based Remote
Attestation Procedures using TPMs", draft-ietf-rats-yang- Attestation Procedures using TPMs", Work in Progress,
tpm-charra-07 (work in progress), April 2021. Internet-Draft, draft-ietf-rats-yang-tpm-charra-08, 14
April 2021, <https://www.ietf.org/archive/id/draft-ietf-
rats-yang-tpm-charra-08.txt>.
[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", Work
ietf-sacm-coswid-17 (work in progress), February 2021. in Progress, Internet-Draft, draft-ietf-sacm-coswid-17, 22
February 2021, <https://www.ietf.org/archive/id/draft-
ietf-sacm-coswid-17.txt>.
[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.
[PC-Client-BIOS-TPM-1.2] [PC-Client-BIOS-TPM-1.2]
Trusted Computing Group, "TCG PC Client Specific Trusted Computing Group, "TCG PC Client Specific
Implementation Specification for Conventional BIOS, Implementation Specification for Conventional BIOS,
Specification Version 1.21 Errata, Revision 1.00", Specification Version 1.21 Errata, Revision 1.00",
skipping to change at page 39, line 29 skipping to change at page 40, line 36
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572, Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019, DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>. <https://www.rfc-editor.org/info/rfc8572>.
[RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity [RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity
skipping to change at page 40, line 36 skipping to change at page 41, line 42
Based_Attestation_v0.8r2_PUBLIC_REVIEW.pdf>. Based_Attestation_v0.8r2_PUBLIC_REVIEW.pdf>.
[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", Work in Progress, Internet-Draft,
subscription-02 (work in progress), March 2021. draft-birkholz-rats-network-device-subscription-02, 31
March 2021, <https://www.ietf.org/archive/id/draft-
birkholz-rats-network-device-subscription-02.txt>.
[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", Work in Progress, Internet-Draft, draft-
model-03 (work in progress), July 2020. birkholz-rats-reference-interaction-model-03, 7 July 2020,
<https://www.ietf.org/archive/id/draft-birkholz-rats-
reference-interaction-model-03.txt>.
[I-D.birkholz-rats-tuda] [I-D.birkholz-rats-tuda]
Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann, Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann,
"Time-Based Uni-Directional Attestation", draft-birkholz- "Time-Based Uni-Directional Attestation", Work in
rats-tuda-04 (work in progress), January 2021. Progress, Internet-Draft, draft-birkholz-rats-tuda-04, 13
January 2021, <https://www.ietf.org/archive/id/draft-
birkholz-rats-tuda-04.txt>.
[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", Work
draft-ietf-rats-architecture-12 (work in progress), April in Progress, Internet-Draft, draft-ietf-rats-architecture-
2021. 12, 23 April 2021, <https://www.ietf.org/archive/id/draft-
ietf-rats-architecture-12.txt>.
[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)", Work in
ietf-rats-eat-09 (work in progress), March 2021. Progress, Internet-Draft, draft-ietf-rats-eat-10, 7 March
2021, <https://www.ietf.org/archive/id/draft-ietf-rats-
eat-10.txt>.
[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", Work in Progress,
rats-usecases-08 (work in progress), November 2020. Internet-Draft, draft-richardson-rats-usecases-08, 2
November 2020, <https://www.ietf.org/archive/id/draft-
[I-D.voit-rats-trusted-path-routing] richardson-rats-usecases-08.txt>.
Voit, E., "Trusted Path Routing", draft-voit-rats-trusted-
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>.
skipping to change at page 42, line 48 skipping to change at page 44, line 12
<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] [SP800-193]
National Institute for Standards and Technology, "NIST National Institute for Standards and Technology, "NIST
Special Publication 800-193: Platform Firmware Resiliency Special Publication 800-193: Platform Firmware Resiliency
Guidelines", April 2018, Guidelines", April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-193.pdf>. NIST.SP.800-193.pdf>.
[SWID-Gen] [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>.
[TPM1.2] Trusted Computing Group, "TPM Main Specification Level 2 [TPM1.2] Trusted Computing Group, "TPM Main Specification Level 2
Version 1.2, Revision 116", March 2011, Version 1.2, Revision 116", March 2011,
skipping to change at page 43, line 25 skipping to change at page 44, line 36
[TPM2.0] Trusted Computing Group, "Trusted Platform Module Library [TPM2.0] Trusted Computing Group, "Trusted Platform Module Library
Specification, Family "2.0", Level 00, Revision 01.59", Specification, Family "2.0", Level 00, Revision 01.59",
November 2019, November 2019,
<https://trustedcomputinggroup.org/resource/tpm-library- <https://trustedcomputinggroup.org/resource/tpm-library-
specification/>. specification/>.
Authors' Addresses Authors' Addresses
Guy Fedorkow (editor) Guy Fedorkow (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
US United States of America
Email: gfedorkow@juniper.net Email: gfedorkow@juniper.net
Eric Voit Eric Voit
Cisco Systems, Inc. Cisco Systems, Inc.
US United States of America
Email: evoit@cisco.com Email: evoit@cisco.com
Jessica Fitzgerald-McKay Jessica Fitzgerald-McKay
National Security Agency National Security Agency
US United States of America
Email: jmfitz2@nsa.gov Email: jmfitz2@nsa.gov
 End of changes. 121 change blocks. 
164 lines changed or deleted 184 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/