idnits 2.17.1
draft-ietf-rats-tpm-based-network-device-attest-06.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (December 07, 2020) is 1235 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '0' on line 562
-- Looks like a reference, but probably isn't: '2' on line 573
-- Looks like a reference, but probably isn't: '4' on line 575
-- Looks like a reference, but probably isn't: '8' on line 581
-- Looks like a reference, but probably isn't: '5' on line 578
== Unused Reference: 'RFC2119' is defined on line 1754, but no explicit
reference was found in the text
== Outdated reference: A later version (-22) exists of
draft-ietf-rats-yang-tpm-charra-03
== Outdated reference: A later version (-24) exists of
draft-ietf-sacm-coswid-16
== Outdated reference: A later version (-03) exists of
draft-birkholz-rats-network-device-subscription-01
== Outdated reference: A later version (-07) exists of
draft-birkholz-rats-tuda-03
== Outdated reference: A later version (-22) exists of
draft-ietf-rats-architecture-07
== Outdated reference: A later version (-25) exists of
draft-ietf-rats-eat-06
Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 RATS Working Group G. Fedorkow, Ed.
3 Internet-Draft Juniper Networks, Inc.
4 Intended status: Informational E. Voit
5 Expires: June 10, 2021 Cisco Systems, Inc.
6 J. Fitzgerald-McKay
7 National Security Agency
8 December 07, 2020
10 TPM-based Network Device Remote Integrity Verification
11 draft-ietf-rats-tpm-based-network-device-attest-06
13 Abstract
15 This document describes a workflow for remote attestation of the
16 integrity of firmware and software installed on network devices that
17 contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by
18 the Trusted Computing Group (TCG).
20 Status of This Memo
22 This Internet-Draft is submitted in full conformance with the
23 provisions of BCP 78 and BCP 79.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF). Note that other groups may also distribute
27 working documents as Internet-Drafts. The list of current Internet-
28 Drafts is at https://datatracker.ietf.org/drafts/current/.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 This Internet-Draft will expire on June 10, 2021.
37 Copyright Notice
39 Copyright (c) 2020 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (https://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
56 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4
57 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
58 1.4. Description of Remote Integrity Verification (RIV) . . . 5
59 1.5. Solution Requirements . . . . . . . . . . . . . . . . . . 7
60 1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8
61 1.6.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8
62 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9
63 2.1. RIV Software Configuration Attestation using TPM . . . . 9
64 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 10
65 2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 12
66 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 14
67 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 15
68 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 17
69 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 18
70 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 19
71 3. Standards Components . . . . . . . . . . . . . . . . . . . . 19
72 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 19
73 3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 20
74 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 20
75 3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 20
76 3.2. Reference Model for Challenge-Response . . . . . . . . . 21
77 3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 23
78 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24
79 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
81 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 26
82 5.2. Prevention of Spoofing and Man-in-the-Middle Attacks . . 28
83 5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29
84 5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 29
85 5.5. Other Factors for Trustworthy Operation . . . . . . . . . 30
86 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 31
87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
89 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32
90 9.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 32
91 9.2. Root of Trust for Measurement . . . . . . . . . . . . . . 33
92 9.3. Layering Model for Network Equipment Attester and
93 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 34
94 9.4. Implementation Notes . . . . . . . . . . . . . . . . . . 36
95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
96 10.1. Normative References . . . . . . . . . . . . . . . . . . 37
97 10.2. Informative References . . . . . . . . . . . . . . . . . 40
98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
100 1. Introduction
102 There are many aspects to consider in fielding a trusted computing
103 device, from operating systems to applications. Mechanisms to prove
104 that a device installed at a customer's site is authentic (i.e., not
105 counterfeit) and has been configured with authorized software, all as
106 part of a trusted supply chain, are just a few of the many aspects
107 which need to be considered concurrently to have confidence that a
108 device is truly trustworthy.
110 A generic architecture for remote attestation has been defined in
111 [I-D.ietf-rats-architecture]. Additionally, the use cases for
112 remotely attesting networking devices are discussed within Section 6
113 of [I-D.richardson-rats-usecases]. However, these documents do not
114 provide sufficient guidance for network equipment vendors and
115 operators to design, build, and deploy interoperable devices.
117 The intent of this document is to provide such guidance. It does
118 this by outlining the Remote Integrity Verification (RIV) problem,
119 and then identifies elements that are necessary to get the complete,
120 scalable attestation procedure working with commercial networking
121 products such as routers, switches and firewalls. An underlying
122 assumption will be the availability within the device of a Trusted
123 Platform Module [TPM1.2], [TPM2.0] compliant cryptoprocessor to
124 enable the trustworthy remote assessment of the device's software and
125 hardware.
127 1.1. Terminology
129 A number of terms are reused from [I-D.ietf-rats-architecture].
130 These include: Appraisal Policy for Evidence, Attestation Result,
131 Attester, Evidence, Reference Value, Relying Party, Verifier, and
132 Verifier Owner.
134 Additionally, this document defines the following term:
136 Attestation: the process of generating, conveying and appraising
137 claims, backed by evidence, about device trustworthiness
138 characteristics, including supply chain trust, identity, device
139 provenance, software configuration, device composition, compliance to
140 test suites, functional and assurance evaluations, etc.
142 The goal of attestation is simply to assure an administrator that the
143 device configuration and software that was launched when the device
144 was last started is authentic and untampered-with.
146 Within the Trusted Computing Group (TCG) context, attestation is the
147 process by which an independent Verifier can obtain cryptographic
148 proof as to the identity of the device in question, and evidence of
149 the integrity of software loaded on that device when it started up,
150 and then verify that what's there matches the intended configuration.
151 For network equipment, a Verifier capability can be embedded in a
152 Network Management Station (NMS), a posture collection server, or
153 other network analytics tool (such as a software asset management
154 solution, or a threat detection and mitigation tool, etc.). While
155 informally referred to as attestation, this document focuses on a
156 subset defined here as Remote Integrity Verification (RIV). RIV
157 takes a network equipment centric perspective that includes a set of
158 protocols and procedures for determining whether a particular device
159 was launched with authentic software, starting from Roots of Trust.
160 While there are many ways to accomplish attestation, RIV sets out a
161 specific set of protocols and tools that work in environments
162 commonly found in network equipment. RIV does not cover other device
163 characteristics that could be attested (e.g., geographic location,
164 connectivity; see [I-D.richardson-rats-usecases]), although it does
165 provide evidence of a secure infrastructure to increase the level of
166 trust in other device characteristics attested by other means (e.g.,
167 by Entity Attestation Tokens [I-D.ietf-rats-eat]).
169 In line with [I-D.ietf-rats-architecture] definitions, this document
170 uses the term Endorser to refer to the role that signs identity and
171 attestation certificates used by the Attester, while Reference Values
172 are signed by a Reference Value Provider. Typically, the
173 manufacturer of an embedded device would be accepted as both the
174 Endorser and Reference Value Provider, although the choice is
175 ultimately up to the Verifier Owner.
177 1.2. Document Organization
179 The remainder of this document is organized into several sections:
181 o The remainder of this section covers goals and requirements, plus
182 a top-level description of RIV.
184 o The Solution Overview section outlines how Remote Integrity
185 Verification works.
187 o The Standards Components section links components of RIV to
188 normative standards.
190 o Privacy and Security shows how specific features of RIV contribute
191 to the trustworthiness of the Attestation Result.
193 o Supporting material is in an appendix at the end.
195 1.3. Goals
197 Network operators benefit from a trustworthy attestation mechanism
198 that provides assurance that their network comprises authentic
199 equipment, and has loaded software free of known vulnerabilities and
200 unauthorized tampering. In line with the overall goal of assuring
201 integrity, attestation can be used to assist in asset management,
202 vulnerability and compliance assessment, plus configuration
203 management.
205 The RIV attestation workflow outlined in this document is intended to
206 meet the following high-level goals:
208 o Provable Device Identity - This specification requires that an
209 Attester (i.e., the attesting device) includes a cryptographic
210 identifier unique to each device. Effectively this means that the
211 TPM must be so provisioned during the manufacturing cycle.
213 o Software Inventory - A key goal is to identify the software
214 release(s) installed on the Attester, and to provide evidence that
215 the software stored within hasn't been altered without
216 authorization.
218 o Verifiability - Verification of software and configuration of the
219 device shows that the software that was authorized for
220 installation by the administrator has actually been launched.
222 In addition, RIV is designed to operate either in a centralized
223 environment, such as with a central authority that manages and
224 configures a number of network devices, or 'peer-to-peer', where
225 network devices independently verify one another to establish a trust
226 relationship. (See Section 3.3 below, and also
227 [I-D.voit-rats-trusted-path-routing])
229 1.4. Description of Remote Integrity Verification (RIV)
231 Attestation requires two interlocking mechanisms between the Attester
232 network device and the Verifier:
234 o Device Identity, the mechanism providing trusted identity, can
235 reassure network managers that the specific devices they ordered
236 from authorized manufacturers for attachment to their network are
237 those that were installed, and that they continue to be present in
238 their network. As part of the mechanism for Device Identity,
239 cryptographic proof of the identity of the manufacturer is also
240 provided.
242 o Software Measurement is the mechanism that reports the state of
243 mutable software components on the device, and can assure network
244 managers that they have known, authentic software configured to
245 run in their network.
247 Using these two interlocking mechanisms, RIV is a component in a
248 chain of procedures that can assure a network operator that the
249 equipment in their network can be reliably identified, and that
250 authentic software of a known version is installed on each device.
251 Equipment in the network includes devices that make up the network
252 itself, such as routers, switches and firewalls.
254 Software used to boot a device can be described as recording a chain
255 of measurements, anchored at the start by a Root of Trust for
256 Measurement (see Section 9.2), each measuring the next stage, that
257 normally ends when the system software is loaded. A measurement
258 signifies the identity, integrity and version of each software
259 component registered with an Attester's TPM [TPM1.2], [TPM2.0], so
260 that a subsequent verification stage can determine if the software
261 installed is authentic, up-to-date, and free of tampering.
263 RIV includes several major processes:
265 1. Generation of Evidence is the process whereby an Attester
266 generates cryptographic proof (Evidence) of claims about device
267 properties. In particular, the device identity and its software
268 configuration are both of critical importance.
270 2. Device Identification refers to the mechanism assuring the
271 Relying Party (ultimately, a network administrator) of the
272 identity of devices that make up their network, and that their
273 manufacturers are known.
275 3. Conveyance of Evidence reliably transports the collected Evidence
276 from Attester to a Verifier to allow a management station to
277 perform a meaningful appraisal in Step 4. The transport is
278 typically carried out via a management network. The channel must
279 provide integrity and authenticity, and, in some use cases, may
280 also require confidentiality.
282 4. Finally, Appraisal of Evidence occurs. This is the process of
283 verifying the Evidence received by a Verifier from the Attester,
284 and using an Appraisal Policy to develop an Attestation Result,
285 used to inform decision making. In practice, this means
286 comparing the Attester's measurements reported as Evidence with
287 the device configuration expected by the Verifier. Subsequently
288 the Appraisal Policy for Evidence might match Evidence found
289 against Reference Values (aka Golden Measurements), which
290 represent the intended configured state of the connected device.
292 All implementations supporting this RIV specification require the
293 support of the following three technologies:
295 1. Identity: Device identity MUST be based on IEEE 802.1AR Device
296 Identity (DevID) [IEEE-802-1AR], coupled with careful supply-
297 chain management by the manufacturer. The Initial DevID (IDevID)
298 certificate contains a statement by the manufacturer that
299 establishes the identity of the device as it left the factory.
300 Some applications with a more-complex post-manufacture supply
301 chain (e.g., Value Added Resellers), or with different privacy
302 concerns, may want to use alternative mechanisms for platform
303 authentication (for example, TCG Platform Certificates
304 [Platform-Certificates], or post-manufacture installation of
305 Local Device ID (LDevID)).
307 2. Platform Attestation provides evidence of configuration of
308 software elements present in the device. This form of
309 attestation can be implemented with TPM Platform Configuration
310 Registers (PCRs), Quote and Log mechanisms, which provide
311 cryptographically authenticated evidence to report what software
312 was started on the device through the boot cycle. Successful
313 attestation requires an unbroken chain from a boot-time root of
314 trust through all layers of software needed to bring the device
315 to an operational state, in which each stage measures components
316 of the next stage, updates the attestation log, and extends
317 hashes into a PCR. The TPM can then report the hashes of all the
318 measured hashes as signed evidence called a Quote (see
319 Section 9.1 for an overview of TPM operation, or [TPM1.2] and
320 [TPM2.0] for many more details).
322 3. Signed Reference Values (aka Reference Integrity Measurements)
323 must be conveyed from the Reference Value Provider (the entity
324 accepted as the software authority, often the manufacturer for
325 embedded systems) to the Verifier.
327 1.5. Solution Requirements
329 Remote Integrity Verification must address the "Lying Endpoint"
330 problem, in which malicious software on an endpoint may subvert the
331 intended function, and also prevent the endpoint from reporting its
332 compromised status. (See Section 5 for further Security
333 Considerations.)
335 RIV attestation is designed to be simple to deploy at scale. RIV
336 should work "out of the box" as far as possible, that is, with the
337 fewest possible provisioning steps or configuration databases needed
338 at the end-user's site. Network equipment is often required to
339 "self-configure", to reliably reach out without manual intervention
340 to prove its identity and operating posture, then download its own
341 configuration, a process which precludes pre-installation
342 configuration. See [RFC8572] for an example of Secure Zero Touch
343 Provisioning.
345 1.6. Scope
347 The need for assurance of software integrity, addressed by Remote
348 Attestation, is a very general problem that could apply to most
349 network-connected computing devices. However, this document includes
350 several assumptions that limit the scope to network equipment (e.g.,
351 routers, switches and firewalls):
353 o This solution is for use in non-privacy-preserving applications
354 (for example, networking, Industrial IoT), avoiding the need for a
355 Privacy Certificate Authority for attestation keys [AK-Enrollment]
356 or TCG Platform Certificates [Platform-Certificates].
358 o This document assumes network protocols that are common in network
359 equipment such as YANG [RFC7950] and NETCONF [RFC6241], but not
360 generally used in other applications.
362 o The approach outlined in this document mandates the use of a
363 compliant TPM [TPM1.2], [TPM2.0].
365 1.6.1. Out of Scope
367 o Run-Time Attestation: The Linux Integrity Measurement Architecture
368 attests each process launched after a device is started (and is in
369 scope for RIV), but continuous run-time attestation of Linux or
370 other multi-threaded operating system processes after they've
371 started considerably expands the scope of the problem. Many
372 researchers are working on that problem, but this document defers
373 the problem of continuous, in-memory run-time attestation.
375 o Multi-Vendor Embedded Systems: Additional coordination would be
376 needed for devices that themselves comprise hardware and software
377 from multiple vendors, integrated by the end user. Although out
378 of scope for this document, these issues are accommodated in
379 [I-D.ietf-rats-architecture].
381 o Processor Sleep Modes: Network equipment typically does not
382 "sleep", so sleep and hibernate modes are not considered.
383 Although out of scope for RIV, Trusted Computing Group
384 specifications do encompass sleep and hibernate states.
386 o Virtualization and Containerization: In a non-virtualized system,
387 the host OS is responsible for measuring each User Space file or
388 process, but that's the end of the boot process. For virtualized
389 systems, the host OS must verify the hypervisor, which then
390 manages its own chain of trust through the virtual machine.
391 Virtualization and containerization technologies are increasingly
392 used in network equipment, but are not considered in this
393 document.
395 2. Solution Overview
397 2.1. RIV Software Configuration Attestation using TPM
399 RIV Attestation is a process which can be used to determine the
400 identity of software running on a specifically-identified device.
401 Remote Attestation is broken into two phases, shown in Figure 1:
403 o During system startup, each distinct software object is "measured"
404 by the Attester. The object's identity, hash (i.e., cryptographic
405 digest) and version information are recorded in a log. Hashes are
406 also extended, or cryptographically folded, into the TPM, in a way
407 that can be used to validate the log entries. The measurement
408 process generally follows the layered chain-of-trust model used in
409 Measured Boot, where each stage of the system measures the next
410 one, and extends its measurement into the TPM, before launching
411 it. See [I-D.ietf-rats-architecture], section "Layered
412 Attestation Environments," for an architectural definition of this
413 model.
415 o Once the device is running and has operational network
416 connectivity, a separate, trusted Verifier will interrogate the
417 network device to retrieve the logs and a copy of the digests
418 collected by hashing each software object, signed by an
419 attestation private key secured by, but never released by, the
420 TPM. The YANG model described in [I-D.ietf-rats-yang-tpm-charra]
421 facilitates this operation.
423 The result is that the Verifier can verify the device's identity by
424 checking the Subject Field and signature of certificate containing
425 the TPM's attestation public key, and can validate the software that
426 was launched by verifying the correctness of the logs by comparing
427 with the signed digests from the TPM, and comparing digests in the
428 log with Reference Values.
430 It should be noted that attestation and identity are inextricably
431 linked; signed Evidence that a particular version of software was
432 loaded is of little value without cryptographic proof of the identity
433 of the Attester producing the Evidence.
435 +-------------------------------------------------------+
436 | +--------+ +--------+ +--------+ +---------+ |
437 | | BIOS |--->| Loader |-->| Kernel |--->|Userland | |
438 | +--------+ +--------+ +--------+ +---------+ |
439 | | | | |
440 | | | | |
441 | +------------+-----------+-+ |
442 | Step 1 | |
443 | V |
444 | +--------+ |
445 | | TPM | |
446 | +--------+ |
447 | Router | |
448 +--------------------------------|----------------------+
449 |
450 | Step 2
451 | +-----------+
452 +--->| Verifier |
453 +-----------+
455 Reset---------------flow-of-time-during-boot--...------->
457 Figure 1: Layered RIV Attestation Model
459 In Step 1, measurements are "extended", or hashed, into the TPM as
460 processes start, with the result that the PCR ends up containing a
461 hash of all the measured hashes. In Step 2, signed PCR digests are
462 retrieved from the TPM for off-box analysis after the system is
463 operational.
465 2.1.1. What Does RIV Attest?
467 TPM attestation is strongly focused on Platform Configuration
468 Registers (PCRs), but those registers are only vehicles for
469 certifying accompanying Evidence, conveyed in log entries. It is the
470 hashes in log entries that are extended into PCRs, where the final
471 PCR values can be retrieved in the form of a structure called a
472 Quote, signed by an Attestation key known only to the TPM. The use
473 of multiple PCRs serves only to provide some independence between
474 different classes of object, so that one class of objects can be
475 updated without changing the extended hash for other classes.
476 Although PCRs can be used for any purpose, this section outlines the
477 objects within the scope of this document which may be extended into
478 the TPM.
480 In general, assignment of measurements to PCRs is a policy choice
481 made by the device manufacturer, selected to independently attest
482 three classes of object:
484 o Code, (i.e., instructions) to be executed by a CPU.
486 o Configuration - Many devices offer numerous options controlled by
487 non-volatile configuration variables which can impact the device's
488 security posture. These settings may have vendor defaults, but
489 often can be changed by administrators, who may want to verify via
490 attestation that the operational state of the settings match their
491 intended state.
493 o Credentials - Administrators may wish to verify via attestation
494 that public keys (and other credentials) outside the Root of Trust
495 have not been subject to unauthorized tampering. (By definition,
496 keys protecting the root of trust can't be verified
497 independently.)
499 The TCG PC Client Platform Firmware Profile Specification
500 [PC-Client-BIOS-TPM-2.0] gives considerable detail on what is to be
501 measured during the boot phase of platform startup using a UEFI BIOS
502 (www.uefi.org), but the goal is simply to measure every bit of code
503 executed in the process of starting the device, along with any
504 configuration information related to security posture, leaving no gap
505 for unmeasured code to remain undetected, potentially subverting the
506 chain.
508 For devices using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] gives
509 detailed normative requirements for PCR usage. For other platform
510 architectures, the table in Figure 2 gives non-normative guidance for
511 PCR assignment that generalizes the specific details of
512 [PC-Client-BIOS-TPM-2.0].
514 By convention, most PCRs are assigned in pairs, which the even-
515 numbered PCR used to measure executable code, and the odd-numbered
516 PCR used to measure whatever data and configuration are associated
517 with that code. It is important to note that each PCR may contain
518 results from dozens (or even thousands) of individual measurements.
520 +------------------------------------------------------------------+
521 | | Assigned PCR # |
522 | Function | Code | Configuration|
523 --------------------------------------------------------------------
524 | Firmware Static Root of Trust, (i.e., | 0 | 1 |
525 | initial boot firmware and drivers) | | |
526 --------------------------------------------------------------------
527 | Drivers and initialization for optional | 2 | 3 |
528 | or add-in devices | | |
529 --------------------------------------------------------------------
530 | OS Loader code and configuration, (i.e., | 4 | 5 |
531 | the code launched by firmware) to load an | | |
532 | operating system kernel. These PCRs record | | |
533 | each boot attempt, and an identifier for | | |
534 | where the loader was found | | |
535 --------------------------------------------------------------------
536 | Vendor Specific Measurements during boot | 6 | 6 |
537 --------------------------------------------------------------------
538 | Secure Boot Policy. This PCR records keys | | 7 |
539 | and configuration used to validate the OS | | |
540 | loader | | |
541 --------------------------------------------------------------------
542 | Measurements made by the OS Loader | 8 | 9 |
543 | (e.g GRUB2 for Linux) | | |
544 --------------------------------------------------------------------
545 | Measurements made by OS (e.g., Linux IMA) | 10 | 10 |
546 +------------------------------------------------------------------+
548 Figure 2: Attested Objects
550 2.1.2. Notes on PCR Allocations
552 It is important to recognize that PCR[0] is critical. The first
553 measurement into PCR[0] is taken by the Root of Trust for
554 Measurement, code which, by definition, cannot be verified by
555 measurement. This measurement establishes the chain of trust for all
556 subsequent measurements. If the PCR[0] measurement cannot be
557 trusted, the validity of the entire chain is put into question.
559 Distinctions Between PCR[0], PCR[2], PCR[4] and PCR[8] are summarized
560 below:
562 o PCR[0] typically represents a consistent view of rarely-changed
563 Host Platform boot components, allowing Attestation policies to be
564 defined using the less changeable components of the transitive
565 trust chain. This PCR typically provides a consistent view of the
566 platform regardless of user selected options.
568 o PCR[2] is intended to represent a "user configurable" environment
569 where the user has the ability to alter the components that are
570 measured into PCR[2]. This is typically done by adding adapter
571 cards, etc., into user-accessible PCI or other slots. In UEFI
572 systems these devices may be configured by Option ROMs measured
573 into PCR[2] and executed by the BIOS.
575 o PCR[4] is intended to represent the software that manages the
576 transition between the platform's Pre-Operating System start and
577 the state of a system with the Operating System present. This
578 PCR, along with PCR[5], identifies the initial operating system
579 loader (e.g., GRUB for Linux).
581 o PCR[8] is used by the OS loader (e.g. GRUB) to record
582 measurements of the various components of the operating system.
584 Although the TCG PC Client document specifies the use of the first
585 eight PCRs very carefully to ensure interoperability among multiple
586 UEFI BIOS vendors, it should be noted that embedded software vendors
587 may have considerably more flexibility. Verifiers typically need to
588 know which log entries are consequential and which are not (possibly
589 controlled by local policies) but the Verifier may not need to know
590 what each log entry means or why it was assigned to a particular PCR.
591 Designers must recognize that some PCRs may cover log entries that a
592 particular Verifier considers critical and other log entries that are
593 not considered important, so differing PCR values may not on their
594 own constitute a check for authenticity. For example, in a UEFI
595 system, some administrators may consider booting an image from a
596 removable drive, something recorded in a PCR, to be a security
597 violation, while others might consider that operation an authorized
598 recovery procedure.
600 Designers may allocate particular events to specific PCRs in order to
601 achieve a particular objective with local attestation, (e.g.,
602 allowing a procedure to execute, or releasing a paricular decryption
603 key, only if a given PCR is in a given state). It may also be
604 important to designers to consider whether streaming notification of
605 PCR updates is required (see
606 [I-D.birkholz-rats-network-device-subscription]). Specific log
607 entries can only be validated if the Verifier receives every log
608 entry affecting the relevant PCR, so (for example) a designer might
609 want to separate rare, high-value events such as configuration
610 changes, from high-volume, routine measurements such as IMA [IMA]
611 logs.
613 2.2. RIV Keying
615 RIV attestation relies on two credentials:
617 o An identity key pair and matching certificate is required to
618 certify the identity of the Attester itself. RIV specifies the
619 use of an IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR],
620 signed by the device manufacturer, containing the device serial
621 number.
623 o An Attestation key pair and matching certificate is required to
624 sign the Quote generated by the TPM to report evidence of software
625 configuration.
627 In TPM application, both the Attestation private key and the DevID
628 private key MUST be protected by the TPM. Depending on other TPM
629 configuration procedures, the two keys are likely be different; some
630 of the considerations are outlined in TCG "TPM 2.0 Keys for Device
631 Identity and Attestation" [Platform-DevID-TPM-2.0].
633 The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies
634 further conventions for these keys:
636 o When separate Identity and Attestation keys are used, the
637 Attestation Key (AK) and its X.509 certificate should parallel the
638 DevID, with the same device ID information as the DevID
639 certificate (that is, the same Subject Name and Subject Alt Name,
640 even though the key pairs are different). This allows a quote
641 from the device, signed by an AK, to be linked directly to the
642 device that provided it, by examining the corresponding AK
643 certificate. If the Subject and Subject Alt Names in the AK
644 certificate don't match the corresponding DevID certifcate, or
645 they're signed by differing authorities the Verifier may signal
646 the detection of an Asokan-style man-in-the-middle attack (see
647 Section 5.2).
649 o Network devices that are expected to use secure zero touch
650 provisioning as specified in [RFC8572]) MUST be shipped by the
651 manufacturer with pre-provisioned keys (Initial DevID and Initial
652 AK, called IDevID and IAK). IDevID and IAK certificates MUST both
653 be signed by the Endorser (typically the device manufacturer).
654 Inclusion of an IDevID and IAK by a vendor does not preclude a
655 mechanism whereby an administrator can define Local Identity and
656 Attestation Keys (LDevID and LAK) if desired.
658 2.3. RIV Information Flow
660 RIV workflow for network equipment is organized around a simple use
661 case where a network operator wishes to verify the integrity of
662 software installed in specific, fielded devices. This use case
663 implies several components:
665 1. The Attester, the device which the network operator wants to
666 examine.
668 2. A Verifier (which might be a network management station)
669 somewhere separate from the Device that will retrieve the signed
670 evidence and measurement logs, and analyze them to pass judgment
671 on the security posture of the device.
673 3. A Relying Party, which can act on Attestation Results.
674 Interaction between the Relying Party and the Verifier is
675 considered out of scope for RIV.
677 4. Signed Reference Integrity Manifests (RIMs), containing Reference
678 Values, can either be created by the device manufacturer and
679 shipped along with the device as part of its software image, or
680 alternatively, could be obtained several other ways (direct to
681 the Verifier from the manufacturer, from a third party, from the
682 owner's observation of what's thought to be a "known good
683 system", etc.). Retrieving RIMs from the device itself allows
684 attestation to be done in systems that may not have access to the
685 public internet, or by other devices that are not management
686 stations per se (e.g., a peer device; see Section 3.1.3). If
687 Reference Values are obtained from multiple sources, the Verifier
688 may need to evaluate the relative level of trust to be placed in
689 each source in case of a discrepancy.
691 These components are illustrated in Figure 3.
693 A more-detailed taxonomy of terms is given in
694 [I-D.ietf-rats-architecture]
695 +----------------+ +-------------+ +---------+--------+
696 |Reference Value | | Attester | Step 1 | Verifier| |
697 |Provider | | (Device |<-------| (Network| Relying|
698 |(Device | | under |------->| Mngmt | Party |
699 |Manufacturer | | attestation)| Step 2 | Station)| |
700 |or other | | | | | |
701 |authority) | | | | | |
702 +----------------+ +-------------+ +---------+--------+
703 | /\
704 | Step 0 |
705 -----------------------------------------------
707 Figure 3: RIV Reference Configuration for Network Equipment
709 o In Step 0, The Reference Value Provider (the device manufacturer
710 or other authority) makes one or more Reference Integrity
711 Manifests (RIMs), corresponding to the software image expected to
712 be found on the device, signed by the Reference Value Provider,
713 available to the Verifier (see Section 3.1.3 for "in-band" and
714 "out of band" ways to make this happen).
716 o In Step 1, the Verifier (Network Management Station), on behalf of
717 a Relying Party, requests Identity, Measurement Values, and
718 possibly RIMs, from the Attester.
720 o In Step 2, the Attester responds to the request by providing a
721 DevID, quotes (measured values, signed by the Attester), and
722 optionally RIMs.
724 To achieve interoperability, the following standards components
725 SHOULD be used:
727 1. TPM Keys MUST be configured according to
728 [Platform-DevID-TPM-2.0], or [Platform-ID-TPM-1.2].
730 2. For devices using UEFI and Linux, measurements of firmware and
731 bootable modules SHOULD be taken according to TCG PC Client
732 [PC-Client-BIOS-TPM-1.2] or [PC-Client-BIOS-TPM-2.0], and Linux
733 IMA [IMA]
735 3. Device Identity MUST be managed as specified in IEEE 802.1AR
736 Device Identity certificates [IEEE-802-1AR], with keys protected
737 by TPMs.
739 4. Attestation logs SHOULD be formatted according to the Canonical
740 Event Log format [Canonical-Event-Log], although other
741 specialized formats may be used. UEFI-based systems MAY use the
742 TCG UEFI BIOS event log [EFI-TPM].
744 5. Quotes are retrieved from the TPM according to TCG TAP
745 Information Model [TAP]. While the TAP IM gives a protocol-
746 independent description of the data elements involved, it's
747 important to note that quotes from the TPM are signed inside the
748 TPM, so MUST be retrieved in a way that does not invalidate the
749 signature, as specified in [I-D.ietf-rats-yang-tpm-charra], to
750 preserve the trust model. (See Section 5 Security
751 Considerations).
753 6. Reference Values SHOULD be encoded as SWID or CoSWID tags, as
754 defined in the TCG RIM document [RIM], compatible with NIST IR
755 8060 [NIST-IR-8060] and the IETF CoSWID draft
756 [I-D.ietf-sacm-coswid]. See Section 2.4.1.
758 2.4. RIV Simplifying Assumptions
760 This document makes the following simplifying assumptions to reduce
761 complexity:
763 o The product to be attested MUST be shipped with an IEEE 802.1AR
764 Device Identity and an Initial Attestation Key (IAK) with
765 certificate. The IAK certificate MUST contain the same identity
766 information as the DevID (specifically, the same Subject Name and
767 Subject Alt Name, signed by the manufacturer), but it's a type of
768 key that can be used to sign a TPM Quote, but not other objects
769 (i.e., it's marked as a TCG "Restricted" key; this convention is
770 described in "TPM 2.0 Keys for Device Identity and Attestation"
771 [Platform-DevID-TPM-2.0]). For network equipment, which is
772 generally non-privacy-sensitive, shipping a device with both an
773 IDevID and an IAK already provisioned substantially simplifies
774 initial startup. Privacy-sensitive applications may use the TCG
775 Platform Certificate or other procedures to install identity
776 credentials into the device after manufacture.
778 o The product MUST be equipped with a Root of Trust for Measurement
779 (RTM), Root of Trust for Storage and Root of Trust for Reporting
780 (as defined in [SP800-155]) that are capable of conforming to TCG
781 Trusted Attestation Protocol (TAP) Information Model [TAP].
783 o The authorized software supplier MUST make available Reference
784 Values in the form of signed SWID or CoSWID tags
785 [I-D.ietf-sacm-coswid], [SWID], as described in TCG Reference
786 Integrity Measurement Manifest Information Model [RIM].
788 2.4.1. Reference Integrity Manifests (RIMs)
790 [I-D.ietf-rats-yang-tpm-charra] focuses on collecting and
791 transmitting evidence in the form of PCR measurements and attestation
792 logs. But the critical part of the process is enabling the Verifier
793 to decide whether the measurements are "the right ones" or not.
795 While it must be up to network administrators to decide what they
796 want on their networks, the software supplier should supply the
797 Reference Values, in signed Reference Integrity Manifests, that may
798 be used by a Verifier to determine if evidence shows known good,
799 known bad or unknown software configurations.
801 In general, there are two kinds of reference measurements:
803 1. Measurements of early system startup (e.g., BIOS, boot loader, OS
804 kernel) are essentially single-threaded, and executed exactly
805 once, in a known sequence, before any results could be reported.
806 In this case, while the method for computing the hash and
807 extending relevant PCRs may be complicated, the net result is
808 that the software (more likely, firmware) vendor will have one
809 known good PCR value that "should" be present in the relevant
810 PCRs after the box has booted. In this case, the signed
811 reference measurement could simply list the expected hashes for
812 the given version. However, a RIM that contains the intermediate
813 hashes can be useful in debugging cases where the expected final
814 hash is not the one reported.
816 2. Measurements taken later in operation of the system, once an OS
817 has started (for example, Linux IMA [IMA]), may be more complex,
818 with unpredictable "final" PCR values. In this case, the
819 Verifier must have enough information to reconstruct the expected
820 PCR values from logs and signed reference measurements from a
821 trusted authority.
823 In both cases, the expected values can be expressed as signed SWID or
824 CoSWID tags, but the SWID structure in the second case is somewhat
825 more complex, as reconstruction of the extended hash in a PCR may
826 involve thousands of files and other objects.
828 TCG has published an information model defining elements of Reference
829 Integrity Manifests under the title TCG Reference Integrity Manifest
830 Information Model [RIM]. This information model outlines how SWID
831 tags should be structured to allow attestation, and defines "bundles"
832 of SWID tags that may be needed to describe a complete software
833 release. The RIM contains metadata relating to the software release
834 it belongs to, plus hashes for each individual file or other object
835 that could be attested.
837 TCG has also published the PC Client Reference Integrity Measurement
838 specification [PC-Client-RIM], which focuses on a SWID-compatible
839 format suitable for expressing expected measurement values in the
840 specific case of a UEFI-compatible BIOS, where the SWID focus on
841 files and file systems is not a direct fit. While the PC Client RIM
842 is not directly applicable to network equipment, many vendors do use
843 a conventional UEFI BIOS to launch their network OS.
845 2.4.2. Attestation Logs
847 Quotes from a TPM can provide evidence of the state of a device up to
848 the time the evidence was recorded, but to make sense of the quote in
849 most cases an event log that identifies which software modules
850 contributed which values to the quote during startup MUST also be
851 provided. The log MUST contain enough information to demonstrate its
852 integrity by allowing exact reconstruction of the digest conveyed in
853 the signed quote (that is, calculating the hash of all the hashes in
854 the log should produce the same values as contained in the PCRs; if
855 they don't match, the log may have been tampered with. See
856 Section 9.1).
858 There are multiple event log formats which may be supported as viable
859 formats of Evidence between the Attester and Verifier:
861 o IMA Event log file exports [IMA]
863 o TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM
864 Family 1.1 or 1.2, Section 7) [EFI-TPM]
866 o TCG Canonical Event Log [Canonical-Event-Log]
868 Attesters which use UEFI BIOS and Linux SHOULD use TCG Canonical
869 Event Log [Canonical-Event-Log] and TCG UEFI BIOS event log
870 [EFI-TPM], although the CHARRA YANG model
871 [I-D.ietf-rats-yang-tpm-charra] has no dependence on the format of
872 the log.
874 3. Standards Components
876 3.1. Prerequisites for RIV
878 The Reference Interaction Model for Challenge-Response-based Remote
879 Attestation ([I-D.birkholz-rats-reference-interaction-model]) is
880 based on the standard roles defined in [I-D.ietf-rats-architecture].
881 However additional prerequisites have been established to allow for
882 interoperable RIV use case implementations. These prerequisites are
883 intended to provide sufficient context information so that the
884 Verifier can acquire and evaluate measurements collected by the
885 Attester.
887 3.1.1. Unique Device Identity
889 A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID
890 certificate [IEEE-802-1AR] MUST be provisioned in the Attester's
891 TPMs.
893 3.1.2. Keys
895 The Attestation Key (AK) and certificate MUST also be provisioned on
896 the Attester according to [Platform-DevID-TPM-2.0],
897 [PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2].
899 The Attester's TPM Keys MUST be associated with the DevID on the
900 Verifier (see [Platform-DevID-TPM-2.0] and Section 5 Security
901 Considerations, below).
903 3.1.3. Appraisal Policy for Evidence
905 The Verifier MUST obtain trustworthy Reference Values (encoded as
906 SWID or CoSWID tags [I-D.birkholz-yang-swid]). These reference
907 measurements will eventually be compared to signed PCR Evidence
908 ('quotes') acquired from an Attester's TPM using Attestation Policies
909 chosen by the administrator or owner of the device.
911 This document does not specify the format or contents for the
912 Appraisal Policy for Evidence, but Reference Values may be acquired
913 in one of two ways:
915 1. a Verifier may obtain reference measurements directly from an
916 Reference Value Provider chosen by the Verifier administrator
917 (e.g., through a web site).
919 2. Signed reference measurements may be distributed by the Reference
920 Value Provider to the Attester, as part of a software update.
921 From there, the reference measurement may be acquired by the
922 Verifier.
924 In either case, the Verifier Owner MUST select the source of trusted
925 Reference Values through the Appraisal Policy for Evidence.
927 ****************** .-------------. .-----------.
928 *Reference Value * | Attester | | Verifier/ |
929 *Provider * | | | Relying |
930 *(Device *----2--->| (Network |----2--->| Party |
931 *config * | Device) | |(Ntwk Mgmt |
932 *Authority) * | | | Station) |
933 ****************** '-------------' '-----------'
934 | ^
935 | |
936 '----------------1----------------------------'
938 Figure 4: Appraisal Policy for Evidence Prerequisites
940 In either case the Reference Values must be generated, acquired and
941 delivered in a secure way, including reference measurements of
942 firmware and bootable modules taken according to TCG PC Client
943 [PC-Client-BIOS-TPM-2.0] and Linux IMA [IMA]. Reference Values MUST
944 be encoded as SWID or CoSWID tags, signed by the device manufacturer,
945 as defined in the TCG RIM document [RIM], compatible with NIST IR
946 8060 [NIST-IR-8060] or the IETF CoSWID draft [I-D.ietf-sacm-coswid].
948 3.2. Reference Model for Challenge-Response
950 Once the prerequisites for RIV are met, a Verifier is able to acquire
951 Evidence from an Attester. The following diagram illustrates a RIV
952 information flow between a Verifier and an Attester, derived from
953 Section 8.1 of [I-D.birkholz-rats-reference-interaction-model].
954 Event times shown correspond to the time types described within
955 Appendix A of [I-D.ietf-rats-architecture]:
957 .----------. .--------------------------.
958 | Attester | | Relying Party / Verifier |
959 '--------- ' '--------------------------'
960 time(VG) |
961 valueGeneration(targetEnvironment) |
962 | => claims |
963 | |
964 | <-----------requestEvidence(nonce, PcrSelection)----time(NS)
965 | |
966 time(EG) |
967 evidenceGeneration(nonce, PcrSelection, collectedClaims) |
968 | => SignedPcrEvidence(nonce, PcrSelection) |
969 | => LogEvidence(collectedClaims) |
970 | |
971 | returnSignedPcrEvidence-------------------------------> |
972 | returnLogEvidence-------------------------------------> |
973 | |
974 | time(RG,RA)
975 | evidenceAppraisal(SignedPcrEvidence, eventLog, refClaims)
976 | attestationResult <= |
977 ~ ~
978 | time(RX)
980 Figure 5: IETF Attestation Information Flow
982 o Step 1 (time(VG)): One or more Attesting Network Device PCRs are
983 extended with measurements. RIV provides no direct link between
984 the time at which the event takes place and the time that it's
985 attested, although streaming attestation as in
986 [I-D.birkholz-rats-network-device-subscription] could.
988 o Step 2 (time(NS)): The Verifier generates a unique random nonce
989 ("number used once"), and makes a request attestation data for one
990 or more PCRs from an Attester. For interoperability, this MUST be
991 accomplished via a YANG [RFC7950] interface that implements the
992 TCG TAP model (e.g., YANG Module for Basic Challenge-Response-
993 based Remote Attestation Procedures
994 [I-D.ietf-rats-yang-tpm-charra]).
996 o Step 3 (time(EG)): On the Attester, measured values are retrieved
997 from the Attester's TPM. This requested PCR evidence, along with
998 the Verifier's nonce, called a Quote, is signed by the Attestation
999 Key (AK) associated with the DevID. Quotes are retrieved
1000 according to TCG TAP Information Model [TAP]. At the same time,
1001 the Attester collects log evidence showing the values have been
1002 extended into that PCR. Section 9.1 gives more detail on how this
1003 works.
1005 o Step 4: Collected Evidence is passed from the Attester to the
1006 Verifier
1008 o Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes
1009 action as needed. As the interaction between Relying Party and
1010 Verifier is out of scope for RIV, this can be described as one
1011 step.
1013 * If the signature covering TPM Evidence is not correct, the
1014 device SHOULD NOT be trusted.
1016 * If the nonce in the response doesn't match the Verifier's
1017 nonce, the response may be a replay, and device SHOULD NOT be
1018 trusted.
1020 * If the signed PCR values do not match the set of log entries
1021 which have extended a particular PCR, the device SHOULD NOT be
1022 trusted.
1024 * If the log entries that the Verifier considers important do not
1025 match known good values, the device SHOULD NOT be trusted. We
1026 note that the process of collecting and analyzing the log can
1027 be omitted if the value in the relevant PCR is already a known-
1028 good value.
1030 * If the set of log entries are not seen as acceptable by the
1031 Appraisal Policy for Evidence, the device SHOULD NOT be
1032 trusted.
1034 * If time(RG)-time(NS) is greater than the Appraisal Policy for
1035 Evidence's threshold for assessing freshness, the Evidence is
1036 considered stale and SHOULD NOT be trusted.
1038 3.2.1. Transport and Encoding
1040 Network Management systems may retrieve signed PCR based Evidence as
1041 shown in Figure 5, and can be accomplished via NETCONF or RESTCONF,
1042 with XML, JSON, or CBOR encoded Evidence.
1044 Implementations that use NETCONF MUST do so over a TLS or SSH secure
1045 tunnel. Implementations that use RESTCONF transport MUST do so over
1046 a TLS or SSH secure tunnel.
1048 Retrieval of Log Evidence SHOULD be done via log interfaces specified
1049 in [I-D.ietf-rats-yang-tpm-charra]).
1051 3.3. Centralized vs Peer-to-Peer
1053 Figure 5 above assumes that the Verifier is trusted, while the
1054 Attester is not. In a Peer-to-Peer application such as two routers
1055 negotiating a trust relationship
1056 [I-D.voit-rats-trusted-path-routing], the two peers can each ask the
1057 other to prove software integrity. In this application, the
1058 information flow is the same, but each side plays a role both as an
1059 Attester and a Verifier. Each device issues a challenge, and each
1060 device responds to the other's challenge, as shown in Figure 6.
1061 Peer-to-peer challenges, particularly if used to establish a trust
1062 relationship between routers, require devices to carry their own
1063 signed reference measurements (RIMs). Devices may also have to carry
1064 Appraisal Policy for Evidence for each possible peer device so that
1065 each device has everything needed for remote attestation, without
1066 having to resort to a central authority.
1068 +---------------+ +---------------+
1069 | RefVal | | RefVal |
1070 | Provider A | | Provider B |
1071 | Firmware | | Firmware |
1072 | Configuration | | Configuration |
1073 | Authority | | Authority |
1074 | | | |
1075 +---------------+ +---------------+
1076 | |
1077 | +------------+ +------------+ |
1078 | | | Step 1 | | | \
1079 | | Attester |<------>| Verifier | | |
1080 | | |<------>| | | | Router B
1081 +------>| | Step 2 | | | |- Challenges
1082 Step 0A| | | | | | Router A
1083 | |------->| | | |
1084 |- Router A -| Step 3 |- Router B -| | /
1085 | | | | |
1086 | | | | |
1087 | | Step 1 | | | \
1088 | Verifier |<------>| Attester |<-+ | Router A
1089 | |<------>| | |- Challenges
1090 | | Step 2 | | | Router B
1091 | | | | |
1092 | |<-------| | |
1093 +------------+ Step 3 +------------+ /
1095 Figure 6: Peer-to-Peer Attestation Information Flow
1097 In this application, each device may need to be equipped with signed
1098 RIMs to act as an Attester, and also an Appraisal Policy for Evidence
1099 and a selection of trusted X.509 root certificates, to allow the
1100 device to act as a Verifier. An existing link layer protocol such as
1101 802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being
1102 enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable
1103 methods for such an exchange.
1105 4. Privacy Considerations
1107 Network equipment, such as routers, switches and firewalls, has a key
1108 role to play in guarding the privacy of individuals using the
1109 network. Network equipment generally adheres to several rules to
1110 protect privacy:
1112 o Packets passing through the device must not be sent to
1113 unauthorized destinations. For example:
1115 * Routers often act as Policy Enforcement Points, where
1116 individual subscribers may be checked for authorization to
1117 access a network. Subscriber login information must not be
1118 released to unauthorized parties.
1120 * Network equipment is often called upon to block access to
1121 protected resources from unauthorized users.
1123 o Routing information, such as the identity of a router's peers,
1124 must not be leaked to unauthorized neighbors.
1126 o If configured, encryption and decryption of traffic must be
1127 carried out reliably, while protecting keys and credentials.
1129 Functions that protect privacy are implemented as part of each layer
1130 of hardware and software that makes up the networking device. In
1131 light of these requirements for protecting the privacy of users of
1132 the network, the network equipment must identify itself, and its boot
1133 configuration and measured device state (for example, PCR values), to
1134 the equipment's administrator, so there's no uncertainty as to what
1135 function each device and configuration is configured to carry out.
1136 Attestation is a component that allows the administrator to ensure
1137 that the network provides individual and peer privacy guarantees,
1138 even though the device itself may not have a right to keep its
1139 identity secret.
1141 RIV specifically addresses the collection of information from
1142 enterprise network devices by authorized agents of the enterprise.
1143 As such, privacy is a fundamental concern for those deploying this
1144 solution, given EU GDPR, California CCPA, and many other privacy
1145 regulations. The enterprise SHOULD implement and enforce their duty
1146 of care.
1148 See [NetEq] for more context on privacy in networking devices.
1150 5. Security Considerations
1152 Attestation Evidence from the RIV procedure are subject to a number
1153 of attacks:
1155 o Keys may be compromised.
1157 o A counterfeit device may attempt to impersonate (spoof) a known
1158 authentic device.
1160 o Man-in-the-middle attacks may be used by a counterfeit device to
1161 attempt to deliver responses that originate in an actual authentic
1162 device.
1164 o Replay attacks may be attempted by a compromised device.
1166 5.1. Keys Used in RIV
1168 Trustworthiness of RIV attestation depends strongly on the validity
1169 of keys used for identity and attestation reports. RIV takes full
1170 advantage of TPM capabilities to ensure that evidence can be trusted.
1172 Two sets of key-pairs are relevant to RIV attestation:
1174 o A DevID key-pair is used to certify the identity of the device in
1175 which the TPM is installed.
1177 o An Attestation Key-pair (AK) key is used to certify attestation
1178 Evidence (called 'quotes' in TCG documents), used to provide
1179 evidence for integrity of the software on the device
1181 TPM practices usually require that these keys be different, as a way
1182 of ensuring that a general-purpose signing key cannot be used to
1183 spoof an attestation quote.
1185 In each case, the private half of the key is known only to the TPM,
1186 and cannot be retrieved externally, even by a trusted party. To
1187 ensure that's the case, specification-compliant private/public key-
1188 pairs are generated inside the TPM, where they're never exposed, and
1189 cannot be extracted (See [Platform-DevID-TPM-2.0]).
1191 Keeping keys safe is a critical enabler of trustworthiness, but it's
1192 just part of attestation security; knowing which keys are bound to
1193 the device in question is just as important in an environment where
1194 private keys are never exposed.
1196 While there are many ways to manage keys in a TPM (see
1197 [Platform-DevID-TPM-2.0]), RIV includes support for "zero touch"
1198 provisioning (also known as zero-touch onboarding) of fielded devices
1199 (e.g., Secure ZTP, [RFC8572]), where keys which have predictable
1200 trust properties are provisioned by the device vendor.
1202 Device identity in RIV is based on IEEE 802.1AR Device Identity
1203 (DevID). This specification provides several elements:
1205 o A DevID requires a unique key pair for each device, accompanied by
1206 an X.509 certificate,
1208 o The private portion of the DevID key is to be stored in the
1209 device, in a manner that provides confidentiality (Section 6.2.5
1210 [IEEE-802-1AR])
1212 The X.509 certificate contains several components:
1214 o The public part of the unique DevID key assigned to that device
1215 allows a challenge of identity.
1217 o An identifying string that's unique to the manufacturer of the
1218 device. This is normally the serial number of the unit, which
1219 might also be printed on a label on the device.
1221 o The certificate must be signed by a key traceable to the
1222 manufacturer's root key.
1224 With these elements, the device's manufacturer and serial number can
1225 be identified by analyzing the DevID certificate plus the chain of
1226 intermediate certificates leading back to the manufacturer's root
1227 certificate. As is conventional in TLS or SSH connections, a random
1228 nonce must be signed by the device in response to a challenge,
1229 proving possession of its DevID private key.
1231 RIV uses the DevID to validate a TLS or SSH connection to the device
1232 as the attestation session begins. Security of this process derives
1233 from TLS or SSH security, with the DevID providing proof that the
1234 session terminates on the intended device. See [RFC8446], [RFC4253].
1236 Evidence of software integrity is delivered in the form of a quote
1237 signed by the TPM itself. Because the contents of the quote are
1238 signed inside the TPM, any external modification (including
1239 reformatting to a different data format) after measurements have been
1240 taken will be detected as tampering. An unbroken chain of trust is
1241 essential to ensuring that blocks of code that are taking
1242 measurements have been verified before execution (see Figure 1).
1244 Requiring measurements of the operating software to be signed by a
1245 key known only to the TPM also removes the need to trust the device's
1246 operating software (beyond the first measurement in the RTM; see
1247 below); any changes to the quote, generated and signed by the TPM
1248 itself, made by malicious device software, or in the path back to the
1249 Verifier, will invalidate the signature on the quote.
1251 A critical feature of the YANG model described in
1252 [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data
1253 structures in their native format, without requiring any changes to
1254 the structures as they were signed and delivered by the TPM. While
1255 alternate methods of conveying TPM quotes could compress out
1256 redundant information, or add an additional layer of signing using
1257 external keys, the implementation MUST preserve the TPM signing, so
1258 that tampering anywhere in the path between the TPM itself and the
1259 Verifier can be detected.
1261 5.2. Prevention of Spoofing and Man-in-the-Middle Attacks
1263 Prevention of spoofing attacks against attestation systems is also
1264 important. There are two cases to consider:
1266 o The entire device could be spoofed. If the Verifier goes to
1267 appraise a specific Attester, it might be redirected to a
1268 different Attester. Use of the 802.1AR Device Identity (DevID) in
1269 the TPM ensures that the Verifier's TLS or SSH session is in fact
1270 terminating on the right device.
1272 o A device with a compromised OS could return a fabricated quote
1273 providing spoofed attestation Evidence.
1275 Protection against spoofed quotes from a device with valid identity
1276 is a bit more complex. An identity key must be available to sign any
1277 kind of nonce or hash offered by the Verifier, and consequently,
1278 could be used to sign a fabricated quote. To block a spoofed
1279 Attestation Result, the quote generated inside the TPM must be signed
1280 by a key that's different from the DevID, called an Attestation Key
1281 (AK).
1283 Given separate Attestation and DevID keys, the binding between the AK
1284 and the same device must also be proven to prevent a man-in-the-
1285 middle attack (e.g., the 'Asokan Attack' [RFC6813]).
1287 This is accomplished in RIV through use of an AK certificate with the
1288 same elements as the DevID (same manufacturer's serial number, signed
1289 by the same manufacturer's key), but containing the device's unique
1290 AK public key instead of the DevID public key.
1292 The TCG document TPM 2.0 Keys for Device Identity and Attestation
1293 [Platform-DevID-TPM-2.0] specifies OIDs for Attestation Certificates
1294 that allow the CA to mark a key as specifically known to be an
1295 Attestation key.
1297 These two key-pairs and certificates are used together:
1299 o The DevID is used to validate a TLS connection terminating on the
1300 device with a known serial number.
1302 o The AK is used to sign attestation quotes, providing proof that
1303 the attestation evidence comes from the same device.
1305 5.3. Replay Attacks
1307 Replay attacks, where results of a previous attestation are submitted
1308 in response to subsequent requests, are usually prevented by
1309 inclusion of a random nonce in the request to the TPM for a quote.
1310 Each request from the Verifier includes a new random number (a
1311 nonce). The resulting quote signed by the TPM contains the same
1312 nonce, allowing the Verifier to determine freshness, (i.e., that the
1313 resulting quote was generated in response to the Verifier's specific
1314 request). Time-Based Uni-directional Attestation
1315 [I-D.birkholz-rats-tuda] provides an alternate mechanism to verify
1316 freshness without requiring a request/response cycle.
1318 5.4. Owner-Signed Keys
1320 Although device manufacturers MUST pre-provision devices with easily
1321 verified DevID and AK certificates if zero-touch provisioning such as
1322 described in [RFC8572] is to be supported, use of those credentials
1323 is not mandatory. IEEE 802.1AR incorporates the idea of an Initial
1324 Device ID (IDevID), provisioned by the manufacturer, and a Local
1325 Device ID (LDevID) provisioned by the owner of the device. RIV and
1326 [Platform-DevID-TPM-2.0] extends that concept by defining an Initial
1327 Attestation Key (IAK) and Local Attestation Key (LAK) with the same
1328 properties.
1330 Device owners can use any method to provision the Local credentials.
1332 o TCG document [Platform-DevID-TPM-2.0] shows how the initial
1333 Attestation keys can be used to certify LDevID and LAK keys. Use
1334 of the LDevID and LAK allows the device owner to use a uniform
1335 identity structure across device types from multiple manufacturers
1336 (in the same way that an "Asset Tag" is used by many enterprises
1337 to identify devices they own). TCG document
1338 [Provisioning-TPM-2.0] also contains guidance on provisioning
1339 Initial and Local identity keys in TPM 2.0.
1341 o Device owners, however, can use any other mechanism they want to
1342 assure themselves that local identity certificates are inserted
1343 into the intended device, including physical inspection and
1344 programming in a secure location, if they prefer to avoid placing
1345 trust in the manufacturer-provided keys.
1347 Clearly, local keys can't be used for secure Zero Touch provisioning;
1348 installation of the local keys can only be done by some process that
1349 runs before the device is installed for network operation.
1351 On the other end of the device life cycle, provision should be made
1352 to wipe local keys when a device is decommissioned, to indicate that
1353 the device is no longer owned by the enterprise. The manufacturer's
1354 Initial identity keys must be preserved, as they contain no
1355 information that's not already printed on the device's serial number
1356 plate.
1358 5.5. Other Factors for Trustworthy Operation
1360 In addition to trustworthy provisioning of keys, RIV depends on a
1361 number of other factors for trustworthy operation.
1363 o Secure identity depends on mechanisms to prevent per-device secret
1364 keys from being compromised. The TPM provides this capability as
1365 a Root of Trust for Storage.
1367 o Attestation depends on an unbroken chain of measurements, starting
1368 from the very first measurement. See Section 9.1 for background
1369 on TPM practices.
1371 o That first measurement is made by code called the Root of Trust
1372 for Measurement, typically done by trusted firmware stored in boot
1373 flash. Mechanisms for maintaining the trustworthiness of the RTM
1374 are out of scope for RIV, but could include immutable firmware,
1375 signed updates, or a vendor-specific hardware verification
1376 technique. See Section 9.2 for background on roots of trust.
1378 o The device owner SHOULD provide some level of physical defense for
1379 the device. If a TPM that has already been programmed with an
1380 authentic DevID is stolen and inserted into a counterfeit device,
1381 attestation of that counterfeit device may become
1382 indistinguishable from an authentic device.
1384 RIV also depends on reliable Reference Values, as expressed by the
1385 RIM [RIM]. The definition of trust procedures for RIMs is out of
1386 scope for RIV, and the device owner is free to use any policy to
1387 validate a set of reference measurements. RIMs may be conveyed out-
1388 of-band or in-band, as part of the attestation process (see
1389 Section 3.1.3). But for embedded devices, where software is usually
1390 shipped as a self-contained package, RIMs signed by the manufacturer
1391 and delivered in-band may be more convenient for the device owner.
1393 The validity of RIV attestation results is also influenced by
1394 procedures used to create Reference Values:
1396 o While the RIM itself is signed, supply-chains SHOULD be carefully
1397 scrutinized to ensure that the values are not subject to
1398 unexpected manipulation prior to signing. Insider-attacks against
1399 code bases and build chains are particularly hard to spot.
1401 o Designers SHOULD guard against hash collision attacks. Reference
1402 Integrity Manifests often give hashes for large objects of
1403 indeterminate size; if one of the measured objects can be replaced
1404 with an implant engineered to produce the same hash, RIV will be
1405 unable to detect the substitution. TPM1.2 uses SHA-1 hashes only,
1406 which have been shown to be susceptible to collision attack.
1407 TPM2.0 will produce quotes with SHA-256, which so far has resisted
1408 such attacks. Consequently, RIV implementations SHOULD use
1409 TPM2.0.
1411 6. Conclusion
1413 TCG technologies can play an important part in the implementation of
1414 Remote Integrity Verification. Standards for many of the components
1415 needed for implementation of RIV already exist:
1417 o Platform identity can be based on IEEE 802.1AR Device Identity,
1418 coupled with careful supply-chain management by the manufacturer.
1420 o Complex supply chains can be certified using TCG Platform
1421 Certificates [Platform-Certificates].
1423 o The TCG TAP mechanism couple with [I-D.ietf-rats-yang-tpm-charra]
1424 can be used to retrieve attestation evidence.
1426 o Reference Values must be conveyed from the software authority
1427 (e.g., the manufacturer) in Reference Integrity Manifests, to the
1428 system in which verification will take place. IETF and TCG SWID
1429 and CoSWID work ([I-D.birkholz-yang-swid], [RIM])) forms the basis
1430 for this function.
1432 7. IANA Considerations
1434 This memo includes no request to IANA.
1436 8. Acknowledgements
1438 The authors wish to thank numerous reviewers for generous assistance,
1439 including William Bellingrath, Mark Baushke, Ned Smith, Henk
1440 Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas
1441 Hardjono, Bill Sulzen, Monty Wiseman, Kathleen Moriarty, Nancy Cam-
1442 Winget and Shwetha Bhandari
1444 9. Appendix
1446 9.1. Using a TPM for Attestation
1448 The Trusted Platform Module and surrounding ecosystem provide three
1449 interlocking capabilities to enable secure collection of evidence
1450 from a remote device, Platform Configuration Registers (PCRs), a
1451 Quote mechanism, and a standardized Event Log.
1453 Each TPM has at least eight and at most twenty-four PCRs (depending
1454 on the profile and vendor choices), each one large enough to hold one
1455 hash value (SHA-1, SHA-256, and other hash algorithms can be used,
1456 depending on TPM version). PCRs can't be accessed directly from
1457 outside the chip, but the TPM interface provides a way to "extend" a
1458 new security measurement hash into any PCR, a process by which the
1459 existing value in the PCR is hashed with the new security measurement
1460 hash, and the result placed back into the same PCR. The result is a
1461 composite fingerprint of all the security measurements extended into
1462 each PCR since the system was reset.
1464 Every time a PCR is extended, an entry should be added to the
1465 corresponding Event Log. Logs contain the security measurement hash
1466 plus informative fields offering hints as to which event generated
1467 the security measurement. The Event Log itself is protected against
1468 accidental manipulation, but it is implicitly tamper-evident - any
1469 verification process can read the security measurement hash from the
1470 log events, compute the composite value and compare that to what
1471 ended up in the PCR. If there's no discrepancy, the logs do provide
1472 an accurate view of what was placed into the PCR.
1474 Note that the composite hash-of-hashes recorded in PCRs is order-
1475 dependent, resulting in different PCR values for different ordering
1476 of the same set of events (e.g. Event A followed by Event B yields a
1477 different PCR value than B followed by A). For single-threaded code,
1478 where both the events and their order are fixed, a Verifier may
1479 validate a single PCR value, and use the log only to diagnose a
1480 mismatch from Reference Values. However, operating system code is
1481 usually non-deterministic, meaning that there may never be a single
1482 "known good" PCR value. In this case, the Verifier may have to
1483 verify that the log is correct, and then analyze each item in the log
1484 to determine if it represents an authorized event.
1486 In a conventional TPM Attestation environment, the first measurement
1487 must be made and extended into the TPM by trusted device code (called
1488 the Root of Trust for Measurement, RTM). That first measurement
1489 should cover the segment of code that is run immediately after the
1490 RTM, which then measures the next code segment before running it, and
1491 so on, forming an unbroken chain of trust. See [TCGRoT] for more on
1492 Mutable vs Immutable roots of trust.
1494 The TPM provides another mechanism called a Quote that can read the
1495 current value of the PCRs and package them, along with the Verifier's
1496 nonce, into a TPM-specific data structure signed by an Attestation
1497 private key, known only to the TPM.
1499 As noted above in Section 5 Security Considerations, it's important
1500 to note that the Quote data structure is signed inside the TPM. The
1501 trust model is preserved by retrieving the Quote in a way that does
1502 not invalidate the signature, as specified in
1503 [I-D.ietf-rats-yang-tpm-charra].
1505 The Verifier uses the Quote and Log together. The Quote contains the
1506 composite hash of the complete sequence of security measurement
1507 hashes, signed by the TPM's private Attestation Key. The Log
1508 contains a record of each measurement extended into the TPM's PCRs.
1509 By computing the composite hash of all the measurements, the Verifier
1510 can verify the integrity of the Event Log, even though the Event Log
1511 itself is not signed. Each hash in the validated Event Log can then
1512 be compared to corresponding expected values in the set of Reference
1513 Values to validate overall system integrity.
1515 A summary of information exchanged in obtaining quotes from TPM1.2
1516 and TPM2.0 can be found in [TAP], Section 4. Detailed information
1517 about PCRs and Quote data structures can be found in [TPM1.2],
1518 [TPM2.0]. Recommended log formats include [PC-Client-BIOS-TPM-2.0]
1519 and [Canonical-Event-Log].
1521 9.2. Root of Trust for Measurement
1523 The measurements needed for attestation require that the device being
1524 attested is equipped with a Root of Trust for Measurement, that is,
1525 some trustworthy mechanism that can compute the first measurement in
1526 the chain of trust required to attest that each stage of system
1527 startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs)
1528 to record the results, and a Root of Trust for Reporting to report
1529 the results [TCGRoT], [SP800-155], [SP800-193].
1531 While there are many complex aspects of a Root of Trust, two aspects
1532 that are important in the case of attestation are:
1534 o The first measurement computed by the Root of Trust for
1535 Measurement, and stored in the TPM's Root of Trust for Storage,
1536 must be assumed to be correct.
1538 o There must not be a way to reset the Root of Trust for Storage
1539 without re-entering the Root of Trust for Measurement code.
1541 The first measurement must be computed by code that is implicitly
1542 trusted; if that first measurement can be subverted, none of the
1543 remaining measurements can be trusted. (See [SP800-155])
1545 It's important to note that the trustworthiness of the RTM code
1546 cannot be assured by the TPM or TPM supplier - code or procedures
1547 external to the TPM must guarantee the security of the RTM.
1549 9.3. Layering Model for Network Equipment Attester and Verifier
1551 Retrieval of identity and attestation state uses one protocol stack,
1552 while retrieval of Reference Values uses a different set of
1553 protocols. Figure 5 shows the components involved.
1555 +-----------------------+ +-------------------------+
1556 | | | |
1557 | Attester |<-------------| Verifier |
1558 | (Device) |------------->| (Management Station) |
1559 | | | | |
1560 +-----------------------+ | +-------------------------+
1561 |
1562 -------------------- --------------------
1563 | |
1564 ------------------------------- ---------------------------------
1565 |Reference Values | | Attestation |
1566 ------------------------------- ---------------------------------
1568 ********************************************************************
1569 * IETF Attestation Reference Interaction Diagram *
1570 ********************************************************************
1572 ....................... .......................
1573 . Reference Integrity . . TAP (PTS2.0) Info .
1574 . Manifest . . Model and Canonical .
1575 . . . Log Format .
1576 ....................... .......................
1578 ************************* .............. **********************
1579 * YANG SWID Module * . TCG . * YANG Attestation *
1580 * I-D.birkholz-yang-swid* . Attestation. * Module *
1581 * * . MIB . * I-D.ietf-rats- *
1582 * * . . * yang-tpm-charra *
1583 ************************* .............. **********************
1585 ************************* ************ ************************
1586 * XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)*
1587 ************************* ************ ************************
1589 ************************* ************************
1590 * RESTCONF/NETCONF * * RESTCONF/NETCONF *
1591 ************************* ************************
1593 ************************* ************************
1594 * TLS, SSH * * TLS, SSH *
1595 ************************* ************************
1597 Figure 7: RIV Protocol Stacks
1599 IETF documents are captured in boxes surrounded by asterisks. TCG
1600 documents are shown in boxes surrounded by dots.
1602 9.4. Implementation Notes
1604 Figure 8 summarizes many of the actions needed to complete an
1605 Attestation system, with links to relevant documents. While
1606 documents are controlled by several standards organizations, the
1607 implied actions required for implementation are all the
1608 responsibility of the manufacturer of the device, unless otherwise
1609 noted. It should be noted that, while the YANG model is RECOMMENDED
1610 for attestation, this table identifies an optional SNMP MIB as well,
1611 [Attest-MIB].
1613 +------------------------------------------------------------------+
1614 | Component | Controlling |
1615 | | Specification |
1616 --------------------------------------------------------------------
1617 | Make a Secure execution environment | TCG RoT |
1618 | o Attestation depends on a secure root of | UEFI.org |
1619 | trust for measurement outside the TPM, as | |
1620 | well as roots for storage and reporting | |
1621 | inside the TPM. | |
1622 | o Refer to TCG Root of Trust for Measurement.| |
1623 | o NIST SP 800-193 also provides guidelines | |
1624 | on Roots of Trust | |
1625 --------------------------------------------------------------------
1626 | Provision the TPM as described in |[Platform-DevID-TPM-2.0]|
1627 | TCG documents. | TCG Platform |
1628 | | Certificate |
1629 --------------------------------------------------------------------
1630 | Put a DevID or Platform Cert in the TPM | TCG TPM DevID |
1631 | o Install an Initial Attestation Key at the | TCG Platform |
1632 | same time so that Attestation can work out | Certificate |
1633 | of the box |-----------------
1634 | o Equipment suppliers and owners may want to | IEEE 802.1AR |
1635 | implement Local Device ID as well as | |
1636 | Initial Device ID | |
1637 --------------------------------------------------------------------
1638 | Connect the TPM to the TLS stack | Vendor TLS |
1639 | o Use the DevID in the TPM to authenticate | stack (This |
1640 | TAP connections, identifying the device | action is |
1641 | | simply |
1642 | | configuring TLS|
1643 | | to use the DevID |
1644 | | as its client |
1645 | | certificate) |
1646 --------------------------------------------------------------------
1647 | Make CoSWID tags for BIOS/LoaderLKernel objects | IETF CoSWID |
1648 | o Add reference measurements into SWID tags | ISO/IEC 19770-2|
1649 | o Manufacturer should sign the SWID tags | NIST IR 8060 |
1650 | o The TCG RIM-IM identifies further | |
1651 | procedures to create signed RIM | |
1652 | documents that provide the necessary | |
1653 | reference information | |
1654 --------------------------------------------------------------------
1655 | Package the SWID tags with a vendor software | Retrieve tags |
1656 | release | with |
1657 | o A tag-generator plugin such | draft-birkholz-yang-swid|
1658 | as [SWID-Gen] can be used |----------------|
1659 | | TCG PC Client |
1660 | | RIM |
1661 --------------------------------------------------------------------
1662 | Use PC Client measurement definitions | TCG PC Client |
1663 | to define the use of PCRs | BIOS |
1664 | (although Windows OS is rare on Networking | |
1665 | Equipment, UEFI BIOS is not) | |
1666 --------------------------------------------------------------------
1667 | Use TAP to retrieve measurements | |
1668 | o Map TAP to SNMP | TCG SNMP MIB |
1669 | o Map to YANG | YANG Module for|
1670 | Use Canonical Log Format | Basic |
1671 | | Attestation |
1672 | | TCG Canonical |
1673 | | Log Format |
1674 --------------------------------------------------------------------
1675 | Posture Collection Server (as described in IETF | |
1676 | SACMs ECP) should request the | |
1677 | attestation and analyze the result | |
1678 | The Management application might be broken down | |
1679 | to several more components: | |
1680 | o A Posture Manager Server | |
1681 | which collects reports and stores them in | |
1682 | a database | |
1683 | o One or more Analyzers that can look at the| |
1684 | results and figure out what it means. | |
1685 --------------------------------------------------------------------
1687 Figure 8: Component Status
1689 10. References
1691 10.1. Normative References
1693 [Canonical-Event-Log]
1694 Trusted Computing Group, "DRAFT Canonical Event Log Format
1695 Version: 1.0, Revision: .12", October 2018.
1697 [I-D.birkholz-yang-swid]
1698 Birkholz, H., "Software Inventory YANG module based on
1699 Software Identifiers", draft-birkholz-yang-swid-02 (work
1700 in progress), October 2018.
1702 [I-D.ietf-rats-yang-tpm-charra]
1703 Birkholz, H., Eckel, M., Voit, E., Bhandari, S., Sulzen,
1704 B., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data
1705 Model for Challenge-Response-based Remote Attestation
1706 Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-03
1707 (work in progress), September 2020.
1709 [I-D.ietf-sacm-coswid]
1710 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
1711 Waltermire, "Concise Software Identification Tags", draft-
1712 ietf-sacm-coswid-16 (work in progress), November 2020.
1714 [IEEE-802-1AR]
1715 Seaman, M., "802.1AR-2018 - IEEE Standard for Local and
1716 Metropolitan Area Networks - Secure Device Identity, IEEE
1717 Computer Society", August 2018.
1719 [PC-Client-BIOS-TPM-1.2]
1720 Trusted Computing Group, "TCG PC Client Specific
1721 Implementation Specification for Conventional BIOS,
1722 Specification Version 1.21 Errata, Revision 1.00",
1723 February 2012,
1724 .
1728 [PC-Client-BIOS-TPM-2.0]
1729 Trusted Computing Group, "PC Client Specific Platform
1730 Firmware Profile Specification Family "2.0", Level 00
1731 Revision 1.04", June 2019,
1732 .
1735 [PC-Client-RIM]
1736 Trusted Computing Group, "DRAFT: TCG PC Client Reference
1737 Integrity Manifest Specification, v.09", December 2019,
1738 .
1741 [Platform-DevID-TPM-2.0]
1742 Trusted Computing Group, "TPM 2.0 Keys for Device Identity
1743 and Attestation, Specification Version 1.0, Revision 2",
1744 September 2020,
1745 .
1748 [Platform-ID-TPM-1.2]
1749 Trusted Computing Group, "TPM Keys for Platform Identity
1750 for TPM 1.2, Specification Version 1.0, Revision 3",
1751 August 2015, .
1754 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1755 Requirement Levels", BCP 14, RFC 2119,
1756 DOI 10.17487/RFC2119, March 1997,
1757 .
1759 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
1760 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
1761 January 2006, .
1763 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1764 and A. Bierman, Ed., "Network Configuration Protocol
1765 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1766 .
1768 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1769 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1770 .
1772 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1773 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1774 .
1776 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
1777 Touch Provisioning (SZTP)", RFC 8572,
1778 DOI 10.17487/RFC8572, April 2019,
1779 .
1781 [RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity
1782 Manifest Information Model", June 2019,
1783 .
1786 [SWID] The International Organization for Standardization/
1787 International Electrotechnical Commission, "Information
1788 Technology Software Asset Management Part 2: Software
1789 Identification Tag, ISO/IEC 19770-2", October 2015,
1790 .
1792 [TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol
1793 (TAP) Information Model for TPM Families 1.2 and 2.0 and
1794 DICE Family 1.0, Version 1.0, Revision 0.36", October
1795 2018, .
1798 10.2. Informative References
1800 [AK-Enrollment]
1801 Trusted Computing Group, "TCG Infrastructure Working Group
1802 - A CMC Profile for AIK Certificate Enrollment Version
1803 1.0, Revision 7", March 2011,
1804 .
1808 [Attest-MIB]
1809 Trusted Computing Group, "SNMP MIB for TPM-Based
1810 Attestation, Version 0.8Revision 0.02", May 2018,
1811 .
1815 [EFI-TPM] Trusted Computing Group, "TCG EFI Platform Specification
1816 for TPM Family 1.1 or 1.2, Specification Version 1.22,
1817 Revision 15", January 2014,
1818 .
1821 [I-D.birkholz-rats-network-device-subscription]
1822 Birkholz, H., Voit, E., and W. Pan, "Attestation Event
1823 Stream Subscription", draft-birkholz-rats-network-device-
1824 subscription-01 (work in progress), October 2020.
1826 [I-D.birkholz-rats-reference-interaction-model]
1827 Birkholz, H., Eckel, M., Newton, C., and L. Chen,
1828 "Reference Interaction Models for Remote Attestation
1829 Procedures", draft-birkholz-rats-reference-interaction-
1830 model-03 (work in progress), July 2020.
1832 [I-D.birkholz-rats-tuda]
1833 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
1834 "Time-Based Uni-Directional Attestation", draft-birkholz-
1835 rats-tuda-03 (work in progress), July 2020.
1837 [I-D.ietf-rats-architecture]
1838 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
1839 W. Pan, "Remote Attestation Procedures Architecture",
1840 draft-ietf-rats-architecture-07 (work in progress),
1841 October 2020.
1843 [I-D.ietf-rats-eat]
1844 Mandyam, G., Lundblade, L., Ballesteros, M., and J.
1845 O'Donoghue, "The Entity Attestation Token (EAT)", draft-
1846 ietf-rats-eat-06 (work in progress), December 2020.
1848 [I-D.richardson-rats-usecases]
1849 Richardson, M., Wallace, C., and W. Pan, "Use cases for
1850 Remote Attestation common encodings", draft-richardson-
1851 rats-usecases-08 (work in progress), November 2020.
1853 [I-D.voit-rats-trusted-path-routing]
1854 Voit, E., "Trusted Path Routing", draft-voit-rats-trusted-
1855 path-routing-02 (work in progress), June 2020.
1857 [IEEE-802.1AE]
1858 Seaman, M., "802.1AE MAC Security (MACsec)", 2018,
1859 .
1861 [IEEE-802.1X]
1862 IEEE Computer Society, "802.1X-2020 - IEEE Standard for
1863 Local and Metropolitan Area Networks--Port-Based Network
1864 Access Control", February 2020,
1865 .
1867 [IMA] and , "Integrity Measurement Architecture", June 2019,
1868 .
1870 [LLDP] IEEE Computer Society, "802.1AB-2016 - IEEE Standard for
1871 Local and metropolitan area networks - Station and Media
1872 Access Control Connectivity Discovery", March 2016,
1873 .
1875 [NetEq] Trusted Computing Group, "TCG Guidance for Securing
1876 Network Equipment, Version 1.0, Revision 29", January
1877 2018, .
1880 [NIST-IR-8060]
1881 National Institute for Standards and Technology,
1882 "Guidelines for the Creation of Interoperable Software
1883 Identification (SWID) Tags", April 2016,
1884 .
1887 [Platform-Certificates]
1888 Trusted Computing Group, "TCG Platform Attribute
1889 Credential Profile, Specification Version 1.0, Revision
1890 16", January 2018,
1891 .
1894 [Provisioning-TPM-2.0]
1895 Trusted Computing Group, "TCG TPM v2.0 Provisioning
1896 Guidance, Version 1.0, Revision 1.0", March 2015,
1897 .
1900 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
1901 Levkowetz, Ed., "Extensible Authentication Protocol
1902 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
1903 .
1905 [RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment
1906 (NEA) Asokan Attack Analysis", RFC 6813,
1907 DOI 10.17487/RFC6813, December 2012,
1908 .
1910 [SP800-155]
1911 National Institute of Standards and Technology, "BIOS
1912 Integrity Measurement Guidelines (Draft)", December 2011,
1913 .
1916 [SP800-193]
1917 National Institute for Standards and Technology, "NIST
1918 Special Publication 800-193: Platform Firmware Resiliency
1919 Guidelines", April 2018,
1920 .
1923 [SWID-Gen]
1924 Labs64, Munich, Germany, "SoftWare IDentification (SWID)
1925 Tags Generator (Maven Plugin)", n.d.,
1926 .
1928 [TCGRoT] Trusted Computing Group, "DRAFT: TCG Roots of Trust
1929 Specification", October 2018,
1930 .
1933 [TPM1.2] Trusted Computing Group, "TPM Main Specification Level 2
1934 Version 1.2, Revision 116", March 2011,
1935 .
1938 [TPM2.0] Trusted Computing Group, "Trusted Platform Module Library
1939 Specification, Family "2.0", Level 00, Revision 01.59",
1940 November 2019,
1941 .
1944 Authors' Addresses
1946 Guy Fedorkow (editor)
1947 Juniper Networks, Inc.
1948 US
1950 Email: gfedorkow@juniper.net
1952 Eric Voit
1953 Cisco Systems, Inc.
1954 US
1956 Email: evoit@cisco.com
1958 Jessica Fitzgerald-McKay
1959 National Security Agency
1960 US
1962 Email: jmfitz2@nsa.gov