draft-ietf-rats-tpm-based-network-device-attest-02.txt   draft-ietf-rats-tpm-based-network-device-attest-03.txt 
RATS Working Group G. Fedorkow, Ed. RATS Working Group G. Fedorkow, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Informational E. Voit Intended status: Informational E. Voit
Expires: January 14, 2021 Cisco Systems, Inc. Expires: February 14, 2021 Cisco Systems, Inc.
J. Fitzgerald-McKay J. Fitzgerald-McKay
National Security Agency National Security Agency
July 13, 2020 August 13, 2020
TPM-based Network Device Remote Integrity Verification TPM-based Network Device Remote Integrity Verification
draft-ietf-rats-tpm-based-network-device-attest-02 draft-ietf-rats-tpm-based-network-device-attest-03
Abstract Abstract
This document describes a workflow for remote attestation of the This document describes a workflow for remote attestation of the
integrity of network devices. integrity of firmware and software installed on network devices that
contain Trusted Platform Modules [TPM].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021. This Internet-Draft will expire on February 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Document Organization . . . . . . . . . . . . . . . . . . 4 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4
1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Description of Remote Integrity Verification (RIV) . . . 5 1.4. Description of Remote Integrity Verification (RIV) . . . 5
1.5. Solution Requirements . . . . . . . . . . . . . . . . . . 7 1.5. Solution Requirements . . . . . . . . . . . . . . . . . . 7
1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8 1.6.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8
2.1. RIV Software Configuration Attestation using TPM . . . . 8 2.1. RIV Software Configuration Attestation using TPM . . . . 8
2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 9 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 10
2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 12 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 13 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 13
2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 15 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 15
2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 16 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 16
2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 17 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 17
3. Standards Components . . . . . . . . . . . . . . . . . . . . 17 3. Standards Components . . . . . . . . . . . . . . . . . . . . 17
3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 17 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 18
3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 18 3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 18
3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 18 3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 18
3.2. Reference Model for Challenge-Response . . . . . . . . . 19 3.2. Reference Model for Challenge-Response . . . . . . . . . 19
3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 21 3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 21
3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 21 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 21
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5.2. Prevention of Spoofing and Man-in-the-Middle Attacks . . 26
5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 27
5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 27
5.5. Other Trust Anchors . . . . . . . . . . . . . . . . . . . 28
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Layering Model for Network Equipment Attester and 8.1. Layering Model for Network Equipment Attester and
Verifier . . . . . . . . . . . . . . . . . . . . . . . . 29 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1.1. Why is OS Attestation Different? . . . . . . . . . . 31 8.1.1. Why is OS Attestation Different? . . . . . . . . . . 31
8.2. Implementation Notes . . . . . . . . . . . . . . . . . . 31 8.2. Implementation Notes . . . . . . . . . . . . . . . . . . 31
8.3. Root of Trust for Measurement . . . . . . . . . . . . . . 33 8.3. Root of Trust for Measurement . . . . . . . . . . . . . . 33
9. Informative References . . . . . . . . . . . . . . . . . . . 33 9. Informative References . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
skipping to change at page 3, line 18 skipping to change at page 3, line 28
[I-D.richardson-rats-usecases]. However, these documents do not [I-D.richardson-rats-usecases]. However, these documents do not
provide sufficient guidance for equipment vendors and network provide sufficient guidance for equipment vendors and network
operators to design, build, and deploy interoperable platforms. operators to design, build, and deploy interoperable platforms.
The intent of this document is to provide such guidance. It does The intent of this document is to provide such guidance. It does
this by outlining the Remote Integrity Verification (RIV) problem, this by outlining the Remote Integrity Verification (RIV) problem,
and then identifies elements that are necessary to get the complete, and then identifies elements that are necessary to get the complete,
scalable attestation procedure working with commercial networking scalable attestation procedure working with commercial networking
products such as routers, switches and firewalls. An underlying products such as routers, switches and firewalls. An underlying
assumption will be the availability within the device of a Trusted assumption will be the availability within the device of a Trusted
Platform Module (TPM) compliant cryptoprocessor to enable the remote Platform Module [TPM] compliant cryptoprocessor to enable the remote
trustworthy assessment of the device's software and hardware. trustworthy assessment of the device's software and hardware.
1.1. Terminology 1.1. Terminology
A number of terms are reused from [I-D.ietf-rats-architecture]. A number of terms are reused from [I-D.ietf-rats-architecture].
These include: Appraisal Policy for Attestation Result, Attestation These include: Appraisal Policy for Attestation Result, Attestation
Result, Attester, Endorser, Evidence, Relying Party, Verifier, Result, Attester, Endorser, Evidence, Relying Party, Verifier,
Verifier Owner. Verifier Owner.
Additionally, this document defines the following terms: Additionally, this document defines the following terms:
skipping to change at page 4, line 48 skipping to change at page 5, line 11
integrity, attestation can be used for asset management, integrity, attestation can be used for asset management,
vulnerability and compliance assessment, plus configuration vulnerability and compliance assessment, plus configuration
management. management.
As a part of a trusted supply chain, the RIV attestation workflow As a part of a trusted supply chain, the RIV attestation workflow
outlined in this document is intended to meet the following high- outlined in this document is intended to meet the following high-
level goals: level goals:
o Provable Device Identity - This specification requires that an o Provable Device Identity - This specification requires that an
attesting device includes a cryptographic identifier unique to attesting device includes a cryptographic identifier unique to
each device. Effectively this means that the TPM or equivalent each device. Effectively this means that the TPM must be so
cryptoprocessor must be so provisioned during the manufacturing provisioned during the manufacturing cycle.
cycle.
o Software Inventory - A key goal is to identify the software o Software Inventory - A key goal is to identify the software
release installed on the attesting device, and to provide evidence release installed on the attesting device, and to provide evidence
that the software stored within hasn't been altered that the software stored within hasn't been altered
o Verifiability - Verification of software and configuration of the o Verifiability - Verification of software and configuration of the
device shows that the software that was authorized for device shows that the software that was authorized for
installation by the administrator has actually been launched. installation by the administrator has actually been launched.
In addition, RIV is designed to operate in a centralized environment, In addition, RIV is designed to operate in a centralized environment,
such as with a central authority that manages and configures a number such as with a central authority that manages and configures a number
of network devices, or 'peer-to-peer', where network devices of network devices, or 'peer-to-peer', where network devices
independently verify one another to establish a trust relationship. independently verify one another to establish a trust relationship.
(See Section 3.3 below, and also (See Section 3.3 below, and also
[I-D.voit-rats-trusted-path-routing]) [I-D.voit-rats-trusted-path-routing])
1.4. Description of Remote Integrity Verification (RIV) 1.4. Description of Remote Integrity Verification (RIV)
Attestation requires two interlocking services between the Attester Attestation requires two interlocking services between the Attester
network device and the Verifier:: network device and the Verifier:
o Platform Identity, the mechanism providing trusted identity, can o Platform 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 Platform Identity, their network. As part of the mechanism for Platform Identity,
cryptographic proof of the identity of the manufacturer is also cryptographic proof of the identity of the manufacturer is also
provided. provided.
o Software Measurement is the mechanism that reports the state of o Software Measurement is the mechanism that reports the state of
skipping to change at page 6, line 14 skipping to change at page 6, line 21
2. Platform Identification refers to the mechanism assuring the 2. Platform Identification refers to the mechanism assuring the
Relying Party (ultimately, a network administrator) of the Relying Party (ultimately, a network administrator) of the
identity of devices that make up their network, and that their identity of devices that make up their network, and that their
manufacturers are known. manufacturers are known.
3. Software used to boot a platform can be described as a chain of 3. Software used to boot a platform can be described as a chain of
measurements, started by a Root of Trust for Measurement, that measurements, started by a Root of Trust for Measurement, that
normally ends when the system software is loaded. A measurement normally ends when the system software is loaded. A measurement
signifies the identity, integrity and version of each software signifies the identity, integrity and version of each software
component registered with an attesting device's TPM, so that the component registered with an attesting device's TPM [TPM], so
subsequent appraisal stage can determine if the software that the subsequent appraisal stage can determine if the software
installed is authentic, up-to-date, and free of tampering. installed is authentic, up-to-date, and free of tampering.
4. Conveyance of Evidence reliably transports at least the minimum 4. Conveyance of Evidence reliably transports at least the minimum
amount of Evidence from Attester to a Verifier to allow a amount of Evidence from Attester to a Verifier to allow a
management station to perform a meaningful appraisal in Step 5. management station to perform a meaningful appraisal in Step 5.
The transport is typically carried out via a management network. The transport is typically carried out via a management network.
The channel must provide integrity and authenticity, and, in some The channel must provide integrity and authenticity, and, in some
use cases, may also require confidentiality. use cases, may also require confidentiality.
5. Finally, Appraisal of Evidence occurs. As the Verifier and 5. Finally, Appraisal of Evidence occurs. As the Verifier and
skipping to change at page 6, line 50 skipping to change at page 7, line 9
coupled with careful supply-chain management by the manufacturer. coupled with careful supply-chain management by the manufacturer.
The DevID certificate contains a statement by the manufacturer that The DevID certificate contains a statement by the manufacturer that
establishes the identity of the device as it left the factory. Some establishes the identity of the device as it left the factory. Some
applications with a more-complex post-manufacture supply chain (e.g. applications with a more-complex post-manufacture supply chain (e.g.
Value Added Resellers), or with different privacy concerns, may want Value Added Resellers), or with different privacy concerns, may want
to use alternative mechanisms for platform authentication (for to use alternative mechanisms for platform authentication (for
example, TCG Platform Certificates [Platform-Certificates]). example, TCG Platform Certificates [Platform-Certificates]).
1. Platform Attestation provides evidence of configuration of 1. Platform Attestation provides evidence of configuration of
software elements present in the device. This form of software elements present in the device. This form of
attestation can be implemented with TPM PCR, Quote and Log attestation can be implemented with TPM Platform Configuration
mechanisms, which provide an authenticated mechanism to report Registers (PCRs), Quote and Log mechanisms, which provide an
what software was started on the device through the boot cycle. authenticated mechanism to report what software was started on
the device through the boot cycle. Successful attestation
Successful attestation requires an unbroken chain from a boot- requires an unbroken chain from a boot-time root of trust through
time root of trust through all layers of software needed to bring all layers of software needed to bring the device to an
the device to an operational state. operational state, in which each stage measures components of the
next stage, updates the attestation log, and extends hashes into
a PCR. The TPM can then report the hashes of all the measured
hashes as a signed Quote (see [TPM] for many more details).
2. Reference Integrity Measurements must be conveyed from the 2. Reference Integrity Measurements must be conveyed from the
Endorser (the entity accepted as the software authority, often Endorser (the entity accepted as the software authority, often
the manufacturer for embedded systems) to the system in which the manufacturer for embedded systems) to the system in which
verification will take place verification will take place
1.5. Solution Requirements 1.5. Solution Requirements
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
skipping to change at page 7, line 41 skipping to change at page 8, line 4
1.6. Scope 1.6. Scope
Remote Attestation is a very general problem that could apply to most Remote Attestation is a very general problem that could apply to most
network-connected computing devices. However, this document includes network-connected computing devices. However, this document includes
several assumptions that limit the scope to Network Equipment (e.g. several assumptions that limit the scope to Network Equipment (e.g.
routers, switches and firewalls): routers, switches and firewalls):
o This solution is for use in non-privacy-preserving applications o This solution is for use in non-privacy-preserving applications
(for example, networking, Industrial IoT), avoiding the need for a (for example, networking, Industrial IoT), avoiding the need for a
Privacy Certificate Authority for attestation keys Privacy Certificate Authority for attestation keys
[AIK-Enrollment] or TCG Platform Certificates [AIK-Enrollment] or TCG Platform Certificates
[Platform-Certificates] [Platform-Certificates]
o This document assumes network protocols that are common in o This document assumes network protocols that are common in
networking equipment such as YANG [RFC7950] and NETCONF [RFC6241], networking equipment such as YANG [RFC7950] and NETCONF [RFC6241],
but not generally used in other applications. but not generally used in other applications.
o The approach outlined in this document mandates the use of TPM 1.2 o The approach outlined in this document mandates the use of a
or TPM 2.0. Other roots of trust could be used with the same compliant TPM [TPM]. Other roots of trust could be used with the
information flow, although different data structures would likely same information flow, although they're out of scope for this
be called for. document.
1.6.1. Out of Scope 1.6.1. Out of Scope
o Run-Time Attestation: Run-time attestation of Linux or other o Run-Time Attestation: Run-time attestation of Linux or other
multi-threaded operating system processes considerably expands the multi-threaded operating system processes considerably expands the
scope of the problem. Many researchers are working on that scope of the problem. Many researchers are working on that
problem, but this document defers the run-time attestation problem, but this document defers the run-time attestation
problem. problem.
o Multi-Vendor Embedded Systems: Additional coordination would be o Multi-Vendor Embedded Systems: Additional coordination would be
skipping to change at page 15, line 50 skipping to change at page 16, line 7
sign a TPM Quote. This convention is described in TCG Guidance sign a TPM Quote. This convention is described in TCG Guidance
for Securing Network Equipment [NetEq]. For network equipment, for Securing Network Equipment [NetEq]. For network equipment,
which is generally non-privacy-sensitive, shipping a device with which is generally non-privacy-sensitive, shipping a device with
both an IDevID and an IAK already provisioned substantially both an IDevID and an IAK already provisioned substantially
simplifies initial startup. Privacy-sensitive applications may simplifies initial startup. Privacy-sensitive applications may
use the TCG Platform Certificate and additional procedures to use the TCG Platform Certificate and additional procedures to
install identity credentials on the platform after manufacture. install identity credentials on the platform after manufacture.
o The product is equipped with a Root of Trust for Measurement, Root o The product is equipped with a Root of Trust for Measurement, Root
of Trust for Storage and Root of Trust for Reporting (as defined of Trust for Storage and Root of Trust for Reporting (as defined
in [GloPlaRoT]) that are capable of conforming to the TCG Trusted in [SP800-155]) that are capable of conforming to the TCG Trusted
Attestation Protocol (TAP) Information Model [TAP]. Attestation Protocol (TAP) Information Model [TAP].
o The vendor will ship Reference Integrity Measurements (i.e., o The vendor will ship Reference Integrity Measurements (i.e.,
known-good measurements) in the form of signed CoSWID tags known-good measurements) in the form of signed CoSWID tags
[I-D.ietf-sacm-coswid], [SWID], as described in TCG Reference [I-D.ietf-sacm-coswid], [SWID], as described in TCG Reference
Integrity Measurement Manifest Information Model [RIM]. Integrity Measurement Manifest Information Model [RIM].
2.4.1. Reference Integrity Manifests (RIMs) 2.4.1. Reference Integrity Manifests (RIMs)
[I-D.ietf-rats-yang-tpm-charra] focuses on collecting and [I-D.ietf-rats-yang-tpm-charra] focuses on collecting and
skipping to change at page 24, line 13 skipping to change at page 24, line 13
o Keys may be compromised o Keys may be compromised
o A counterfeit device may attempt to impersonate (spoof) a known o A counterfeit device may attempt to impersonate (spoof) a known
authentic device authentic device
o Man-in-the-middle attacks may be used by a counterfeit device to o Man-in-the-middle attacks may be used by a counterfeit device to
attempt to deliver responses that originate in an actual authentic attempt to deliver responses that originate in an actual authentic
device device
o Replay attacks may be attempted by a compromised device o Replay attacks may be attempted by a compromised device
5.1. Keys Used in RIV
Trustworthiness of RIV attestation depends strongly on the validity Trustworthiness of RIV attestation depends strongly on the validity
of keys used for identity and attestation reports. RIV takes full of keys used for identity and attestation reports. RIV takes full
advantage of TPM capabilities to ensure that results can be trusted. advantage of TPM capabilities to ensure that results can be trusted.
Two sets of keys are relevant to RIV attestation Two sets of keys are relevant to RIV attestation
o A DevID key is used to certify the identity of the device in which o A DevID key is used to certify the identity of the device in which
the TPM is installed. the TPM is installed.
o An Attestation Key (AK) key signs attestation reports, (called o An Attestation Key (AK) key signs attestation reports, (called
skipping to change at page 25, line 38 skipping to change at page 25, line 38
attestation session begins. Security of this process derives from attestation session begins. Security of this process derives from
TLS security, with the DevID providing proof that the TLS session TLS security, with the DevID providing proof that the TLS session
terminates on the intended device. [RFC8446]. terminates on the intended device. [RFC8446].
Evidence of software integrity is delivered in the form of a quote Evidence of software integrity is delivered in the form of a quote
signed by the TPM itself. Because the contents of the quote are signed by the TPM itself. Because the contents of the quote are
signed inside the TPM, any external modification (including signed inside the TPM, any external modification (including
reformatting to a different data format) will be detected as reformatting to a different data format) will be detected as
tampering. tampering.
Requiring results of attestation of the operating software to be
signed by a key known only to the TPM also removes the need to trust
the device's operating software (beyond the first measurement; see
below); any changes to the quote, generated and signed by the TPM
itself, made by malicious device software, or in the path back to the
verifier, will invalidate the signature on the quote.
A critical feature of the YANG model described in A critical feature of the YANG model described in
[I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data
structures in their native format, without requiring any changes to structures in their native format, without requiring any changes to
the structures as they were signed and delivered by the TPM. While the structures as they were signed and delivered by the TPM. While
alternate methods of conveying TPM quotes could compress out alternate methods of conveying TPM quotes could compress out
redundant information, or add an additional layer of signing using redundant information, or add an additional layer of signing using
external keys, the important part is to preserve the TPM signing, so external keys, the important part is to 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
Prevention of spoofing attacks against attestation systems is also Prevention of spoofing attacks against attestation systems is also
important. There are two cases to consider: important. There are two cases to consider:
o The entire device could be spoofed, that is, when the Verifier o The entire device could be spoofed, that is, when the Verifier
goes to verify a specific device, it might be redirected to a goes to verify a specific device, it might be redirected to a
different device. Use of the 802.1AR identity in the TPM ensures different device. Use of the 802.1AR identity in the TPM ensures
that the Verifier's TLS session is in fact terminating on the that the Verifier's TLS session is in fact terminating on the
right device. right device.
o A compromised device could respond with a spoofed attestation o A compromised device could respond with a spoofed attestation
skipping to change at page 26, line 38 skipping to change at page 27, line 5
by the CA to be an Attestation key?] by the CA to be an Attestation key?]
These two keys and certificates are used together: These two keys and certificates are used together:
o The DevID is used to validate a TLS connection terminating on the o The DevID is used to validate a TLS connection terminating on the
device with a known serial number. device with a known serial number.
o The AK is used to sign attestation quotes, providing proof that o The AK is used to sign attestation quotes, providing proof that
the attestation evidence comes from the same device. the attestation evidence comes from the same device.
5.3. Replay Attacks
Replay attacks, where results of a previous attestation are submitted Replay attacks, where results of a previous attestation are submitted
in response to subsequent requests, are usually prevented by in response to subsequent requests, are usually prevented by
inclusion of a nonce in the request to the TPM for a quote. Each inclusion of a nonce in the request to the TPM for a quote. Each
request from the Verifier includes a new random number (a nonce). request from the Verifier includes a new random number (a nonce).
The resulting quote signed by the TPM contains the same nonce, The resulting quote signed by the TPM contains the same nonce,
allowing the verifier to determine freshness, i.e., that the allowing the verifier to determine freshness, i.e., that the
resulting quote was generated in response to the verifier's specific resulting quote was generated in response to the verifier's specific
request. Time-Based Uni-directional Attestation request. Time-Based Uni-directional Attestation
[I-D.birkholz-rats-tuda] provides an alternate mechanism to verify [I-D.birkholz-rats-tuda] provides an alternate mechanism to verify
freshness without requiring a request/response cycle. freshness without requiring a request/response cycle.
Requiring results of attestation of the operating software to be 5.4. Owner-Signed Keys
signed by a key known only to the TPM also removes the need to trust
the device's operating software (beyond the first measurement; see
below); any changes to the quote, generated and signed by the TPM
itself, made by malicious device software, or in the path back to the
verifier, will invalidate the signature on the quote.
Although RIV recommends that device manufacturers pre-provision Although RIV recommends that device manufacturers pre-provision
devices with easily-verified DevID and AK certs, use of those devices with easily-verified DevID and AK certs, use of those
credentials is not mandatory. IEEE 802.1AR incorporates the idea of credentials is not mandatory. IEEE 802.1AR incorporates the idea of
an Initial Device ID (IDevID), provisioned by the manufacturer, and a an Initial Device ID (IDevID), provisioned by the manufacturer, and a
Local Device ID (LDevID) provisioned by the owner of the device. RIV Local Device ID (LDevID) provisioned by the owner of the device. RIV
extends that concept by defining an Initial Attestation Key (IAK) and extends that concept by defining an Initial Attestation Key (IAK) and
Local Attestation Key (LAK) with the same properties. Local Attestation Key (LAK) with the same properties.
Device owners can use any method to provision the Local credentials. Device owners can use any method to provision the Local credentials.
skipping to change at page 27, line 43 skipping to change at page 28, line 7
installation of the Local keys can only be done by some process that installation of the Local keys can only be done by some process that
runs before the device is configured for network operation. runs before the device is configured for network operation.
On the other end of the device life cycle, provision should be made On the other end of the device life cycle, provision should be made
to wipe Local keys when a device is decommissioned, to indicate that to wipe Local keys when a device is decommissioned, to indicate that
the device is no longer owned by the enterprise. The manufacturer's the device is no longer owned by the enterprise. The manufacturer's
Initial identity keys must be preserved, as they contain no Initial identity keys must be preserved, as they contain no
information that's not already printed on the device's serial number information that's not already printed on the device's serial number
plate. plate.
5.5. Other Trust Anchors
In addition to trustworthy provisioning of keys, RIV depends on other In addition to trustworthy provisioning of keys, RIV depends on other
trust anchors. (See [GloPlaRoT] for definitions of Roots of Trust.) trust anchors. (See [SP800-155] for definitions of Roots of Trust.)
o Secure identity depends on mechanisms to prevent per-device secret o Secure identity depends on mechanisms to prevent per-device secret
keys from being compromised. The TPM provides this capability as keys from being compromised. The TPM provides this capability as
a Root of Trust for Storage a Root of Trust for Storage
o Attestation depends on an unbroken chain of measurements, starting o Attestation depends on an unbroken chain of measurements, starting
from the very first measurement. That first measurement is made from the very first measurement. That first measurement is made
by code called the Root of Trust for Measurement, typically done by code called the Root of Trust for Measurement, typically done
by trusted firmware stored in boot flash. Mechanisms for by trusted firmware stored in boot flash. Mechanisms for
maintaining the trustworthiness of the RTM are out of scope for maintaining the trustworthiness of the RTM are out of scope for
skipping to change at page 28, line 25 skipping to change at page 28, line 39
RIV also depends on reliable reference measurements, as expressed by RIV also depends on reliable reference measurements, as expressed by
the RIM [RIM]. The definition of trust procedures for RIMs is out of the RIM [RIM]. The definition of trust procedures for RIMs is out of
scope for RIV, and the device owner is free to use any policy to scope for RIV, and the device owner is free to use any policy to
validate a set of reference measurements. RIMs may be conveyed out- validate a set of reference measurements. RIMs may be conveyed out-
of-band or in-band, as part of the attestation process (see of-band or in-band, as part of the attestation process (see
Section 3.1.3). But for embedded devices, where software is usually Section 3.1.3). But for embedded devices, where software is usually
shipped as a self-contained package, RIMs signed by the manufacturer shipped as a self-contained package, RIMs signed by the manufacturer
and delivered in-band may be more convenient for the device owner. and delivered in-band may be more convenient for the device owner.
The validity of RIV attestation results is also influenced by
procedures used to create reference measurements:
o While the RIM itself is signed, supply-chains must be carefully
scrutinized to ensure that the values are not subject to
unexpected manipulation prior to signing. Insider-attacks against
code bases and build chains are particularly hard to spot.
o Designers must guard against hash collision attacks. Reference
measurements often give hashes for large objects of indeterminate
size; if one of the measured objects can be replaced with an
implant engineered to produce the same hash, RIV will be unable to
detect the substitution. TPM1.2 uses SHA-1 hashes only, which
have been shown to be susceptible to collision attack. TPM2.0
will produce quotes with SHA-256, which so far has resisted such
attacks, and consequently is preferred.
6. Conclusion 6. Conclusion
TCG technologies can play an important part in the implementation of TCG technologies can play an important part in the implementation of
Remote Integrity Verification. Standards for many of the components Remote Integrity Verification. Standards for many of the components
needed for implementation of RIV already exist: needed for implementation of RIV already exist:
o Platform identity can be based on IEEE 802.1AR Device identity, o Platform identity can be based on IEEE 802.1AR Device identity,
coupled with careful supply-chain management by the manufacturer. coupled with careful supply-chain management by the manufacturer.
o Complex supply chains can be certified using TCG Platform o Complex supply chains can be certified using TCG Platform
skipping to change at page 33, line 22 skipping to change at page 33, line 22
Figure 8: Component Status Figure 8: Component Status
8.3. Root of Trust for Measurement 8.3. Root of Trust for Measurement
The measurements needed for attestation require that the device being The measurements needed for attestation require that the device being
attested is equipped with a Root of Trust for Measurement, i.e., some attested is equipped with a Root of Trust for Measurement, i.e., some
trustworthy mechanism that can compute the first measurement in the trustworthy mechanism that can compute the first measurement in the
chain of trust required to attest that each stage of system startup chain of trust required to attest that each stage of system startup
is verified, a Root of Trust for Storage (i.e., the TPM PCRs) to 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 the record the results, and a Root of Trust for Reporting to report the
results [TCGRoT], [GloPlaRoT]. results [TCGRoT], [SP800-155].
While there are many complex aspects of a Root of Trust, two aspects While there are many complex aspects of a Root of Trust, two aspects
that are important in the case of attestation are: that are important in the case of attestation are:
o The first measurement computed by the Root of Trust for o The first measurement computed by the Root of Trust for
Measurement, and stored in the TPM's Root of Trust for Storage, is Measurement, and stored in the TPM's Root of Trust for Storage, is
presumed to be correct. presumed to be correct.
o There must not be a way to reset the Root of Trust for Storage o There must not be a way to reset the Root of Trust for Storage
without re-entering the Root of Trust for Measurement code. without re-entering the Root of Trust for Measurement code.
The first measurement must be computed by code that is implicitly The first measurement must be computed by code that is implicitly
trusted; if that first measurement can be subverted, none of the trusted; if that first measurement can be subverted, none of the
remaining measurements can be trusted. (See [NIST-SP-800-155]) remaining measurements can be trusted. (See [NIST-SP-800-155])
9. Informative References 9. Informative References
[AIK-Enrollment] [AIK-Enrollment]
Trusted Computing Group, "TCG Infrastructure Working Trusted Computing Group, "TCG Infrastructure Working Group
GroupA 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/wp-content/uploads/ <https://trustedcomputinggroup.org/resource/tcg-
IWG_CMC_Profile_Cert_Enrollment_v1_r7.pdf>. infrastructure-working-group-a-cmc-profile-for-aik-
certificate-enrollment/>.
[Canonical-Event-Log] [Canonical-Event-Log]
Trusted Computing Group, "DRAFT Canonical Event Log Format Trusted Computing Group, "DRAFT Canonical Event Log Format
Version: 1.0, Revision: .12", October 2018. Version: 1.0, Revision: .12", October 2018.
[EFI-TPM] Trusted Computing Group, "TCG EFI Platform Specification [EFI-TPM] Trusted Computing Group, "TCG EFI Platform Specification
for TPM Family 1.1 or 1.2, Specification Version 1.22, for TPM Family 1.1 or 1.2, Specification Version 1.22,
Revision 15", January 2014, Revision 15", January 2014,
<https://trustedcomputinggroup.org/wp-content/uploads/EFI- <https://trustedcomputinggroup.org/resource/tcg-efi-
Protocol-Specification-rev13-160330final.pdf>. platform-specification/>.
[GloPlaRoT]
GlobalPlatform Technology, "Root of Trust Definitions and
Requirements Version 1.1", June 2018,
<https://globalplatform.org/specs-library/globalplatform-
root-of-trust-definitions-and-requirements/>.
[I-D.birkholz-rats-reference-interaction-model] [I-D.birkholz-rats-reference-interaction-model]
Birkholz, H., Eckel, M., Newton, C., and L. Chen, Birkholz, H., Eckel, M., Newton, C., and L. Chen,
"Reference Interaction Models for Remote Attestation "Reference Interaction Models for Remote Attestation
Procedures", draft-birkholz-rats-reference-interaction- Procedures", draft-birkholz-rats-reference-interaction-
model-03 (work in progress), July 2020. model-03 (work in progress), July 2020.
[I-D.birkholz-rats-tuda] [I-D.birkholz-rats-tuda]
Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
"Time-Based Uni-Directional Attestation", draft-birkholz- "Time-Based Uni-Directional Attestation", draft-birkholz-
rats-tuda-02 (work in progress), March 2020. rats-tuda-03 (work in progress), July 2020.
[I-D.birkholz-yang-swid] [I-D.birkholz-yang-swid]
Birkholz, H., "Software Inventory YANG module based on Birkholz, H., "Software Inventory YANG module based on
Software Identifiers", draft-birkholz-yang-swid-02 (work Software Identifiers", draft-birkholz-yang-swid-02 (work
in progress), October 2018. in progress), October 2018.
[I-D.ietf-rats-architecture] [I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", W. Pan, "Remote Attestation Procedures Architecture",
draft-ietf-rats-architecture-05 (work in progress), July draft-ietf-rats-architecture-05 (work in progress), July
skipping to change at page 35, line 43 skipping to change at page 35, line 38
[IMA] and , "Integrity Measurement Architecture", June 2019, [IMA] and , "Integrity Measurement Architecture", June 2019,
<https://sourceforge.net/p/linux-ima/wiki/Home/>. <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", January 2018, Network Equipment, Version 1.0, Revision 29", January
<https://trustedcomputinggroup.org/wp-content/uploads/ 2018, <https://trustedcomputinggroup.org/resource/tcg-
TCG_Guidance_for_Securing_NetEq_1_0r29.pdf>. guidance-securing-network-equipment/>.
[NIST-IR-8060] [NIST-IR-8060]
National Institute for Standards and Technology, National Institute for Standards and Technology,
"Guidelines for the Creation of Interoperable Software "Guidelines for the Creation of Interoperable Software
Identification (SWID) Tags", April 2016, Identification (SWID) Tags", April 2016,
<https://nvlpubs.nist.gov/nistpubs/ir/2016/ <https://nvlpubs.nist.gov/nistpubs/ir/2016/
NIST.IR.8060.pdf>. NIST.IR.8060.pdf>.
[NIST-SP-800-155] [NIST-SP-800-155]
National Institute for Standards and Technology, "BIOS National Institute for Standards and Technology, "BIOS
Integrity Measurement Guidelines (Draft)", December 2011, Integrity Measurement Guidelines (Draft)", December 2011,
<https://csrc.nist.gov/csrc/media/publications/sp/800- <https://csrc.nist.gov/csrc/media/publications/sp/800-
155/draft/documents/draft-sp800-155_dec2011.pdf>. 155/draft/documents/draft-sp800-155_dec2011.pdf>.
[PC-Client-BIOS-TPM-1.2] [PC-Client-BIOS-TPM-1.2]
Trusted Computing Group, "TCG PC Client Specific Trusted Computing Group, "TCG PC Client Specific
Implementation Specification for Conventional BIOS, Implementation Specification for Conventional BIOS,
Specification Version 1.21 Errata, Revision 1.00", Specification Version 1.21 Errata, Revision 1.00",
February 2012, <https://www.trustedcomputinggroup.org/wp- February 2012,
content/uploads/TCG_PCClientImplementation_1-21_1_00.pdf>. <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.04", June 2019,
<https://trustedcomputinggroup.org/pc-client-specific- <https://trustedcomputinggroup.org/pc-client-specific-
platform-firmware-profile-specification>. platform-firmware-profile-specification>.
[PC-Client-RIM] [PC-Client-RIM]
Trusted Computing Group, "DRAFT: TCG PC Client Reference Trusted Computing Group, "DRAFT: TCG PC Client Reference
Integrity Manifest Specification, v.09", December 2019, Integrity Manifest Specification, v.09", December 2019,
<https://trustedcomputinggroup.org/xx>. <https://trustedcomputinggroup.org/wp-content/uploads/
TCG_PC_Client_RIM_r0p15_15june2020.pdf>.
[Platform-Certificates] [Platform-Certificates]
Trusted Computing Group, "DRAFT: TCG Platform Attribute Trusted Computing Group, "TCG Platform Attribute
Credential Profile, Specification Version 1.0, Revision Credential Profile, Specification Version 1.0, Revision
15, 07 December 2017", December 2017. 16", January 2018,
<https://trustedcomputinggroup.org/resource/tcg-platform-
attribute-credential-profile/>.
[Platform-DevID-TPM-2.0] [Platform-DevID-TPM-2.0]
Trusted Computing Group, "DRAFT: TPM Keys for Platform Trusted Computing Group, "DRAFT: TPM Keys for Platform
DevID for TPM2, Specification Version 0.7, Revision 0", DevID for TPM2, Specification Version 0.7, Revision 0",
October 2018. October 2018.
[Platform-ID-TPM-1.2] [Platform-ID-TPM-1.2]
Trusted Computing Group, "TPM Keys for Platform Identity Trusted Computing Group, "TPM Keys for Platform Identity
for TPM 1.2, Specification Version 1.0, Revision 3", for TPM 1.2, Specification Version 1.0, Revision 3",
August 2015, <https://trustedcomputinggroup.org/wp- August 2015, <https://trustedcomputinggroup.org/resource/
content/uploads/ tpm-keys-for-platform-identity-for-tpm-1-2-2/>.
TPM_Keys_for_Platform_Identity_v1_0_r3_Final.pdf>.
[Provisioning-TPM-2.0] [Provisioning-TPM-2.0]
Trusted Computing Group, "TCG TPM v2.0 Provisioning Trusted Computing Group, "TCG TPM v2.0 Provisioning
Guidance", March 2015, <https://trustedcomputinggroup.org/ Guidance, Version 1.0, Revision 1.0", March 2015,
wp-content/uploads/TCG-TPM-v2.0-Provisioning-Guidance- <https://trustedcomputinggroup.org/wp-content/uploads/TCG-
Published-v1r1.pdf>. TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
skipping to change at page 37, line 38 skipping to change at page 37, line 44
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
Touch Provisioning (SZTP)", RFC 8572, Touch Provisioning (SZTP)", RFC 8572,
DOI 10.17487/RFC8572, April 2019, DOI 10.17487/RFC8572, April 2019,
<https://www.rfc-editor.org/info/rfc8572>. <https://www.rfc-editor.org/info/rfc8572>.
[RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity [RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity
Manifest Information Model", June 2019, Manifest Information Model", June 2019,
<https://trustedcomputinggroup.org/wp-content/uploads/ <https://trustedcomputinggroup.org/wp-content/uploads/
TCG_RIM_Model_v1-r13_2feb20.pdf>. TCG_RIM_Model_v1-r13_2feb20.pdf>.
[SP800-155]
National Institute of Standards and Technology, "BIOS
Integrity Measurement Guidelines (Draft)", December 2011,
<https://csrc.nist.gov/csrc/media/publications/sp/800-
155/draft/documents/draft-sp800-155_dec2011.pdf>.
[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, "DRAFT: TCG Trusted Attestation [TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol
Protocol (TAP) Information Model for TPM Families 1.2 and (TAP) Information Model for TPM Families 1.2 and 2.0 and
2.0 and DICE Family 1.0, Version 1.0, Revision 0.29", DICE Family 1.0, Version 1.0, Revision 0.36", October
October 2018. 2018, <https://trustedcomputinggroup.org/resource/tcg-tap-
information-model/>.
[TCGRoT] Trusted Computing Group, "TCG Roots of Trust [TCGRoT] Trusted Computing Group, "DRAFT: TCG Roots of Trust
Specification", October 2018, Specification", October 2018,
<https://trustedcomputinggroup.org/wp-content/uploads/ <https://trustedcomputinggroup.org/wp-content/uploads/
TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf>. TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf>.
[TPM] ISO/IEC JTC 1 Information technology, "ISO/IEC
11889-1:2015 Information technology -- Trusted platform
module library -- Part 1: Architecture", August 2015,
<https://www.iso.org/standard/66510.html>.
Authors' Addresses Authors' Addresses
Guy Fedorkow (editor) Guy Fedorkow (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
US US
Email: gfedorkow@juniper.net Email: gfedorkow@juniper.net
Eric Voit Eric Voit
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 41 change blocks. 
69 lines changed or deleted 116 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/