draft-ietf-rats-tpm-based-network-device-attest-00.txt   draft-ietf-rats-tpm-based-network-device-attest-01.txt 
RATS Working Group G. Fedorkow, Ed. RATS Working Group G. Fedorkow, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Informational E. Voit Intended status: Informational E. Voit
Expires: December 5, 2020 Cisco Systems, Inc. Expires: January 13, 2021 Cisco Systems, Inc.
J. Fitzgerald-McKay J. Fitzgerald-McKay
National Security Agency National Security Agency
June 03, 2020 July 12, 2020
TPM-based Network Device Remote Integrity Verification TPM-based Network Device Remote Integrity Verification
draft-ietf-rats-tpm-based-network-device-attest-00 draft-ietf-rats-tpm-based-network-device-attest-01
Abstract Abstract
This document describes a workflow for remote attestation of This document describes a workflow for remote attestation of the
integrity of network devices. integrity of network devices.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 5, 2020. This Internet-Draft will expire on January 13, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Document Organization . . . . . . . . . . . . . . . . . . 4 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4
1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Description of Remote Integrity Verification (RIV) . . . 5 1.4. Description of Remote Integrity Verification (RIV) . . . 5
1.5. Solution Requirements . . . . . . . . . . . . . . . . . . 7 1.5. Solution Requirements . . . . . . . . . . . . . . . . . . 7
1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8 1.6.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8
2. Solution Outline . . . . . . . . . . . . . . . . . . . . . . 8 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8
2.1. RIV Software Configuration Attestation using TPM . . . . 8 2.1. RIV Software Configuration Attestation using TPM . . . . 8
2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 9 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 9
2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 12 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 13
2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 14 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 15
2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 15 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 16
2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 16 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 17
3. Standards Components . . . . . . . . . . . . . . . . . . . . 16 3. Standards Components . . . . . . . . . . . . . . . . . . . . 17
3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 16 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 17
3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 17 3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 18
3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 17 3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 18
3.2. Reference Model for Challenge-Response . . . . . . . . . 18 3.2. Reference Model for Challenge-Response . . . . . . . . . 19
3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 19 3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 21
3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 20 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 21
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Layering Model for Network Equipment Attester and 8.1. Layering Model for Network Equipment Attester and
Verifier . . . . . . . . . . . . . . . . . . . . . . . . 27 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1.1. Why is OS Attestation Different? . . . . . . . . . . 29 8.1.1. Why is OS Attestation Different? . . . . . . . . . . 31
8.2. Implementation Notes . . . . . . . . . . . . . . . . . . 29 8.2. Implementation Notes . . . . . . . . . . . . . . . . . . 31
8.3. Root of Trust for Measurement . . . . . . . . . . . . . . 31 8.3. Root of Trust for Measurement . . . . . . . . . . . . . . 33
9. Informative References . . . . . . . . . . . . . . . . . . . 31 9. Informative References . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
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 case for [I-D.ietf-rats-architecture]. Additionally, the use case for
remotely attesting networking devices is within Section 6 of remotely attesting networking devices is within Section 6 of
[I-D.richardson-rats-usecases]. However, two these documents do not [I-D.richardson-rats-usecases]. However, these documents do not
provide sufficient guidance for equipment vendors and network provide sufficient guidance for equipment vendors and network
operators and to design, build, and deploy interoperable platforms. operators to design, build, and deploy interoperable platforms.
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 and Switches. An underlying assumption will products such as routers, switches and firewalls. An underlying
be the availability within the device of a Trusted Platform Module assumption will be the availability within the device of a Trusted
(TPM) compliant cryptoprocessor to enable the remote trustworthy Platform Module (TPM) compliant cryptoprocessor to enable the remote
assessment of the device's software and hardware. trustworthy assessment of the device's software and hardware.
1.1. Terminology 1.1. Terminology
A number of terms are reused from [I-D.ietf-rats-architecture]. A number of terms are reused from [I-D.ietf-rats-architecture].
These include: Appraisal Policy for Attestation Result, Attestation These include: Appraisal Policy for Attestation Result, Attestation
Result, Attester, Endorser, Evidence, Relying Party, Verifier, Result, Attester, Endorser, Evidence, Relying Party, Verifier,
Verifier Owner. Verifier Owner.
Additionally, this document defines the following terms: Additionally, this document defines the following terms:
Attestation: the process of creating, conveying and appraising Attestation: the process of creating, conveying and appraising
assertions about Platform trustworthiness characteristics, including assertions about Platform trustworthiness characteristics, including
supply chain trust, identity, platform provenance, software supply chain trust, identity, platform provenance, software
configuration, hardware configuration, platform composition, configuration, hardware configuration, platform composition,
compliance to test suites, functional and assurance evaluations, etc. compliance to test suites, functional and assurance evaluations, etc.
The goal of attestation is simply to assure an administrator that the The goal of attestation is simply to assure an administrator that the
software that was launched when the device was last started is the software that was launched when the device was last started is an
same as the software that the device vendor initially shipped. authentic and untampered copy of the software that the device vendor
shipped.
Within the Trusted Computing Group context, attestation is the Within the Trusted Computing Group context, attestation is the
process by which an independent Verifier can obtain cryptographic process by which an independent Verifier can obtain cryptographic
proof as to the identity of the device in question, evidence of the proof as to the identity of the device in question, evidence of the
integrity of software loaded on that device when it started up, and integrity of software loaded on that device when it started up, and
then verify that what's there is what's supposed to be there. For then verify that what's there is what's supposed to be there. For
networking equipment, a verifier capability can be embedded in a networking equipment, a verifier capability can be embedded in a
Network Management Station (NMS), a posture collection server, or Network Management Station (NMS), a posture collection server, or
other network analytics tool (such as a software asset management other network analytics tool (such as a software asset management
solution, or a threat detection and mitigation tool, etc.). While solution, or a threat detection and mitigation tool, etc.). While
informally referred to as attestation, this document focuses on a informally referred to as attestation, this document focuses on a
subset defined here as Remote Integrity Verification (RIV). RIV subset defined here as Remote Integrity Verification (RIV). RIV
takes a network equipment centric perspective that includes a set of takes a network equipment centric perspective that includes a set of
protocols and procedures for determining whether a particular device protocols and procedures for determining whether a particular device
was launched with untampered software, starting from Roots of Trust. was launched with untampered software, starting from Roots of Trust.
While there are many ways to accomplish attestation, RIV sets out a While there are many ways to accomplish attestation, RIV sets out a
specific set of protocols and tools that work in environments specific set of protocols and tools that work in environments
commonly found in Networking Equipment. RIV does not cover other commonly found in Networking Equipment. RIV does not cover other
platform characteristics that could be attested, although it does platform characteristics that could be attested (e.g. geographic
provide evidence of a secure infrastructure to increase the level of location, connectivity; see [I-D.richardson-rats-usecases]), although
trust in other platform characteristics attested by other means it does provide evidence of a secure infrastructure to increase the
(e.g., by Entity Attestation Tokens [I-D.ietf-rats-eat]. level of trust in other platform characteristics attested by other
means (e.g., by Entity Attestation Tokens [I-D.ietf-rats-eat]).
1.2. Document Organization 1.2. Document Organization
The remainder of this document is organized into several sections: The remainder of this document is organized into several sections:
o The remainder of this section covers goals and requirements, plus o The remainder of this section covers goals and requirements, plus
a top-level overview a top-level description of RIV
o The Solution Overview section outlines how RIV works o The Solution Overview section outlines how RIV works
o The Standards Components section links components of RIV to o The Standards Components section links components of RIV to
normative standards. normative standards.
o Privacy and Security shows how specific features of RIV contribute
to the trustworthiness of the attestation result
o Supporting material is in an appendix at the end. o Supporting material is in an appendix at the end.
1.3. Goals 1.3. 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 for asset management, integrity, attestation can be used for asset management,
vulnerability and compliance assessment, plus configuration vulnerability and compliance assessment, plus configuration
skipping to change at page 5, line 7 skipping to change at page 5, line 11
each device. Effectively this means that the TPM or equivalent each device. Effectively this means that the TPM or equivalent
cryptoprocessor must be so provisioned during the manufacturing cryptoprocessor must be so provisioned during the manufacturing
cycle. cycle.
o Software Inventory - A key goal is to identify the software o Software Inventory - A key goal is to identify the software
release installed on the attesting device, and to provide evidence release installed on the attesting device, and to provide evidence
that the software stored within hasn't been altered that the software stored within hasn't been altered
o Verifiability - Verification of software and configuration of the o Verifiability - Verification of software and configuration of the
device shows that the software that was authorized for device shows that the software that was authorized for
installation by the administrator has actually has been launched. installation by the administrator has actually been launched.
In addition, RIV is designed to operate in a centralized environment, In addition, RIV is designed to operate in a centralized environment,
such as with a central authority that manages and configures a number such as with a central authority that manages and configures a number
of network devices, or 'peer-to-peer', where network devices of network devices, or 'peer-to-peer', where network devices
independently verify one another to establish a trust relationship. independently verify one another to establish a trust relationship.
(See Section 3.3 below, and also (See Section 3.3 below, and also
[I-D.voit-rats-trusted-path-routing]) [I-D.voit-rats-trusted-path-routing])
1.4. Description of Remote Integrity Verification (RIV) 1.4. Description of Remote Integrity Verification (RIV)
skipping to change at page 6, line 21 skipping to change at page 6, line 26
installed is authentic, up-to-date, and free of tampering. installed is authentic, up-to-date, and free of tampering.
4. Conveyance of Evidence reliably transports at least the minimum 4. Conveyance of Evidence reliably transports at least the minimum
amount of Evidence from Attester to a Verifier to allow a amount of Evidence from Attester to a Verifier to allow a
management station to perform a meaningful appraisal in Step 5. management station to perform a meaningful appraisal in Step 5.
The transport is typically carried out via a management network. The transport is typically carried out via a management network.
The channel must provide integrity and authenticity, and, in some The channel must provide integrity and authenticity, and, in some
use cases, may also require confidentiality. use cases, may also require confidentiality.
5. Finally, Appraisal of Evidence occurs. As the Verifier and 5. Finally, Appraisal of Evidence occurs. As the Verifier and
Relaying Party roles are often combined within RIV, this is the Relying Party roles are often combined within RIV, this is the
process of verifying the Evidence received by a Verifier from the process of verifying the Evidence received by a Verifier from the
Attesting device, and using an Appraisal Policy to develop an Attesting device, and using an Appraisal Policy to develop an
Attestation Result, used to inform decision making. In practice, Attestation Result, used to inform decision making. In practice,
this means comparing the device measurements reported as Evidence this means comparing the device measurements reported as Evidence
with the Attester configuration expected by the Verifier. with the Attester configuration expected by the Verifier.
Subsequently the Appraisal Policy for Attestation Results might Subsequently the Appraisal Policy for Attestation Results might
match what was found against Reference Integrity Measurements match what was found against Reference Integrity Measurements
(aka Golden Measurements) which representing the intended (aka Golden Measurements) which represent the intended configured
configured state of the connected device. state of the connected device.
All implementations supporting this RIV specification require the All implementations supporting this RIV specification require the
support of the following three technologies : 1. Identity: Platform support of the following three technologies: 1. Identity: Platform
identity can be based on IEEE 802.1AR Device Identity [IEEE-802-1AR], identity can be based on IEEE 802.1AR Device Identity [IEEE-802-1AR],
coupled with careful supply-chain management by the manufacturer. coupled with careful supply-chain management by the manufacturer.
The DevID certificate contains a statement by the manufacturer that The DevID certificate contains a statement by the manufacturer that
establishes the identity of the device as it left the factory. Some establishes the identity of the device as it left the factory. Some
applications with a more-complex post-manufacture supply chain (e.g. applications with a more-complex post-manufacture supply chain (e.g.
Value Added Resellers), or with different privacy concerns, may want Value Added Resellers), or with different privacy concerns, may want
to use alternate mechanisms for platform authentication (for example, to use alternative mechanisms for platform authentication (for
TCG Platform Certificates [Platform-Certificates]). example, TCG Platform Certificates [Platform-Certificates]).
1. Platform Attestation provides evidence of configuration of 1. Platform Attestation provides evidence of configuration of
software elements present in the device. This form of software elements present in the device. This form of
attestation can be implemented with TPM PCR, Quote and Log attestation can be implemented with TPM PCR, Quote and Log
mechanisms, which provide an authenticated mechanism to report mechanisms, which provide an authenticated mechanism to report
what software was started on the device through the boot cycle. what software was started on the device through the boot cycle.
Successful attestation requires an unbroken chain from a boot- Successful attestation requires an unbroken chain from a boot-
time root of trust through all layers of software needed to bring time root of trust through all layers of software needed to bring
the device to an operational state. the device to an operational state.
2. Reference Integrity Measurements must be conveyed from the 2. Reference Integrity Measurements must be conveyed from the
Endorser (the entity accepted as the software authority, often Endorser (the entity accepted as the software authority, often
the manufacturer for embedded systems) to the system in which the manufacturer for embedded systems) to the system in which
verification will take place verification will take place
1.5. Solution Requirements 1.5. Solution Requirements
skipping to change at page 8, line 22 skipping to change at page 8, line 22
o Multi-Vendor Embedded Systems: Additional coordination would be o Multi-Vendor Embedded Systems: Additional coordination would be
needed for devices that themselves comprise hardware and software needed for devices that themselves comprise hardware and software
from multiple vendors, integrated by the end user. from multiple vendors, integrated by the end user.
o Processor Sleep Modes: Network equipment typically does not o Processor Sleep Modes: Network equipment typically does not
"sleep", so sleep and hibernate modes are not considered. "sleep", so sleep and hibernate modes are not considered.
Although out of scope for RIV, Trusted Computing Group Although out of scope for RIV, Trusted Computing Group
specifications do encompass sleep and hibernate states. specifications do encompass sleep and hibernate states.
o Virtualization and Containerization: These technologies are o Virtualization and Containerization: In a non-virtualized system,
increasingly used in Network equipment, but are not considered in the host OS is responsible for measuring each Userland file or
this revision of the document. process, but that't the end of the chain of trust. For
virtualized systems, the host OS must verify the hypervisor, which
then manages its own chain of trust through the virtual machine.
Virtualization and containerization technologies are increasingly
used in Network equipment, but are not considered in this revision
of the document.
2. Solution Outline 2. Solution Overview
2.1. RIV Software Configuration Attestation using TPM 2.1. RIV Software Configuration Attestation using TPM
RIV Attestation is a process which can be used to determine the RIV Attestation is a process which can be used to determine the
identity of software running on a specifically-identified device. identity of software running on a specifically-identified device.
Remote Attestation is broken into two phases, shown in Figure 1: Remote Attestation is broken into two phases, shown in Figure 1:
o During system startup, each distinct software object is o During system startup, each distinct software object is
"measured". Its identity, hash (i.e. cryptographic digest) and "measured". Its identity, hash (i.e. cryptographic digest) and
version information is recorded in a log. Hashes are also version information are recorded in a log. Hashes are also
extended, or cryptographically folded, into the TPM, in a way that extended, or cryptographically folded, into the TPM, in a way that
can be used to validate the log entries. The measurement process can be used to validate the log entries. The measurement process
generally follows the Chain of Trust model used in Measured Boot, generally follows the Chain of Trust model used in Measured Boot,
where each stage of the system measures the next one, and extends where each stage of the system measures the next one, and extends
its measurement into the TPM, before launching it. its measurement into the TPM, before launching it.
o Once the device is running and has operational network o Once the device is running and has operational network
connectivity, a separate, trusted Verifier will interrogate the connectivity, a separate, trusted Verifier will interrogate the
network device to retrieve the logs and a copy of the digests network device to retrieve the logs and a copy of the digests
collected by hashing each software object, signed by an collected by hashing each software object, signed by an
skipping to change at page 9, line 42 skipping to change at page 9, line 46
Reset---------------flow-of-time-during-boot--...-------> Reset---------------flow-of-time-during-boot--...------->
Figure 1: RIV Attestation Model Figure 1: RIV Attestation Model
In Step 1, measurements are "extended" into the TPM as processes In Step 1, measurements are "extended" into the TPM as processes
start. In Step 2, signed PCR digests are retrieved from the TPM for start. In Step 2, signed PCR digests are retrieved from the TPM for
off-box analysis after the system is operational. off-box analysis after the system is operational.
2.1.1. What Does RIV Attest? 2.1.1. What Does RIV Attest?
TPM attestation is strongly focused around Platform Configuration TPM attestation is strongly focused on Platform Configuration
Registers (PCRs), but those registers are only vehicles for Registers (PCRs), but those registers are only vehicles for
certifying accompanying Evidence, conveyed in log entries. It is the certifying accompanying Evidence, conveyed in log entries. It is the
hashes in log entries are extended into PCRs, where they can be hashes in log entries that are extended into PCRs, where the final
retrieved in the form of a Quote signed by a key known only to the digests can be retrieved in the form of a Quote signed by a key known
TPM (xref). The use of multiple PCRs serves only to provide some only to the TPM. The use of multiple PCRs serves only to provide
independence between different classes of object, so that one class some independence between different classes of object, so that one
of objects can be updated without changing the extended hash for class of objects can be updated without changing the extended hash
other classes. Although PCRs can be used for any purpose, this for other classes. Although PCRs can be used for any purpose, this
section outlines the objects within the scope of this document which section outlines the objects within the scope of this document which
may be extended into the TPM. may be extended into the TPM.
In general, PCRs are organized to independently attest three classes In general, PCRs are organized to independently attest three classes
of object: of object:
o Code, i.e., instructions to be executed by a CPU. o Code, i.e., instructions to be executed by a CPU.
o Configuration - Many devices offer numerous options controlled by o Configuration - Many devices offer numerous options controlled by
non-volatile configuration variables which can impact the device's non-volatile configuration variables which can impact the device's
security posture. These settings may have vendor defaults, but security posture. These settings may have vendor defaults, but
often can be changed by administrators, who may want to verify via often can be changed by administrators, who may want to verify via
attestation that the settings they intend are still in place. attestation that the settings they intend are still in place.
o Credentials - Administrators may wish to verify via attestation o Credentials - Administrators may wish to verify via attestation
that keys (and other credentials) outside the Root of Trust have that keys (and other credentials) outside the Root of Trust have
not be subject to unauthorized tampering. (By definition, keys not been subject to unauthorized tampering. (By definition, keys
inside the root of trust can't be verified independently) inside the root of trust can't be verified independently)
The TCG PC Client Platform Firmware Profile Specification The TCG PC Client Platform Firmware Profile Specification
[PC-Client-BIOS-TPM-2.0] gives considerable detail on what is to be [PC-Client-BIOS-TPM-2.0] gives considerable detail on what is to be
measured during the boot phase of a platform boot using a UEFI BOIS measured during the boot phase of a platform boot using a UEFI BOIS
(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. Table XX configuration information related to security posture, leaving no gap
summarizes the functions that are measured, and how this document for unmeasured code to subvert the chain.
recommends they be allocated to PCRs. It's important to note that
each PCR may contain results from dozens (or even thousands) of For platforms using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] gives
individual measurements. detailed normative requirements for PCR usage. But for other
platform architectures, the table in Figure 2 gives guidance for PCR
assignment that generalizes the specific details of
[PC-Client-BIOS-TPM-2.0].
By convention, most PCRs are allocated in pairs, which the even-
numbered PCR used to measure executable code, and the odd-numbered
PCR used to measure whatever data and configuration are associated
with that code. It is important to note that each PCR may contain
results from dozens (or even thousands) of individual measurements.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| | Allocated PCR # | | | Allocated PCR # |
| Function | Code | Configuration| | Function | Code | Configuration|
-------------------------------------------------------------------- --------------------------------------------------------------------
| BIOS Static Root of Trust, plus embedded | 0 | 1 | | Firmware Static Root of Trust, i.e., | 0 | 1 |
| Option ROMs and drivers | | | | initial boot firmware and drivers | | |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Pluggable Option ROMs to initialize and | 2 | 3 | | Drivers and initialization for optional | 2 | 3 |
| configure add-in devices | | | | or add-in devices | | |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Boot Manager code and configuration (UEFI | 4 | 5 | | OS Loader code and configuration, i.e., | 4 | 5 |
| uses a separate module to implement | | | | the code launched by firmware to load an | | |
| policies for selecting among a variety of | | | | operating system kernel. These PCRs record | | |
| potential boot devices). This PCR records | | | | each boot attempt, and an identifier for | | |
| boot attempts, and identifies what | | | | where the loader was found | | |
| resources were used to boot the OS. | | |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Vendor Specific Measurements during boot | 6 | 6 | | Vendor Specific Measurements during boot | 6 | 6 |
-------------------------------------------------------------------- --------------------------------------------------------------------
| 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 | | |
-------------------------------------------------------------------- --------------------------------------------------------------------
| OS Loader (e.g GRUB2 for Linux) | 8 | 9 | | Measurements made by the OS Loader | 8 | 9 |
| (e.g GRUB2 for Linux) | | |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Reserved for 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
Notes on PCR Allocations
It is important to recognize that PCR[0] is critical. The first
measurement into PCR[0] taken by the Root of Trust for Measurement,
is critical to establishing the chain of trust for all subsequent
measurements. If the PCR[0] measurement cannot be trusted, the
validity of the entire chain is put into question.
Distinctions Between PCR[0], PCR[2], PCR[4] and PCR[8]
o PCR[0] typically represents a consistent view of the Host Platform
between boot cycles, allowing Attestation and Sealed Storage
policies to be defined using the less changeable components of the
transitive trust chain. This PCR typically provides a consistent
view of the platform regardless of user selected options.
o PCR[2] is intended to represent a "user configurable" environment
where the user has the ability to alter the components that are
measured into PCR[2]. This is typically done by adding adapter
cards, etc., into user-accessible PCI or other slots. In UEFI
systems these devices may be configured by Option ROMsm easured
into PCR[2] and executed by the BIOS.
o PCR[4] is intended to represent the software that manages the
transition between the platform's Pre-Operating System Start and
the state of a system with the Operating System present. This
PCR, along with PCR[5], identifies the initial operating system
loader (e.g. GRUB for Linux)
o PCR[8] is used by the OS loader to record measurements of the
various components of the operating system.
Although the TCG PC Client document specifies the use of the first
eight PCRs very carefully to ensure interoperability among multiple
UEFI BIOS vendors, it should be noted that embedded software vendors
may have considerably more flexibility. Verifiers typically need to
know which log entries are consequential and which are not (possibly
controlled by local policies) but the verifier may not need to know
what each log entry means or why it was assigned to a particular PCR.
Designers must recognize that some PCRs may cover log entries that a
particular verifier considers critical and other log entries that are
not considered important, so differing PCR values may not on their
own constitute a check for authenticity.
Designers may allocate particular events to specific PCRs in order to
achieve a particular objective with Local Attestation, i.e., allowing
a procedure to execute only if a given PCR is in a given state. It
may also be important to designers to consider whether streaming
notification of PCR updates is required (see ID Rats Streaming).
Specific log entries can only be validated if the verifier receives
every log entry affecting the relevant PCR, so (for example) a
designer might want to separate rare, high-value events such as
configuration changes, from high-volume, routine measurements such as
IMA logs.
2.2. RIV Keying 2.2. RIV Keying
RIV attestation relies on two keys: RIV attestation relies on two keys:
o An identity key is required to certify the identity of the o An identity key is required to certify the identity of the
Attester itself. RIV specifies the use of an IEEE 802.1AR DevID Attester itself. RIV specifies the use of an IEEE 802.1AR DevID
[IEEE-802-1AR], signed by the device manufacturer, containing the [IEEE-802-1AR], signed by the device manufacturer, containing the
device serial number. device serial number.
o An Attestation Key is required to sign the Quote generated by the o An Attestation Key is required to sign the Quote generated by the
skipping to change at page 13, line 28 skipping to change at page 14, line 34
| Manufacturer | | attestation)| Step 2 | Station)| | | Manufacturer | | attestation)| Step 2 | Station)| |
| or other | | | | | | | or other | | | | | |
| authority) | | | | | | | authority) | | | | | |
+---------------+ +-------------+ +---------+--------+ +---------------+ +-------------+ +---------+--------+
| /\ | /\
| Step 0 | | Step 0 |
----------------------------------------------- -----------------------------------------------
Figure 3: RIV Reference Configuration for Network Equipment Figure 3: RIV Reference Configuration for Network Equipment
In Step 0, The Asserter (the device manufacturer) provides a Software In Step 0, The Endorser (the device manufacturer) provides a Software
Image accompanied by one or more Reference Integrity Manifests (RIMs) Image to the Attester (the device under attestation), and makes one
to the Attester (the device under attestation) signed by the or more Reference Integrity Manifests (RIMs) signed by the Endorser,
asserter. In Step 1, the Verifier (Network Management Station), on available to the Verifier (see Section 3.1.3 for "in-band" and "out
behalf of a Relying Party, requests Identity, Measurement Values (and of band" ways to make this happen). In Step 1, the Verifier (Network
possibly RIMs) from the Attester. In Step 2, the Attester responds Management Station), on behalf of a Relying Party, requests Identity,
to the request by providing a DevID, quotes (measured values), and Measurement Values (and possibly RIMs) from the Attester. In Step 2,
optionally RIMs, signed by the Attester. the Attester responds to the request by providing a DevID, quotes
(measured values), and optionally RIMs, signed by the Attester.
The following standards components may be used: The following standards components may be used:
1. TPM Keys are configured according to [Platform-DevID-TPM-2.0], 1. TPM Keys are configured according to [Platform-DevID-TPM-2.0],
[PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2] [PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2]
2. Measurements of firmware and bootable modules may be taken 2. Measurements of firmware and bootable modules may be taken
according to TCG PC Client [PC-Client-BIOS-TPM-2.0] and Linux IMA according to TCG PC Client [PC-Client-BIOS-TPM-2.0] and Linux IMA
[IMA] [IMA]
3. Device Identity is managed by IEEE 802.1AR certificates 3. Device Identity is managed by IEEE 802.1AR certificates
[IEEE-802-1AR], with keys protected by TPMs. [IEEE-802-1AR], with keys protected by TPMs.
4. Attestation logs may be formatted according to the Canonical 4. Attestation logs may be formatted according to the Canonical
Event Log format [Canonical-Event-Log], although other Event Log format [Canonical-Event-Log], although other
specialized formats may be used. specialized formats may be used.
5. Quotes are retrieved from the TPM according to TCG TAP 5. Quotes are retrieved from the TPM according to the TCG TAP
Information Model [TAP]. While the TAP IM gives a protocol- Information Model [TAP]. While the TAP IM gives a protocol-
independent description of the data elements involved, it's independent description of the data elements involved, it's
important to note that quotes from the TPM are signed inside the important to note that quotes from the TPM are signed inside the
TPM, so must be retrieved in a way that does not invalidate the TPM, so must be retrieved in a way that does not invalidate the
signature, as specified in [I-D.ietf-rats-yang-tpm-charra], to signature, as specified in [I-D.ietf-rats-yang-tpm-charra], to
preserve the trust model. (See Section 5 Security preserve the trust model. (See Section 5 Security
Considerations). Considerations).
6. Reference Integrity Measurements may be encoded as CoSWID tags, 6. Reference Integrity Measurements may be encoded as CoSWID tags,
as defined in the TCG RIM document [RIM], compatible with NIST IR as defined in the TCG RIM document [RIM], compatible with NIST IR
skipping to change at page 15, line 50 skipping to change at page 17, line 6
In both cases, the expected values can be expressed as signed SWID or In both cases, the expected values can be expressed as signed SWID or
CoSWID tags, but the SWID structure in the second case is somewhat CoSWID tags, but the SWID structure in the second case is somewhat
more complex, as reconstruction of the extended hash in a PCR may more complex, as reconstruction of the extended hash in a PCR may
involve thousands of files and other objects. involve thousands of files and other objects.
The TCG has published an information model defining elements of The TCG has published an information model defining elements of
reference integrity manifests under the title TCG Reference Integrity reference integrity manifests under the title TCG Reference Integrity
Manifest Information Model [RIM]. This information model outlines Manifest Information Model [RIM]. This information model outlines
how SWID tags should be structured to allow attestation, and defines how SWID tags should be structured to allow attestation, and defines
"bundles" of SWID tags that may be needed to describe a complete "bundles" of SWID tags that may be needed to describe a complete
software release. The RIM contains some metadata relating to the software release. The RIM contains metadata relating to the software
software release it belongs to, plus hashes for each individual file release it belongs to, plus hashes for each individual file or other
or other object that could be attested. object that could be attested.
TCG has also published the PC Client Reference Integrity Measurement TCG has also published the PC Client Reference Integrity Measurement
specification [PC-Client-RIM], which focuses on a SWID-compatible specification [PC-Client-RIM], which focuses on a SWID-compatible
format suitable for expressing expected measurement values in the format suitable for expressing expected measurement values in the
specific case of a UEFI-compatible BIOS, where the SWID focus on specific case of a UEFI-compatible BIOS, where the SWID focus on
files and file systems is not a direct fit. While the PC Client RIM files and file systems is not a direct fit. While the PC Client RIM
is not directly applicable to network equipment, many vendors do use is not directly applicable to network equipment, many vendors do use
a conventional UEFI BIOS to launch their network OS. a conventional UEFI BIOS to launch their network OS.
2.4.2. Attestation Logs 2.4.2. Attestation Logs
skipping to change at page 16, line 35 skipping to change at page 17, line 40
o Event log exports from [I-D.ietf-rats-yang-tpm-charra] o Event log exports from [I-D.ietf-rats-yang-tpm-charra]
o IMA Event log file exports [IMA] o IMA Event log file exports [IMA]
o TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM o TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM
Family 1.1 or 1.2, Section 7 [EFI-TPM]) Family 1.1 or 1.2, Section 7 [EFI-TPM])
o TCG Canonical Event Log [Canonical-Event-Log] o TCG Canonical Event Log [Canonical-Event-Log]
o Legacy BIOS event log, although this document is less relevant as
UEFI has largely replaced the Legacy BIOS (TCG PC Client Specific
Implementation Specification for Conventional BIOS,
Section 11.3[PC-Client-BIOS-TPM-1.2])
3. Standards Components 3. Standards Components
3.1. Prerequisites for RIV 3.1. Prerequisites for RIV
The Reference Interaction Model for Challenge-Response-based Remote The Reference Interaction Model for Challenge-Response-based Remote
Attestation is based on the standard roles defined in Attestation is based on the standard roles defined in
[I-D.ietf-rats-architecture]. However additional prerequisites must [I-D.ietf-rats-architecture]. However additional prerequisites must
be established to allow for interoperable RIV use case be established to allow for interoperable RIV use case
implementations. These prerequisites are intended to provide implementations. These prerequisites are intended to provide
sufficient context information so that the Verifier can acquire and sufficient context information so that the Verifier can acquire and
skipping to change at page 17, line 22 skipping to change at page 18, line 22
The Attestation Identity Key (AIK) and certificate must also be The Attestation Identity Key (AIK) and certificate must also be
provisioned on the Attester according to [Platform-DevID-TPM-2.0], provisioned on the Attester according to [Platform-DevID-TPM-2.0],
[PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2]. [PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2].
The Attester's TPM Keys must be associated with the DevID on the The Attester's TPM Keys must be associated with the DevID on the
Verifier (see Section 5 Security Considerations). Verifier (see Section 5 Security Considerations).
3.1.3. Appraisal Policy for Evidence 3.1.3. Appraisal Policy for Evidence
(Editor's Note - terminology in this section must be brought back
into line with the RATS Architecture definitions)
The Verifier must obtain the Appraisal Policy for Evidence. This The Verifier must obtain the Appraisal Policy for Evidence. This
policy may be in the form of reference measurements (e.g., Known Good policy may be in the form of reference measurements (e.g., Known Good
Values, CoSWID tags [I-D.birkholz-yang-swid]). These reference Values, CoSWID tags [I-D.birkholz-yang-swid]). These reference
measurements will eventually be compared to signed PCR Evidence measurements will eventually be compared to signed PCR Evidence
acquired from an Attester's TPM. acquired from an Attester's TPM.
This document does not specify the format or contents for the This document does not specify the format or contents for the
Appraisal Policy for Evidence. But acquiring this policy may happen Appraisal Policy for Evidence. But acquiring this policy may happen
in one of two ways: in one of two ways:
1. a Verifier obtains reference measurements directly from a 1. a Verifier obtains reference measurements directly from a
Verifier Owner / device configuration authority chosen by the Verifier Owner (i.e., a Device Configuration Authority) chosen by
network administrator. the Verifier administrator.
2. Signed reference measurements may be distributed by the Verifier 2. Signed reference measurements may be distributed by the Verifier
Owner to the Attester. From there, the reference measurement may Owner to the Attester. From there, the reference measurement may
be acquired by the Verifier. be acquired by the Verifier.
************* .-------------. .-----------. ************* .-------------. .-----------.
* Verifier * | Attester | | Verifier/ | * Verifier * | Attester | | Verifier/ |
* Owner * | | | Relying | * Owner * | | | Relying |
*(Device *----2--->| (Network |----2--->| Party | *(Device *----2--->| (Network |----2--->| Party |
* config * | Device) | |(Ntwk Mgmt | * config * | Device) | |(Ntwk Mgmt |
skipping to change at page 18, line 25 skipping to change at page 20, line 5
[I-D.ietf-sacm-coswid]. [I-D.ietf-sacm-coswid].
3.2. Reference Model for Challenge-Response 3.2. Reference Model for Challenge-Response
Once the prerequisites for RIV are met, a Verifier may acquire Once the prerequisites for RIV are met, a Verifier may acquire
Evidence from an Attester. The following diagram illustrates a RIV Evidence from an Attester. The following diagram illustrates a RIV
information flow between a Verifier and an Attester. Event times information flow between a Verifier and an Attester. Event times
shown correspond to the time types described within Appendix A of shown correspond to the time types described within Appendix A of
[I-D.ietf-rats-architecture]: [I-D.ietf-rats-architecture]:
.----------. .--------------------------. .----------. .--------------------------.
| Attester | | Relying Party / Verifier | | Attester | | Relying Party / Verifier |
'----------' '--------------------------' '----------' '--------------------------'
time(vg) | time(VG) |
|<-- requestAttestation(nonce,PcrSelection)-------time(ns) valueGeneration(targetEnvironment) |
| | | => claims |
time(eg) LogEvidence(assertionsSelection) | | |
| SignedPcrEvidence(PCR, nonce) | | <--------------requestEvidence(nonce, PcrSelection)-----time(NS)
| | | |
|-----------LogEvidence,SignedPcrEvidence---------->| time(EG) |
| | evidenceGeneration(nonce, PcrSelection, collectedClaims) |
| verifyAttestationEvidence time(rg,ra) | => SignedPcrEvidence(nonce, PcrSelection) |
| ~ | => LogEvidence(collectedClaims) |
time(rx) | |
| returnSignedPcrEvidence----------------------------------> |
| returnLogEvidence----------------------------------------> |
| |
| time(RG,RA)
| evidenceAppraisal(SignedPcrEvidence, eventLog, refClaims)
| attestationResult <= |
~ ~
| time(RX)
Figure 5: IETF Attestation Information Flow Figure 5: IETF Attestation Information Flow
o time(vg): One or more Attesting Network Device PCRs are extended o time(VG): One or more Attesting Network Device PCRs are extended
with measurements. with measurements.
o time(ns): The Verifier generates a nonce, and makes a request o time(NS): The Verifier generates a unique nonce ("number used
attestation data for one or more PCRs from an Attester. This can once"), and makes a request attestation data for one or more PCRs
be accomplished via a YANG [RFC7950] interface that implements the from an Attester. This can be accomplished via a YANG [RFC7950]
TCG TAP model (e.g. YANG Module for Basic Challenge-Response- interface that implements the TCG TAP model (e.g. YANG Module for
based Remote Attestation Procedures Basic Challenge-Response-based Remote Attestation Procedures
[I-D.ietf-rats-yang-tpm-charra]). [I-D.ietf-rats-yang-tpm-charra]).
o time(eg): On the Attester, measured values are retrieved from the o time(EG): On the Attester, measured values are retrieved from the
Attester's TPM. This requested PCR evidence is signed by the Attester's TPM. This requested PCR evidence is signed by the
Attestation Identity Key (AIK) associated with the DevID. Quotes Attestation Identity Key (AIK) associated with the DevID. Quotes
are retrieved according to TCG TAP Information Model [TAP]. While are retrieved according to TCG TAP Information Model [TAP]. While
the TAP IM gives a protocol-independent description of the data the TAP IM gives a protocol-independent description of the data
elements involved, it's important to note that quotes from the TPM elements involved, it's important to note that quotes from the TPM
are signed inside the TPM, so must be retrieved in a way that does are signed inside the TPM, so must be retrieved in a way that does
not invalidate the signature, as specified in not invalidate the signature, as specified in
[I-D.ietf-rats-yang-tpm-charra], to preserve the trust model. [I-D.ietf-rats-yang-tpm-charra], to preserve the trust model.
(See Section 5 Security Considerations). (See Section 5 Security Considerations). At the same time, the
Attester collects log evidence showing what values have been
* At the same time, for any PCRs where known good values might extended into that PCR.
not be known by the Verifier, the Attester collects log
evidence showing what values have been extended into that PCR.
Attestation logs are formatted according to the Canonical Event
Log format [Canonical-Event-Log].
o Collected Evidence is passed from the Attester to the Verifier o Collected Evidence is passed from the Attester to the Verifier
o time(rg,ra): The Verifier reviews the Evidence and takes action as o time(RG,RA): The Verifier reviews the Evidence and takes action as
needed. As the Relying Party and Verifier are assumed co- needed. As the Relying Party and Verifier are assumed co-
resident, this can happen in one step. resident, this can happen in one step.
* If the signed PCR values do not match either KGVs, or the set * If the signed PCR values do not match the set of log entries
of log entries which have extended a particular PCR, the device which have extended a particular PCR, the device should not be
should not be trusted. trusted.
* If the log entries that the verifier considers important do not
match known good values, the device should not be trusted. We
note that the process of collecting and analyzing the log can
be omitted if the value in the relevant PCR is already a known-
good value.
* If the set of log entries are not seen as acceptable by the * If the set of log entries are not seen as acceptable by the
Appraisal Policy for Evidence, the device should not be Appraisal Policy for Evidence, the device should not be
trusted. trusted.
* If the AIK signature is not correct, or freshness such as that * If the AIK signature is not correct, or freshness such as that
provided by the nonce is not included in the response, the provided by the nonce is not included in the response, the
device should not be trusted. device should not be trusted.
o time(rx): At some point after the verification of Evidence, the o time(RX): At some point after the verification of Evidence, the
Attester can no longer be considered Attested as trustworthy. Attester can no longer be considered Attested as trustworthy.
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: shown in Figure 5, and can be accomplished via:
o XML, JSON, or CBOR encoded Evidence, using o XML, JSON, or CBOR encoded Evidence, using
o RESTCONF or NETCONF transport, over a o RESTCONF or NETCONF transport, over a
skipping to change at page 20, line 25 skipping to change at page 22, line 15
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) so that each device has signed reference measurements (RIMs) so that each device has
everything needed for attestation, without having to resort to a everything needed for attestation, without having to resort to a
central authority. central authority.
+---------------+ +---------------+ +---------------+ +---------------+
| | | | | | | |
| Asserter A | | Asserter B | | Endorser A | | Endorser B |
| Firmware | | Firmware | | Firmware | | Firmware |
| Configuration | | Configuration | | Configuration | | Configuration |
| Authority | | Authority | | Authority | | Authority |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
| | | |
| +-------------+ +------------+ | | +-------------+ +------------+ |
| | | Step 1 | | | \ | | | Step 1 | | | \
| | Attester |<------>| Verifier | | | | | Attester |<------>| Verifier | | |
| | |<------>| | | | Router B | | |<------>| | | | Router B
skipping to change at page 21, line 14 skipping to change at page 23, line 7
In this application, each device may need to be equipped with signed In this application, each device may need to be equipped with signed
RIMs to act as an Attester, and also a selection of trusted x.509 RIMs to act as an Attester, and also a selection of trusted x.509
root certificates to allow the device to act as a Verifier. An root certificates to allow the device to act as a Verifier. An
existing link layer protocol such as 802.1x [IEEE-802.1x] or 802.1AE existing link layer protocol such as 802.1x [IEEE-802.1x] or 802.1AE
[IEEE-802.1ae], with Evidence being enclosed over a variant of EAP [IEEE-802.1ae], with Evidence being enclosed over a variant of EAP
[RFC3748] or LLDP [LLDP] are suitable methods for such an exchange. [RFC3748] or LLDP [LLDP] are suitable methods for such an exchange.
4. Privacy Considerations 4. Privacy Considerations
Networking Equipment such as routers, switches and firewalls has a Networking Equipment, such as routers, switches and firewalls, has a
key role to play in guarding the privacy of individuals using the key role to play in guarding the privacy of individuals using the
network: network:
o Packets passing through the device must not be sent to o Packets passing through the device must not be sent to
unauthorized destinations. For example unauthorized destinations. For example:
o Routers often act as Policy Enforcement Points, where individual * Routers often act as Policy Enforcement Points, where
subscribers may be checked for authorization to access a network. individual subscribers may be checked for authorization to
Subscriber login information must not be released to unauthorized access a network. Subscriber login information must not be
parties. released to unauthorized parties.
o Networking Equipment is often called upon to block access to * Networking Equipment is often called upon to block access to
protected resources from unauthorized users. protected resources from unauthorized users.
o Routing information, such as the identity of a router's peers, o Routing information, such as the identity of a router's peers,
must not be leaked to unauthorized neighbors. must not be leaked to unauthorized neighbors.
o If configured, encryption and decryption of traffic must be o If configured, encryption and decryption of traffic must be
carried out reliably, while protecting keys and credentials. carried out reliably, while protecting keys and credentials.
Functions that protect privacy are implemented as part of each layer Functions that protect privacy are implemented as part of each layer
of hardware and software that makes up the networking device. In of hardware and software that makes up the networking device. In
light of these requirements for protecting the privacy of users of light of these requirements for protecting the privacy of users of
the network, the Network Equipment must identify itself, and its boot the network, the Network Equipment must identify itself, and its boot
configuration and measured device state (for example, PCR values), to configuration and measured device state (for example, PCR values), to
the Equipment's Administrator, so there's no uncertainty as to what the Equipment's Administrator, so there's no uncertainty as to what
function each device and configuration is configured to carry out. function each device and configuration is configured to carry out.
This allows the administrator to ensure that the network provides This allows the administrator to ensure that the network provides
individual and peer privacy guarantees. individual and peer privacy guarantees.
RIV specifically addresses the collection information from enterprise RIV specifically addresses the collection of information from
network devices by an enterprise network. As such, privacy is a enterprise network devices by authorized agents of the enterprise.
fundamental concern for those deploying this solution, given EU GDPR, As such, privacy is a fundamental concern for those deploying this
California CCPA, and many other privacy regulations. The enterprise solution, given EU GDPR, California CCPA, and many other privacy
should implement and enforce their duty of care. regulations. The enterprise should implement and enforce their duty
of care.
See [NetEq] for more context on privacy in networking devices See [NetEq] for more context on privacy in networking devices
5. Security Considerations 5. Security Considerations
Attestation results from the RIV procedure are subject to a number of Attestation results from the RIV procedure are subject to a number of
attacks: attacks:
o Keys may be compromised o Keys may be compromised
o A counterfeit device may attempt to impersonate (spoof) a known o A counterfeit device may attempt to impersonate (spoof) a known
authentic device authentic device
o Man-in-the-middle attacks may be used by a counterfeit device to o Man-in-the-middle attacks may be used by a counterfeit device to
attempt to deliver responses that originate in an actual authentic attempt to deliver responses that originate in an actual authentic
device device
o Replay attacks may be attempted by a compromised device o Replay attacks may be attempted by a compromised device
Trustworthiness of RIV attestation depends strongly on the validity Trustworthiness of RIV attestation depends strongly on the validity
skipping to change at page 23, line 21 skipping to change at page 25, line 15
o The private portion of the DevID key is to be stored in the o The private portion of the DevID key is to be stored in the
device, in a manner that provides confidentiality (Section 6.2.5 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 o The public part of the unique DevID key assigned to that device
o An identifying string that's unique to the manufacturer of the o An identifying string that's unique to the manufacturer of the
device. This is normally the serial number of the unit, which device. This is normally the serial number of the unit, which
might also be printed on label on the device. might also be printed on a label on the device.
o The certificate must be signed by a key traceable to the o The certificate must be signed by a key traceable to the
manufacturer's root key. manufacturer's root key.
With these elements, the device's manufacturer and serial number can With these elements, the device's manufacturer and serial number can
be identified by analyzing the DevID certificate plus the chain of be identified by analyzing the DevID certificate plus the chain of
intermediate certs leading back to the manufacturer's root intermediate certs leading back to the manufacturer's root
certificate. As is conventional in TLS connections, a nonce must be certificate. As is conventional in TLS connections, a nonce must be
signed by the device in response to a challenge, proving possession signed by the device in response to a challenge, proving possession
of its DevID private key. of its DevID private key.
skipping to change at page 24, line 21 skipping to change at page 26, line 15
that the Verifier's TLS session is in fact terminating on the that the Verifier's TLS session is in fact terminating on the
right device. right device.
o A compromised device could respond with a spoofed attestation o A compromised device could respond with a spoofed attestation
result, that is, a compromised OS could return a fabricated quote. result, that is, a compromised OS could return a fabricated quote.
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 spoofed could be used to sign a fabricated quote. To block spoofed
attestation result, the quote generated inside the TPM must by signed attestation result, the quote generated inside the TPM must be signed
by a key that's different from the DevID, called an Attestation Key by a key that's different from the DevID, called an Attestation Key
(AK). (AK).
Given separate Attestation and DevID keys, the binding between the AK Given separate Attestation and DevID keys, the binding between the AK
and the same device must also be proven to prevent a man-in-the- and the same device must also be proven to prevent a man-in-the-
middle attack (e.g. the 'Asokan Attack' [RFC6813]). middle attack (e.g. the 'Asokan Attack' [RFC6813]).
This is accomplished in RIV through use of an AK certificate with the This is accomplished in RIV through use of an AK certificate with the
same elements as the DevID (i.e., same manufacturer's serial number, same elements as the DevID (i.e., same manufacturer's serial number,
signed by the same manufacturer's key), but containing the device's signed by the same manufacturer's key), but containing the device's
unique AK public key instead of the DevID public key. [this will unique AK public key instead of the DevID public key.
require an OID that says the key is known by the CA to be an [Editor's Note: does this require an OID that says the key is known
Attestation key] by the CA to be an Attestation key?]
These two keys and certificates are used together: These two keys and certificates are used together:
o The DevID is used to validate a TLS connection terminating on the o The DevID is used to validate a TLS connection terminating on the
device with a known serial number. device with a known serial number.
o The AK is used to sign attestation quotes, providing proof that o The AK is used to sign attestation quotes, providing proof that
the attestation evidence comes from the same device. the attestation evidence comes from the same device.
Replay attacks, where results of a previous attestation are submitted Replay attacks, where results of a previous attestation are submitted
skipping to change at page 25, line 30 skipping to change at page 27, line 23
extends that concept by defining an Initial Attestation Key (IAK) and extends that concept by defining an Initial Attestation Key (IAK) and
Local Attestation Key (LAK) with the same properties. Local Attestation Key (LAK) with the same 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 o TCG document [Platform-DevID-TPM-2.0] shows how the initial
Attestation keys can be used to certify LDevID and LAK keys. Use Attestation keys can be used to certify LDevID and LAK keys. Use
of the LDevID and LAK allows the device owner to use a uniform of the LDevID and LAK allows the device owner to use a uniform
identity structure across device types from multiple manufacturers identity structure across device types from multiple manufacturers
(in the same way that an "Asset Tag" is used by many enterprises (in the same way that an "Asset Tag" is used by many enterprises
use to identify devices they own). TCG doc [Provisioning-TPM-2.0] to identify devices they own). TCG doc [Provisioning-TPM-2.0]
also contains guidance on provisioning identity keys in TPM 2.0. also contains guidance on provisioning identity keys in TPM 2.0.
o But device owners can use any other mechanism they want to assure o But device owners can use any other mechanism they want to assure
themselves that Local identity certificates are inserted into the themselves that Local identity certificates are inserted into the
intended device, including physical inspection and programming in intended device, including physical inspection and programming in
a secure location, if they prefer to avoid placing trust in the a secure location, if they prefer to avoid placing trust in the
manufacturer-provided keys. 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
skipping to change at page 29, line 18 skipping to change at page 31, line 18
transitioning to YANG, so in some cases, both will be required. TLS transitioning to YANG, so in some cases, both will be required. TLS
Authentication with TPM has been shown to work; SSH authentication Authentication with TPM has been shown to work; SSH authentication
using TPM-protected keys is not as easily done [as of 2019] using TPM-protected keys is not as easily done [as of 2019]
8.1.1. Why is OS Attestation Different? 8.1.1. Why is OS Attestation Different?
Even in embedded systems, adding Attestation at the OS level (e.g. Even in embedded systems, adding Attestation at the OS level (e.g.
Linux IMA, Integrity Measurement Architecture [IMA]) increases the Linux IMA, Integrity Measurement Architecture [IMA]) increases the
number of objects to be attested by one or two orders of magnitude, number of objects to be attested by one or two orders of magnitude,
involves software that's updated and changed frequently, and involves software that's updated and changed frequently, and
introduces processes that begin in unpredictable order. introduces processes that begin in an unpredictable order.
TCG and others (including the Linux community) are working on methods TCG and others (including the Linux community) are working on methods
and procedures for attesting the operating system and application and procedures for attesting the operating system and application
software, but standardization is still in process. software, but standardization is still in process.
8.2. Implementation Notes 8.2. Implementation Notes
Table 1 summarizes many of the actions needed to complete an Table 1 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 29, line 40 skipping to change at page 31, line 40
responsibility of the manufacturer of the device, unless otherwise responsibility of the manufacturer of the device, unless otherwise
noted. noted.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| Component | Controlling | | Component | Controlling |
| | Specification | | | Specification |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Make a Secure execution environment | TCG RoT | | Make a Secure execution environment | TCG RoT |
| o Attestation depends on a secure root of | UEFI.org | | o Attestation depends on a secure root of | UEFI.org |
| trust for measurement outside the TPM, as | | | trust for measurement outside the TPM, as | |
| well as roots for storage amd reporting | | | well as roots for storage and reporting | |
| inside the TPM. | | | inside the TPM. | |
| o Refer to TCG Root of Trust for Measurement.| | | o Refer to TCG Root of Trust for Measurement.| |
| o NIST SP 800-193 also provides guidelines | | | o NIST SP 800-193 also provides guidelines | |
| on Roots of Trust | | | on Roots of Trust | |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Provision the TPM as described in | TCG TPM DevID | | Provision the TPM as described in | TCG TPM DevID |
| TCG documents. | TCG Platform | | TCG documents. | TCG Platform |
| | Certificate | | | Certificate |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Put a DevID or Platform Cert in the TPM | TCG TPM DevID | | Put a DevID or Platform Cert in the TPM | TCG TPM DevID |
skipping to change at page 31, line 20 skipping to change at page 33, line 20
-------------------------------------------------------------------- --------------------------------------------------------------------
Figure 8: Component Status Figure 8: Component Status
8.3. Root of Trust for Measurement 8.3. 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, i.e., some attested is equipped with a Root of Trust for Measurement, i.e., some
trustworthy mechanism that can compute the first measurement in the trustworthy mechanism that can compute the first measurement in the
chain of trust required to attest that each stage of system startup chain of trust required to attest that each stage of system startup
is verified, and a Root of Trust for Reporting to report the results is verified, a Root of Trust for Storage (i.e., the TPM PCRs) to
[TCGRoT], [GloPlaRoT]. record the results, and a Root of Trust for Reporting to report the
results [TCGRoT], [GloPlaRoT].
While there are many complex aspects of a Root of Trust, two aspects While there are many complex aspects of a Root of Trust, two aspects
that are important in the case of attestation are: that are important in the case of attestation are:
o The first measurement computed by the Root of Trust for o The first measurement computed by the Root of Trust for
Measurement, and stored in the TPM's Root of Trust for Storage, is Measurement, and stored in the TPM's Root of Trust for Storage, is
presumed to be correct. presumed to be correct.
o There must not be a way to reset the RTS without re-entering the o There must not be a way to reset the Root of Trust for Storage
RTM code. without re-entering the Root of Trust for Measurement code.
The first measurement must be computed by code that is implicitly The first measurement must be computed by code that is implicitly
trusted; if that first measurement can be subverted, none of the trusted; if that first measurement can be subverted, none of the
remaining measurements can be trusted. (See [NIST-SP-800-155]) remaining measurements can be trusted. (See [NIST-SP-800-155])
9. Informative References 9. Informative References
[AIK-Enrollment] [AIK-Enrollment]
Trusted Computing Group, "TCG Infrastructure Working Trusted Computing Group, "TCG Infrastructure Working
GroupA CMC Profile for AIK Certificate Enrollment Version GroupA CMC Profile for AIK Certificate Enrollment Version
skipping to change at page 32, line 17 skipping to change at page 34, line 17
Revision 15", January 2014, Revision 15", January 2014,
<https://trustedcomputinggroup.org/wp-content/uploads/EFI- <https://trustedcomputinggroup.org/wp-content/uploads/EFI-
Protocol-Specification-rev13-160330final.pdf>. Protocol-Specification-rev13-160330final.pdf>.
[GloPlaRoT] [GloPlaRoT]
GlobalPlatform Technology, "Root of Trust Definitions and GlobalPlatform Technology, "Root of Trust Definitions and
Requirements Version 1.1", June 2018, Requirements Version 1.1", June 2018,
<https://globalplatform.org/specs-library/globalplatform- <https://globalplatform.org/specs-library/globalplatform-
root-of-trust-definitions-and-requirements/>. root-of-trust-definitions-and-requirements/>.
[I-D.birkholz-rats-reference-interaction-model]
Birkholz, H., Eckel, M., Newton, C., and L. Chen,
"Reference Interaction Models for Remote Attestation
Procedures", draft-birkholz-rats-reference-interaction-
model-03 (work in progress), July 2020.
[I-D.birkholz-rats-tuda] [I-D.birkholz-rats-tuda]
Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
"Time-Based Uni-Directional Attestation", draft-birkholz- "Time-Based Uni-Directional Attestation", draft-birkholz-
rats-tuda-02 (work in progress), March 2020. rats-tuda-02 (work in progress), March 2020.
[I-D.birkholz-yang-swid] [I-D.birkholz-yang-swid]
Birkholz, H., "Software Inventory YANG module based on Birkholz, H., "Software Inventory YANG module based on
Software Identifiers", draft-birkholz-yang-swid-02 (work Software Identifiers", draft-birkholz-yang-swid-02 (work
in progress), October 2018. in progress), October 2018.
[I-D.ietf-rats-architecture] [I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", W. Pan, "Remote Attestation Procedures Architecture",
draft-ietf-rats-architecture-04 (work in progress), May draft-ietf-rats-architecture-05 (work in progress), July
2020. 2020.
[I-D.ietf-rats-eat] [I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Ballesteros, M., and J. Mandyam, G., Lundblade, L., Ballesteros, M., and J.
O'Donoghue, "The Entity Attestation Token (EAT)", draft- O'Donoghue, "The Entity Attestation Token (EAT)", draft-
ietf-rats-eat-03 (work in progress), February 2020. ietf-rats-eat-03 (work in progress), February 2020.
[I-D.ietf-rats-yang-tpm-charra] [I-D.ietf-rats-yang-tpm-charra]
Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit, Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit,
E., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data E., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data
Model for Challenge-Response-based Remote Attestation Model for Challenge-Response-based Remote Attestation
Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-01 Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-02
(work in progress), March 2020. (work in progress), June 2020.
[I-D.ietf-sacm-coswid] [I-D.ietf-sacm-coswid]
Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
Waltermire, "Concise Software Identification Tags", draft- Waltermire, "Concise Software Identification Tags", draft-
ietf-sacm-coswid-15 (work in progress), May 2020. ietf-sacm-coswid-15 (work in progress), May 2020.
[I-D.richardson-rats-usecases] [I-D.richardson-rats-usecases]
Richardson, M., Wallace, C., and W. Pan, "Use cases for Richardson, M., Wallace, C., and W. Pan, "Use cases for
Remote Attestation common encodings", draft-richardson- Remote Attestation common encodings", draft-richardson-
rats-usecases-07 (work in progress), March 2020. rats-usecases-07 (work in progress), March 2020.
[I-D.voit-rats-trusted-path-routing] [I-D.voit-rats-trusted-path-routing]
Voit, E., "Trusted Path Routing using Remote Attestation", Voit, E., "Trusted Path Routing", draft-voit-rats-trusted-
draft-voit-rats-trusted-path-routing-01 (work in path-routing-02 (work in progress), June 2020.
progress), March 2020.
[IEEE-802-1AR] [IEEE-802-1AR]
Seaman, M., "802.1AR-2018 - IEEE Standard for Local and Seaman, M., "802.1AR-2018 - IEEE Standard for Local and
Metropolitan Area Networks - Secure Device Identity, IEEE Metropolitan Area Networks - Secure Device Identity, IEEE
Computer Society", August 2018. Computer Society", August 2018.
[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/>.
 End of changes. 67 change blocks. 
165 lines changed or deleted 255 lines changed or added

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