draft-ietf-rats-tpm-based-network-device-attest-11.txt   draft-ietf-rats-tpm-based-network-device-attest-12.txt 
RATS Working Group G.C. 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: 2 August 2022 Cisco Expires: 27 August 2022 Cisco
J. Fitzgerald-McKay J. Fitzgerald-McKay
National Security Agency National Security Agency
29 January 2022 23 February 2022
TPM-based Network Device Remote Integrity Verification TPM-based Network Device Remote Integrity Verification
draft-ietf-rats-tpm-based-network-device-attest-11 draft-ietf-rats-tpm-based-network-device-attest-12
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 2 August 2022. This Internet-Draft will expire on 27 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Document Organization . . . . . . . . . . . . . . . . . . 5 1.3. Document Organization . . . . . . . . . . . . . . . . . . 5
1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Description of Remote Integrity Verification (RIV) . . . 6 1.5. Description of Remote Integrity Verification (RIV) . . . 6
1.6. Solution Requirements . . . . . . . . . . . . . . . . . . 8 1.6. Solution Requirements . . . . . . . . . . . . . . . . . . 8
1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 9 1.7.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 9
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 10 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 10
2.1. RIV Software Configuration Attestation using TPM . . . . 10 2.1. RIV Software Configuration Attestation using TPM . . . . 10
2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 11 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 12
2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 13 2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 13
2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 15 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 15
2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 16 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 16
2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 18 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 18
2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 18 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 19
2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 20 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 20
3. Standards Components . . . . . . . . . . . . . . . . . . . . 20 3. Standards Components . . . . . . . . . . . . . . . . . . . . 21
3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 20 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 21
3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 20 3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 21
3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . 24
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 Person-in-the-Middle 5.2. Prevention of Spoofing and Person-in-the-Middle
Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 28 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
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 . . . . . . . . . . . . . . 34 9.2. Root of Trust for Measurement . . . . . . . . . . . . . . 35
9.3. Layering Model for Network Equipment Attester and 9.3. Layering Model for Network Equipment Attester and
Verifier . . . . . . . . . . . . . . . . . . . . . . . . 34 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 36
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.
A generic architecture for remote attestation has been defined in A generic architecture for remote attestation has been defined in
[I-D.ietf-rats-architecture]. Additionally, the use cases for [I-D.ietf-rats-architecture]. Additionally, use cases for remotely
remotely attesting networking devices are discussed within Section 6 attesting networking devices are discussed within Section 6 of
of [I-D.richardson-rats-usecases]. However, these documents do not [I-D.richardson-rats-usecases]. However, these documents do not
provide sufficient guidance for network equipment vendors and provide sufficient guidance for network equipment vendors and
operators to design, build, and deploy interoperable devices. operators to design, build, and deploy interoperable devices.
The intent of this document is to provide such guidance. It does The intent of this document is to provide such guidance. It does
this by outlining the Remote Integrity Verification (RIV) problem, this by outlining the Remote Integrity Verification (RIV) problem,
and 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
skipping to change at page 4, line 40 skipping to change at page 4, line 40
independent Verifier can obtain cryptographic proof as to the independent Verifier can obtain cryptographic proof as to the
identity of the device in question, and evidence of the integrity of identity of the device in question, and evidence of the integrity of
software loaded on that device when it started up, and then verify software loaded on that device when it started up, and then verify
that what's there matches the intended configuration. For network that what's there matches the intended configuration. For network
equipment, a Verifier capability can be embedded in a Network equipment, a Verifier capability can be embedded in a Network
Management Station (NMS), a posture collection server, or other Management Station (NMS), a posture collection server, or other
network analytics tool (such as a software asset management solution, network analytics tool (such as a software asset management solution,
or a threat detection and mitigation tool, etc.). While informally or a threat detection and mitigation tool, etc.). While informally
referred to as attestation, this document focuses on a specific referred to as attestation, this document focuses on a specific
subset of attestation tasks, defined here as Remote Integrity subset of attestation tasks, defined here as Remote Integrity
Verification (RIV). RIV takes a network equipment centric Verification (RIV). RIV in this document takes a network-equipment-
perspective that includes a set of protocols and procedures for centric perspective that includes a set of protocols and procedures
determining whether a particular device was launched with authentic for determining whether a particular device was launched with
software, starting from Roots of Trust. While there are many ways to authentic software, starting from Roots of Trust. While there are
accomplish attestation, RIV sets out a specific set of protocols and many ways to accomplish attestation, RIV sets out a specific set of
tools that work in environments commonly found in network equipment. protocols and tools that work in environments commonly found in
RIV does not cover other device characteristics that could be network equipment. RIV does not cover other device characteristics
attested (e.g., geographic location, connectivity; see that could be attested (e.g., geographic location, connectivity; see
[I-D.richardson-rats-usecases]), although it does provide evidence of [I-D.richardson-rats-usecases]), although it does provide evidence of
a secure infrastructure to increase the level of trust in other a secure infrastructure to increase the level of trust in other
device characteristics attested by other means (e.g., by Entity device characteristics attested by other means (e.g., by Entity
Attestation Tokens [I-D.ietf-rats-eat]). 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 a network device would be accepted as both the manufacturer of a network device would be accepted as both the
skipping to change at page 7, line 5 skipping to change at page 7, line 5
administrators that they have known, authentic software configured administrators that they have known, authentic software configured
to run in their network. to run in their network.
Using these two interlocking mechanisms, RIV is a component in a 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.
Software used to boot a device can be described as a chain of Software used to boot a device can be identified by a chain of
measurements, anchored at the start by a Root of Trust for measurements, anchored at the start by a Root of Trust for
Measurement (see Section 9.2), each measuring the next stage and Measurement (see Section 9.2), each measuring the next stage and
recording the result in tamper-resistant storage, normally ending recording the result in tamper-resistant storage, normally ending
when the system software is fully loaded. A measurement signifies when the system software is fully loaded. A measurement signifies
the identity, integrity and version of each software component the identity, integrity and version of each software component
registered with an Attester's TPM [TPM1.2], [TPM2.0], so that a registered with an Attester's TPM [TPM1.2], [TPM2.0], so that a
subsequent verification stage can determine if the software installed subsequent verification stage can determine if the software installed
is authentic, up-to-date, and free of tampering. is authentic, up-to-date, and free of tampering.
RIV includes several major processes, split between the Attester and RIV includes several major processes, split between the Attester and
skipping to change at page 7, line 33 skipping to change at page 7, line 33
2. Device Identification refers to the mechanism assuring the 2. Device Identification refers to the mechanism assuring the
Relying Party (ultimately, a network administrator) of the Relying Party (ultimately, a network administrator) of the
identity of devices that make up their network, and that their identity of devices that make up their network, and that their
manufacturers are known. manufacturers are known.
3. Conveyance of Evidence reliably transports the collected Evidence 3. Conveyance of Evidence reliably transports the collected Evidence
from Attester to a Verifier to allow a management station to from Attester to a Verifier to allow a management station to
perform a meaningful appraisal in Step 4. The transport is perform a meaningful appraisal in Step 4. The transport is
typically carried out via a management network. The channel must typically carried out via a management network. The channel must
provide integrity and authenticity, and, in some use cases, may provide integrity and authenticity, and, in some use cases, may
also require confidentiality. also require confidentiality. It should be noted that critical
attestation evidence from the TPM is signed by a key known only
to TPM, and is not dependent on encyption carried out as part of
a reliable transport.
4. Finally, Appraisal of Evidence occurs. This is the process of 4. Finally, Appraisal of Evidence occurs. This is the process of
verifying the Evidence received by a Verifier from the Attester, verifying the Evidence received by a Verifier from the Attester,
and using an Appraisal Policy to develop an Attestation Result, and using an Appraisal Policy to develop an Attestation Result,
used to inform decision making. In practice, this means used to inform decision making. In practice, this means
comparing the Attester's measurements reported as Evidence with comparing the Attester's measurements reported as Evidence with
the device configuration expected by the Verifier. Subsequently the device configuration expected by the Verifier. Subsequently
the Appraisal Policy for Evidence might match Evidence found the Appraisal Policy for Evidence might match Evidence found
against Reference Values (aka Golden Measurements), which against Reference Values (aka Golden Measurements), which
represent the intended configured state of the connected device. represent the intended configured state of the connected device.
skipping to change at page 9, line 15 skipping to change at page 9, line 24
1.7. Scope 1.7. Scope
The need for assurance of software integrity, addressed by Remote The need for assurance of software integrity, addressed by Remote
Attestation, is a very general problem that could apply to most Attestation, is a very general problem that could apply to most
network-connected computing devices. However, this document includes network-connected computing devices. However, this document includes
several assumptions that limit the scope to network equipment (e.g., several assumptions that limit the scope to network equipment (e.g.,
routers, switches and firewalls): routers, switches and firewalls):
* This solution is for use in non-privacy-preserving applications * This solution is for use in non-privacy-preserving applications
(for example, networking, Industrial IoT), avoiding the need for a (for example, networking, Industrial IoT), avoiding the need for a
Privacy Certificate Authority for attestation keys [AK-Enrollment] Privacy Certificate Authority (also called an Attestation CA) for
or TCG Platform Certificates [Platform-Certificates]. attestation keys [AK-Enrollment] or TCG Platform Certificates
[Platform-Certificates].
* 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.
* 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.7.1. Out of Scope 1.7.1. Out of Scope
* Run-Time Attestation: The Linux Integrity Measurement Architecture * Run-Time Attestation: The Linux Integrity Measurement Architecture
[IMA] attests each process launched after a device is started (and [IMA] attests each process launched after a device is started (and
is in scope for RIV), but continuous run-time attestation of Linux is in scope for RIV in general), but continuous run-time
or other multi-threaded operating system processes after they've attestation of Linux or other multi-threaded operating system
started considerably expands the scope of the problem. Many processes after the OS has started considerably expands the scope
researchers are working on that problem, but this document defers of the problem. Many researchers are working on that problem, but
the problem of continuous, in-memory run-time attestation. this document defers the problem of continuous, in-memory run-time
attestation.
* Multi-Vendor Embedded Systems: Additional coordination would be * Multi-Vendor Embedded Systems: Additional coordination would be
needed for devices that themselves comprise hardware and software needed for devices that themselves comprise hardware and software
from multiple vendors, integrated by the end user. Although out from multiple vendors, 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].
* 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 in this document, Trusted Computing
specifications do encompass sleep and hibernate states. Group specifications do encompass sleep and hibernate states,
which could be incorporated into remote attestation for network
equipment in the future, given a compelling need.
* Virtualization and Containerization: In a non-virtualized system, * Virtualization and Containerization: In a non-virtualized system,
the host OS is responsible for measuring each User Space file or the host OS is responsible for measuring each User Space file or
process, but that's the end of the boot process. For virtualized process throughout the operational lifetime of the system. For
systems, the host OS must verify the hypervisor, which then virtualized systems, the host OS must verify the hypervisor, but
manages its own chain of trust through the virtual machine. then the hypervisor must manage its own chain of trust through the
Virtualization and containerization technologies are increasingly virtual machine. Virtualization and containerization technologies
used in network equipment, but are not considered in this are increasingly used in network equipment, but are not considered
document. in this document.
2. Solution Overview 2. Solution Overview
2.1. RIV Software Configuration Attestation using TPM 2.1. RIV Software Configuration Attestation using TPM
RIV Attestation is a process which can be used to determine the RIV Attestation is a process 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.
The Remote Attestation steps of Section 1.5 are broken into two The Remote Attestation steps of Section 1.5 are broken into two
phases, shown in Figure 1: phases, shown in Figure 1:
skipping to change at page 10, line 45 skipping to change at page 11, line 6
* Once the device is running and has operational network * Once the device is running and has operational network
connectivity, verification can take place. A separate Verifier, connectivity, verification can take place. A separate Verifier,
running in its own trusted environment, will interrogate the running in its own trusted environment, will interrogate the
network device to retrieve the logs and a copy of the digests network device to retrieve the logs and a copy of the digests
collected by hashing each software object, signed by an collected by hashing each software object, signed by an
attestation private key secured by, but never released by, the attestation private key secured by, but never released by, the
TPM. The YANG model described in [I-D.ietf-rats-yang-tpm-charra] TPM. The YANG model described in [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 attribute of the distinguished name and checking the subject[RFC5280] and signature of the certificate
signature of the certificate containing the TPM's attestation public containing the TPM's attestation public key, and can validate the
key, and can validate the software that was launched by verifying the software that was launched by verifying the correctness of the logs
correctness of the logs by comparing with the signed digests from the by comparing with the signed digests from the TPM, and comparing
TPM, and comparing digests in the log with Reference Values. digests in the log with Reference Values.
It should be noted that attestation and identity are inextricably It should be noted that attestation and identity are inextricably
linked; signed Evidence that a particular version of software was linked; signed Evidence that a particular version of software was
loaded is of little value without cryptographic proof of the identity loaded is of little value without cryptographic proof of the identity
of the Attester producing the Evidence. of the Attester producing the Evidence.
+-------------------------------------------------------+ +-------------------------------------------------------+
| +---------+ +--------+ +--------+ +---------+ | | +---------+ +--------+ +--------+ +---------+ |
| |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | | | |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |
| +---------+ +--------+ +--------+ +---------+ | | +---------+ +--------+ +--------+ +---------+ |
skipping to change at page 11, line 30 skipping to change at page 11, line 37
| | TPM | | | | TPM | |
| +--------+ | | +--------+ |
| Router | | | Router | |
+--------------------------------|----------------------+ +--------------------------------|----------------------+
| |
| Verification Phase | Verification Phase
| +-----------+ | +-----------+
+--->| Verifier | +--->| Verifier |
+-----------+ +-----------+
Reset---------------flow-of-time-during-boot--...-------> Reset---------------flow-of-time-during-boot...--------->
Figure 1: Layered RIV Attestation Model Figure 1: Layered RIV Attestation Model
In the Boot phase, measurements are "extended", or hashed, into the In the Boot phase, measurements are "extended", or hashed, into the
TPM as processes start, with the result that the TPM ends up TPM as processes start, with the result that the TPM ends up
containing hashes of all the measured hashes. Later, once the system containing hashes of all the measured hashes. Later, once the system
is operational, during the Verification phase, signed digests are is operational, during the Verification phase, signed digests are
retrieved from the TPM for off-box analysis. retrieved from the TPM for off-box analysis.
2.1.1. What Does RIV Attest? 2.1.1. What Does RIV Attest?
skipping to change at page 12, line 19 skipping to change at page 12, line 33
* Code, (i.e., instructions) to be executed by a CPU. * Code, (i.e., instructions) to be executed by a CPU.
* Configuration - Many devices offer numerous options controlled by * Configuration - Many devices offer numerous options controlled by
non-volatile configuration variables which can impact the device's non-volatile configuration variables 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.
* 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 credentials outside the Root of Trust have
have not been subject to unauthorized tampering. (By definition, not been subject to unauthorized tampering. (By definition, keys
keys protecting the root of trust can't be verified 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
configuration information related to security posture, leaving no gap configuration information related to security posture, leaving no gap
for unmeasured code to remain undetected, potentially subverting the for unmeasured code to remain undetected, potentially subverting the
chain. chain.
skipping to change at page 15, line 31 skipping to change at page 15, line 44
private key MUST be protected by the TPM. Depending on other TPM private key MUST be protected by the TPM. Depending on other TPM
configuration procedures, the two keys are likely to be different; configuration procedures, the two keys are likely to be different;
some of the considerations are outlined in TCG "TPM 2.0 Keys for some of the considerations are outlined in TCG "TPM 2.0 Keys for
Device Identity and Attestation" [Platform-DevID-TPM-2.0]. Device 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:
* 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 unique device identification as the DevID
certificate (that is, the same subject and subjectAltName (if certificate (that is, the same subject and subjectAltName (if
present), even though the key pairs are different). This allows a present), even though the key pairs are different). This allows a
quote from the device, signed by an AK, to be linked directly to quote from the device, signed by an AK, to be linked directly to
the device that provided it, by examining the corresponding AK the device that provided it, by examining the corresponding AK
certificate. If the subject in the AK certificate doesn't match certificate. If the subject in the AK certificate doesn't match
the corresponding DevID certificate, or they're signed by the corresponding DevID certificate, or they're signed by
differing authorities the Verifier may signal the detection of an differing authorities the Verifier may signal the detection of an
Asokan-style person-in-the-middle attack (see Section 5.2). Asokan-style person-in-the-middle attack (see Section 5.2).
* Network devices that are expected to use secure zero touch * Network devices that are expected to use secure zero touch
skipping to change at page 17, line 31 skipping to change at page 17, line 43
Use of the following standards components allows for Use of the following standards components allows for
interoperability: interoperability:
1. TPM Keys MUST be configured according to 1. TPM Keys MUST be configured according to
[Platform-DevID-TPM-2.0], 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
bootable modules MUST be taken according to TCG PC Client bootable modules MUST be taken according to TCG PC Client
[PC-Client-EFI-TPM-1.2] or [PC-Client-BIOS-TPM-2.0], and Linux [PC-Client-EFI-TPM-1.2] or [PC-Client-BIOS-TPM-2.0], and Linux
IMA [IMA] IMA [IMA].
3. Device Identity MUST be managed as specified in IEEE 802.1AR 3. Device Identity MUST be managed as specified in IEEE 802.1AR
Device Identity certificates [IEEE-802-1AR], with keys protected Device Identity certificates [IEEE-802-1AR], with keys protected
by TPMs. by TPMs.
4. Attestation logs from Linux-based systems MUST be formatted 4. Attestation logs from Linux-based systems MUST be formatted
according to the Canonical Event Log format according to the Canonical Event Log format
[Canonical-Event-Log]. UEFI-based systems MUST use the TCG UEFI [Canonical-Event-Log]. UEFI-based systems MUST use the TCG UEFI
BIOS event log [PC-Client-EFI-TPM-1.2] for TPM1.2 systems, and BIOS event log [PC-Client-EFI-TPM-1.2] for TPM1.2 systems, and
TCG PC Client Platform Firmware Profile [PC-Client-BIOS-TPM-2.0] TCG PC Client Platform Firmware Profile [PC-Client-BIOS-TPM-2.0]
for TPM2.0. for TPM2.0.
5. Quotes MUST be retrieved from the TPM according to TCG TAP 5. Quotes MUST be retrieved from the TPM according to TCG TAP
Information Model [TAP] and the CHARRA YANG model Information Model [TAP] and the CHARRA YANG model
[I-D.ietf-rats-yang-tpm-charra]. While the TAP IM gives a [I-D.ietf-rats-yang-tpm-charra]. While the TAP IM gives a
protocol-independent description of the data elements involved, protocol-independent description of the data elements involved,
it's important to note that quotes from the TPM are signed inside it's important to note that quotes from the TPM are signed inside
the TPM, and MUST be retrieved in a way that does not invalidate the TPM, and MUST be retrieved in a way that does not invalidate
the signature, to preserve the trust model. The the signature, to preserve the trust model. The
[I-D.ietf-rats-yang-tpm-charra] can be used for this purpose. [I-D.ietf-rats-yang-tpm-charra] is used for this purpose. (See
(See Section 5 Security Considerations). Section 5 Security Considerations).
6. Reference Values MUST be encoded as defined in the TCG RIM 6. Reference Values MUST be encoded as defined in the TCG RIM
document [RIM], typically using SWID [SWID], [NIST-IR-8060] or document [RIM], typically using SWID [SWID], [NIST-IR-8060] or
CoSWID tags [I-D.ietf-sacm-coswid]. CoSWID tags [I-D.ietf-sacm-coswid].
2.4. RIV Simplifying Assumptions 2.4. RIV Simplifying Assumptions
This document makes the following simplifying assumptions to reduce This document makes the following simplifying assumptions to reduce
complexity: complexity:
* The product to be attested MUST be shipped by the equipment vendor * The product to be attested MUST be shipped by the equipment vendor
with both an IEEE 802.1AR Device Identity and an Initial with both an IEEE 802.1AR Device Identity and an Initial
Attestation Key (IAK) with certificate in place. The IAK Attestation Key (IAK), with certificates in place. The IAK
certificate MUST contain the same identity information as the certificate must contain the same identity information as the
DevID (specifically, the same subject and subjectAltName (if DevID (specifically, the same subject and subjectAltName (if
used), signed by the manufacturer), but it's a type of key that used), signed by the manufacturer). The IAK is a type of key that
can be used to sign a TPM Quote, but not other objects (i.e., it's 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 described in marked as a TCG "Restricted" key; this convention is described in
"TPM 2.0 Keys for Device Identity and Attestation" "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. initial startup.
* IEEE 802.1AR does not require a product serial number as part of * IEEE 802.1AR does not require a product serial number as part of
the subject, but RIV-compliant devices MUST include their serial the subject, but RIV-compliant devices MUST include their serial
numbers in the DevID/IAK certificates to simplify tracking numbers in the DevID/IAK certificates to simplify tracking
logistics for network equipment users. All other optional 802.1AR logistics for network equipment users. All other optional 802.1AR
fields remain optional in RIV fields remain optional in RIV.
It should be noted that 802.1AR use of X.509 certificate fields is
not identical to those descsribed in [RFC6125] for representation
of application service identity.
* 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]) which together are capable of (as defined in [SP800-155]) which together are capable of
conforming to TCG Trusted Attestation Protocol Information Model conforming to TCG Trusted Attestation Protocol Information Model
[TAP]. [TAP].
* The authorized software supplier MUST make available Reference * The authorized software supplier MUST make available Reference
Values in the form of signed SWID or CoSWID tags. Values in the form of signed SWID or CoSWID tags.
skipping to change at page 20, line 9 skipping to change at page 20, line 30
network operating system. These vendors may want to also use the TCG network operating system. These vendors may want to also use the TCG
PC Client Reference Integrity Measurement specification PC Client Reference Integrity Measurement specification
[PC-Client-RIM], which focuses specifically on a SWID-compatible [PC-Client-RIM], which focuses specifically on a SWID-compatible
format suitable for expressing measurement values expected from a format suitable for expressing measurement values expected from a
UEFI BIOS. UEFI BIOS.
2.4.2. Attestation Logs 2.4.2. Attestation Logs
Quotes from a TPM can provide evidence of the state of a device up to Quotes from a TPM can provide evidence of the state of a device up to
the time the evidence was recorded, but to make sense of the quote in the time the evidence was recorded, but to make sense of the quote in
most cases an event log that identifies which software modules cases where several events are extended into one PCR an event log
contributed which values to the quote during startup MUST also be that identifies which software modules contributed which values to
provided. The log MUST contain enough information to demonstrate its the quote during startup must also be provided. When required, the
integrity by allowing exact reconstruction of the digest conveyed in log MUST contain enough information to demonstrate its integrity by
the signed quote (that is, calculating the hash of all the hashes in allowing exact reconstruction of the digest conveyed in the signed
the log should produce the same values as contained in the PCRs; if quote (that is, calculating the hash of all the hashes in the log
they don't match, the log may have been tampered with. See should produce the same values as contained in the PCRs; if they
Section 9.1). don't match, the log may have been tampered with. See 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, but to formats of Evidence between the Attester and Verifier, but to
simplify interoperability, RIV focuses on just three: simplify interoperability, RIV focuses on just three:
* TCG UEFI BIOS event log for TPM 2.0 (TCG PC Client Platform * TCG UEFI BIOS event log for TPM 2.0 (TCG PC Client Platform
Firmware Profile) [PC-Client-BIOS-TPM-2.0] Firmware Profile) [PC-Client-BIOS-TPM-2.0]
* TCG UEFI BIOS event log for TPM 1.2 (TCG EFI Platform * TCG UEFI BIOS event log for TPM 1.2 (TCG EFI Platform
Specification for TPM Family 1.1 or 1.2, Section 7) Specification for TPM Family 1.1 or 1.2, Section 7)
skipping to change at page 20, line 47 skipping to change at page 21, line 21
based on the standard roles defined in [I-D.ietf-rats-architecture]. based on the standard roles defined in [I-D.ietf-rats-architecture].
However additional prerequisites have been established to allow for However additional prerequisites have been established to allow for
interoperable RIV use case implementations. These prerequisites are interoperable RIV use case implementations. These prerequisites are
intended to provide sufficient context information so that the intended to provide sufficient context information so that the
Verifier can acquire and evaluate measurements collected by the Verifier can acquire and evaluate measurements collected by the
Attester. Attester.
3.1.1. Unique Device Identity 3.1.1. Unique Device Identity
A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID
certificate [IEEE-802-1AR] MUST be provisioned in the Attester's certificate [IEEE-802-1AR] must be provisioned in the Attester's
TPMs. TPMs.
3.1.2. Keys 3.1.2. Keys
The Attestation Key (AK) and certificate MUST also be provisioned on The Attestation Key (AK) and certificate must also be provisioned on
the Attester according to [Platform-DevID-TPM-2.0], or the Attester according to [Platform-DevID-TPM-2.0], or
[Platform-ID-TPM-1.2]. [Platform-ID-TPM-1.2].
It MUST be possible for the Verifier to determine that the Attester's It MUST be possible for the Verifier to determine that the Attester's
Attestation keys are resident in the same TPM as its DevID keys (see Attestation keys are resident in the same TPM as its DevID keys (see
Section 2.2 and Section 5 Security Considerations). Section 2.2 and Section 5 Security Considerations).
3.1.3. Appraisal Policy for Evidence 3.1.3. Appraisal Policy for Evidence
As noted in Section 2.3, the Verifier may obtain Reference Values As noted in Section 2.3, the Verifier may obtain Reference Values
skipping to change at page 22, line 40 skipping to change at page 22, line 51
Figure 4: IETF Attestation Information Flow Figure 4: IETF Attestation Information Flow
* Step 1 (time(VG)): One or more Attesting Network Device PCRs are * Step 1 (time(VG)): One or more Attesting Network Device PCRs are
extended with measurements. RIV provides no direct link between extended with measurements. RIV provides no direct link between
the time at which the event takes place and the time that it's the time at which the event takes place and the time that it's
attested, although streaming attestation as in attested, although streaming attestation as in
[I-D.birkholz-rats-network-device-subscription] could. [I-D.birkholz-rats-network-device-subscription] could.
* Step 2 (time(NS)): The Verifier generates a unique random nonce * Step 2 (time(NS)): The Verifier generates a unique random nonce
("number used once"), and makes a request for one or more PCRs ("number used once"), and makes a request for one or more PCRs
from an Attester. For interoperability, this MUST be accomplished from an Attester. For interoperability, this must be accomplished
via an interface that implements the YANG Data Model for as specified in the YANG Data Model for Challenge-Response-based
Challenge-Response-based Remote Attestation Procedures using TPMs Remote Attestation Procedures using TPMs
[I-D.ietf-rats-yang-tpm-charra]. TPM1.2 and TPM2.0 both allow [I-D.ietf-rats-yang-tpm-charra]. TPM1.2 and TPM2.0 both allow
nonces as large as the operative digest size (i.e., 20 or 32 nonces as large as the operative digest size (i.e., 20 or 32
bytes; see [TPM1.2] Part 2, Section 5.5 and [TPM2.0] Part 2, bytes; see [TPM1.2] Part 2, Section 5.5 and [TPM2.0] Part 2,
Section 10.4.4). Section 10.4.4).
* Step 3 (time(EG)): On the Attester, measured values are retrieved * Step 3 (time(EG)): On the Attester, measured values are retrieved
from the Attester's TPM. This requested PCR evidence, along with from the Attester's TPM. This requested PCR evidence, along with
the Verifier's nonce, called a Quote, is signed by the Attestation the Verifier's nonce, 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 CHARRA YANG model [I-D.ietf-rats-yang-tpm-charra]. according to CHARRA YANG model [I-D.ietf-rats-yang-tpm-charra].
skipping to change at page 23, line 45 skipping to change at page 24, line 7
- 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 MUST retrieve signed PCR based Evidence Network Management systems may retrieve signed PCR based Evidence
using [I-D.ietf-rats-yang-tpm-charra] with NETCONF or RESTCONF. using NETCONF or RESTCONF with [I-D.ietf-rats-yang-tpm-charra]. In
either case, implementatations must do so using a secure tunnel.
Implementations that use NETCONF MUST do so over a TLS or SSH secure
tunnel. Implementations that use RESTCONF transport MUST do so over
a TLS or SSH secure tunnel.
Log Evidence MUST be retrieved via log interfaces specified in Log Evidence MUST be retrieved via log interfaces specified in
[I-D.ietf-rats-yang-tpm-charra]. [I-D.ietf-rats-yang-tpm-charra].
3.3. Centralized vs Peer-to-Peer 3.3. Centralized vs Peer-to-Peer
Figure 4 above assumes that the Verifier is trusted, while the Figure 4 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, the two peers can each ask the negotiating a trust relationship, 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 5. device responds to the other's challenge, as shown in Figure 5.
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. Details of peer-to-peer
operation are out of scope for this document.
+---------------+ +---------------+ +---------------+ +---------------+
| RefVal | | RefVal | | RefVal | | RefVal |
| Provider A | | Provider B | | Provider A | | Provider B |
| Firmware | | Firmware | | Firmware | | Firmware |
| Configuration | | Configuration | | Configuration | | Configuration |
| Authority | | Authority | | Authority | | Authority |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
| | | |
| |Step 0B
| +------------+ +------------+ | | +------------+ +------------+ |
| | | Step 1 | | | \ | | | Step 1 | | | \
| | Attester |<------>| Verifier | | | | | Attester |<------>| Verifier | | |
| | |<------>| | | | Router B | | |<------>| | | | Router B
+------>| | Step 2 | | | |- Challenges +------>| | Step 2 | | | |- Challenges
Step 0A| | | | | | Router A Step 0A| | | | | | Router A
| |------->| | | | | |------->| | | |
|- Router A -| Step 3 |- Router B -| | / |- Router A -| Step 3 |- Router B -| | /
| | | | | | | | | |
| | | | | | | | | |
skipping to change at page 26, line 14 skipping to change at page 26, line 42
While attestation information from network devices is not likely to While attestation information from network devices is not likely to
contain privacy-sensitive content regarding network users, contain privacy-sensitive content regarding network users,
administrators may want to keep attestation records confidential to administrators may want to keep attestation records confidential to
avoid disclosing versions of software loaded on the device, avoid disclosing versions of software loaded on the device,
information which could facilitate attacks against known information which could facilitate attacks against known
vulnerabilities. vulnerabilities.
5. Security Considerations 5. Security Considerations
Attestation Evidence from the RIV procedure are subject to a number Specifications such as [RFC8446] (TLS) and [RFC7950] (YANG) contain
of attacks: considerable advice on keeping network-connected systems secure.
This section outlines specific risks and mitigations related to
attestation.
Attestation Evidence obtained by the RIV procedure is subject to a
number of attacks:
* Keys may be compromised. * Keys may be compromised.
* A counterfeit device may attempt to impersonate (spoof) a known * A counterfeit device may attempt to impersonate (spoof) a known
authentic device. authentic device.
* Person-in-the-middle attacks may be used by a compromised device * Person-in-the-middle attacks may be used by a compromised device
to attempt to deliver responses that originate in an authentic to attempt to deliver responses that originate in an authentic
device. device.
skipping to change at page 27, line 47 skipping to change at page 28, line 33
With these elements, the device's manufacturer and serial number can With these elements, the device's manufacturer and serial number can
be identified by analyzing the DevID certificate plus the chain of be identified by analyzing the DevID certificate plus the chain of
intermediate certificates leading back to the manufacturer's root intermediate certificates leading back to the manufacturer's root
certificate. As is conventional in TLS or SSH connections, a random certificate. As is conventional in TLS or SSH connections, a random
nonce must be signed by the device in response to a challenge, nonce must be signed by the device in response to a challenge,
proving possession of its DevID private key. proving possession of its DevID private key.
RIV uses the DevID to validate a TLS or SSH connection to the device RIV uses the DevID to validate a TLS or SSH connection to the device
as the attestation session begins. Security of this process derives as the attestation session begins. Security of this process derives
from TLS or SSH security, with the DevID providing proof that the from TLS or SSH security, with the DevID, containing a device serial
session terminates on the intended device. See [RFC8446], [RFC4253]. number, providing proof that the session terminates on the intended
device. See [RFC8446], [RFC4253].
Evidence of software integrity is delivered in the form of a quote Evidence of software integrity is delivered in the form of a quote
signed by the TPM itself. Because the contents of the quote are signed by the TPM itself, accompanied by an IAK certificate
signed inside the TPM, any external modification (including containing the same identity information as the DevID. Because the
reformatting to a different data format) after measurements have been contents of the quote are signed inside the TPM, any external
taken will be detected as tampering. An unbroken chain of trust is modification (including reformatting to a different data format)
essential to ensuring that blocks of code that are taking after measurements have been taken will be detected as tampering. An
measurements have been verified before execution (see Figure 1). unbroken chain of trust is essential to ensuring that blocks of code
that are taking measurements have been verified before execution (see
Figure 1).
Requiring measurements of the operating software to be signed by a Requiring measurements of the operating software to be signed by a
key known only to the TPM also removes the need to trust the device's key known only to the TPM also removes the need to trust the device's
operating software (beyond the first measurement in the RTM; see operating software (beyond the first measurement in the RTM; see
below); any changes to the quote, generated and signed by the TPM below); any changes to the quote, generated and signed by the TPM
itself, made by malicious device software, or in the path back to the itself, made by malicious device software, or in the path back to the
Verifier, will invalidate the signature on the quote. Verifier, will invalidate the signature on the quote.
A critical feature of the YANG model described in A critical feature of the YANG model described in
[I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data
skipping to change at page 28, line 29 skipping to change at page 29, line 18
the structures as they were signed and delivered by the TPM. While the structures as they were signed and delivered by the TPM. While
alternate methods of conveying TPM quotes could compress out alternate methods of conveying TPM quotes could compress out
redundant information, or add an additional layer of signing using redundant information, or add an additional layer of signing using
external keys, the implementation MUST preserve the TPM signing, so external keys, the implementation MUST preserve the TPM signing, so
that tampering anywhere in the path between the TPM itself and the that tampering anywhere in the path between the TPM itself and the
Verifier can be detected. Verifier can be detected.
5.2. Prevention of Spoofing and Person-in-the-Middle Attacks 5.2. Prevention of Spoofing and Person-in-the-Middle Attacks
Prevention of spoofing attacks against attestation systems is also Prevention of spoofing attacks against attestation systems is also
important. There are two cases to consider: important. There are several cases to consider:
* The entire device could be spoofed. If the Verifier goes to * The entire device could be spoofed. If the Verifier goes to
appraise a specific Attester, it might be redirected to a appraise a specific Attester, it might be redirected to a
different Attester. Use of the 802.1AR Device Identity (DevID) in different Attester.
the TPM ensures that the Verifier's TLS or SSH session is in fact
terminating on the right device. * A compromised device could have a valid DevID, but substitute a
quote from a knonwn-good device, instead of returning its own, as
described in [RFC6813].
* A device with a compromised OS could return a fabricated quote * A device with a compromised OS could return a fabricated quote
providing spoofed attestation Evidence. providing spoofed attestation Evidence.
Use of the 802.1AR Device Identity (DevID) in the TPM provides
protection against the case of a spoofed device, by ensuring that the
Verifier's TLS or SSH session is in fact terminating on the right
device.
Protection against spoofed quotes from a device with valid identity Protection against spoofed quotes from a device with valid identity
is a bit more complex. An identity key must be available to sign any is a bit more complex. An identity key must be available to sign any
kind of nonce or hash offered by the Verifier, and consequently, kind of nonce or hash offered by the Verifier, and consequently,
could be used to sign a fabricated quote. To block a spoofed could be used to sign a fabricated quote. To block a spoofed
Attestation Result, the quote generated inside the TPM must be signed Attestation Result, the quote generated inside the TPM must be signed
by a key that's different from the DevID, called an Attestation Key by a key that's different from the DevID, called an Attestation Key
(AK). (AK).
Given separate Attestation and DevID keys, the binding between the AK Given separate Attestation and DevID keys, the binding between the AK
and the same device must also be proven to prevent a person-in-the- and the same device must also be proven to prevent a person-in-the-
middle attack (e.g., the 'Asokan Attack' [RFC6813]). middle attack (e.g., the 'Asokan Attack' [RFC6813]).
This is accomplished in RIV through use of an AK certificate with the This is accomplished in RIV through use of an AK certificate with the
same elements as the DevID (same manufacturer's serial number, signed same elements as the DevID (same manufacturer's serial number, signed
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. This binding between
DevID and AK certificates is critical to reliable attestation.
The TCG document TPM 2.0 Keys for Device Identity and Attestation The TCG document TPM 2.0 Keys for Device Identity and Attestation
[Platform-DevID-TPM-2.0] specifies OIDs for Attestation Certificates [Platform-DevID-TPM-2.0] specifies OIDs for Attestation Certificates
that allow the CA to mark a key as specifically known to be an that allow the CA to mark a key as specifically known to be an
Attestation key. Attestation key.
These two key-pairs and certificates are used together: These two key-pairs and certificates are used together:
* The DevID is used to validate a TLS connection terminating on the * The DevID is used to validate a TLS connection terminating on the
device with a known serial number. device with a known serial number.
skipping to change at page 29, line 38 skipping to change at page 30, line 33
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
resulting quote was generated in response to the Verifier's specific resulting quote was generated in response to the Verifier's specific
request). Time-Based Uni-directional Attestation request). Time-Based Uni-directional Attestation
[I-D.birkholz-rats-tuda] provides an alternate mechanism to verify [I-D.birkholz-rats-tuda] provides an alternate mechanism to verify
freshness without requiring a request/response cycle. freshness without requiring a request/response cycle.
5.4. Owner-Signed Keys 5.4. Owner-Signed Keys
Although device manufacturers MUST pre-provision devices with easily Although device manufacturers must pre-provision devices with easily
verified DevID and AK certificates if zero-touch provisioning such as verified DevID and AK certificates if zero-touch provisioning such as
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.
* 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. Local identity keys in TPM 2.0. Owners should follow the same
practice of binding Local DevID and Local AK as the manufacturer
would for IDevID and IAK. See Section Section 2.2.
* Device owners, however, can use any other mechanism they want to * Device owners, however, can use any other mechanism they want 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, or using
procedures such as those outlined in Bootstrapping Remote Secure Key
Infrastructure (BRSKI) [RFC8995].
On the other end of the device life cycle, provision should be made On the other end of the device life cycle, provision should be made
to wipe local keys when a device is decommissioned, to indicate that to wipe local keys when a device is decommissioned, to indicate that
the device is no longer owned by the enterprise. The manufacturer's the device is no longer owned by the enterprise. The manufacturer's
Initial identity keys must be preserved, as they contain no Initial identity keys must be preserved, as they contain no
information that's not already printed on the device's serial number information that's not already printed on the device's serial number
plate. plate.
5.5. Other Factors for Trustworthy Operation 5.5. Other Factors for Trustworthy Operation
skipping to change at page 31, line 8 skipping to change at page 32, line 21
* 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. It should also be noted
of-band or in-band, as part of the attestation process (see that, while RIV can provide a reliable indication that a known
Section 3.1.3). But for network devices, where software is usually software package is in use by the device, and that the package has
shipped as a self-contained package, RIMs signed by the manufacturer not been tampered, it is the device owner's responsibility to
and delivered in-band may be more convenient for the device owner. determine that it's the correct package for the application.
RIMs may be conveyed out-of-band or in-band, as part of the
attestation process (see Section 3.1.3). But for network devices,
where software is usually shipped as a self-contained package, RIMs
signed by the manufacturer and delivered in-band may be more
convenient for the device owner.
The validity of RIV attestation results is also influenced by The validity of RIV attestation results is also influenced by
procedures used to create Reference Values: procedures used to create Reference Values:
* While the RIM itself is signed, supply-chains SHOULD be carefully * While the RIM itself is signed, supply-chains SHOULD be carefully
scrutinized to ensure that the values are not subject to scrutinized to ensure that the values are not subject to
unexpected manipulation prior to signing. Insider-attacks against unexpected manipulation prior to signing. Insider-attacks against
code bases and build chains are particularly hard to spot. code bases and build chains are particularly hard to spot.
* Designers SHOULD guard against hash collision attacks. Reference * Designers SHOULD guard against hash collision attacks. Reference
skipping to change at page 34, line 13 skipping to change at page 35, line 29
and [Canonical-Event-Log]. and [Canonical-Event-Log].
9.2. Root of Trust for Measurement 9.2. Root of Trust for Measurement
The measurements needed for attestation require that the device being The measurements needed for attestation require that the device being
attested is equipped with a Root of Trust for Measurement, that is, attested is equipped with a Root of Trust for Measurement, that is,
some trustworthy mechanism that can compute the first measurement in some trustworthy mechanism that can compute the first measurement in
the chain of trust required to attest that each stage of system the chain of trust required to attest that each stage of system
startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs) startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs)
to record the results, and a Root of Trust for Reporting to report to record the results, and a Root of Trust for Reporting to report
the results [TCGRoT], [SP800-155], [SP800-193]. the results.
While there are many complex aspects of a Root of Trust, two aspects While there are many complex aspects of Roots of Trust ( [TCGRoT],
that are important in the case of attestation are: [SP800-155], [SP800-193]), two aspects that are important in the case
of attestation are:
* The first measurement computed by the Root of Trust for * 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.
* 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
skipping to change at page 35, line 22 skipping to change at page 36, line 28
-------------------- -------------------- -------------------- --------------------
| | | |
------------------------------- --------------------------------- ------------------------------- ---------------------------------
|Reference Values | | Attestation | |Reference Values | | Attestation |
------------------------------- --------------------------------- ------------------------------- ---------------------------------
******************************************************************** ********************************************************************
* IETF Attestation Reference Interaction Diagram * * IETF Attestation Reference Interaction Diagram *
******************************************************************** ********************************************************************
....................... ....................... ......................... .........................
. Reference Integrity . . TAP (PTS2.0) Info . . Reference Integrity . . TAP (PTS2.0) Info .
. Manifest . . Model and Canonical . . Manifest . . Model and Canonical .
. . . Log Format . . . . Log Format .
....................... ....................... ......................... .........................
************************* **********************
* YANG SWID Module * * YANG Attestation *
* I-D.ietf-sacm-coswid * * Module *
* * * I-D.ietf-rats- *
* * * yang-tpm-charra *
************************* **********************
************************* ************ ************************ ************************* *************************
* XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)* * YANG SWID Module * * YANG Attestation *
************************* ************ ************************ * I-D.ietf-sacm-coswid * * Module *
* * * I-D.ietf-rats- *
* * * yang-tpm-charra *
************************* *************************
************************* ************************ ************************* *************************
* RESTCONF/NETCONF * * RESTCONF/NETCONF * * XML, JSON, CBOR (etc) * * XML, JSON, CBOR (etc) *
************************* ************************ ************************* *************************
************************* ************************ ************************* *************************
* TLS, SSH * * TLS, SSH * * RESTCONF/NETCONF * * RESTCONF/NETCONF *
************************* ************************ ************************* *************************
************************* *************************
* TLS, SSH * * TLS, SSH *
************************* *************************
Figure 6: RIV Protocol Stacks Figure 6: RIV Protocol Stacks
IETF documents are captured in boxes surrounded by asterisks. TCG IETF documents are captured in boxes surrounded by asterisks. TCG
documents are shown in boxes surrounded by dots. documents are shown in boxes surrounded by dots.
9.4. Implementation Notes 9.4. Implementation Notes
Figure 7 summarizes many of the actions needed to complete an Figure 7 summarizes many of the actions needed to complete an
Attestation system, with links to relevant documents. While Attestation system, with links to relevant documents. While
documents are controlled by several standards organizations, the documents are controlled by several standards organizations, the
skipping to change at page 36, line 45 skipping to change at page 37, line 49
| o Install an Initial Attestation Key at the | TCG Platform | | o Install an Initial Attestation Key at the | TCG Platform |
| same time so that Attestation can work out | Certificate | | same time so that Attestation can work out | Certificate |
| of the box |----------------- | of the box |-----------------
| o Equipment suppliers and owners may want to | IEEE 802.1AR | | o Equipment suppliers and owners may want to | IEEE 802.1AR |
| implement Local Device ID as well as | | | implement Local Device ID as well as | |
| Initial Device ID | | | Initial Device ID | |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Connect the TPM to the TLS stack | Vendor TLS | | Connect the TPM to the TLS stack | Vendor TLS |
| o Use the DevID in the TPM to authenticate | stack (This | | o Use the DevID in the TPM to authenticate | stack (This |
| TAP connections, identifying the device | action is | | TAP connections, identifying the device | action is |
| | simply |
| | configuring TLS| | | configuring TLS|
| | to use the DevID | | | to use the DevID |
| | as its client | | | as its client |
| | certificate) | | | certificate) |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Make CoSWID tags for BIOS/Loader/Kernel objects | IETF CoSWID | | Make CoSWID tags for BIOS/Loader/Kernel objects | IETF CoSWID |
| o Add reference measurements into SWID tags | ISO/IEC 19770-2| | o Add reference measurements into SWID tags | ISO/IEC 19770-2|
| o Manufacturer should sign the SWID tags | NIST IR 8060 | | o Manufacturer should sign the SWID tags | NIST IR 8060 |
| o The TCG RIM-IM identifies further | | | o The TCG RIM-IM identifies further | |
| procedures to create signed RIM | | | procedures to create signed RIM | |
skipping to change at page 38, line 5 skipping to change at page 39, line 11
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: .30", December 2020, Version: 1.0, Revision: .30", December 2020,
<https://www.trustedcomputinggroup.org/wp-content/uploads/ <https://www.trustedcomputinggroup.org/wp-content/uploads/
TCG_IWG_CEL_v1_r0p30_13feb2021.pdf>. TCG_IWG_CEL_v1_r0p30_13feb2021.pdf>.
[I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", Work
in Progress, Internet-Draft, draft-ietf-rats-architecture-
15, 8 February 2022, <https://www.ietf.org/archive/id/
draft-ietf-rats-architecture-15.txt>.
[I-D.ietf-rats-yang-tpm-charra] [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", Work in Progress, Attestation Procedures using TPMs", Work in Progress,
Internet-Draft, draft-ietf-rats-yang-tpm-charra-12, 14 Internet-Draft, draft-ietf-rats-yang-tpm-charra-13, 2
January 2022, <https://www.ietf.org/archive/id/draft-ietf- February 2022, <https://www.ietf.org/archive/id/draft-
rats-yang-tpm-charra-12.txt>. ietf-rats-yang-tpm-charra-13.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", Work Waltermire, "Concise Software Identification Tags", Work
in Progress, Internet-Draft, draft-ietf-sacm-coswid-20, 26 in Progress, Internet-Draft, draft-ietf-sacm-coswid-20, 26
January 2022, <https://www.ietf.org/archive/id/draft-ietf- January 2022, <https://www.ietf.org/archive/id/draft-ietf-
sacm-coswid-20.txt>. sacm-coswid-20.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
skipping to change at page 39, line 23 skipping to change at page 40, line 36
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>. January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[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",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>.
[RIM] Trusted Computing Group, "TCG Reference Integrity Manifest [RIM] Trusted Computing Group, "TCG Reference Integrity Manifest
(RIM) Information Model, v1.0, r0.16", June 2019, (RIM) Information Model, v1.0, r0.16", June 2019,
<https://trustedcomputinggroup.org/wp-content/uploads/ <https://trustedcomputinggroup.org/wp-content/uploads/
TCG_RIM_Model_v1p01_r0p16_pub.pdf>. TCG_RIM_Model_v1p01_r0p16_pub.pdf>.
[SWID] The International Organization for Standardization/ [SWID] The International Organization for Standardization/
International Electrotechnical Commission, "Information International Electrotechnical Commission, "Information
Technology Software Asset Management Part 2: Software Technology Software Asset Management Part 2: Software
Identification Tag, ISO/IEC 19770-2", October 2015, Identification Tag, ISO/IEC 19770-2", October 2015,
<https://www.iso.org/standard/65666.html>. <https://www.iso.org/standard/65666.html>.
skipping to change at page 41, line 5 skipping to change at page 42, line 12
<https://www.ietf.org/archive/id/draft-birkholz-rats- <https://www.ietf.org/archive/id/draft-birkholz-rats-
reference-interaction-model-03.txt>. 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", Work in "Time-Based Uni-Directional Attestation", Work in
Progress, Internet-Draft, draft-birkholz-rats-tuda-06, 12 Progress, Internet-Draft, draft-birkholz-rats-tuda-06, 12
January 2022, <https://www.ietf.org/archive/id/draft- January 2022, <https://www.ietf.org/archive/id/draft-
birkholz-rats-tuda-06.txt>. birkholz-rats-tuda-06.txt>.
[I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", Work
in Progress, Internet-Draft, draft-ietf-rats-architecture-
14, 9 December 2021, <https://www.ietf.org/archive/id/
draft-ietf-rats-architecture-14.txt>.
[I-D.ietf-rats-eat] [I-D.ietf-rats-eat]
Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity
Attestation Token (EAT)", Work in Progress, Internet- Attestation Token (EAT)", Work in Progress, Internet-
Draft, draft-ietf-rats-eat-11, 24 October 2021, Draft, draft-ietf-rats-eat-11, 24 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-rats-eat- <https://www.ietf.org/archive/id/draft-ietf-rats-eat-
11.txt>. 11.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", Work in Progress, Remote Attestation common encodings", Work in Progress,
skipping to change at page 42, line 23 skipping to change at page 43, line 23
Trusted Computing Group, "TCG TPM v2.0 Provisioning Trusted Computing Group, "TCG TPM v2.0 Provisioning
Guidance, Version 1.0, Revision 1.0", March 2015, Guidance, Version 1.0, Revision 1.0", March 2015,
<https://trustedcomputinggroup.org/wp-content/uploads/TCG- <https://trustedcomputinggroup.org/wp-content/uploads/TCG-
TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf>. TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment [RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment
(NEA) Asokan Attack Analysis", RFC 6813, (NEA) Asokan Attack Analysis", RFC 6813,
DOI 10.17487/RFC6813, December 2012, DOI 10.17487/RFC6813, December 2012,
<https://www.rfc-editor.org/info/rfc6813>. <https://www.rfc-editor.org/info/rfc6813>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/info/rfc8995>.
[SP800-155] [SP800-155]
National Institute of Standards and Technology, "BIOS National Institute of Standards and Technology, "BIOS
Integrity Measurement Guidelines (Draft)", December 2011, Integrity Measurement Guidelines (Draft)", December 2011,
<https://csrc.nist.gov/csrc/media/publications/sp/800- <https://csrc.nist.gov/csrc/media/publications/sp/800-
155/draft/documents/draft-sp800-155_dec2011.pdf>. 155/draft/documents/draft-sp800-155_dec2011.pdf>.
[SP800-193] [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,
 End of changes. 63 change blocks. 
162 lines changed or deleted 214 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/