draft-ietf-rats-tpm-based-network-device-attest-08.txt   draft-ietf-rats-tpm-based-network-device-attest-09.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: 27 January 2022 Cisco Systems, Inc. Expires: 22 May 2022 Cisco
J. Fitzgerald-McKay J. Fitzgerald-McKay
National Security Agency National Security Agency
26 July 2021 18 November 2021
TPM-based Network Device Remote Integrity Verification TPM-based Network Device Remote Integrity Verification
draft-ietf-rats-tpm-based-network-device-attest-08 draft-ietf-rats-tpm-based-network-device-attest-09
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 27 January 2022. This Internet-Draft will expire on 22 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 9 1.7.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 9
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 10
2.1. RIV Software Configuration Attestation using TPM . . . . 9 2.1. RIV Software Configuration Attestation using TPM . . . . 10
2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 11 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 11
2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 13 2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 13
2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 14 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 15
2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 15 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 16
2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 17 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 18
2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 18 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 18
2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 19 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 20
3. Standards Components . . . . . . . . . . . . . . . . . . . . 20 3. Standards Components . . . . . . . . . . . . . . . . . . . . 20
3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 20 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 20
3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 20 3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 20
3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 21 3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 21
3.2. Reference Model for Challenge-Response . . . . . . . . . 22 3.2. Reference Model for Challenge-Response . . . . . . . . . 21
3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 23 3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 23
3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 27 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 26
5.2. Prevention of Spoofing and Man-in-the-Middle Attacks . . 29 5.2. Prevention of Spoofing and Person-in-the-Middle
5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 30 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 30 5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29
5.5. Other Factors for Trustworthy Operation . . . . . . . . . 31 5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 29
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.5. Other Factors for Trustworthy Operation . . . . . . . . . 30
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 33 9.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 32
9.2. Root of Trust for Measurement . . . . . . . . . . . . . . 34 9.2. Root of Trust for Measurement . . . . . . . . . . . . . . 34
9.3. Layering Model for Network Equipment Attester and 9.3. Layering Model for Network Equipment Attester and
Verifier . . . . . . . . . . . . . . . . . . . . . . . . 35 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 34
9.4. Implementation Notes . . . . . . . . . . . . . . . . . . 37 9.4. Implementation Notes . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . 38 10.1. Normative References . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . 41 10.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
There are many aspects to consider in fielding a trusted computing There are many aspects to consider in fielding a trusted computing
device, from operating systems to applications. Mechanisms to prove device, from operating systems to applications. Mechanisms to prove
that a device installed at a customer's site is authentic (i.e., not that a device installed at a customer's site is authentic (i.e., not
counterfeit) and has been configured with authorized software, all as counterfeit) and has been configured with authorized software, all as
part of a trusted supply chain, are just a few of the many aspects part of a trusted supply chain, are just a few of the many aspects
which need to be considered concurrently to have confidence that a which need to be considered concurrently to have confidence that a
device is truly trustworthy. device is truly trustworthy.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
Verifier Owner. Verifier Owner.
Additionally, this document defines the following term: Additionally, this document defines the following term:
Attestation: the process of generating, conveying and appraising Attestation: the process of generating, conveying and appraising
claims, backed by evidence, about device trustworthiness claims, backed by evidence, about device trustworthiness
characteristics, including supply chain trust, identity, device characteristics, including supply chain trust, identity, device
provenance, software configuration, device composition, compliance to provenance, software configuration, device composition, compliance to
test suites, functional and assurance evaluations, etc. 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 or
device configuration and software that was launched when the device auditor that the device configuration and software that was launched
was last started is authentic and untampered-with. when the device was last started is authentic and untampered-with.
The determination of software authenticity is not prescribed in this
document, but it's typically taken to mean a software image generated
by an authority trusted by the administrator, such as the device
manufacturer.
Within the Trusted Computing Group (TCG) context, attestation is the Within the Trusted Computing Group (TCG) context, the scope of
process by which an independent Verifier can obtain cryptographic attestation is typically narrowed to describe the process by which an
proof as to the identity of the device in question, and evidence of independent Verifier can obtain cryptographic proof as to the
the integrity of software loaded on that device when it started up, identity of the device in question, and evidence of the integrity of
and then verify that what's there matches the intended configuration. software loaded on that device when it started up, and then verify
For network equipment, a Verifier capability can be embedded in a that what's there matches the intended configuration. For network
Network Management Station (NMS), a posture collection server, or equipment, a Verifier capability can be embedded in a Network
other network analytics tool (such as a software asset management Management Station (NMS), a posture collection server, or other
solution, or a threat detection and mitigation tool, etc.). While network analytics tool (such as a software asset management solution,
informally referred to as attestation, this document focuses on a or a threat detection and mitigation tool, etc.). While informally
subset defined here as Remote Integrity Verification (RIV). RIV referred to as attestation, this document focuses on a specific
takes a network equipment centric perspective that includes a set of subset of attestation tasks, defined here as Remote Integrity
protocols and procedures for determining whether a particular device Verification (RIV). RIV takes a network equipment centric
was launched with authentic software, starting from Roots of Trust. perspective that includes a set of protocols and procedures for
While there are many ways to accomplish attestation, RIV sets out a determining whether a particular device was launched with authentic
specific set of protocols and tools that work in environments software, starting from Roots of Trust. While there are many ways to
commonly found in network equipment. RIV does not cover other device accomplish attestation, RIV sets out a specific set of protocols and
characteristics that could be attested (e.g., geographic location, tools that work in environments commonly found in network equipment.
connectivity; see [I-D.richardson-rats-usecases]), although it does RIV does not cover other device characteristics that could be
provide evidence of a secure infrastructure to increase the level of attested (e.g., geographic location, connectivity; see
trust in other device characteristics attested by other means (e.g., [I-D.richardson-rats-usecases]), although it does provide evidence of
by Entity Attestation Tokens [I-D.ietf-rats-eat]). a secure infrastructure to increase the level of trust in other
device characteristics attested by other means (e.g., by Entity
Attestation Tokens [I-D.ietf-rats-eat]).
In line with [I-D.ietf-rats-architecture] definitions, this document In line with [I-D.ietf-rats-architecture] definitions, this document
uses the term Endorser to refer to the role that signs identity and uses the term Endorser to refer to the role that signs identity and
attestation certificates used by the Attester, while Reference Values attestation certificates used by the Attester, while Reference Values
are signed by a Reference Value Provider. Typically, the are signed by a Reference Value Provider. Typically, the
manufacturer of an embedded device would be accepted as both the manufacturer of an network device would be accepted as both the
Endorser and Reference Value Provider, although the choice is Endorser and Reference Value Provider, although the choice is
ultimately up to the Verifier Owner. ultimately up to the Verifier Owner.
1.3. Document Organization 1.3. Document Organization
The remainder of this document is organized into several sections: The remainder of this document is organized into several sections:
* The remainder of this section covers goals and requirements, plus * The remainder of this section covers goals and requirements, plus
a top-level description of RIV. a top-level description of RIV.
skipping to change at page 5, line 47 skipping to change at page 5, line 47
integrity, attestation can be used to assist in asset management, integrity, attestation can be used to assist in asset management,
vulnerability and compliance assessment, plus configuration vulnerability and compliance assessment, plus configuration
management. management.
The RIV attestation workflow outlined in this document is intended to The RIV attestation workflow outlined in this document is intended to
meet the following high-level goals: meet the following high-level goals:
* Provable Device Identity - This specification requires that an * Provable Device Identity - This specification requires that an
Attester (i.e., the attesting device) includes a cryptographic Attester (i.e., the attesting device) includes a cryptographic
identifier unique to each device. Effectively this means that the identifier unique to each device. Effectively this means that the
TPM must be so provisioned during the manufacturing cycle. device's TPM must be so provisioned during the manufacturing
cycle.
* Software Inventory - A key goal is to identify the software * Software Inventory - A key goal is to identify the software
release(s) installed on the Attester, and to provide evidence that release(s) installed on the Attester, and to provide evidence that
the software stored within hasn't been altered without the software stored within hasn't been altered without
authorization. authorization.
* Verifiability - Verification of software and configuration of the * Verifiability - Verification of software and configuration of the
device shows that the software that was authorized for device shows that the software that the administrator authorized
installation by the administrator has actually been launched. for use was actually launched.
In addition, RIV is designed to operate either in a centralized In addition, RIV is designed to operate either in a centralized
environment, such as with a central authority that manages and environment, such as with a central authority that manages and
configures a number of network devices, or 'peer-to-peer', where configures a number of network devices, or 'peer-to-peer', where
network devices independently verify one another to establish a trust network devices independently verify one another to establish a trust
relationship. (See Section 3.3 below) relationship. (See Section 3.3 below)
1.5. Description of Remote Integrity Verification (RIV) 1.5. Description of Remote Integrity Verification (RIV)
Attestation requires two interlocking mechanisms between the Attester Attestation requires two interlocking mechanisms between the Attester
skipping to change at page 6, line 29 skipping to change at page 6, line 34
* Device Identity, the mechanism providing trusted identity, can * Device Identity, the mechanism providing trusted identity, can
reassure network managers that the specific devices they ordered reassure network managers that the specific devices they ordered
from authorized manufacturers for attachment to their network are from authorized manufacturers for attachment to their network are
those that were installed, and that they continue to be present in those that were installed, and that they continue to be present in
their network. As part of the mechanism for Device Identity, their network. As part of the mechanism for Device Identity,
cryptographic proof of the identity of the manufacturer is also cryptographic proof of the identity of the manufacturer is also
provided. provided.
* Software Measurement is the mechanism that reports the state of * Software Measurement is the mechanism that reports the state of
mutable software components on the device, and can assure network mutable software components on the device, and can assure
managers that they have known, authentic software configured to administrators that they have known, authentic software configured
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 recording a chain Software used to boot a device can be described as a chain of
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, that Measurement (see Section 9.2), each measuring the next stage and
normally ends when the system software is loaded. A measurement recording the result in tamper-resistant storage, normally ending
signifies the identity, integrity and version of each software when the system software is fully loaded. A measurement signifies
component registered with an Attester's TPM [TPM1.2], [TPM2.0], so the identity, integrity and version of each software component
that a subsequent verification stage can determine if the software registered with an Attester's TPM [TPM1.2], [TPM2.0], so that a
installed is authentic, up-to-date, and free of tampering. subsequent verification stage can determine if the software installed
is authentic, up-to-date, and free of tampering.
RIV includes several major processes: RIV includes several major processes, split between the Attester and
Verifier:
1. Generation of Evidence is the process whereby an Attester 1. Generation of Evidence is the process whereby an Attester
generates cryptographic proof (Evidence) of claims about device generates cryptographic proof (Evidence) of claims about device
properties. In particular, the device identity and its software properties. In particular, the device identity and its software
configuration are both of critical importance. configuration are both of critical importance.
2. Device Identification refers to the mechanism assuring the 2. Device Identification refers to the mechanism assuring the
Relying Party (ultimately, a network administrator) of the Relying Party (ultimately, a network administrator) of the
identity of devices that make up their network, and that their identity of devices that make up their network, and that their
manufacturers are known. manufacturers are known.
skipping to change at page 7, line 35 skipping to change at page 7, line 48
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.
All implementations supporting this RIV specification require the All implementations supporting this RIV specification require the
support of the following three technologies: support of the following three technologies:
1. Identity: Device identity MUST be based on IEEE 802.1AR Device 1. Identity: Device identity in RIV is based on IEEE 802.1AR Device
Identity (DevID) [IEEE-802-1AR], coupled with careful supply- Identity (DevID) [IEEE-802-1AR], coupled with careful supply-
chain management by the manufacturer. The Initial DevID (IDevID) chain management by the manufacturer. The Initial DevID (IDevID)
certificate contains a statement by the manufacturer that certificate contains a statement by the manufacturer that
establishes the identity of the device as it left the factory. establishes the identity of the device as it left the factory.
Some applications with a more-complex post-manufacture supply Some applications with a more-complex post-manufacture supply
chain (e.g., Value Added Resellers), or with different privacy chain (e.g., Value Added Resellers), or with different privacy
concerns, may want to use alternative mechanisms for platform concerns, may want to use alternative mechanisms for platform
authentication (for example, TCG Platform Certificates authentication (for example, TCG Platform Certificates
[Platform-Certificates], or post-manufacture installation of [Platform-Certificates], or post-manufacture installation of
Local Device ID (LDevID)). Local Device ID (LDevID)).
2. Platform Attestation provides evidence of configuration of 2. Platform Attestation provides evidence of configuration of
software elements present in the device. This form of software elements present in the device. This form of
attestation can be implemented with TPM Platform Configuration attestation can be implemented with TPM Platform Configuration
skipping to change at page 8, line 6 skipping to change at page 8, line 20
Local Device ID (LDevID)). Local Device ID (LDevID)).
2. Platform Attestation provides evidence of configuration of 2. Platform Attestation provides evidence of configuration of
software elements present in the device. This form of software elements present in the device. This form of
attestation can be implemented with TPM Platform Configuration attestation can be implemented with TPM Platform Configuration
Registers (PCRs), Quote and Log mechanisms, which provide Registers (PCRs), Quote and Log mechanisms, which provide
cryptographically authenticated evidence to report what software cryptographically authenticated evidence to report what software
was started on the device through the boot cycle. Successful was started on the device through the boot cycle. Successful
attestation requires an unbroken chain from a boot-time root of attestation requires an unbroken chain from a boot-time root of
trust through all layers of software needed to bring the device trust through all layers of software needed to bring the device
to an operational state, in which each stage measures components to an operational state, in which each stage computes the hash of
of the next stage, updates the attestation log, and extends components of the next stage, then updates the attestation log
hashes into a PCR. The TPM can then report the hashes of all the and the TPM. The TPM can then report the hashes of all the
measured hashes as signed evidence called a Quote (see measured hashes as signed evidence called a Quote (see
Section 9.1 for an overview of TPM operation, or [TPM1.2] and Section 9.1 for an overview of TPM operation, or [TPM1.2] and
[TPM2.0] for many more details). [TPM2.0] for many more details).
3. Signed Reference Values (aka Reference Integrity Measurements) 3. Signed Reference Values (aka Reference Integrity Measurements)
must be conveyed from the Reference Value Provider (the entity must be conveyed from the Reference Value Provider (the entity
accepted as the software authority, often the manufacturer for accepted as the software authority, often the manufacturer of the
embedded systems) to the Verifier. network device) to the Verifier.
1.6. Solution Requirements 1.6. Solution Requirements
Remote Integrity Verification must address the "Lying Endpoint" Remote Integrity Verification must address the "Lying Endpoint"
problem, in which malicious software on an endpoint may subvert the problem, in which malicious software on an endpoint may subvert the
intended function, and also prevent the endpoint from reporting its intended function, and also prevent the endpoint from reporting its
compromised status. (See Section 5 for further Security compromised status. (See Section 5 for further Security
Considerations.) Considerations.)
RIV attestation is designed to be simple to deploy at scale. RIV RIV attestation is designed to be simple to deploy at scale. RIV
skipping to change at page 9, line 11 skipping to change at page 9, line 28
* 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
attests each process launched after a device is started (and is in [IMA] attests each process launched after a device is started (and
scope for RIV), but continuous run-time attestation of Linux or is in scope for RIV), but continuous run-time attestation of Linux
other multi-threaded operating system processes after they've or other multi-threaded operating system processes after they've
started considerably expands the scope of the problem. Many started considerably expands the scope of the problem. Many
researchers are working on that problem, but this document defers researchers are working on that problem, but this document defers
the problem of continuous, in-memory run-time attestation. the problem of continuous, in-memory run-time attestation.
* 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].
skipping to change at page 9, line 44 skipping to change at page 10, line 20
Virtualization and containerization technologies are increasingly Virtualization and containerization technologies are increasingly
used in network equipment, but are not considered in this used in network equipment, but are not considered in this
document. document.
2. Solution Overview 2. Solution Overview
2.1. RIV Software Configuration Attestation using TPM 2.1. RIV Software Configuration Attestation using TPM
RIV Attestation is a process which can be used to determine the RIV Attestation is a process which can be used to determine the
identity of software running on a specifically-identified device. identity of software running on a specifically-identified device.
Remote Attestation is broken into two phases, shown in Figure 1: The Remote Attestation steps of Section 1.5 are broken into two
phases, shown in Figure 1:
* During system startup, each distinct software object is "measured" * During system startup, or boot phase, each distinct software
by the Attester. The object's identity, hash (i.e., cryptographic object is "measured" by the Attester. The object's identity, hash
digest) and version information are recorded in a log. Hashes are (i.e., cryptographic digest) and version information are recorded
also extended, or cryptographically folded, into the TPM, in a way in a log. Hashes are also extended into the TPM (see Section 9.1
that can be used to validate the log entries. The measurement for more on 'extending hashes'), in a way that can be used to
process generally follows the layered chain-of-trust model used in validate the log entries. The measurement process generally
Measured Boot, where each stage of the system measures the next follows the layered chain-of-trust model used in Measured Boot,
one, and extends its measurement into the TPM, before launching where each stage of the system measures the next one, and extends
it. See [I-D.ietf-rats-architecture], section "Layered its measurement into the TPM, before launching it. See
Attestation Environments," for an architectural definition of this [I-D.ietf-rats-architecture], section "Layered Attestation
model. Environments," for an architectural definition of this model.
* Once the device is running and has operational network * Once the device is running and has operational network
connectivity, a separate, trusted Verifier will interrogate the connectivity, verification can take place. A separate Verifier,
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 Field and signature of certificate containing checking the subjectName and signature of the certificate containing
the TPM's attestation public key, and can validate the software that the TPM's attestation public key, and can validate the software that
was launched by verifying the correctness of the logs by comparing was launched by verifying the correctness of the logs by comparing
with the signed digests from the TPM, and comparing digests in the with the signed digests from the TPM, and comparing digests in the
log with Reference Values. log with Reference Values.
It should be noted that attestation and identity are inextricably It should be noted that attestation and identity are inextricably
linked; signed Evidence that a particular version of software was linked; signed Evidence that a particular version of software was
loaded is of little value without cryptographic proof of the identity loaded is of little value without cryptographic proof of the identity
of the Attester producing the Evidence. of the Attester producing the Evidence.
+-------------------------------------------------------+ +-------------------------------------------------------+
| +--------+ +--------+ +--------+ +---------+ | | +--------+ +--------+ +--------+ +---------+ |
| | BIOS |--->| Loader |-->| Kernel |--->|Userland | | | | BIOS |--->| Loader |-->| Kernel |--->|Userland | |
| +--------+ +--------+ +--------+ +---------+ | | +--------+ +--------+ +--------+ +---------+ |
| | | | | | | | | |
| | | | | | | | | |
| +------------+-----------+-+ | | +------------+-----------+-+ |
| Step 1 | | | Boot Phase | |
| V | | V |
| +--------+ | | +--------+ |
| | TPM | | | | TPM | |
| +--------+ | | +--------+ |
| Router | | | Router | |
+--------------------------------|----------------------+ +--------------------------------|----------------------+
| |
| Step 2 | 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 Step 1, measurements are "extended", or hashed, into the TPM as In the Boot phase, measurements are "extended", or hashed, into the
processes start, with the result that the PCR ends up containing a TPM as processes start, with the result that the TPM ends up
hash of all the measured hashes. In Step 2, signed PCR digests are containing hashes of all the measured hashes. Later, once the system
retrieved from the TPM for off-box analysis after the system is is operational, during the Verification phase, signed digests are
operational. retrieved from the TPM for off-box analysis.
2.1.1. What Does RIV Attest? 2.1.1. What Does RIV Attest?
TPM attestation is strongly focused on Platform Configuration TPM attestation is focused on Platform Configuration Registers
Registers (PCRs), but those registers are only vehicles for (PCRs), but those registers are only vehicles for certifying
certifying accompanying Evidence, conveyed in log entries. It is the accompanying Evidence, conveyed in log entries. It is the hashes in
hashes in log entries that are extended into PCRs, where the final log entries that are extended into PCRs, where the final PCR values
PCR values can be retrieved in the form of a structure called a can be retrieved in the form of a structure called a Quote, signed by
Quote, signed by an Attestation key known only to the TPM. The use an Attestation key known only to the TPM. The use of multiple PCRs
of multiple PCRs serves only to provide some independence between serves only to provide some independence between different classes of
different classes of object, so that one class of objects can be object, so that one class of objects can be updated without changing
updated without changing the extended hash for other classes. the extended hash for other classes. Although PCRs can be used for
Although PCRs can be used for any purpose, this section outlines the any purpose, this section outlines the objects within the scope of
objects within the scope of this document which may be extended into this document which may be extended into the TPM.
the TPM.
In general, assignment of measurements to PCRs is a policy choice In general, assignment of measurements to PCRs is a policy choice
made by the device manufacturer, selected to independently attest made by the device manufacturer, selected to independently attest
three classes of object: three classes of object:
* 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
skipping to change at page 12, line 5 skipping to change at page 12, line 33
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.
For devices using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] gives For devices using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] and
detailed normative requirements for PCR usage. For other platform [PC-Client-EFI-TPM-1.2] give detailed normative requirements for PCR
architectures, the table in Figure 2 gives non-normative guidance for usage. For other platform architectures, where TCG normative
PCR assignment that generalizes the specific details of requirements currently do not exist, the table in Figure 2 gives non-
[PC-Client-BIOS-TPM-2.0]. normative guidance for PCR assignment that generalizes the specific
details of [PC-Client-BIOS-TPM-2.0].
By convention, most PCRs are assigned in pairs, which the even- By convention, most PCRs are assigned in pairs, which the even-
numbered PCR used to measure executable code, and the odd-numbered numbered PCR used to measure executable code, and the odd-numbered
PCR used to measure whatever data and configuration are associated PCR used to measure whatever data and configuration are associated
with that code. It is important to note that each PCR may contain with that code. It is important to note that each PCR may contain
results from dozens (or even thousands) of individual measurements. results from dozens (or even thousands) of individual measurements.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| | Assigned PCR # | | | Assigned PCR # |
| Function | Code | Configuration| | Function | Code | Configuration|
skipping to change at page 13, line 28 skipping to change at page 14, line 10
Host Platform boot components, allowing Attestation policies to be Host Platform boot components, allowing Attestation policies to be
defined using the less changeable components of the transitive defined using the less changeable components of the transitive
trust chain. This PCR typically provides a consistent view of the trust chain. This PCR typically provides a consistent view of the
platform regardless of user selected options. platform regardless of user selected options.
* PCR[2] is intended to represent a "user configurable" environment * PCR[2] is intended to represent a "user configurable" environment
where the user has the ability to alter the components that are where the user has the ability to alter the components that are
measured into PCR[2]. This is typically done by adding adapter measured into PCR[2]. This is typically done by adding adapter
cards, etc., into user-accessible PCI or other slots. In UEFI cards, etc., into user-accessible PCI or other slots. In UEFI
systems these devices may be configured by Option ROMs measured systems these devices may be configured by Option ROMs measured
into PCR[2] and executed by the BIOS. into PCR[2] and executed by the UEFI BIOS.
* PCR[4] is intended to represent the software that manages the * PCR[4] is intended to represent the software that manages the
transition between the platform's Pre-Operating System start and transition between the platform's Pre-Operating System start and
the state of a system with the Operating System present. This the state of a system with the Operating System present. This
PCR, along with PCR[5], identifies the initial operating system PCR, along with PCR[5], identifies the initial operating system
loader (e.g., GRUB for Linux). loader (e.g., GRUB for Linux).
* PCR[8] is used by the OS loader (e.g. GRUB) to record * PCR[8] is used by the OS loader (e.g. GRUB) to record
measurements of the various components of the operating system. measurements of the various components of the operating system.
skipping to change at page 14, line 23 skipping to change at page 14, line 39
particular Verifier considers critical and other log entries that are particular Verifier considers critical and other log entries that are
not considered important, so differing PCR values may not on their not considered important, so differing PCR values may not on their
own constitute a check for authenticity. For example, in a UEFI own constitute a check for authenticity. For example, in a UEFI
system, some administrators may consider booting an image from a system, some administrators may consider booting an image from a
removable drive, something recorded in a PCR, to be a security removable drive, something recorded in a PCR, to be a security
violation, while others might consider that operation an authorized violation, while others might consider that operation an authorized
recovery procedure. recovery procedure.
Designers may allocate particular events to specific PCRs in order to Designers may allocate particular events to specific PCRs in order to
achieve a particular objective with local attestation, (e.g., achieve a particular objective with local attestation, (e.g.,
allowing a procedure to execute, or releasing a paricular decryption allowing a procedure to execute, or releasing a particular decryption
key, only if a given PCR is in a given state). It may also be key, only if a given PCR is in a given state). It may also be
important to designers to consider whether streaming notification of important to designers to consider whether streaming notification of
PCR updates is required (see PCR updates is required (see
[I-D.birkholz-rats-network-device-subscription]). Specific log [I-D.birkholz-rats-network-device-subscription]). Specific log
entries can only be validated if the Verifier receives every log entries can only be validated if the Verifier receives every log
entry affecting the relevant PCR, so (for example) a designer might entry affecting the relevant PCR, so (for example) a designer might
want to separate rare, high-value events such as configuration want to separate rare, high-value events such as configuration
changes, from high-volume, routine measurements such as IMA [IMA] changes, from high-volume, routine measurements such as IMA [IMA]
logs. logs.
2.2. RIV Keying 2.2. RIV Keying
RIV attestation relies on two credentials: RIV attestation relies on two credentials:
* An identity key pair and matching certificate is required to * An identity key pair and matching certificate is required to
certify the identity of the Attester itself. RIV specifies the certify the identity of the Attester itself. RIV specifies the
use of an IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR], use of an IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR],
signed by the device manufacturer, containing the device serial signed by the device manufacturer, containing the device serial
number. number. This requirement goes slightly beyond 802.1AR; see
Section 2.4 for notes.
* An Attestation key pair and matching certificate is required to * An Attestation key pair and matching certificate is required to
sign the Quote generated by the TPM to report evidence of software sign the Quote generated by the TPM to report evidence of software
configuration. configuration.
In TPM application, both the Attestation private key and the DevID In a TPM application, both the Attestation private key and the DevID
private key MUST be protected by the TPM. Depending on other TPM private key MUST be protected by the TPM. Depending on other TPM
configuration procedures, the two keys are likely be different; some configuration procedures, the two keys are likely be different; some
of the considerations are outlined in TCG "TPM 2.0 Keys for Device of the considerations are outlined in TCG "TPM 2.0 Keys for Device
Identity and Attestation" [Platform-DevID-TPM-2.0]. Identity and Attestation" [Platform-DevID-TPM-2.0].
The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies
further conventions for these keys: further conventions for these keys:
* When separate Identity and Attestation keys are used, the * When separate Identity and Attestation keys are used, the
Attestation Key (AK) and its X.509 certificate should parallel the Attestation Key (AK) and its X.509 certificate should parallel the
DevID, with the same device ID information as the DevID DevID, with the same device ID information as the DevID
certificate (that is, the same Subject Name and Subject Alt Name, certificate (that is, the same subjectName and subjectAltName (if
even though the key pairs are different). This allows a quote present), even though the key pairs are different). This allows a
from the device, signed by an AK, to be linked directly to the quote from the device, signed by an AK, to be linked directly to
device that provided it, by examining the corresponding AK the device that provided it, by examining the corresponding AK
certificate. If the Subject and Subject Alt Names in the AK certificate. If the subjectName in the AK certificate doesn't
certificate don't match the corresponding DevID certifcate, or match the corresponding DevID certificate, or they're signed by
they're signed by differing authorities the Verifier may signal differing authorities the Verifier may signal the detection of an
the detection of an Asokan-style man-in-the-middle attack (see Asokan-style person-in-the-middle attack (see Section 5.2).
Section 5.2).
* Network devices that are expected to use secure zero touch * Network devices that are expected to use secure zero touch
provisioning as specified in [RFC8572]) MUST be shipped by the provisioning as specified in [RFC8572]) MUST be shipped by the
manufacturer with pre-provisioned keys (Initial DevID and Initial manufacturer with pre-provisioned keys (Initial DevID and Initial
AK, called IDevID and IAK). IDevID and IAK certificates MUST both AK, called IDevID and IAK). IDevID and IAK certificates MUST both
be signed by the Endorser (typically the device manufacturer). be signed by the Endorser (typically the device manufacturer).
Inclusion of an IDevID and IAK by a vendor does not preclude a Inclusion of an IDevID and IAK by a vendor does not preclude a
mechanism whereby an administrator can define Local Identity and mechanism whereby an administrator can define Local Identity and
Attestation Keys (LDevID and LAK) if desired. Attestation Keys (LDevID and LAK) if desired.
2.3. RIV Information Flow 2.3. RIV Information Flow
RIV workflow for network equipment is organized around a simple use RIV workflow for network equipment is organized around a simple use
case where a network operator wishes to verify the integrity of case where a network operator wishes to verify the integrity of
software installed in specific, fielded devices. This use case software installed in specific, fielded devices. A normative
implies several components: taxonomy of terms is given in [I-D.ietf-rats-architecture], but as a
reminder, this use case implies several roles and objects:
1. The Attester, the device which the network operator wants to 1. The Attester, the device which the network operator wants to
examine. examine.
2. A Verifier (which might be a network management station) 2. A Verifier (which might be a network management station)
somewhere separate from the Device that will retrieve the signed somewhere separate from the Device that will retrieve the signed
evidence and measurement logs, and analyze them to pass judgment evidence and measurement logs, and analyze them to pass judgment
on the security posture of the device. on the security posture of the device.
3. A Relying Party, which can act on Attestation Results. 3. A Relying Party, which can act on Attestation Results.
skipping to change at page 16, line 16 skipping to change at page 16, line 41
system", etc.). Retrieving RIMs from the device itself allows system", etc.). Retrieving RIMs from the device itself allows
attestation to be done in systems that may not have access to the attestation to be done in systems that may not have access to the
public internet, or by other devices that are not management public internet, or by other devices that are not management
stations per se (e.g., a peer device; see Section 3.1.3). If stations per se (e.g., a peer device; see Section 3.1.3). If
Reference Values are obtained from multiple sources, the Verifier Reference Values are obtained from multiple sources, the Verifier
may need to evaluate the relative level of trust to be placed in may need to evaluate the relative level of trust to be placed in
each source in case of a discrepancy. each source in case of a discrepancy.
These components are illustrated in Figure 3. These components are illustrated in Figure 3.
A more-detailed taxonomy of terms is given in
[I-D.ietf-rats-architecture]
+----------------+ +-------------+ +---------+--------+ +----------------+ +-------------+ +---------+--------+
|Reference Value | | Attester | Step 1 | Verifier| | |Reference Value | | Attester | Step 1 | Verifier| |
|Provider | | (Device |<-------| (Network| Relying| |Provider | | (Device |<-------| (Network| Relying|
|(Device | | under |------->| Mngmt | Party | |(Device | | under |------->| Mngmt | Party |
|Manufacturer | | attestation)| Step 2 | Station)| | |Manufacturer | | attestation)| Step 2 | Station)| |
|or other | | | | | | |or other | | | | | |
|authority) | | | | | | |authority) | | | | | |
+----------------+ +-------------+ +---------+--------+ +----------------+ +-------------+ +---------+--------+
| /\ | /\
| Step 0 | | Step 0 |
skipping to change at page 16, line 48 skipping to change at page 17, line 22
"out of band" ways to make this happen). "out of band" ways to make this happen).
* In Step 1, the Verifier (Network Management Station), on behalf of * In Step 1, the Verifier (Network Management Station), on behalf of
a Relying Party, requests Identity, Measurement Values, and a Relying Party, requests Identity, Measurement Values, and
possibly RIMs, from the Attester. possibly RIMs, from the Attester.
* In Step 2, the Attester responds to the request by providing a * In Step 2, the Attester responds to the request by providing a
DevID, quotes (measured values, signed by the Attester), and DevID, quotes (measured values, signed by the Attester), and
optionally RIMs. optionally RIMs.
To achieve interoperability, the following standards components Use of the following standards components allows for
SHOULD be used: 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 SHOULD be taken according to TCG PC Client bootable modules MUST be taken according to TCG PC Client
[PC-Client-BIOS-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 SHOULD be formatted according to the Canonical 4. Attestation logs from Linux-based systems MUST be formatted
Event Log format [Canonical-Event-Log], although other according to the Canonical Event Log format
specialized formats may be used. UEFI-based systems MAY use the [Canonical-Event-Log]. UEFI-based systems MUST use the TCG UEFI
TCG UEFI BIOS event log [EFI-TPM]. 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]
for TPM2.0.
5. Quotes are retrieved from the TPM according to TCG TAP 5. Quotes MUST be retrieved from the TPM according to TCG TAP
Information Model [TAP]. While the TAP IM gives a protocol- Information Model [TAP] and the CHARRA YANG model
independent description of the data elements involved, it's [I-D.ietf-rats-yang-tpm-charra]. While the TAP IM gives a
important to note that quotes from the TPM are signed inside the protocol-independent description of the data elements involved,
TPM, so MUST be retrieved in a way that does not invalidate the it's important to note that quotes from the TPM are signed inside
signature, as specified in [I-D.ietf-rats-yang-tpm-charra], to the TPM, and MUST be retrieved in a way that does not invalidate
preserve the trust model. (See Section 5 Security the signature, to preserve the trust model. The
Considerations). [I-D.ietf-rats-yang-tpm-charra] can be used for this purpose.
(See Section 5 Security Considerations).
6. Reference Values SHOULD be encoded as SWID or CoSWID tags, as 6. Reference Values MUST be encoded as defined in the TCG RIM
defined in the TCG RIM document [RIM], compatible with NIST IR document [RIM], typically using SWID [SWID], [NIST-IR-8060] or
8060 [NIST-IR-8060] and the IETF CoSWID draft CoSWID tags [I-D.ietf-sacm-coswid].
[I-D.ietf-sacm-coswid]. See Section 2.4.1.
2.4. RIV Simplifying Assumptions 2.4. RIV Simplifying Assumptions
This document makes the following simplifying assumptions to reduce This document makes the following simplifying assumptions to reduce
complexity: complexity:
* The product to be attested MUST be shipped with an IEEE 802.1AR * The product to be attested MUST be shipped by the equipment vendor
Device Identity and an Initial Attestation Key (IAK) with with both an IEEE 802.1AR Device Identity and an Initial
certificate. The IAK certificate MUST contain the same identity Attestation Key (IAK) with certificate in place. The IAK
information as the DevID (specifically, the same Subject Name and certificate MUST contain the same identity information as the
Subject Alt Name, signed by the manufacturer), but it's a type of DevID (specifically, the same subjectName and subjectAltName (if
key that can be used to sign a TPM Quote, but not other objects used), signed by the manufacturer), but it's a type of key that
(i.e., it's marked as a TCG "Restricted" key; this convention is can be used to sign a TPM Quote, but not other objects (i.e., it's
described in "TPM 2.0 Keys for Device Identity and Attestation" marked as a TCG "Restricted" key; this convention is described in
"TPM 2.0 Keys for Device Identity and Attestation"
[Platform-DevID-TPM-2.0]). For network equipment, which is [Platform-DevID-TPM-2.0]). For network equipment, which is
generally non-privacy-sensitive, shipping a device with both an generally non-privacy-sensitive, shipping a device with both an
IDevID and an IAK already provisioned substantially simplifies IDevID and an IAK already provisioned substantially simplifies
initial startup. Privacy-sensitive applications may use the TCG initial startup.
Platform Certificate or other procedures to install identity
credentials into the device after manufacture. * IEEE 802.1AR does not require a product serial number as part of
the subjectName, but RIV-compliant devices MUST include their
serial numbers in the DevID/IAK certificates to simplify tracking
logistics for network equipment users. All other optional 802.1AR
fields remain optional in RIV
* The product MUST be equipped with a Root of Trust for Measurement * The product MUST be equipped with a Root of Trust for Measurement
(RTM), Root of Trust for Storage and Root of Trust for Reporting (RTM), Root of Trust for Storage and Root of Trust for Reporting
(as defined in [SP800-155]) that are capable of conforming to TCG (as defined in [SP800-155]) which together are capable of
Trusted Attestation Protocol (TAP) Information Model [TAP]. conforming to TCG Trusted Attestation Protocol Information Model
[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.
[I-D.ietf-sacm-coswid], [SWID], as described in TCG Reference
Integrity Measurement Manifest Information Model [RIM].
2.4.1. Reference Integrity Manifests (RIMs) 2.4.1. Reference Integrity Manifests (RIMs)
[I-D.ietf-rats-yang-tpm-charra] focuses on collecting and [I-D.ietf-rats-yang-tpm-charra] focuses on collecting and
transmitting evidence in the form of PCR measurements and attestation transmitting evidence in the form of PCR measurements and attestation
logs. But the critical part of the process is enabling the Verifier logs. But the critical part of the process is enabling the Verifier
to decide whether the measurements are "the right ones" or not. to decide whether the measurements are "the right ones" or not.
While it must be up to network administrators to decide what they While it must be up to network administrators to decide what they
want on their networks, the software supplier should supply the want on their networks, the software supplier should supply the
skipping to change at page 19, line 30 skipping to change at page 19, line 47
TCG has published an information model defining elements of Reference TCG has published an information model defining elements of Reference
Integrity Manifests under the title TCG Reference Integrity Manifest Integrity Manifests under the title TCG Reference Integrity Manifest
Information Model [RIM]. This information model outlines how SWID Information Model [RIM]. This information model outlines how SWID
tags should be structured to allow attestation, and defines "bundles" tags should be structured to allow attestation, and defines "bundles"
of SWID tags that may be needed to describe a complete software of SWID tags that may be needed to describe a complete software
release. The RIM contains metadata relating to the software release release. The RIM contains metadata relating to the software release
it belongs to, plus hashes for each individual file or other object it belongs to, plus hashes for each individual file or other object
that could be attested. that could be attested.
TCG has also published the PC Client Reference Integrity Measurement Many network equipment vendors use a UEFI BIOS to launch their
specification [PC-Client-RIM], which focuses on a SWID-compatible network operating system. These vendors may want to also use the TCG
format suitable for expressing expected measurement values in the PC Client Reference Integrity Measurement specification
specific case of a UEFI-compatible BIOS, where the SWID focus on [PC-Client-RIM], which focuses specifically on a SWID-compatible
files and file systems is not a direct fit. While the PC Client RIM format suitable for expressing measurement values expected from a
is not directly applicable to network equipment, many vendors do use UEFI BIOS.
a conventional UEFI BIOS to launch their network OS.
2.4.2. Attestation Logs 2.4.2. Attestation Logs
Quotes from a TPM can provide evidence of the state of a device up to Quotes from a TPM can provide evidence of the state of a device up to
the time the evidence was recorded, but to make sense of the quote in the time the evidence was recorded, but to make sense of the quote in
most cases an event log that identifies which software modules most cases an event log that identifies which software modules
contributed which values to the quote during startup MUST also be contributed which values to the quote during startup MUST also be
provided. The log MUST contain enough information to demonstrate its provided. The log MUST contain enough information to demonstrate its
integrity by allowing exact reconstruction of the digest conveyed in integrity by allowing exact reconstruction of the digest conveyed in
the signed quote (that is, calculating the hash of all the hashes in the signed quote (that is, calculating the hash of all the hashes in
the log should produce the same values as contained in the PCRs; if the log should produce the same values as contained in the PCRs; if
they don't match, the log may have been tampered with. See they don't match, the log may have been tampered with. See
Section 9.1). Section 9.1).
There are multiple event log formats which may be supported as viable There are multiple event log formats which may be supported as viable
formats of Evidence between the Attester and Verifier: formats of Evidence between the Attester and Verifier, but to
simplify interoperability, RIV focuses on just three:
* IMA Event log file exports [IMA] * TCG UEFI BIOS event log for TPM 2.0 (TCG PC Client Platform
Firmware Profile) [PC-Client-BIOS-TPM-2.0]
* TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM * TCG UEFI BIOS event log for TPM 1.2 (TCG EFI Platform
Family 1.1 or 1.2, Section 7) [EFI-TPM] Specification for TPM Family 1.1 or 1.2, Section 7)
[PC-Client-EFI-TPM-1.2]
* TCG Canonical Event Log [Canonical-Event-Log] * TCG Canonical Event Log [Canonical-Event-Log]
Attesters which use UEFI BIOS and Linux SHOULD use TCG Canonical
Event Log [Canonical-Event-Log] and TCG UEFI BIOS event log
[EFI-TPM], although the CHARRA YANG model
[I-D.ietf-rats-yang-tpm-charra] has no dependence on the format of
the log.
3. Standards Components 3. Standards Components
3.1. Prerequisites for RIV 3.1. Prerequisites for RIV
The Reference Interaction Model for Challenge-Response-based Remote The Reference Interaction Model for Challenge-Response-based Remote
Attestation ([I-D.birkholz-rats-reference-interaction-model]) is Attestation ([I-D.birkholz-rats-reference-interaction-model]) is
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
skipping to change at page 20, line 43 skipping to change at page 21, line 8
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], the Attester according to [Platform-DevID-TPM-2.0], or
[PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2]. [Platform-ID-TPM-1.2].
The Attester's TPM Keys MUST be associated with the DevID on the It MUST be possible for the Verifier to determine that the Attester's
Verifier (see [Platform-DevID-TPM-2.0] and Section 5 Security Attestation keys are resident in the same TPM as its DevID keys (see
Considerations, below). Section 2.2 and Section 5 Security Considerations).
3.1.3. Appraisal Policy for Evidence 3.1.3. Appraisal Policy for Evidence
The Verifier MUST obtain trustworthy Reference Values (encoded as As noted in Section 2.3, the Verifier may obtain Reference Values
SWID or CoSWID tags [I-D.ietf-sacm-coswid]. These reference from several sources. In addition, administrators may make
measurements will eventually be compared to signed PCR Evidence authorized, site-specific changes (e.g. keys in key databases) that
('quotes') acquired from an Attester's TPM using Attestation Policies could impact attestation results. As such, there could be conflicts,
chosen by the administrator or owner of the device. omissions or ambiguities between some Reference Values and collected
Evidence.
This document does not specify the format or contents for the
Appraisal Policy for Evidence, but Reference Values may be acquired
in one of two ways:
1. a Verifier may obtain reference measurements directly from an
Reference Value Provider chosen by the Verifier administrator
(e.g., through a web site).
2. Signed reference measurements may be distributed by the Reference
Value Provider to the Attester, as part of a software update.
From there, the reference measurement may be acquired by the
Verifier.
In either case, the Verifier Owner MUST select the source of trusted
Reference Values through the Appraisal Policy for Evidence.
****************** .-------------. .-----------.
*Reference Value * | Attester | | Verifier/ |
*Provider * | | | Relying |
*(Device *----2--->| (Network |----2--->| Party |
*config * | Device) | |(Ntwk Mgmt |
*Authority) * | | | Station) |
****************** '-------------' '-----------'
| ^
| |
'----------------1----------------------------'
Figure 4: Appraisal Policy for Evidence Prerequisites
In either case the Reference Values must be generated, acquired and The Verifier MUST have an Appraisal Policy for Evidence to evaluate
delivered in a secure way, including reference measurements of the significance of any discrepancies between different reference
firmware and bootable modules taken according to TCG PC Client sources, or between reference values and evidence from logs and
[PC-Client-BIOS-TPM-2.0] and Linux IMA [IMA]. Reference Values MUST quotes. While there must be an Appraisal Policy, this document does
be encoded as SWID or CoSWID tags, signed by the device manufacturer, not specify the format or mechanism to convey the intended policy,
as defined in the TCG RIM document [RIM], compatible with NIST IR nor does RIV specify mechanisms by which the results of applying the
8060 [NIST-IR-8060] or the IETF CoSWID draft [I-D.ietf-sacm-coswid]. policy are communicated to the Relying Party.
3.2. Reference Model for Challenge-Response 3.2. Reference Model for Challenge-Response
Once the prerequisites for RIV are met, a Verifier is able to acquire Once the prerequisites for RIV are met, a Verifier is able to acquire
Evidence from an Attester. The following diagram illustrates a RIV Evidence from an Attester. The following diagram illustrates a RIV
information flow between a Verifier and an Attester, derived from information flow between a Verifier and an Attester, derived from
Section 8.1 of [I-D.birkholz-rats-reference-interaction-model]. Section 7.1 of [I-D.birkholz-rats-reference-interaction-model]. In
Event times shown correspond to the time types described within this diagram, each event with its input and output parameters is
Appendix A of [I-D.ietf-rats-architecture]: shown as "Event(input-params)=>(outputs)". Event times shown
correspond to the time types described within Appendix A of
[I-D.ietf-rats-architecture]:
.----------. .--------------------------. .----------. .-----------------------.
| Attester | | Relying Party / Verifier | | Attester | | Relying Party/Verifier |
'--------- ' '--------------------------' '----------' '------------------------'
time(VG) | time(VG) |
valueGeneration(targetEnvironment) | generateClaims(attestingEnvironment) |
| => claims | | => claims, eventLogs |
| | | |
| <-----------requestEvidence(nonce, PcrSelection)----time(NS) | time(NS)
| | | <-- requestAttestation(handle, authSecIDs, claimSelection) |
time(EG) | | |
evidenceGeneration(nonce, PcrSelection, collectedClaims) | time(EG) |
| => SignedPcrEvidence(nonce, PcrSelection) | collectClaims(claims, claimSelection) |
| => LogEvidence(collectedClaims) | | => collectedClaims |
| | | |
| returnSignedPcrEvidence-------------------------------> | generateEvidence(handle, authSecIDs, collectedClaims) |
| returnLogEvidence-------------------------------------> | | => evidence |
| | | time(RG,RA)
| time(RG,RA) | evidence, eventLogs -------------------------------------> |
| evidenceAppraisal(SignedPcrEvidence, eventLog, refClaims) | |
| attestationResult <= | | appraiseEvidence(evidence, eventLogs, refValues)
~ ~ | attestationResult <= |
| time(RX) | |
~ ~
| time(RX)
Figure 5: 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 attestation data for one ("number used once"), and makes a request for one or more PCRs
or more PCRs from an Attester. For interoperability, this MUST be from an Attester. For interoperability, this MUST be accomplished
accomplished via a YANG [RFC7950] interface that implements the via an interface that implements the YANG Data Model for
TCG TAP model (e.g., YANG Module for Basic Challenge-Response- Challenge-Response-based Remote Attestation Procedures using TPMs
based Remote Attestation Procedures [I-D.ietf-rats-yang-tpm-charra]. TPM1.2 and TPM2.0 both allow
[I-D.ietf-rats-yang-tpm-charra]). 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,
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 TCG TAP Information Model [TAP]. At the same time, according to CHARRA YANG model [I-D.ietf-rats-yang-tpm-charra].
the Attester collects log evidence showing the values have been
extended into that PCR. Section 9.1 gives more detail on how this At the same time, the Attester collects log evidence showing the
works. values have been extended into that PCR. Section 9.1 gives more
detail on how this works, including references to the structure
and contents of quotes in TPM documents.
* Step 4: Collected Evidence is passed from the Attester to the * Step 4: Collected Evidence is passed from the Attester to the
Verifier Verifier
* Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes * Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes
action as needed. As the interaction between Relying Party and action as needed. As the interaction between Relying Party and
Verifier is out of scope for RIV, this can be described as one Verifier is out of scope for RIV, this can be described as one
step. step.
- If the signature covering TPM Evidence is not correct, the - If the signature covering TPM Evidence is not correct, the
skipping to change at page 23, line 49 skipping to change at page 23, line 45
- If the set of log entries are not seen as acceptable by the - If the set of log entries are not seen as acceptable by the
Appraisal Policy for Evidence, the device SHOULD NOT be Appraisal Policy for Evidence, the device SHOULD NOT be
trusted. trusted.
- If time(RG)-time(NS) is greater than the Appraisal Policy for - If time(RG)-time(NS) is greater than the Appraisal Policy for
Evidence's threshold for assessing freshness, the Evidence is Evidence's threshold for assessing freshness, the Evidence is
considered stale and SHOULD NOT be trusted. considered stale and SHOULD NOT be trusted.
3.2.1. Transport and Encoding 3.2.1. Transport and Encoding
Network Management systems may retrieve signed PCR based Evidence as Network Management systems MUST retrieve signed PCR based Evidence
shown in Figure 5, and can be accomplished via NETCONF or RESTCONF, using [I-D.ietf-rats-yang-tpm-charra] with NETCONF or RESTCONF.
with XML, JSON, or CBOR encoded Evidence.
Implementations that use NETCONF MUST do so over a TLS or SSH secure Implementations that use NETCONF MUST do so over a TLS or SSH secure
tunnel. Implementations that use RESTCONF transport MUST do so over tunnel. Implementations that use RESTCONF transport MUST do so over
a TLS or SSH secure tunnel. a TLS or SSH secure tunnel.
Retrieval of Log Evidence SHOULD be done via log interfaces specified Log Evidence MUST be retrieved via log interfaces specified in
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 5 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 6. 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.
+---------------+ +---------------+ +---------------+ +---------------+
| RefVal | | RefVal | | RefVal | | RefVal |
| Provider A | | Provider B | | Provider A | | Provider B |
skipping to change at page 25, line 32 skipping to change at page 24, line 51
| | | | | | | | | |
| | | | | | | | | |
| | Step 1 | | | \ | | Step 1 | | | \
| Verifier |<------>| Attester |<-+ | Router A | Verifier |<------>| Attester |<-+ | Router A
| |<------>| | |- Challenges | |<------>| | |- Challenges
| | Step 2 | | | Router B | | Step 2 | | | Router B
| | | | | | | | | |
| |<-------| | | | |<-------| | |
+------------+ Step 3 +------------+ / +------------+ Step 3 +------------+ /
Figure 6: Peer-to-Peer Attestation Information Flow Figure 5: Peer-to-Peer Attestation Information Flow
In this application, each device may need to be equipped with signed In this application, each device may need to be equipped with signed
RIMs to act as an Attester, and also an Appraisal Policy for Evidence RIMs to act as an Attester, and also an Appraisal Policy for Evidence
and a selection of trusted X.509 root certificates, to allow the and a selection of trusted X.509 root certificates, to allow the
device to act as a Verifier. An existing link layer protocol such as device to act as a Verifier. An existing link layer protocol such as
802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being 802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being
enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable
methods for such an exchange. methods for such an exchange.
4. Privacy Considerations 4. Privacy Considerations
skipping to change at page 26, line 31 skipping to change at page 25, line 49
light of these requirements for protecting the privacy of users of light of these requirements for protecting the privacy of users of
the network, the network equipment must identify itself, and its boot the network, the network equipment must identify itself, and its boot
configuration and measured device state (for example, PCR values), to configuration and measured device state (for example, PCR values), to
the equipment's administrator, so there's no uncertainty as to what the equipment's administrator, so there's no uncertainty as to what
function each device and configuration is configured to carry out. function each device and configuration is configured to carry out.
Attestation is a component that allows the administrator to ensure Attestation is a component that allows the administrator to ensure
that the network provides individual and peer privacy guarantees, that the network provides individual and peer privacy guarantees,
even though the device itself may not have a right to keep its even though the device itself may not have a right to keep its
identity secret. identity secret.
RIV specifically addresses the collection of information from
enterprise network devices by authorized agents of the enterprise.
As such, privacy is a fundamental concern for those deploying this
solution, given EU GDPR, California CCPA, and many other privacy
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.
While attestation information from network devices is not likely to
contain privacy-sensitive content regarding network users,
administrators may want to keep attestation records confidential to
avoid disclosing versions of software loaded on the device,
information which could facilitate attacks against known
vulnerabilities.
5. Security Considerations 5. Security Considerations
Attestation Evidence from the RIV procedure are subject to a number Attestation Evidence from the RIV procedure are subject to a number
of attacks: of attacks:
* 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.
* Man-in-the-middle attacks may be used by a counterfeit device to * Person-in-the-middle attacks may be used by a compromised device
attempt to deliver responses that originate in an actual authentic to attempt to deliver responses that originate in an authentic
device. device.
* Replay attacks may be attempted by a compromised device. * Replay attacks may be attempted by a compromised device.
5.1. Keys Used in RIV 5.1. Keys Used in RIV
Trustworthiness of RIV attestation depends strongly on the validity Trustworthiness of RIV attestation depends strongly on the validity
of keys used for identity and attestation reports. RIV takes full of keys used for identity and attestation reports. RIV takes full
advantage of TPM capabilities to ensure that evidence can be trusted. advantage of TPM capabilities to ensure that evidence can be trusted.
skipping to change at page 27, line 29 skipping to change at page 26, line 50
Evidence (called 'quotes' in TCG documents), used to provide Evidence (called 'quotes' in TCG documents), used to provide
evidence for integrity of the software on the device evidence for integrity of the software on the device
TPM practices usually require that these keys be different, as a way TPM practices usually require that these keys be different, as a way
of ensuring that a general-purpose signing key cannot be used to of ensuring that a general-purpose signing key cannot be used to
spoof an attestation quote. spoof an attestation quote.
In each case, the private half of the key is known only to the TPM, In each case, the private half of the key is known only to the TPM,
and cannot be retrieved externally, even by a trusted party. To and cannot be retrieved externally, even by a trusted party. To
ensure that's the case, specification-compliant private/public key- ensure that's the case, specification-compliant private/public key-
pairs are generated inside the TPM, where they're never exposed, and pairs are generated inside the TPM, where they are never exposed, and
cannot be extracted (See [Platform-DevID-TPM-2.0]). cannot be extracted (See [Platform-DevID-TPM-2.0]).
Keeping keys safe is a critical enabler of trustworthiness, but it's Keeping keys safe is a critical enabler of trustworthiness, but it's
just part of attestation security; knowing which keys are bound to just part of attestation security; knowing which keys are bound to
the device in question is just as important in an environment where the device in question is just as important in an environment where
private keys are never exposed. private keys are never exposed.
While there are many ways to manage keys in a TPM (see While there are many ways to manage keys in a TPM (see
[Platform-DevID-TPM-2.0]), RIV includes support for "zero touch" [Platform-DevID-TPM-2.0]), RIV includes support for "zero touch"
provisioning (also known as zero-touch onboarding) of fielded devices provisioning (also known as zero-touch onboarding) of fielded devices
skipping to change at page 29, line 5 skipping to change at page 28, line 26
A critical feature of the YANG model described in A critical feature of the YANG model described in
[I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data
structures in their native format, without requiring any changes to structures in their native format, without requiring any changes to
the structures as they were signed and delivered by the TPM. While the structures as they were signed and delivered by the TPM. While
alternate methods of conveying TPM quotes could compress out alternate methods of conveying TPM quotes could compress out
redundant information, or add an additional layer of signing using redundant information, or add an additional layer of signing using
external keys, the implementation MUST preserve the TPM signing, so external keys, the implementation MUST preserve the TPM signing, so
that tampering anywhere in the path between the TPM itself and the that tampering anywhere in the path between the TPM itself and the
Verifier can be detected. Verifier can be detected.
5.2. Prevention of Spoofing and Man-in-the-Middle Attacks 5.2. Prevention of Spoofing and 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 two 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. Use of the 802.1AR Device Identity (DevID) in
the TPM ensures that the Verifier's TLS or SSH session is in fact the TPM ensures that the Verifier's TLS or SSH session is in fact
terminating on the right device. terminating on the right device.
skipping to change at page 29, line 28 skipping to change at page 28, line 49
Protection against spoofed quotes from a device with valid identity Protection against spoofed quotes from a device with valid identity
is a bit more complex. An identity key must be available to sign any is a bit more complex. An identity key must be available to sign any
kind of nonce or hash offered by the Verifier, and consequently, kind of nonce or hash offered by the Verifier, and consequently,
could be used to sign a fabricated quote. To block a spoofed could be used to sign a fabricated quote. To block a spoofed
Attestation Result, the quote generated inside the TPM must be signed Attestation Result, the quote generated inside the TPM must be signed
by a key that's different from the DevID, called an Attestation Key by a key that's different from the DevID, called an Attestation Key
(AK). (AK).
Given separate Attestation and DevID keys, the binding between the AK Given separate Attestation and DevID keys, the binding between the AK
and the same device must also be proven to prevent a man-in-the- and the same device must also be proven to prevent a 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.
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
skipping to change at page 31, line 43 skipping to change at page 31, line 10
the device. If a TPM that has already been programmed with an the device. If a TPM that has already been programmed with an
authentic DevID is stolen and inserted into a counterfeit device, authentic DevID is stolen and inserted into a counterfeit device,
attestation of that counterfeit device may become attestation of that counterfeit device may become
indistinguishable from an authentic device. indistinguishable from an authentic device.
RIV also depends on reliable Reference Values, as expressed by the RIV also depends on reliable Reference Values, as expressed by the
RIM [RIM]. The definition of trust procedures for RIMs is out of RIM [RIM]. The definition of trust procedures for RIMs is out of
scope for RIV, and the device owner is free to use any policy to scope for RIV, and the device owner is free to use any policy to
validate a set of reference measurements. RIMs may be conveyed out- validate a set of reference measurements. RIMs may be conveyed out-
of-band or in-band, as part of the attestation process (see of-band or in-band, as part of the attestation process (see
Section 3.1.3). But for embedded devices, where software is usually Section 3.1.3). But for network devices, where software is usually
shipped as a self-contained package, RIMs signed by the manufacturer shipped as a self-contained package, RIMs signed by the manufacturer
and delivered in-band may be more convenient for the device owner. and delivered in-band may be more convenient for the device owner.
The validity of RIV attestation results is also influenced by The validity of RIV attestation results is also influenced by
procedures used to create Reference Values: procedures used to create Reference Values:
* 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.
skipping to change at page 33, line 22 skipping to change at page 32, line 34
Quote mechanism, and a standardized Event Log. Quote mechanism, and a standardized Event Log.
Each TPM has at least eight and at most twenty-four PCRs (depending Each TPM has at least eight and at most twenty-four PCRs (depending
on the profile and vendor choices), each one large enough to hold one on the profile and vendor choices), each one large enough to hold one
hash value (SHA-1, SHA-256, and other hash algorithms can be used, hash value (SHA-1, SHA-256, and other hash algorithms can be used,
depending on TPM version). PCRs can't be accessed directly from depending on TPM version). PCRs can't be accessed directly from
outside the chip, but the TPM interface provides a way to "extend" a outside the chip, but the TPM interface provides a way to "extend" a
new security measurement hash into any PCR, a process by which the new security measurement hash into any PCR, a process by which the
existing value in the PCR is hashed with the new security measurement existing value in the PCR is hashed with the new security measurement
hash, and the result placed back into the same PCR. The result is a hash, and the result placed back into the same PCR. The result is a
composite fingerprint of all the security measurements extended into composite fingerprint comprising the hash of all the security
each PCR since the system was reset. measurements extended into each PCR since the system was reset.
Every time a PCR is extended, an entry should be added to the Every time a PCR is extended, an entry should be added to the
corresponding Event Log. Logs contain the security measurement hash corresponding Event Log. Logs contain the security measurement hash
plus informative fields offering hints as to which event generated plus informative fields offering hints as to which event generated
the security measurement. The Event Log itself is protected against the security measurement. The Event Log itself is protected against
accidental manipulation, but it is implicitly tamper-evident - any accidental manipulation, but it is implicitly tamper-evident - any
verification process can read the security measurement hash from the verification process can read the security measurement hash from the
log events, compute the composite value and compare that to what log events, compute the composite value and compare that to what
ended up in the PCR. If there's no discrepancy, the logs do provide ended up in the PCR. If there's no discrepancy, the logs do provide
an accurate view of what was placed into the PCR. an accurate view of what was placed into the PCR.
skipping to change at page 34, line 22 skipping to change at page 33, line 27
The TPM provides another mechanism called a Quote that can read the The TPM provides another mechanism called a Quote that can read the
current value of the PCRs and package them, along with the Verifier's current value of the PCRs and package them, along with the Verifier's
nonce, into a TPM-specific data structure signed by an Attestation nonce, into a TPM-specific data structure signed by an Attestation
private key, known only to the TPM. private key, known only to the TPM.
As noted above in Section 5 Security Considerations, it's important As noted above in Section 5 Security Considerations, it's important
to note that the Quote data structure is signed inside the TPM. The to note that the Quote data structure is signed inside the TPM. The
trust model is preserved by retrieving the Quote in a way that does trust model is preserved by retrieving the Quote 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]. [I-D.ietf-rats-yang-tpm-charra]. The structure of the command and
response for a quote, including its signature, as generated by the
TPM, can be seen in [TPM1.2] Part 3, Section 16.5, and [TPM2.0]
Section 18.4.2.
The Verifier uses the Quote and Log together. The Quote contains the The Verifier uses the Quote and Log together. The Quote contains the
composite hash of the complete sequence of security measurement composite hash of the complete sequence of security measurement
hashes, signed by the TPM's private Attestation Key. The Log hashes, signed by the TPM's private Attestation Key. The Log
contains a record of each measurement extended into the TPM's PCRs. contains a record of each measurement extended into the TPM's PCRs.
By computing the composite hash of all the measurements, the Verifier By computing the composite hash of all the measurements, the Verifier
can verify the integrity of the Event Log, even though the Event Log can verify the integrity of the Event Log, even though the Event Log
itself is not signed. Each hash in the validated Event Log can then itself is not signed. Each hash in the validated Event Log can then
be compared to corresponding expected values in the set of Reference be compared to corresponding expected values in the set of Reference
Values to validate overall system integrity. Values to validate overall system integrity.
A summary of information exchanged in obtaining quotes from TPM1.2 A summary of information exchanged in obtaining quotes from TPM1.2
and TPM2.0 can be found in [TAP], Section 4. Detailed information and TPM2.0 can be found in [TAP], Section 4. Detailed information
about PCRs and Quote data structures can be found in [TPM1.2], about PCRs and Quote data structures can be found in [TPM1.2],
[TPM2.0]. Recommended log formats include [PC-Client-BIOS-TPM-2.0] [TPM2.0]. Recommended log formats include [PC-Client-BIOS-TPM-2.0],
and [Canonical-Event-Log]. and [Canonical-Event-Log].
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
skipping to change at page 36, line 28 skipping to change at page 35, line 28
******************************************************************** ********************************************************************
* IETF Attestation Reference Interaction Diagram * * IETF Attestation Reference Interaction Diagram *
******************************************************************** ********************************************************************
....................... ....................... ....................... .......................
. Reference Integrity . . TAP (PTS2.0) Info . . Reference Integrity . . TAP (PTS2.0) Info .
. Manifest . . Model and Canonical . . Manifest . . Model and Canonical .
. . . Log Format . . . . Log Format .
....................... ....................... ....................... .......................
************************* .............. ********************** ************************* **********************
* YANG SWID Module * . TCG . * YANG Attestation * * YANG SWID Module * * YANG Attestation *
* I-D.ietf-sacm-coswid * . Attestation. * Module * * I-D.ietf-sacm-coswid * * Module *
* * . MIB . * I-D.ietf-rats- * * * * I-D.ietf-rats- *
* * . . * yang-tpm-charra * * * * yang-tpm-charra *
************************* .............. ********************** ************************* **********************
************************* ************ ************************ ************************* ************ ************************
* XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)* * XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)*
************************* ************ ************************ ************************* ************ ************************
************************* ************************ ************************* ************************
* RESTCONF/NETCONF * * RESTCONF/NETCONF * * RESTCONF/NETCONF * * RESTCONF/NETCONF *
************************* ************************ ************************* ************************
************************* ************************ ************************* ************************
* TLS, SSH * * TLS, SSH * * TLS, SSH * * TLS, SSH *
************************* ************************ ************************* ************************
Figure 7: 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 8 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
implied actions required for implementation are all the implied actions required for implementation are all the
responsibility of the manufacturer of the device, unless otherwise responsibility of the manufacturer of the device, unless otherwise
noted. It should be noted that, while the YANG model is RECOMMENDED noted.
for attestation, this table identifies an optional SNMP MIB as well,
[Attest-MIB]. As noted, SWID tags can be generated many ways, but one possible tool
is [SWID-Gen]
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| 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 and reporting | | | well as roots for storage and reporting | |
| inside the TPM. | | | inside the TPM. | |
skipping to change at page 38, line 22 skipping to change at page 37, line 23
| as [SWID-Gen] can be used |----------------| | as [SWID-Gen] can be used |----------------|
| | TCG PC Client | | | TCG PC Client |
| | RIM | | | RIM |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Use PC Client measurement definitions | TCG PC Client | | Use PC Client measurement definitions | TCG PC Client |
| to define the use of PCRs | BIOS | | to define the use of PCRs | BIOS |
| (although Windows OS is rare on Networking | | | (although Windows OS is rare on Networking | |
| Equipment, UEFI BIOS is not) | | | Equipment, UEFI BIOS is not) | |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Use TAP to retrieve measurements | | | Use TAP to retrieve measurements | |
| o Map TAP to SNMP | TCG SNMP MIB |
| o Map to YANG | YANG Module for| | o Map to YANG | YANG Module for|
| Use Canonical Log Format | Basic | | Use Canonical Log Format | Basic |
| | Attestation | | | Attestation |
| | TCG Canonical | | | TCG Canonical |
| | Log Format | | | Log Format |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Posture Collection Server (as described in IETF | | | Posture Collection Server (as described in IETF | |
| SACMs ECP) should request the | | | SACMs ECP) should request the | |
| attestation and analyze the result | | | attestation and analyze the result | |
| The Management application might be broken down | | | The Management application might be broken down | |
| to several more components: | | | to several more components: | |
| o A Posture Manager Server | | | o A Posture Manager Server | |
| which collects reports and stores them in | | | which collects reports and stores them in | |
| a database | | | a database | |
| o One or more Analyzers that can look at the| | | o One or more Analyzers that can look at the| |
| results and figure out what it means. | | | results and figure out what it means. | |
-------------------------------------------------------------------- --------------------------------------------------------------------
Figure 8: Component Status Figure 7: Component Status
10. References 10. References
10.1. Normative References 10.1. Normative References
[Canonical-Event-Log] [Canonical-Event-Log]
Trusted Computing Group, "DRAFT Canonical Event Log Format Trusted Computing Group, "DRAFT Canonical Event Log Format
Version: 1.0, Revision: .12", October 2018. Version: 1.0, Revision: .30", December 2020,
<https://www.trustedcomputinggroup.org/wp-content/uploads/
TCG_IWG_CEL_v1_r0p30_13feb2021.pdf>.
[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-08, 14 Internet-Draft, draft-ietf-rats-yang-tpm-charra-11, 26
April 2021, <https://www.ietf.org/archive/id/draft-ietf- August 2021, <https://www.ietf.org/archive/id/draft-ietf-
rats-yang-tpm-charra-08.txt>. rats-yang-tpm-charra-11.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-17, 22 in Progress, Internet-Draft, draft-ietf-sacm-coswid-19, 20
February 2021, <https://www.ietf.org/archive/id/draft- October 2021, <https://www.ietf.org/archive/id/draft-ietf-
ietf-sacm-coswid-17.txt>. sacm-coswid-19.txt>.
[IEEE-802-1AR] [IEEE-802-1AR]
Seaman, M., "802.1AR-2018 - IEEE Standard for Local and Seaman, M., "802.1AR-2018 - IEEE Standard for Local and
Metropolitan Area Networks - Secure Device Identity, IEEE Metropolitan Area Networks - Secure Device Identity, IEEE
Computer Society", August 2018. Computer Society", August 2018.
[PC-Client-BIOS-TPM-1.2] [IMA] dsafford, kds_etu, mzohar, reinersailer, and serge_hallyn,
Trusted Computing Group, "TCG PC Client Specific "Integrity Measurement Architecture", June 2019,
Implementation Specification for Conventional BIOS, <https://sourceforge.net/p/linux-ima/wiki/Home/>.
Specification Version 1.21 Errata, Revision 1.00",
February 2012,
<https://trustedcomputinggroup.org/resource/pc-client-
work-group-specific-implementation-specification-for-
conventional-bios/>.
[PC-Client-BIOS-TPM-2.0] [PC-Client-BIOS-TPM-2.0]
Trusted Computing Group, "PC Client Specific Platform Trusted Computing Group, "PC Client Specific Platform
Firmware Profile Specification Family "2.0", Level 00 Firmware Profile Specification Family "2.0", Level 00
Revision 1.04", June 2019, Revision 1.05", May 2021,
<https://trustedcomputinggroup.org/pc-client-specific- <https://trustedcomputinggroup.org/wp-content/uploads/
platform-firmware-profile-specification>. TCG_PCClient_PFP_r1p05_v23_pub.pdf>.
[PC-Client-EFI-TPM-1.2]
Trusted Computing Group, "TCG EFI Platform Specification
for TPM Family 1.1 or 1.2, Specification Version 1.22,
Revision 15", January 2014,
<https://trustedcomputinggroup.org/resource/tcg-efi-
platform-specification/>.
[PC-Client-RIM] [PC-Client-RIM]
Trusted Computing Group, "DRAFT: TCG PC Client Reference Trusted Computing Group, "TCG PC Client Reference
Integrity Manifest Specification, v.09", December 2019, Integrity Manifest Specification, v1.04", December 2019,
<https://trustedcomputinggroup.org/wp-content/uploads/ <https://trustedcomputinggroup.org/wp-content/uploads/
TCG_PC_Client_RIM_r0p15_15june2020.pdf>. TCG_PC_Client_RIM_r1p04_pub.pdf>.
[Platform-DevID-TPM-2.0] [Platform-DevID-TPM-2.0]
Trusted Computing Group, "TPM 2.0 Keys for Device Identity Trusted Computing Group, "TPM 2.0 Keys for Device Identity
and Attestation, Specification Version 1.0, Revision 2", and Attestation, Specification Version 1.0, Revision 2",
September 2020, September 2020,
<https://trustedcomputinggroup.org/resource/tpm-2-0-keys- <https://trustedcomputinggroup.org/resource/tpm-2-0-keys-
for-device-identity-and-attestation/>. for-device-identity-and-attestation/>.
[Platform-ID-TPM-1.2] [Platform-ID-TPM-1.2]
Trusted Computing Group, "TPM Keys for Platform Identity Trusted Computing Group, "TPM Keys for Platform Identity
skipping to change at page 40, line 49 skipping to change at page 39, line 45
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572, Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019, DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>. <https://www.rfc-editor.org/info/rfc8572>.
[RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity [RIM] Trusted Computing Group, "TCG Reference Integrity Manifest
Manifest Information Model", 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_v1-r13_2feb20.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>.
[TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol [TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol
(TAP) Information Model for TPM Families 1.2 and 2.0 and (TAP) Information Model for TPM Families 1.2 and 2.0 and
DICE Family 1.0, Version 1.0, Revision 0.36", October DICE Family 1.0, Version 1.0, Revision 0.36", October
skipping to change at page 41, line 27 skipping to change at page 40, line 27
10.2. Informative References 10.2. Informative References
[AK-Enrollment] [AK-Enrollment]
Trusted Computing Group, "TCG Infrastructure Working Group Trusted Computing Group, "TCG Infrastructure Working Group
- A CMC Profile for AIK Certificate Enrollment Version - A CMC Profile for AIK Certificate Enrollment Version
1.0, Revision 7", March 2011, 1.0, Revision 7", March 2011,
<https://trustedcomputinggroup.org/resource/tcg- <https://trustedcomputinggroup.org/resource/tcg-
infrastructure-working-group-a-cmc-profile-for-aik- infrastructure-working-group-a-cmc-profile-for-aik-
certificate-enrollment/>. certificate-enrollment/>.
[Attest-MIB]
Trusted Computing Group, "SNMP MIB for TPM-Based
Attestation, Version 0.8Revision 0.02", May 2018,
<https://trustedcomputinggroup.org/wp-content/uploads/
TCG_SNMP_MIB_for_TPM-
Based_Attestation_v0.8r2_PUBLIC_REVIEW.pdf>.
[EFI-TPM] Trusted Computing Group, "TCG EFI Platform Specification
for TPM Family 1.1 or 1.2, Specification Version 1.22,
Revision 15", January 2014,
<https://trustedcomputinggroup.org/resource/tcg-efi-
platform-specification/>.
[I-D.birkholz-rats-network-device-subscription] [I-D.birkholz-rats-network-device-subscription]
Birkholz, H., Voit, E., and W. Pan, "Attestation Event Birkholz, H., Voit, E., and W. Pan, "Attestation Event
Stream Subscription", Work in Progress, Internet-Draft, Stream Subscription", Work in Progress, Internet-Draft,
draft-birkholz-rats-network-device-subscription-02, 31 draft-birkholz-rats-network-device-subscription-03, 17
March 2021, <https://www.ietf.org/archive/id/draft- August 2021, <https://www.ietf.org/archive/id/draft-
birkholz-rats-network-device-subscription-02.txt>. birkholz-rats-network-device-subscription-03.txt>.
[I-D.birkholz-rats-reference-interaction-model] [I-D.birkholz-rats-reference-interaction-model]
Birkholz, H., Eckel, M., Newton, C., and L. Chen, Birkholz, H., Eckel, M., Newton, C., and L. Chen,
"Reference Interaction Models for Remote Attestation "Reference Interaction Models for Remote Attestation
Procedures", Work in Progress, Internet-Draft, draft- Procedures", Work in Progress, Internet-Draft, draft-
birkholz-rats-reference-interaction-model-03, 7 July 2020, birkholz-rats-reference-interaction-model-03, 7 July 2020,
<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-04, 13 Progress, Internet-Draft, draft-birkholz-rats-tuda-05, 12
January 2021, <https://www.ietf.org/archive/id/draft- July 2021, <https://www.ietf.org/archive/id/draft-
birkholz-rats-tuda-04.txt>. birkholz-rats-tuda-05.txt>.
[I-D.ietf-rats-architecture] [I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", Work W. Pan, "Remote Attestation Procedures Architecture", Work
in Progress, Internet-Draft, draft-ietf-rats-architecture- in Progress, Internet-Draft, draft-ietf-rats-architecture-
12, 23 April 2021, <https://www.ietf.org/archive/id/draft- 13, 8 November 2021, <https://www.ietf.org/archive/id/
ietf-rats-architecture-12.txt>. draft-ietf-rats-architecture-13.txt>.
[I-D.ietf-rats-eat] [I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Ballesteros, M., and J. Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity
O'Donoghue, "The Entity Attestation Token (EAT)", Work in Attestation Token (EAT)", Work in Progress, Internet-
Progress, Internet-Draft, draft-ietf-rats-eat-10, 7 March Draft, draft-ietf-rats-eat-11, 24 October 2021,
2021, <https://www.ietf.org/archive/id/draft-ietf-rats- <https://www.ietf.org/archive/id/draft-ietf-rats-eat-
eat-10.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,
Internet-Draft, draft-richardson-rats-usecases-08, 2 Internet-Draft, draft-richardson-rats-usecases-08, 2
November 2020, <https://www.ietf.org/archive/id/draft- November 2020, <https://www.ietf.org/archive/id/draft-
richardson-rats-usecases-08.txt>. richardson-rats-usecases-08.txt>.
[IEEE-802.1AE] [IEEE-802.1AE]
Seaman, M., "802.1AE MAC Security (MACsec)", 2018, Seaman, M., "802.1AE MAC Security (MACsec)", 2018,
<https://1.ieee802.org/security/802-1ae/>. <https://1.ieee802.org/security/802-1ae/>.
[IEEE-802.1X] [IEEE-802.1X]
IEEE Computer Society, "802.1X-2020 - IEEE Standard for IEEE Computer Society, "802.1X-2020 - IEEE Standard for
Local and Metropolitan Area Networks--Port-Based Network Local and Metropolitan Area Networks--Port-Based Network
Access Control", February 2020, Access Control", February 2020,
<https://standards.ieee.org/standard/802_1X-2020.html>. <https://standards.ieee.org/standard/802_1X-2020.html>.
[IMA] and , "Integrity Measurement Architecture", June 2019,
<https://sourceforge.net/p/linux-ima/wiki/Home/>.
[LLDP] IEEE Computer Society, "802.1AB-2016 - IEEE Standard for [LLDP] IEEE Computer Society, "802.1AB-2016 - IEEE Standard for
Local and metropolitan area networks - Station and Media Local and metropolitan area networks - Station and Media
Access Control Connectivity Discovery", March 2016, Access Control Connectivity Discovery", March 2016,
<https://standards.ieee.org/standard/802_1AB-2016.html>. <https://standards.ieee.org/standard/802_1AB-2016.html>.
[NetEq] Trusted Computing Group, "TCG Guidance for Securing [NetEq] Trusted Computing Group, "TCG Guidance for Securing
Network Equipment, Version 1.0, Revision 29", January Network Equipment, Version 1.0, Revision 29", January
2018, <https://trustedcomputinggroup.org/resource/tcg- 2018, <https://trustedcomputinggroup.org/resource/tcg-
guidance-securing-network-equipment/>. guidance-securing-network-equipment/>.
skipping to change at page 44, line 36 skipping to change at page 43, line 20
[TPM2.0] Trusted Computing Group, "Trusted Platform Module Library [TPM2.0] Trusted Computing Group, "Trusted Platform Module Library
Specification, Family "2.0", Level 00, Revision 01.59", Specification, Family "2.0", Level 00, Revision 01.59",
November 2019, November 2019,
<https://trustedcomputinggroup.org/resource/tpm-library- <https://trustedcomputinggroup.org/resource/tpm-library-
specification/>. specification/>.
Authors' Addresses Authors' Addresses
Guy Fedorkow (editor) Guy Fedorkow (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive
Westford, Massachusetts 01886
United States of America United States of America
Email: gfedorkow@juniper.net Email: gfedorkow@juniper.net
Eric Voit Eric Voit
Cisco Systems, Inc. Cisco Systems
United States of America
Email: evoit@cisco.com Email: evoit@cisco.com
Jessica Fitzgerald-McKay Jessica Fitzgerald-McKay
National Security Agency National Security Agency
9800 Savage Road
Ft. Meade, Maryland 20755
United States of America United States of America
Email: jmfitz2@nsa.gov Email: jmfitz2@nsa.gov
 End of changes. 105 change blocks. 
364 lines changed or deleted 350 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/