draft-ietf-rats-tpm-based-network-device-attest-05.txt   draft-ietf-rats-tpm-based-network-device-attest-06.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: April 29, 2021 Cisco Systems, Inc. Expires: June 10, 2021 Cisco Systems, Inc.
J. Fitzgerald-McKay J. Fitzgerald-McKay
National Security Agency National Security Agency
October 26, 2020 December 07, 2020
TPM-based Network Device Remote Integrity Verification TPM-based Network Device Remote Integrity Verification
draft-ietf-rats-tpm-based-network-device-attest-05 draft-ietf-rats-tpm-based-network-device-attest-06
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 April 29, 2021. This Internet-Draft will expire on June 10, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 26 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 26
5.2. Prevention of Spoofing and Man-in-the-Middle Attacks . . 28 5.2. Prevention of Spoofing and Man-in-the-Middle Attacks . . 28
5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29 5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29
5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 29 5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 29
5.5. Other Factors for Trustworthy Operation . . . . . . . . . 30 5.5. Other Factors for Trustworthy Operation . . . . . . . . . 30
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 32 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.2. Root of Trust for Measurement . . . . . . . . . . . . . . 33 9.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 32
8.3. Layering Model for Network Equipment Attester and 9.2. Root of Trust for Measurement . . . . . . . . . . . . . . 33
9.3. Layering Model for Network Equipment Attester and
Verifier . . . . . . . . . . . . . . . . . . . . . . . . 34 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 34
8.4. Implementation Notes . . . . . . . . . . . . . . . . . . 36 9.4. Implementation Notes . . . . . . . . . . . . . . . . . . 36
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Normative References . . . . . . . . . . . . . . . . . . 37 10.1. Normative References . . . . . . . . . . . . . . . . . . 37
9.2. Informative References . . . . . . . . . . . . . . . . . 40 10.2. Informative References . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 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
skipping to change at page 6, line 19 skipping to change at page 6, line 19
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 recording a chain
of measurements, anchored at the start by a Root of Trust for of measurements, anchored at the start by a Root of Trust for
Measurement (see Section 8.2), each measuring the next stage, that Measurement (see Section 9.2), each measuring the next stage, 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 Attester's TPM [TPM1.2], [TPM2.0], so component registered with an Attester's TPM [TPM1.2], [TPM2.0], so
that a subsequent verification stage can determine if the software that a subsequent verification 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.
RIV includes several major processes: RIV includes several major processes:
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
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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 measures components
of the next stage, updates the attestation log, and extends of the next stage, updates the attestation log, and extends
hashes into a PCR. The TPM can then report the hashes of all the hashes into a PCR. The TPM can then report the hashes of all the
measured hashes as signed evidence called a Quote (see measured hashes as signed evidence called a Quote (see
Section 8.1 for an overview of TPM operation, or [TPM1.2] and Section 9.1 for an overview of TPM operation, or [TPM1.2] and
[TPM2.0] for many more details). [TPM2.0] for many more details).
3. Signed Reference Values (aka Reference Integrity Measurements) 3. Signed Reference Values (aka Reference Integrity Measurements)
must be conveyed from the Reference Value Provider (the entity must be conveyed from the Reference Value Provider (the entity
accepted as the software authority, often the manufacturer for accepted as the software authority, often the manufacturer for
embedded systems) to the Verifier. embedded systems) to the Verifier.
1.5. Solution Requirements 1.5. Solution Requirements
Remote Integrity Verification must address the "Lying Endpoint" Remote Integrity Verification must address the "Lying Endpoint"
skipping to change at page 19, line 24 skipping to change at page 19, line 24
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 8.1). Section 9.1).
There are multiple event log formats which may be supported as viable There are multiple event log formats which may be supported as viable
formats of Evidence between the Attester and Verifier: formats of Evidence between the Attester and Verifier:
o IMA Event log file exports [IMA] o IMA Event log file exports [IMA]
o TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM o TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM
Family 1.1 or 1.2, Section 7) [EFI-TPM] Family 1.1 or 1.2, Section 7) [EFI-TPM]
o TCG Canonical Event Log [Canonical-Event-Log] o TCG Canonical Event Log [Canonical-Event-Log]
skipping to change at page 22, line 5 skipping to change at page 22, line 5
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 8.1 of [I-D.birkholz-rats-reference-interaction-model].
Event times shown correspond to the time types described within Event times shown correspond to the time types described within
Appendix A of [I-D.ietf-rats-architecture]: Appendix A of [I-D.ietf-rats-architecture]:
.---------. .--------------------------. .----------. .--------------------------.
| Atteser | | Relying Party / Verifier | | Attester | | Relying Party / Verifier |
'---------' '--------------------------' '--------- ' '--------------------------'
time(VG) | time(VG) |
valueGeneration(targetEnvironment) | valueGeneration(targetEnvironment) |
| => claims | | => claims |
| | | |
| <-----------requestEvidence(nonce, PcrSelection)----time(NS) | <-----------requestEvidence(nonce, PcrSelection)----time(NS)
| | | |
time(EG) | time(EG) |
evidenceGeneration(nonce, PcrSelection, collectedClaims) | evidenceGeneration(nonce, PcrSelection, collectedClaims) |
| => SignedPcrEvidence(nonce, PcrSelection) | | => SignedPcrEvidence(nonce, PcrSelection) |
| => LogEvidence(collectedClaims) | | => LogEvidence(collectedClaims) |
skipping to change at page 22, line 50 skipping to change at page 22, line 50
TCG TAP model (e.g., YANG Module for Basic Challenge-Response- TCG TAP model (e.g., YANG Module for Basic Challenge-Response-
based Remote Attestation Procedures based Remote Attestation Procedures
[I-D.ietf-rats-yang-tpm-charra]). [I-D.ietf-rats-yang-tpm-charra]).
o Step 3 (time(EG)): On the Attester, measured values are retrieved o Step 3 (time(EG)): On the Attester, measured values are retrieved
from the Attester's TPM. This requested PCR evidence, along with from the Attester's TPM. This requested PCR evidence, along with
the Verifier's nonce, called a Quote, is signed by the Attestation the Verifier's nonce, called a Quote, is signed by the Attestation
Key (AK) associated with the DevID. Quotes are retrieved Key (AK) associated with the DevID. Quotes are retrieved
according to TCG TAP Information Model [TAP]. At the same time, according to TCG TAP Information Model [TAP]. At the same time,
the Attester collects log evidence showing the values have been the Attester collects log evidence showing the values have been
extended into that PCR. Section 8.1 gives more detail on how this extended into that PCR. Section 9.1 gives more detail on how this
works. works.
o Step 4: Collected Evidence is passed from the Attester to the o Step 4: Collected Evidence is passed from the Attester to the
Verifier Verifier
o Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes o 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.
skipping to change at page 25, line 9 skipping to change at page 25, line 9
| | | | | | | | | |
| |<-------| | | | |<-------| | |
+------------+ Step 3 +------------+ / +------------+ Step 3 +------------+ /
Figure 6: Peer-to-Peer Attestation Information Flow Figure 6: 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
Network equipment, such as routers, switches and firewalls, has a key Network equipment, such as routers, switches and firewalls, has a key
role to play in guarding the privacy of individuals using the role to play in guarding the privacy of individuals using the
network. Network equipment generally adheres to several rules to network. Network equipment generally adheres to several rules to
protect privacy: protect privacy:
skipping to change at page 30, line 35 skipping to change at page 30, line 35
5.5. Other Factors for Trustworthy Operation 5.5. Other Factors for Trustworthy Operation
In addition to trustworthy provisioning of keys, RIV depends on a In addition to trustworthy provisioning of keys, RIV depends on a
number of other factors for trustworthy operation. number of other factors for trustworthy operation.
o Secure identity depends on mechanisms to prevent per-device secret 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. See Section 8.1 for background from the very first measurement. See Section 9.1 for background
on TPM practices. on TPM practices.
o That first measurement is made by code called the Root of Trust o That first measurement is made by code called the Root of Trust
for Measurement, typically done by trusted firmware stored in boot for Measurement, typically done by trusted firmware stored in boot
flash. Mechanisms for maintaining the trustworthiness of the RTM flash. Mechanisms for maintaining the trustworthiness of the RTM
are out of scope for RIV, but could include immutable firmware, are out of scope for RIV, but could include immutable firmware,
signed updates, or a vendor-specific hardware verification signed updates, or a vendor-specific hardware verification
technique. See Section 8.2 for background on roots of trust. technique. See Section 9.2 for background on roots of trust.
o The device owner SHOULD provide some level of physical defense for o The device owner SHOULD provide some level of physical defense for
the device. If a TPM that has already been programmed with an the device. If a TPM that has already been programmed with an
authentic DevID is stolen and inserted into a counterfeit device, authentic DevID is stolen and inserted into a counterfeit device,
attestation of that counterfeit device may become attestation of that counterfeit device may become
indistinguishable from an authentic device. indistinguishable from an authentic device.
RIV also depends on reliable Reference Values, as expressed by the RIV also depends on reliable Reference Values, as expressed by the
RIM [RIM]. The definition of trust procedures for RIMs is out of RIM [RIM]. The definition of trust procedures for RIMs is out of
scope for RIV, and the device owner is free to use any policy to scope for RIV, and the device owner is free to use any policy to
skipping to change at page 32, line 9 skipping to change at page 32, line 9
o Reference Values must be conveyed from the software authority o Reference Values must be conveyed from the software authority
(e.g., the manufacturer) in Reference Integrity Manifests, to the (e.g., the manufacturer) in Reference Integrity Manifests, to the
system in which verification will take place. IETF and TCG SWID system in which verification will take place. IETF and TCG SWID
and CoSWID work ([I-D.birkholz-yang-swid], [RIM])) forms the basis and CoSWID work ([I-D.birkholz-yang-swid], [RIM])) forms the basis
for this function. for this function.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Appendix 8. Acknowledgements
8.1. Using a TPM for Attestation The authors wish to thank numerous reviewers for generous assistance,
including William Bellingrath, Mark Baushke, Ned Smith, Henk
Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas
Hardjono, Bill Sulzen, Monty Wiseman, Kathleen Moriarty, Nancy Cam-
Winget and Shwetha Bhandari
9. Appendix
9.1. Using a TPM for Attestation
The Trusted Platform Module and surrounding ecosystem provide three The Trusted Platform Module and surrounding ecosystem provide three
interlocking capabilities to enable secure collection of evidence interlocking capabilities to enable secure collection of evidence
from a remote device, Platform Configuration Registers (PCRs), a from a remote device, Platform Configuration Registers (PCRs), a
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
skipping to change at page 32, line 47 skipping to change at page 33, line 6
an accurate view of what was placed into the PCR. an accurate view of what was placed into the PCR.
Note that the composite hash-of-hashes recorded in PCRs is order- Note that the composite hash-of-hashes recorded in PCRs is order-
dependent, resulting in different PCR values for different ordering dependent, resulting in different PCR values for different ordering
of the same set of events (e.g. Event A followed by Event B yields a of the same set of events (e.g. Event A followed by Event B yields a
different PCR value than B followed by A). For single-threaded code, different PCR value than B followed by A). For single-threaded code,
where both the events and their order are fixed, a Verifier may where both the events and their order are fixed, a Verifier may
validate a single PCR value, and use the log only to diagnose a validate a single PCR value, and use the log only to diagnose a
mismatch from Reference Values. However, operating system code is mismatch from Reference Values. However, operating system code is
usually non-deterministic, meaning that there may never be a single usually non-deterministic, meaning that there may never be a single
"known good" PCR value. In this case, the Verifier may have verify "known good" PCR value. In this case, the Verifier may have to
that the log is correct, and then analyze each item in the log to verify that the log is correct, and then analyze each item in the log
determine if it represents an authorized event. to determine if it represents an authorized event.
In a conventional TPM Attestation environment, the first measurement In a conventional TPM Attestation environment, the first measurement
must be made and extended into the TPM by trusted device code (called must be made and extended into the TPM by trusted device code (called
the Root of Trust for Measurement, RTM). That first measurement the Root of Trust for Measurement, RTM). That first measurement
should cover the segment of code that is run immediately after the should cover the segment of code that is run immediately after the
RTM, which then measures the next code segment before running it, and RTM, which then measures the next code segment before running it, and
so on, forming an unbroken chain of trust. See [TCGRoT] for more on so on, forming an unbroken chain of trust. See [TCGRoT] for more on
Mutable vs Immutable roots of trust. Mutable vs Immutable roots of trust.
The TPM provides another mechanism called a Quote that can read the The TPM provides another mechanism called a Quote that can read the
skipping to change at page 33, line 37 skipping to change at page 33, line 45
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].
8.2. Root of Trust for Measurement 9.2. Root of Trust for Measurement
The measurements needed for attestation require that the device being The measurements needed for attestation require that the device being
attested is equipped with a Root of Trust for Measurement, that is, attested is equipped with a Root of Trust for Measurement, that is,
some trustworthy mechanism that can compute the first measurement in some trustworthy mechanism that can compute the first measurement in
the chain of trust required to attest that each stage of system the chain of trust required to attest that each stage of system
startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs) startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs)
to record the results, and a Root of Trust for Reporting to report to record the results, and a Root of Trust for Reporting to report
the results [TCGRoT], [SP800-155], [SP800-193]. the results [TCGRoT], [SP800-155], [SP800-193].
While there are many complex aspects of a Root of Trust, two aspects While there are many complex aspects of a Root of Trust, two aspects
skipping to change at page 34, line 20 skipping to change at page 34, line 25
without re-entering the Root of Trust for Measurement code. without re-entering the Root of Trust for Measurement code.
The first measurement must be computed by code that is implicitly The first measurement must be computed by code that is implicitly
trusted; if that first measurement can be subverted, none of the trusted; if that first measurement can be subverted, none of the
remaining measurements can be trusted. (See [SP800-155]) remaining measurements can be trusted. (See [SP800-155])
It's important to note that the trustworthiness of the RTM code It's important to note that the trustworthiness of the RTM code
cannot be assured by the TPM or TPM supplier - code or procedures cannot be assured by the TPM or TPM supplier - code or procedures
external to the TPM must guarantee the security of the RTM. external to the TPM must guarantee the security of the RTM.
8.3. Layering Model for Network Equipment Attester and Verifier 9.3. Layering Model for Network Equipment Attester and Verifier
Retrieval of identity and attestation state uses one protocol stack, Retrieval of identity and attestation state uses one protocol stack,
while retrieval of Reference Values uses a different set of while retrieval of Reference Values uses a different set of
protocols. Figure 5 shows the components involved. protocols. Figure 5 shows the components involved.
+-----------------------+ +-------------------------+ +-----------------------+ +-------------------------+
| | | | | | | |
| Attester |<-------------| Verifier | | Attester |<-------------| Verifier |
| (Device) |------------->| (Management Station) | | (Device) |------------->| (Management Station) |
| | | | | | | | | |
skipping to change at page 35, line 41 skipping to change at page 35, line 41
* * . MIB . * I-D.ietf-rats- * * * . MIB . * 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 7: 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.
8.4. Implementation Notes 9.4. Implementation Notes
Figure 8 summarizes many of the actions needed to complete an Figure 8 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. It should be noted that, while the YANG model is RECOMMENDED
for attestation, this table identifies an optional SNMP MIB as well, for attestation, this table identifies an optional SNMP MIB as well,
[Attest-MIB]. [Attest-MIB].
skipping to change at page 37, line 43 skipping to change at page 37, line 43
| to several more components: | | | to several more components: | |
| o A Posture Manager Server | | | o A Posture Manager Server | |
| which collects reports and stores them in | | | which collects reports and stores them in | |
| a database | | | a database | |
| o One or more Analyzers that can look at the| | | o One or more Analyzers that can look at the| |
| results and figure out what it means. | | | results and figure out what it means. | |
-------------------------------------------------------------------- --------------------------------------------------------------------
Figure 8: Component Status Figure 8: Component Status
9. References 10. References
9.1. Normative References 10.1. Normative References
[Canonical-Event-Log] [Canonical-Event-Log]
Trusted Computing Group, "DRAFT Canonical Event Log Format Trusted Computing Group, "DRAFT Canonical Event Log Format
Version: 1.0, Revision: .12", October 2018. Version: 1.0, Revision: .12", October 2018.
[I-D.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-yang-tpm-charra] [I-D.ietf-rats-yang-tpm-charra]
Birkholz, H., Eckel, M., Voit, E., Bhandari, S., Sulzen, Birkholz, H., Eckel, M., Voit, E., Bhandari, S., Sulzen,
B., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data B., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data
Model for Challenge-Response-based Remote Attestation Model for Challenge-Response-based Remote Attestation
Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-03 Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-03
(work in progress), September 2020. (work in progress), September 2020.
[I-D.ietf-sacm-coswid] [I-D.ietf-sacm-coswid]
Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
Waltermire, "Concise Software Identification Tags", draft- Waltermire, "Concise Software Identification Tags", draft-
ietf-sacm-coswid-15 (work in progress), May 2020. ietf-sacm-coswid-16 (work in progress), November 2020.
[IEEE-802-1AR] [IEEE-802-1AR]
Seaman, M., "802.1AR-2018 - IEEE Standard for Local and Seaman, M., "802.1AR-2018 - IEEE Standard for Local and
Metropolitan Area Networks - Secure Device Identity, IEEE Metropolitan Area Networks - Secure Device Identity, IEEE
Computer Society", August 2018. Computer Society", August 2018.
[PC-Client-BIOS-TPM-1.2] [PC-Client-BIOS-TPM-1.2]
Trusted Computing Group, "TCG PC Client Specific Trusted Computing Group, "TCG PC Client Specific
Implementation Specification for Conventional BIOS, Implementation Specification for Conventional BIOS,
Specification Version 1.21 Errata, Revision 1.00", Specification Version 1.21 Errata, Revision 1.00",
skipping to change at page 39, line 18 skipping to change at page 39, line 18
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
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/resource/ August 2015, <https://trustedcomputinggroup.org/resource/
tpm-keys-for-platform-identity-for-tpm-1-2-2/>. tpm-keys-for-platform-identity-for-tpm-1-2-2/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>. January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
skipping to change at page 40, line 11 skipping to change at page 40, line 17
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
2018, <https://trustedcomputinggroup.org/resource/tcg-tap- 2018, <https://trustedcomputinggroup.org/resource/tcg-tap-
information-model/>. information-model/>.
9.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] [Attest-MIB]
skipping to change at page 41, line 14 skipping to change at page 41, line 19
[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-07 (work in progress), draft-ietf-rats-architecture-07 (work in progress),
October 2020. October 2020.
[I-D.ietf-rats-eat] [I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Ballesteros, M., and J. Mandyam, G., Lundblade, L., Ballesteros, M., and J.
O'Donoghue, "The Entity Attestation Token (EAT)", draft- O'Donoghue, "The Entity Attestation Token (EAT)", draft-
ietf-rats-eat-04 (work in progress), August 2020. ietf-rats-eat-06 (work in progress), December 2020.
[I-D.richardson-rats-usecases] [I-D.richardson-rats-usecases]
Richardson, M., Wallace, C., and W. Pan, "Use cases for Richardson, M., Wallace, C., and W. Pan, "Use cases for
Remote Attestation common encodings", draft-richardson- Remote Attestation common encodings", draft-richardson-
rats-usecases-07 (work in progress), March 2020. rats-usecases-08 (work in progress), November 2020.
[I-D.voit-rats-trusted-path-routing] [I-D.voit-rats-trusted-path-routing]
Voit, E., "Trusted Path Routing", draft-voit-rats-trusted- Voit, E., "Trusted Path Routing", draft-voit-rats-trusted-
path-routing-02 (work in progress), June 2020. path-routing-02 (work in progress), June 2020.
[IEEE-802.1AE] [IEEE-802.1AE]
Seaman, M., "802.1AE MAC Security (MACsec)", 2018, Seaman, M., "802.1AE MAC Security (MACsec)", 2018,
<https://1.ieee802.org/security/802-1ae/>. <https://1.ieee802.org/security/802-1ae/>.
[IEEE-802.1x] [IEEE-802.1X]
IEEE Computer Society, "802.1X-2020 - IEEE Standard for IEEE Computer Society, "802.1X-2020 - IEEE Standard for
Local and Metropolitan Area Networks--Port-Based Network Local and Metropolitan Area Networks--Port-Based Network
Access Control", February 2020, Access Control", February 2020,
<https://standards.ieee.org/standard/802_1X-2020.html>. <https://standards.ieee.org/standard/802_1X-2020.html>.
[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
 End of changes. 29 change blocks. 
39 lines changed or deleted 52 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/