idnits 2.17.00 (12 Aug 2021)
/tmp/idnits11883/draft-ietf-rats-tpm-based-network-device-attest-14.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 document date (22 March 2022) is 53 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Looks like a reference, but probably isn't: '0' on line 591
-- Looks like a reference, but probably isn't: '2' on line 602
-- Looks like a reference, but probably isn't: '4' on line 604
-- Looks like a reference, but probably isn't: '8' on line 610
-- Looks like a reference, but probably isn't: '5' on line 607
== Outdated reference: A later version (-19) exists of
draft-ietf-rats-yang-tpm-charra-18
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 RATS Working Group G. C. Fedorkow, Ed.
3 Internet-Draft Juniper Networks, Inc.
4 Intended status: Informational E. Voit
5 Expires: 23 September 2022 Cisco
6 J. Fitzgerald-McKay
7 National Security Agency
8 22 March 2022
10 TPM-based Network Device Remote Integrity Verification
11 draft-ietf-rats-tpm-based-network-device-attest-14
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)), or equivalent hardware
19 implementations that include the protected capabilities, as provided
20 by TPMs.
22 Status of This Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at https://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on 23 September 2022.
39 Copyright Notice
41 Copyright (c) 2022 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents (https://trustee.ietf.org/
46 license-info) in effect on the date of publication of this document.
47 Please review these documents carefully, as they describe your rights
48 and restrictions with respect to this document. Code Components
49 extracted from this document must include Revised BSD License text as
50 described in Section 4.e of the Trust Legal Provisions and are
51 provided without warranty as described in the Revised BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
56 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
58 1.3. Document Organization . . . . . . . . . . . . . . . . . . 5
59 1.4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
60 1.5. Description of Remote Integrity Verification (RIV) . . . 6
61 1.6. Solution Requirements . . . . . . . . . . . . . . . . . . 8
62 1.7. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8
63 1.7.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 9
64 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9
65 2.1. RIV Software Configuration Attestation using TPM . . . . 9
66 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 11
67 2.1.2. Notes on PCR Allocations . . . . . . . . . . . . . . 13
68 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 15
69 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 16
70 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 18
71 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 18
72 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 20
73 3. Standards Components . . . . . . . . . . . . . . . . . . . . 20
74 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 20
75 3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 20
76 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 21
77 3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 21
78 3.2. Reference Model for Challenge-Response . . . . . . . . . 21
79 3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 23
80 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24
81 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
83 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 26
84 5.2. Prevention of Spoofing and Person-in-the-Middle
85 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 28
86 5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29
87 5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 30
88 5.5. Other Factors for Trustworthy Operation . . . . . . . . . 30
89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
90 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 32
91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
92 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32
93 9.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 32
94 9.2. Root of Trust for Measurement . . . . . . . . . . . . . . 34
95 9.3. Layering Model for Network Equipment Attester and
96 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 35
98 9.4. Implementation Notes . . . . . . . . . . . . . . . . . . 37
99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
100 10.1. Normative References . . . . . . . . . . . . . . . . . . 38
101 10.2. Informative References . . . . . . . . . . . . . . . . . 41
102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
104 1. Introduction
106 There are many aspects to consider in fielding a trusted computing
107 device, from operating systems to applications. Mechanisms to prove
108 that a device installed at a customer's site is authentic (i.e., not
109 counterfeit) and has been configured with authorized software, all as
110 part of a trusted supply chain, are just a few of the many aspects
111 which need to be considered concurrently to have confidence that a
112 device is truly trustworthy.
114 A generic architecture for remote attestation has been defined in
115 [I-D.ietf-rats-architecture]. Additionally, use cases for remotely
116 attesting networking devices are discussed within Section 6 of
117 [I-D.richardson-rats-usecases]. However, these documents do not
118 provide sufficient guidance for network equipment vendors and
119 operators to design, build, and deploy interoperable devices.
121 The intent of this document is to provide such guidance. It does
122 this by outlining the Remote Integrity Verification (RIV) problem,
123 and then identifies elements that are necessary to get the complete,
124 scalable attestation procedure working with commercial networking
125 products such as routers, switches and firewalls. An underlying
126 assumption will be the availability within the device of a Trusted
127 Platform Module [TPM1.2], [TPM2.0] compatible cryptoprocessor to
128 enable the trustworthy remote assessment of the device's software and
129 hardware.
131 1.1. Requirements notation
133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
135 "OPTIONAL" in this document are to be interpreted as described in BCP
136 14 [RFC2119] [RFC8174] when, and only when, they appear in all
137 capitals, as shown here.
139 1.2. Terminology
141 A number of terms are reused from [I-D.ietf-rats-architecture].
142 These include: Appraisal Policy for Evidence, Attestation Result,
143 Attester, Evidence, Reference Value, Relying Party, Verifier, and
144 Verifier Owner.
146 Additionally, this document defines the following term:
148 Attestation: the process of generating, conveying and appraising
149 claims, backed by evidence, about device trustworthiness
150 characteristics, including supply chain trust, identity, device
151 provenance, software configuration, device composition, compliance to
152 test suites, functional and assurance evaluations, etc.
154 The goal of attestation is simply to assure an administrator or
155 auditor that the device configuration and software that was launched
156 when the device was last started is authentic and untampered-with.
157 The determination of software authenticity is not prescribed in this
158 document, but it's typically taken to mean a software image generated
159 by an authority trusted by the administrator, such as the device
160 manufacturer.
162 Within the Trusted Computing Group (TCG) context, the scope of
163 attestation is typically narrowed to describe the process by which an
164 independent Verifier can obtain cryptographic proof as to the
165 identity of the device in question, and evidence of the integrity of
166 software loaded on that device when it started up, and then verify
167 that what's there matches the intended configuration. For network
168 equipment, a Verifier capability can be embedded in a Network
169 Management Station (NMS), a posture collection server, or other
170 network analytics tool (such as a software asset management solution,
171 or a threat detection and mitigation tool, etc.). While informally
172 referred to as attestation, this document focuses on a specific
173 subset of attestation tasks, defined here as Remote Integrity
174 Verification (RIV). RIV in this document takes a network-equipment-
175 centric perspective that includes a set of protocols and procedures
176 for determining whether a particular device was launched with
177 authentic software, starting from Roots of Trust. While there are
178 many ways to accomplish attestation, RIV sets out a specific set of
179 protocols and tools that work in environments commonly found in
180 network equipment. RIV does not cover other device characteristics
181 that could be attested (e.g., geographic location, connectivity; see
182 [I-D.richardson-rats-usecases]), although it does provide evidence of
183 a secure infrastructure to increase the level of trust in other
184 device characteristics attested by other means (e.g., by Entity
185 Attestation Tokens [I-D.ietf-rats-eat]).
187 In line with [I-D.ietf-rats-architecture] definitions, this document
188 uses the term Endorser to refer to the role that signs identity and
189 attestation certificates used by the Attester, while Reference Values
190 are signed by a Reference Value Provider. Typically, the
191 manufacturer of a network device would be accepted as both the
192 Endorser and Reference Value Provider, although the choice is
193 ultimately up to the Verifier Owner.
195 1.3. Document Organization
197 The remainder of this document is organized into several sections:
199 * The remainder of this section covers goals and requirements, plus
200 a top-level description of RIV.
202 * The Solution Overview section outlines how Remote Integrity
203 Verification works.
205 * The Standards Components section links components of RIV to
206 normative standards.
208 * Privacy and Security shows how specific features of RIV contribute
209 to the trustworthiness of the Attestation Result.
211 * Supporting material is in an appendix at the end.
213 1.4. Goals
215 Network operators benefit from a trustworthy attestation mechanism
216 that provides assurance that their network comprises authentic
217 equipment, and has loaded software free of known vulnerabilities and
218 unauthorized tampering. In line with the overall goal of assuring
219 integrity, attestation can be used to assist in asset management,
220 vulnerability and compliance assessment, plus configuration
221 management.
223 The RIV attestation workflow outlined in this document is intended to
224 meet the following high-level goals:
226 * Provable Device Identity - This specification requires that an
227 Attester (i.e., the attesting device) includes a cryptographic
228 identifier unique to each device. Effectively this means that the
229 device's TPM must be so provisioned during the manufacturing
230 cycle.
232 * Software Inventory - A key goal is to identify the software
233 release(s) installed on the Attester, and to provide evidence that
234 the software stored within hasn't been altered without
235 authorization.
237 * Verifiability - Verification of software and configuration of the
238 device shows that the software that the administrator authorized
239 for use was actually launched.
241 In addition, RIV is designed to operate either in a centralized
242 environment, such as with a central authority that manages and
243 configures a number of network devices, or 'peer-to-peer', where
244 network devices independently verify one another to establish a trust
245 relationship. (See Section 3.3 below)
247 1.5. Description of Remote Integrity Verification (RIV)
249 Attestation requires two interlocking mechanisms between the Attester
250 network device and the Verifier:
252 * Device Identity, the mechanism providing trusted identity, can
253 reassure network managers that the specific devices they ordered
254 from authorized manufacturers for attachment to their network are
255 those that were installed, and that they continue to be present in
256 their network. As part of the mechanism for Device Identity,
257 cryptographic proof of the identity of the manufacturer is also
258 provided.
260 * Software Measurement is the mechanism that reports the state of
261 mutable software components on the device, and can assure
262 administrators that they have known, authentic software configured
263 to run in their network.
265 Using these two interlocking mechanisms, RIV is a component in a
266 chain of procedures that can assure a network operator that the
267 equipment in their network can be reliably identified, and that
268 authentic software of a known version is installed on each device.
269 Equipment in the network includes devices that make up the network
270 itself, such as routers, switches and firewalls.
272 Software used to boot a device can be identified by a chain of
273 measurements, anchored at the start by a Root of Trust for
274 Measurement (see Section 9.2), each measuring the next stage and
275 recording the result in tamper-resistant storage, normally ending
276 when the system software is fully loaded. A measurement signifies
277 the identity, integrity and version of each software component
278 registered with an Attester's TPM [TPM1.2], [TPM2.0], so that a
279 subsequent verification stage can determine if the software installed
280 is authentic, up-to-date, and free of tampering.
282 RIV includes several major processes, split between the Attester and
283 Verifier:
285 1. Generation of Evidence is the process whereby an Attester
286 generates cryptographic proof (Evidence) of claims about device
287 properties. In particular, the device identity and its software
288 configuration are both of critical importance.
290 2. Device Identification refers to the mechanism assuring the
291 Relying Party (ultimately, a network administrator) of the
292 identity of devices that make up their network, and that their
293 manufacturers are known.
295 3. Conveyance of Evidence reliably transports the collected Evidence
296 from Attester to a Verifier to allow a management station to
297 perform a meaningful appraisal in Step 4. The transport is
298 typically carried out via a management network. While not
299 required for reliable attestation, an encrypted channel may be
300 used to provide integrity, authenticity, or confidentiality once
301 attestation is complete. It should be noted that critical
302 attestation evidence from the TPM is signed by a key known only
303 to TPM, and is not dependent on encyption carried out as part of
304 a reliable transport.
306 4. Finally, Appraisal of Evidence occurs. This is the process of
307 verifying the Evidence received by a Verifier from the Attester,
308 and using an Appraisal Policy to develop an Attestation Result,
309 used to inform decision-making. In practice, this means
310 comparing the Attester's measurements reported as Evidence with
311 the device configuration expected by the Verifier. Subsequently,
312 the Appraisal Policy for Evidence might match Evidence found
313 against Reference Values (aka Golden Measurements), which
314 represent the intended configured state of the connected device.
316 All implementations supporting this RIV specification require the
317 support of the following three technologies:
319 1. Identity: Device identity in RIV is based on IEEE 802.1AR Device
320 Identity (DevID) [IEEE-802-1AR], coupled with careful supply-
321 chain management by the manufacturer. The Initial DevID (IDevID)
322 certificate contains a statement by the manufacturer that
323 establishes the identity of the device as it left the factory.
324 Some applications with a more-complex post-manufacture supply
325 chain (e.g., Value Added Resellers), or with different privacy
326 concerns, may want to use alternative mechanisms for platform
327 authentication (for example, TCG Platform Certificates
328 [Platform-Certificates], or post-manufacture installation of
329 Local Device ID (LDevID)).
331 2. Platform Attestation provides evidence of configuration of
332 software elements present in the device. This form of
333 attestation can be implemented with TPM Platform Configuration
334 Registers (PCRs), Quote and Log mechanisms, which provide
335 cryptographically authenticated evidence to report what software
336 was started on the device through the boot cycle. Successful
337 attestation requires an unbroken chain from a boot-time root of
338 trust through all layers of software needed to bring the device
339 to an operational state, in which each stage computes the hash of
340 components of the next stage, then updates the attestation log
341 and the TPM. The TPM can then report the hashes of all the
342 measured hashes as signed evidence called a Quote (see
343 Section 9.1 for an overview of TPM operation, or [TPM1.2] and
344 [TPM2.0] for many more details).
346 3. Signed Reference Values (aka Reference Integrity Measurements)
347 must be conveyed from the Reference Value Provider (the entity
348 accepted as the software authority, often the manufacturer of the
349 network device) to the Verifier.
351 1.6. Solution Requirements
353 Remote Integrity Verification must address the "Lying Endpoint"
354 problem, in which malicious software on an endpoint may subvert the
355 intended function, and also prevent the endpoint from reporting its
356 compromised status. (See Section 5 for further Security
357 Considerations.)
359 RIV attestation is designed to be simple to deploy at scale. RIV
360 should work "out of the box" as far as possible, that is, with the
361 fewest possible provisioning steps or configuration databases needed
362 at the end-user's site. Network equipment is often required to
363 "self-configure", to reliably reach out without manual intervention
364 to prove its identity and operating posture, then download its own
365 configuration, a process which precludes pre-installation
366 configuration. See [RFC8572] for an example of Secure Zero Touch
367 Provisioning.
369 1.7. Scope
371 The need for assurance of software integrity, addressed by Remote
372 Attestation, is a very general problem that could apply to most
373 network-connected computing devices. However, this document includes
374 several assumptions that limit the scope to network equipment (e.g.,
375 routers, switches and firewalls):
377 * This solution is for use in non-privacy-preserving applications
378 (for example, networking, Industrial IoT), avoiding the need for a
379 Privacy Certificate Authority (also called an Attestation CA) for
380 attestation keys [AK-Enrollment] or TCG Platform Certificates
381 [Platform-Certificates].
383 * This document assumes network protocols that are common in network
384 equipment such as YANG [RFC7950] and NETCONF [RFC6241], but not
385 generally used in other applications.
387 * The approach outlined in this document mandates the use of a TPM
388 [TPM1.2], [TPM2.0], or a compatible cryptoprocessor.
390 1.7.1. Out of Scope
392 * Run-Time Attestation: The Linux Integrity Measurement Architecture
393 [IMA] attests each process launched after a device is started (and
394 is in scope for RIV in general), but continuous run-time
395 attestation of Linux or other multi-threaded operating system
396 processes after the OS has started considerably expands the scope
397 of the problem. Many researchers are working on that problem, but
398 this document defers the problem of continuous, in-memory run-time
399 attestation.
401 * Multi-Vendor Embedded Systems: Additional coordination would be
402 needed for devices that themselves comprise hardware and software
403 from multiple vendors, integrated by the end user. Although out
404 of scope for this document, these issues are accommodated in
405 [I-D.ietf-rats-architecture].
407 * Processor Sleep Modes: Network equipment typically does not
408 "sleep", so sleep and hibernate modes are not considered.
409 Although out of scope for RIV in this document, Trusted Computing
410 Group specifications do encompass sleep and hibernate states,
411 which could be incorporated into remote attestation for network
412 equipment in the future, given a compelling need.
414 * Virtualization and Containerization: In a non-virtualized system,
415 the host OS is responsible for measuring each User Space file or
416 process throughout the operational lifetime of the system. For
417 virtualized systems, the host OS must verify the hypervisor, but
418 then the hypervisor must manage its own chain of trust through the
419 virtual machine. Virtualization and containerization technologies
420 are increasingly used in network equipment, but are not considered
421 in this document.
423 2. Solution Overview
425 2.1. RIV Software Configuration Attestation using TPM
427 RIV Attestation is a process which can be used to determine the
428 identity of software running on a specifically-identified device.
429 The Remote Attestation steps of Section 1.5 are broken into two
430 phases, shown in Figure 1:
432 * During system startup, or boot phase, each distinct software
433 object is "measured" by the Attester. The object's identity, hash
434 (i.e., cryptographic digest) and version information are recorded
435 in a log. Hashes are also extended into the TPM (see Section 9.1
436 for more on 'extending hashes'), in a way that can be used to
437 validate the log entries. The measurement process generally
438 follows the layered chain-of-trust model used in Measured Boot,
439 where each stage of the system measures the next one, and extends
440 its measurement into the TPM, before launching it. See
441 [I-D.ietf-rats-architecture], section "Layered Attestation
442 Environments," for an architectural definition of this model.
444 * Once the device is running and has operational network
445 connectivity, verification can take place. A separate Verifier,
446 running in its own trusted environment, will interrogate the
447 network device to retrieve the logs and a copy of the digests
448 collected by hashing each software object, signed by an
449 attestation private key secured by, but never released by, the
450 TPM. The YANG model described in [I-D.ietf-rats-yang-tpm-charra]
451 facilitates this operation.
453 The result is that the Verifier can verify the device's identity by
454 checking the subject[RFC5280] and signature of the certificate
455 containing the TPM's attestation public key, and can validate the
456 software that was launched by verifying the correctness of the logs
457 by comparing with the signed digests from the TPM, and comparing
458 digests in the log with Reference Values.
460 It should be noted that attestation and identity are inextricably
461 linked; signed Evidence that a particular version of software was
462 loaded is of little value without cryptographic proof of the identity
463 of the Attester producing the Evidence.
465 +-------------------------------------------------------+
466 | +---------+ +--------+ +--------+ +---------+ |
467 | |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |
468 | +---------+ +--------+ +--------+ +---------+ |
469 | | | | |
470 | | | | |
471 | +------------+-----------+-+ |
472 | Boot Phase | |
473 | V |
474 | +--------+ |
475 | | TPM | |
476 | +--------+ |
477 | Router | |
478 +--------------------------------|----------------------+
479 |
480 | Verification Phase
481 | +-----------+
482 +--->| Verifier |
483 +-----------+
485 Reset---------------flow-of-time-during-boot...--------->
487 Figure 1: Layered RIV Attestation Model
489 In the Boot phase, measurements are "extended", or hashed, into the
490 TPM as processes start, with the result that the TPM ends up
491 containing hashes of all the measured hashes. Later, once the system
492 is operational, during the Verification phase, signed digests are
493 retrieved from the TPM for off-box analysis.
495 2.1.1. What Does RIV Attest?
497 TPM attestation is focused on Platform Configuration Registers
498 (PCRs), but those registers are only vehicles for certifying
499 accompanying Evidence, conveyed in log entries. It is the hashes in
500 log entries that are extended into PCRs, where the final PCR values
501 can be retrieved in the form of a structure called a Quote, signed by
502 an Attestation key known only to the TPM. The use of multiple PCRs
503 serves only to provide some independence between different classes of
504 object, so that one class of objects can be updated without changing
505 the extended hash for other classes. Although PCRs can be used for
506 any purpose, this section outlines the objects within the scope of
507 this document which may be extended into the TPM.
509 In general, assignment of measurements to PCRs is a policy choice
510 made by the device manufacturer, selected to independently attest
511 three classes of object:
513 * Code, (i.e., instructions) to be executed by a CPU.
515 * Configuration - Many devices offer numerous options controlled by
516 non-volatile configuration variables which can impact the device's
517 security posture. These settings may have vendor defaults, but
518 often can be changed by administrators, who may want to verify via
519 attestation that the operational state of the settings match their
520 intended state.
522 * Credentials - Administrators may wish to verify via attestation
523 that public keys and credentials outside the Root of Trust have
524 not been subject to unauthorized tampering. (By definition, keys
525 protecting the root of trust can't be verified independently.)
527 The TCG PC Client Platform Firmware Profile Specification
528 [PC-Client-BIOS-TPM-2.0] gives considerable detail on what is to be
529 measured during the boot phase of platform startup using a UEFI BIOS
530 (www.uefi.org), but the goal is simply to measure every bit of code
531 executed in the process of starting the device, along with any
532 configuration information related to security posture, leaving no gap
533 for unmeasured code to remain undetected, potentially subverting the
534 chain.
536 For devices using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] and
537 [PC-Client-EFI-TPM-1.2] give detailed normative requirements for PCR
538 usage. For other platform architectures, where TCG normative
539 requirements currently do not exist, the table in Figure 2 gives non-
540 normative guidance for PCR assignment that generalizes the specific
541 details of [PC-Client-BIOS-TPM-2.0].
543 By convention, most PCRs are assigned in pairs, which the even-
544 numbered PCR used to measure executable code, and the odd-numbered
545 PCR used to measure whatever data and configuration are associated
546 with that code. It is important to note that each PCR may contain
547 results from dozens (or even thousands) of individual measurements.
549 +------------------------------------------------------------------+
550 | | Assigned PCR # |
551 | Function | Code | Configuration|
552 --------------------------------------------------------------------
553 | Firmware Static Root of Trust, (i.e., | 0 | 1 |
554 | initial boot firmware and drivers) | | |
555 --------------------------------------------------------------------
556 | Drivers and initialization for optional | 2 | 3 |
557 | or add-in devices | | |
558 --------------------------------------------------------------------
559 | OS Loader code and configuration, (i.e., | 4 | 5 |
560 | the code launched by firmware) to load an | | |
561 | operating system kernel. These PCRs record | | |
562 | each boot attempt, and an identifier for | | |
563 | where the loader was found | | |
564 --------------------------------------------------------------------
565 | Vendor Specific Measurements during boot | 6 | 6 |
566 --------------------------------------------------------------------
567 | Secure Boot Policy. This PCR records keys | | 7 |
568 | and configuration used to validate the OS | | |
569 | loader | | |
570 --------------------------------------------------------------------
571 | Measurements made by the OS Loader | 8 | 9 |
572 | (e.g. GRUB2 for Linux) | | |
573 --------------------------------------------------------------------
574 | Measurements made by OS (e.g., Linux IMA) | 10 | 10 |
575 +------------------------------------------------------------------+
577 Figure 2: Attested Objects
579 2.1.2. Notes on PCR Allocations
581 It is important to recognize that PCR[0] is critical. The first
582 measurement into PCR[0] is taken by the Root of Trust for
583 Measurement, code which, by definition, cannot be verified by
584 measurement. This measurement establishes the chain of trust for all
585 subsequent measurements. If the PCR[0] measurement cannot be
586 trusted, the validity of the entire chain is put into question.
588 Distinctions Between PCR[0], PCR[2], PCR[4] and PCR[8] are summarized
589 below:
591 * PCR[0] typically represents a consistent view of rarely-changed
592 Host Platform boot components, allowing Attestation policies to be
593 defined using the less changeable components of the transitive
594 trust chain. This PCR typically provides a consistent view of the
595 platform regardless of user selected options.
597 * PCR[2] is intended to represent a "user configurable" environment
598 where the user has the ability to alter the components that are
599 measured into PCR[2]. This is typically done by adding adapter
600 cards, etc., into user-accessible PCI or other slots. In UEFI
601 systems these devices may be configured by Option ROMs measured
602 into PCR[2] and executed by the UEFI BIOS.
604 * PCR[4] is intended to represent the software that manages the
605 transition between the platform's Pre-Operating System start and
606 the state of a system with the Operating System present. This
607 PCR, along with PCR[5], identifies the initial operating system
608 loader (e.g., GRUB for Linux).
610 * PCR[8] is used by the OS loader (e.g. GRUB) to record
611 measurements of the various components of the operating system.
613 Although the TCG PC Client document specifies the use of the first
614 eight PCRs very carefully to ensure interoperability among multiple
615 UEFI BIOS vendors, it should be noted that embedded software vendors
616 may have considerably more flexibility. Verifiers typically need to
617 know which log entries are consequential and which are not (possibly
618 controlled by local policies) but the Verifier may not need to know
619 what each log entry means or why it was assigned to a particular PCR.
620 Designers must recognize that some PCRs may cover log entries that a
621 particular Verifier considers critical and other log entries that are
622 not considered important, so differing PCR values may not on their
623 own constitute a check for authenticity. For example, in a UEFI
624 system, some administrators may consider booting an image from a
625 removable drive, something recorded in a PCR, to be a security
626 violation, while others might consider that operation an authorized
627 recovery procedure.
629 Designers may allocate particular events to specific PCRs in order to
630 achieve a particular objective with local attestation, (e.g.,
631 allowing a procedure to execute, or releasing a particular decryption
632 key, only if a given PCR is in a given state). It may also be
633 important to designers to consider whether streaming notification of
634 PCR updates is required (see
635 [I-D.birkholz-rats-network-device-subscription]). Specific log
636 entries can only be validated if the Verifier receives every log
637 entry affecting the relevant PCR, so (for example) a designer might
638 want to separate rare, high-value events such as configuration
639 changes, from high-volume, routine measurements such as IMA [IMA]
640 logs.
642 2.2. RIV Keying
644 RIV attestation relies on two credentials:
646 * An identity key pair and matching certificate is required to
647 certify the identity of the Attester itself. RIV specifies the
648 use of an IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR],
649 signed by the device manufacturer, containing the device serial
650 number. This requirement goes slightly beyond 802.1AR; see
651 Section 2.4 for notes.
653 * An Attestation key pair and matching certificate is required to
654 sign the Quote generated by the TPM to report evidence of software
655 configuration.
657 In a TPM application, both the Attestation private key and the DevID
658 private key MUST be protected by the TPM. Depending on other TPM
659 configuration procedures, the two keys are likely to be different;
660 some of the considerations are outlined in TCG "TPM 2.0 Keys for
661 Device Identity and Attestation" [Platform-DevID-TPM-2.0].
663 The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies
664 further conventions for these keys:
666 * When separate Identity and Attestation keys are used, the
667 Attestation Key (AK) and its X.509 certificate should parallel the
668 DevID, with the same unique device identification as the DevID
669 certificate (that is, the same subject and subjectAltName (if
670 present), even though the key pairs are different). This allows a
671 quote from the device, signed by an AK, to be linked directly to
672 the device that provided it, by examining the corresponding AK
673 certificate. If the subject in the AK certificate doesn't match
674 the corresponding DevID certificate, or they're signed by
675 differing authorities the Verifier may signal the detection of an
676 Asokan-style person-in-the-middle attack (see Section 5.2).
678 * Network devices that are expected to use secure zero touch
679 provisioning as specified in [RFC8572] MUST be shipped by the
680 manufacturer with pre-provisioned keys (Initial DevID and Initial
681 AK, called IDevID and IAK). IDevID and IAK certificates MUST both
682 be signed by the Endorser (typically the device manufacturer).
683 Inclusion of an IDevID and IAK by a vendor does not preclude a
684 mechanism whereby an administrator can define Local Identity and
685 Attestation Keys (LDevID and LAK) if desired.
687 2.3. RIV Information Flow
689 RIV workflow for network equipment is organized around a simple use
690 case where a network operator wishes to verify the integrity of
691 software installed in specific, fielded devices. A normative
692 taxonomy of terms is given in [I-D.ietf-rats-architecture], but as a
693 reminder, this use case implies several roles and objects:
695 1. The Attester, the device which the network operator wants to
696 examine.
698 2. A Verifier (which might be a network management station)
699 somewhere separate from the Device that will retrieve the signed
700 evidence and measurement logs, and analyze them to pass judgment
701 on the security posture of the device.
703 3. A Relying Party, which can act on Attestation Results.
704 Interaction between the Relying Party and the Verifier is
705 considered out of scope for RIV.
707 4. Signed Reference Integrity Manifests (RIMs), containing Reference
708 Values, can either be created by the device manufacturer and
709 shipped along with the device as part of its software image, or
710 alternatively, could be obtained several other ways (direct to
711 the Verifier from the manufacturer, from a third party, from the
712 owner's observation of what's thought to be a "known good
713 system", etc.). Retrieving RIMs from the device itself allows
714 attestation to be done in systems that may not have access to the
715 public internet, or by other devices that are not management
716 stations per se (e.g., a peer device; see Section 3.1.3). If
717 Reference Values are obtained from multiple sources, the Verifier
718 may need to evaluate the relative level of trust to be placed in
719 each source in case of a discrepancy.
721 These components are illustrated in Figure 3.
723 +----------------+ +-------------+ +---------+--------+
724 |Reference Value | | Attester | Step 1 | Verifier| |
725 |Provider | | (Device |<-------| (Network| Relying|
726 |(Device | | under |------->| Mngmt | Party |
727 |Manufacturer | | attestation)| Step 2 | Station)| |
728 |or other | | | | | |
729 |authority) | | | | | |
730 +----------------+ +-------------+ +---------+--------+
731 | /\
732 | Step 0 |
733 -----------------------------------------------
735 Figure 3: RIV Reference Configuration for Network Equipment
737 * In Step 0, The Reference Value Provider (the device manufacturer
738 or other authority) makes one or more Reference Integrity
739 Manifests (RIMs), corresponding to the software image expected to
740 be found on the device, signed by the Reference Value Provider,
741 available to the Verifier (see Section 3.1.3 for "in-band" and
742 "out of band" ways to make this happen).
744 * In Step 1, the Verifier (Network Management Station), on behalf of
745 a Relying Party, requests Identity, Measurement Values, and
746 possibly RIMs, from the Attester.
748 * In Step 2, the Attester responds to the request by providing a
749 DevID, quotes (measured values, signed by the Attester), and
750 optionally RIMs.
752 Use of the following standards components allows for
753 interoperability:
755 1. TPM Keys MUST be configured according to
756 [Platform-DevID-TPM-2.0], or [Platform-ID-TPM-1.2].
758 2. For devices using UEFI and Linux, measurements of firmware and
759 bootable modules MUST be taken according to TCG PC Client
760 [PC-Client-EFI-TPM-1.2] or [PC-Client-BIOS-TPM-2.0], and Linux
761 IMA [IMA].
763 3. Device Identity MUST be managed as specified in IEEE 802.1AR
764 Device Identity certificates [IEEE-802-1AR], with keys protected
765 by TPMs.
767 4. Attestation logs from Linux-based systems MUST be formatted
768 according to the Canonical Event Log format
769 [Canonical-Event-Log]. UEFI-based systems MUST use the TCG UEFI
770 BIOS event log [PC-Client-EFI-TPM-1.2] for TPM1.2 systems, and
771 TCG PC Client Platform Firmware Profile [PC-Client-BIOS-TPM-2.0]
772 for TPM2.0.
774 5. Quotes MUST be retrieved from the TPM according to TCG TAP
775 Information Model [TAP] and the CHARRA YANG model
776 [I-D.ietf-rats-yang-tpm-charra]. While the TAP IM gives a
777 protocol-independent description of the data elements involved,
778 it's important to note that quotes from the TPM are signed inside
779 the TPM, and MUST be retrieved in a way that does not invalidate
780 the signature, to preserve the trust model. The
781 [I-D.ietf-rats-yang-tpm-charra] is used for this purpose. (See
782 Section 5 Security Considerations).
784 6. Reference Values MUST be encoded as defined in the TCG RIM
785 document [RIM], typically using SWID [SWID], [NIST-IR-8060] or
786 CoSWID tags [I-D.ietf-sacm-coswid].
788 2.4. RIV Simplifying Assumptions
790 This document makes the following simplifying assumptions to reduce
791 complexity:
793 * The product to be attested MUST be shipped by the equipment vendor
794 with both an IEEE 802.1AR Device Identity and an Initial
795 Attestation Key (IAK), with certificates in place. The IAK
796 certificate must contain the same identity information as the
797 DevID (specifically, the same subject and subjectAltName (if
798 used), signed by the manufacturer). The IAK is a type of key that
799 can be used to sign a TPM Quote, but not other objects (i.e., it's
800 marked as a TCG "Restricted" key; this convention is described in
801 "TPM 2.0 Keys for Device Identity and Attestation"
802 [Platform-DevID-TPM-2.0]). For network equipment, which is
803 generally non-privacy-sensitive, shipping a device with both an
804 IDevID and an IAK already provisioned substantially simplifies
805 initial startup.
807 * IEEE 802.1AR does not require a product serial number as part of
808 the subject, but RIV-compliant devices MUST include their serial
809 numbers in the DevID/IAK certificates to simplify tracking
810 logistics for network equipment users. All other optional 802.1AR
811 fields remain optional in RIV.
813 It should be noted that 802.1AR use of X.509 certificate fields is
814 not identical to those descsribed in [RFC6125] for representation
815 of application service identity.
817 * The product MUST be equipped with a Root of Trust for Measurement
818 (RTM), Root of Trust for Storage and Root of Trust for Reporting
819 (as defined in [SP800-155]) which together are capable of
820 conforming to TCG Trusted Attestation Protocol Information Model
821 [TAP].
823 * The authorized software supplier MUST make available Reference
824 Values in the form of signed SWID or CoSWID tags.
826 2.4.1. Reference Integrity Manifests (RIMs)
828 [I-D.ietf-rats-yang-tpm-charra] focuses on collecting and
829 transmitting evidence in the form of PCR measurements and attestation
830 logs. But the critical part of the process is enabling the Verifier
831 to decide whether the measurements are "the right ones" or not.
833 While it must be up to network administrators to decide what they
834 want on their networks, the software supplier should supply the
835 Reference Values, in signed Reference Integrity Manifests, that may
836 be used by a Verifier to determine if evidence shows known good,
837 known bad or unknown software configurations.
839 In general, there are two kinds of reference measurements:
841 1. Measurements of early system startup (e.g., BIOS, boot loader, OS
842 kernel) are essentially single-threaded, and executed exactly
843 once, in a known sequence, before any results could be reported.
844 In this case, while the method for computing the hash and
845 extending relevant PCRs may be complicated, the net result is
846 that the software (more likely, firmware) vendor will have one
847 known good PCR value that "should" be present in the relevant
848 PCRs after the box has booted. In this case, the signed
849 reference measurement could simply list the expected hashes for
850 the given version. However, a RIM that contains the intermediate
851 hashes can be useful in debugging cases where the expected final
852 hash is not the one reported.
854 2. Measurements taken later in operation of the system, once an OS
855 has started (for example, Linux IMA [IMA]), may be more complex,
856 with unpredictable "final" PCR values. In this case, the
857 Verifier must have enough information to reconstruct the expected
858 PCR values from logs and signed reference measurements from a
859 trusted authority.
861 In both cases, the expected values can be expressed as signed SWID or
862 CoSWID tags, but the SWID structure in the second case is somewhat
863 more complex, as reconstruction of the extended hash in a PCR may
864 involve thousands of files and other objects.
866 TCG has published an information model defining elements of Reference
867 Integrity Manifests under the title TCG Reference Integrity Manifest
868 Information Model [RIM]. This information model outlines how SWID
869 tags should be structured to allow attestation, and defines "bundles"
870 of SWID tags that may be needed to describe a complete software
871 release. The RIM contains metadata relating to the software release
872 it belongs to, plus hashes for each individual file or other object
873 that could be attested.
875 Many network equipment vendors use a UEFI BIOS to launch their
876 network operating system. These vendors may want to also use the TCG
877 PC Client Reference Integrity Measurement specification
878 [PC-Client-RIM], which focuses specifically on a SWID-compatible
879 format suitable for expressing measurement values expected from a
880 UEFI BIOS.
882 2.4.2. Attestation Logs
884 Quotes from a TPM can provide evidence of the state of a device up to
885 the time the evidence was recorded, but to make sense of the quote in
886 cases where several events are extended into one PCR an event log
887 that identifies which software modules contributed which values to
888 the quote during startup must also be provided. When required, the
889 log MUST contain enough information to demonstrate its integrity by
890 allowing exact reconstruction of the digest conveyed in the signed
891 quote (that is, calculating the hash of all the hashes in the log
892 should produce the same values as contained in the PCRs; if they
893 don't match, the log may have been tampered with. See Section 9.1).
895 There are multiple event log formats which may be supported as viable
896 formats of Evidence between the Attester and Verifier, but to
897 simplify interoperability, RIV focuses on just three:
899 * TCG UEFI BIOS event log for TPM 2.0 (TCG PC Client Platform
900 Firmware Profile) [PC-Client-BIOS-TPM-2.0]
902 * TCG UEFI BIOS event log for TPM 1.2 (TCG EFI Platform
903 Specification for TPM Family 1.1 or 1.2, Section 7)
904 [PC-Client-EFI-TPM-1.2]
906 * TCG Canonical Event Log [Canonical-Event-Log]
908 3. Standards Components
910 3.1. Prerequisites for RIV
912 The Reference Interaction Model for Challenge-Response-based Remote
913 Attestation ([I-D.birkholz-rats-reference-interaction-model]) is
914 based on the standard roles defined in [I-D.ietf-rats-architecture].
915 However, additional prerequisites have been established to allow for
916 interoperable RIV use case implementations. These prerequisites are
917 intended to provide sufficient context information so that the
918 Verifier can acquire and evaluate measurements collected by the
919 Attester.
921 3.1.1. Unique Device Identity
923 A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID
924 certificate [IEEE-802-1AR] must be provisioned in the Attester's
925 TPMs.
927 3.1.2. Keys
929 The Attestation Key (AK) and certificate must also be provisioned on
930 the Attester according to [Platform-DevID-TPM-2.0], or
931 [Platform-ID-TPM-1.2].
933 It MUST be possible for the Verifier to determine that the Attester's
934 Attestation keys are resident in the same TPM as its DevID keys (see
935 Section 2.2 and Section 5 Security Considerations).
937 3.1.3. Appraisal Policy for Evidence
939 As noted in Section 2.3, the Verifier may obtain Reference Values
940 from several sources. In addition, administrators may make
941 authorized, site-specific changes (e.g. keys in key databases) that
942 could impact attestation results. As such, there could be conflicts,
943 omissions or ambiguities between some Reference Values and collected
944 Evidence.
946 The Verifier MUST have an Appraisal Policy for Evidence to evaluate
947 the significance of any discrepancies between different reference
948 sources, or between reference values and evidence from logs and
949 quotes. While there must be an Appraisal Policy, this document does
950 not specify the format or mechanism to convey the intended policy,
951 nor does RIV specify mechanisms by which the results of applying the
952 policy are communicated to the Relying Party.
954 3.2. Reference Model for Challenge-Response
956 Once the prerequisites for RIV are met, a Verifier is able to acquire
957 Evidence from an Attester. The following diagram illustrates a RIV
958 information flow between a Verifier and an Attester, derived from
959 Section 7.1 of [I-D.birkholz-rats-reference-interaction-model]. In
960 this diagram, each event with its input and output parameters is
961 shown as "Event(input-params)=>(outputs)". Event times shown
962 correspond to the time types described within Appendix A of
963 [I-D.ietf-rats-architecture]:
965 .----------. .-----------------------.
966 | Attester | | Relying Party/Verifier |
967 '----------' '------------------------'
968 time(VG) |
969 generateClaims(attestingEnvironment) |
970 | => claims, eventLogs |
971 | |
972 | time(NS)
973 | <-- requestAttestation(handle, authSecIDs, claimSelection) |
974 | |
975 time(EG) |
976 collectClaims(claims, claimSelection) |
977 | => collectedClaims |
978 | |
979 generateEvidence(handle, authSecIDs, collectedClaims) |
980 | => evidence |
981 | time(RG,RA)
982 | evidence, eventLogs -------------------------------------> |
983 | |
984 | appraiseEvidence(evidence, eventLogs, refValues)
985 | attestationResult <= |
986 | |
987 ~ ~
988 | time(RX)
990 Figure 4: IETF Attestation Information Flow
992 * Step 1 (time(VG)): One or more Attesting Network Device PCRs are
993 extended with measurements. RIV provides no direct link between
994 the time at which the event takes place and the time that it's
995 attested, although streaming attestation as in
996 [I-D.birkholz-rats-network-device-subscription] could.
998 * Step 2 (time(NS)): The Verifier generates a unique random nonce
999 ("number used once"), and makes a request for one or more PCRs
1000 from an Attester. For interoperability, this must be accomplished
1001 as specified in the YANG Data Model for Challenge-Response-based
1002 Remote Attestation Procedures using TPMs
1003 [I-D.ietf-rats-yang-tpm-charra]. TPM1.2 and TPM2.0 both allow
1004 nonces as large as the operative digest size (i.e., 20 or 32
1005 bytes; see [TPM1.2] Part 2, Section 5.5 and [TPM2.0] Part 2,
1006 Section 10.4.4).
1008 * Step 3 (time(EG)): On the Attester, measured values are retrieved
1009 from the Attester's TPM. This requested PCR evidence, along with
1010 the Verifier's nonce, called a Quote, is signed by the Attestation
1011 Key (AK) associated with the DevID. Quotes are retrieved
1012 according to CHARRA YANG model [I-D.ietf-rats-yang-tpm-charra].
1014 At the same time, the Attester collects log evidence showing the
1015 values have been extended into that PCR. Section 9.1 gives more
1016 detail on how this works, including references to the structure
1017 and contents of quotes in TPM documents.
1019 * Step 4: Collected Evidence is passed from the Attester to the
1020 Verifier
1022 * Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes
1023 action as needed. As the interaction between Relying Party and
1024 Verifier is out of scope for RIV, this can be described as one
1025 step.
1027 - If the signature covering TPM Evidence is not correct, the
1028 device SHOULD NOT be trusted.
1030 - If the nonce in the response doesn't match the Verifier's
1031 nonce, the response may be a replay, and device SHOULD NOT be
1032 trusted.
1034 - If the signed PCR values do not match the set of log entries
1035 which have extended a particular PCR, the device SHOULD NOT be
1036 trusted.
1038 - If the log entries that the Verifier considers important do not
1039 match known good values, the device SHOULD NOT be trusted. We
1040 note that the process of collecting and analyzing the log can
1041 be omitted if the value in the relevant PCR is already a known-
1042 good value.
1044 - If the set of log entries are not seen as acceptable by the
1045 Appraisal Policy for Evidence, the device SHOULD NOT be
1046 trusted.
1048 - If time(RG)-time(NS) is greater than the Appraisal Policy for
1049 Evidence's threshold for assessing freshness, the Evidence is
1050 considered stale and SHOULD NOT be trusted.
1052 3.2.1. Transport and Encoding
1054 Network Management systems may retrieve signed PCR based Evidence
1055 using NETCONF or RESTCONF with [I-D.ietf-rats-yang-tpm-charra]. In
1056 either case, implementatations must do so using a secure tunnel.
1058 Log Evidence MUST be retrieved via log interfaces specified in
1059 [I-D.ietf-rats-yang-tpm-charra].
1061 3.3. Centralized vs Peer-to-Peer
1063 Figure 4 above assumes that the Verifier is trusted, while the
1064 Attester is not. In a Peer-to-Peer application such as two routers
1065 negotiating a trust relationship, the two peers can each ask the
1066 other to prove software integrity. In this application, the
1067 information flow is the same, but each side plays a role both as an
1068 Attester and a Verifier. Each device issues a challenge, and each
1069 device responds to the other's challenge, as shown in Figure 5.
1070 Peer-to-peer challenges, particularly if used to establish a trust
1071 relationship between routers, require devices to carry their own
1072 signed reference measurements (RIMs). Devices may also have to carry
1073 Appraisal Policy for Evidence for each possible peer device so that
1074 each device has everything needed for remote attestation, without
1075 having to resort to a central authority.
1077 +---------------+ +---------------+
1078 | RefVal | | RefVal |
1079 | Provider A | | Provider B |
1080 | Firmware | | Firmware |
1081 | Configuration | | Configuration |
1082 | Authority | | Authority |
1083 | | | |
1084 +---------------+ +---------------+
1085 | |
1086 | |Step 0B
1087 | +------------+ +------------+ |
1088 | | | Step 1 | | | \
1089 | | Attester |<------>| Verifier | | |
1090 | | |<------>| | | | Router B
1091 +------>| | Step 2 | | | |- Challenges
1092 Step 0A| | | | | | Router A
1093 | |------->| | | |
1094 |- Router A -| Step 3 |- Router B -| | /
1095 | | | | |
1096 | | | | |
1097 | | Step 1 | | | \
1098 | Verifier |<------>| Attester |<-+ | Router A
1099 | |<------>| | |- Challenges
1100 | | Step 2 | | | Router B
1101 | | | | |
1102 | |<-------| | |
1103 +------------+ Step 3 +------------+ /
1105 Figure 5: Peer-to-Peer Attestation Information Flow
1107 In this application, each device may need to be equipped with signed
1108 RIMs to act as an Attester, and also an Appraisal Policy for Evidence
1109 and a selection of trusted X.509 root certificates, to allow the
1110 device to act as a Verifier. An existing link layer protocol such as
1111 802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being
1112 enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable
1113 methods for such an exchange. Details of peer-to-peer operation are
1114 out of scope for this document.
1116 4. Privacy Considerations
1118 Network equipment, such as routers, switches and firewalls, has a key
1119 role to play in guarding the privacy of individuals using the
1120 network. Network equipment generally adheres to several rules to
1121 protect privacy:
1123 * Packets passing through the device must not be sent to
1124 unauthorized destinations. For example:
1126 - Routers often act as Policy Enforcement Points, where
1127 individual subscribers may be checked for authorization to
1128 access a network. Subscriber login information must not be
1129 released to unauthorized parties.
1131 - Network equipment is often called upon to block access to
1132 protected resources from unauthorized users.
1134 * Routing information, such as the identity of a router's peers,
1135 must not be leaked to unauthorized neighbors.
1137 * If configured, encryption and decryption of traffic must be
1138 carried out reliably, while protecting keys and credentials.
1140 Functions that protect privacy are implemented as part of each layer
1141 of hardware and software that makes up the networking device. In
1142 light of these requirements for protecting the privacy of users of
1143 the network, the network equipment must identify itself, and its boot
1144 configuration and measured device state (for example, PCR values), to
1145 the equipment's administrator, so there's no uncertainty as to what
1146 function each device and configuration is configured to carry out.
1147 Attestation is a component that allows the administrator to ensure
1148 that the network provides individual and peer privacy guarantees,
1149 even though the device itself may not have a right to keep its
1150 identity secret.
1152 See [NetEq] for more context on privacy in networking devices.
1154 While attestation information from network devices is not likely to
1155 contain privacy-sensitive content regarding network users,
1156 administrators may want to keep attestation records confidential to
1157 avoid disclosing versions of software loaded on the device,
1158 information which could facilitate attacks against known
1159 vulnerabilities.
1161 5. Security Considerations
1163 Specifications such as [RFC8446] (TLS) and [RFC7950] (YANG) contain
1164 considerable advice on keeping network-connected systems secure.
1165 This section outlines specific risks and mitigations related to
1166 attestation.
1168 Attestation Evidence obtained by the RIV procedure is subject to a
1169 number of attacks:
1171 * Keys may be compromised.
1173 * A counterfeit device may attempt to impersonate (spoof) a known
1174 authentic device.
1176 * Person-in-the-middle attacks may be used by a compromised device
1177 to attempt to deliver responses that originate in an authentic
1178 device.
1180 * Replay attacks may be attempted by a compromised device.
1182 5.1. Keys Used in RIV
1184 Trustworthiness of RIV attestation depends strongly on the validity
1185 of keys used for identity and attestation reports. RIV takes full
1186 advantage of TPM capabilities to ensure that evidence can be trusted.
1188 Two sets of key-pairs are relevant to RIV attestation:
1190 * A DevID key-pair is used to certify the identity of the device in
1191 which the TPM is installed.
1193 * An Attestation Key-pair (AK) key is used to certify attestation
1194 Evidence (called 'quotes' in TCG documents), used to provide
1195 evidence for integrity of the software on the device
1197 TPM practices usually require that these keys be different, as a way
1198 of ensuring that a general-purpose signing key cannot be used to
1199 spoof an attestation quote.
1201 In each case, the private half of the key is known only to the TPM,
1202 and cannot be retrieved externally, even by a trusted party. To
1203 ensure that's the case, specification-compliant private/public key-
1204 pairs are generated inside the TPM, where they are never exposed, and
1205 cannot be extracted (See [Platform-DevID-TPM-2.0]).
1207 Keeping keys safe is a critical enabler of trustworthiness, but it's
1208 just part of attestation security; knowing which keys are bound to
1209 the device in question is just as important in an environment where
1210 private keys are never exposed.
1212 While there are many ways to manage keys in a TPM (see
1213 [Platform-DevID-TPM-2.0]), RIV includes support for "zero touch"
1214 provisioning (also known as zero-touch onboarding) of fielded devices
1215 (e.g., Secure ZTP, [RFC8572]), where keys which have predictable
1216 trust properties are provisioned by the device vendor.
1218 Device identity in RIV is based on IEEE 802.1AR Device Identity
1219 (DevID). This specification provides several elements:
1221 * A DevID requires a unique key pair for each device, accompanied by
1222 an X.509 certificate,
1224 * The private portion of the DevID key is to be stored in the
1225 device, in a manner that provides confidentiality (Section 6.2.5
1226 [IEEE-802-1AR])
1228 The X.509 certificate contains several components:
1230 * The public part of the unique DevID key assigned to that device
1231 allows a challenge of identity.
1233 * An identifying string that's unique to the manufacturer of the
1234 device. This is normally the serial number of the unit, which
1235 might also be printed on a label on the device.
1237 * The certificate must be signed by a key traceable to the
1238 manufacturer's root key.
1240 With these elements, the device's manufacturer and serial number can
1241 be identified by analyzing the DevID certificate plus the chain of
1242 intermediate certificates leading back to the manufacturer's root
1243 certificate. As is conventional in TLS or SSH connections, a random
1244 nonce must be signed by the device in response to a challenge,
1245 proving possession of its DevID private key.
1247 RIV uses the DevID to validate a TLS or SSH connection to the device
1248 as the attestation session begins. Security of this process derives
1249 from TLS or SSH security, with the DevID, containing a device serial
1250 number, providing proof that the session terminates on the intended
1251 device. See [RFC8446], [RFC4253].
1253 Evidence of software integrity is delivered in the form of a quote
1254 signed by the TPM itself, accompanied by an IAK certificate
1255 containing the same identity information as the DevID. Because the
1256 contents of the quote are signed inside the TPM, any external
1257 modification (including reformatting to a different data format)
1258 after measurements have been taken will be detected as tampering. An
1259 unbroken chain of trust is essential to ensuring that blocks of code
1260 that are taking measurements have been verified before execution (see
1261 Figure 1).
1263 Requiring measurements of the operating software to be signed by a
1264 key known only to the TPM also removes the need to trust the device's
1265 operating software (beyond the first measurement in the RTM; see
1266 below); any changes to the quote, generated and signed by the TPM
1267 itself, made by malicious device software, or in the path back to the
1268 Verifier, will invalidate the signature on the quote.
1270 A critical feature of the YANG model described in
1271 [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data
1272 structures in their TCG-defined format, without requiring any changes
1273 to the structures as they were signed and delivered by the TPM.
1274 While alternate methods of conveying TPM quotes could compress out
1275 redundant information, or add another layer of signing using external
1276 keys, the implementation MUST preserve the TPM signing, so that
1277 tampering anywhere in the path between the TPM itself and the
1278 Verifier can be detected.
1280 5.2. Prevention of Spoofing and Person-in-the-Middle Attacks
1282 Prevention of spoofing attacks against attestation systems is also
1283 important. There are several cases to consider:
1285 * The entire device could be spoofed. If the Verifier goes to
1286 appraise a specific Attester, it might be redirected to a
1287 different Attester.
1289 * A compromised device could have a valid DevID, but substitute a
1290 quote from a knonwn-good device, instead of returning its own, as
1291 described in [RFC6813].
1293 * A device with a compromised OS could return a fabricated quote
1294 providing spoofed attestation Evidence.
1296 Use of the 802.1AR Device Identity (DevID) in the TPM provides
1297 protection against the case of a spoofed device, by ensuring that the
1298 Verifier's TLS or SSH session is in fact terminating on the right
1299 device.
1301 Protection against spoofed quotes from a device with valid identity
1302 is a bit more complex. An identity key must be available to sign any
1303 kind of nonce or hash offered by the Verifier, and consequently,
1304 could be used to sign a fabricated quote. To block a spoofed
1305 Attestation Result, the quote generated inside the TPM must be signed
1306 by a key that's different from the DevID, called an Attestation Key
1307 (AK).
1309 Given separate Attestation and DevID keys, the binding between the AK
1310 and the same device must also be proven to prevent a person-in-the-
1311 middle attack (e.g., the 'Asokan Attack' [RFC6813]).
1313 This is accomplished in RIV through use of an AK certificate with the
1314 same elements as the DevID (same manufacturer's serial number, signed
1315 by the same manufacturer's key), but containing the device's unique
1316 AK public key instead of the DevID public key. This binding between
1317 DevID and AK certificates is critical to reliable attestation.
1319 The TCG document TPM 2.0 Keys for Device Identity and Attestation
1320 [Platform-DevID-TPM-2.0] specifies OIDs for Attestation Certificates
1321 that allow the CA to mark a key as specifically known to be an
1322 Attestation key.
1324 These two key-pairs and certificates are used together:
1326 * The DevID is used to validate a TLS connection terminating on the
1327 device with a known serial number.
1329 * The AK is used to sign attestation quotes, providing proof that
1330 the attestation evidence comes from the same device.
1332 5.3. Replay Attacks
1334 Replay attacks, where results of a previous attestation are submitted
1335 in response to subsequent requests, are usually prevented by
1336 inclusion of a random nonce in the request to the TPM for a quote.
1337 Each request from the Verifier includes a new random number (a
1338 nonce). The resulting quote signed by the TPM contains the same
1339 nonce, allowing the Verifier to determine freshness, (i.e., that the
1340 resulting quote was generated in response to the Verifier's specific
1341 request). Time-Based Uni-directional Attestation
1342 [I-D.birkholz-rats-tuda] provides an alternate mechanism to verify
1343 freshness without requiring a request/response cycle.
1345 5.4. Owner-Signed Keys
1347 Although device manufacturers must pre-provision devices with easily
1348 verified DevID and AK certificates if zero-touch provisioning such as
1349 described in [RFC8572] is to be supported, use of those credentials
1350 is not mandatory. IEEE 802.1AR incorporates the idea of an Initial
1351 Device ID (IDevID), provisioned by the manufacturer, and a Local
1352 Device ID (LDevID) provisioned by the owner of the device. RIV and
1353 [Platform-DevID-TPM-2.0] extends that concept by defining an Initial
1354 Attestation Key (IAK) and Local Attestation Key (LAK) with the same
1355 properties.
1357 Device owners can use any method to provision the Local credentials.
1359 * TCG document [Platform-DevID-TPM-2.0] shows how the initial
1360 Attestation keys can be used to certify LDevID and LAK keys. Use
1361 of the LDevID and LAK allows the device owner to use a uniform
1362 identity structure across device types from multiple manufacturers
1363 (in the same way that an "Asset Tag" is used by many enterprises
1364 to identify devices they own). TCG document
1365 [Provisioning-TPM-2.0] also contains guidance on provisioning
1366 Local identity keys in TPM 2.0. Owners should follow the same
1367 practice of binding Local DevID and Local AK as the manufacturer
1368 would for IDevID and IAK. See Section Section 2.2.
1370 * Device owners, however, can use any other mechanism they want to
1371 assure themselves that local identity certificates are inserted
1372 into the intended device, including physical inspection and
1373 programming in a secure location, if they prefer to avoid placing
1374 trust in the manufacturer-provided keys.
1376 Clearly, local keys can't be used for secure Zero Touch provisioning;
1377 installation of the local keys can only be done by some process that
1378 runs before the device is installed for network operation, or using
1379 procedures such as those outlined in Bootstrapping Remote Secure Key
1380 Infrastructure (BRSKI) [RFC8995].
1382 On the other end of the device life cycle, provision should be made
1383 to wipe local keys when a device is decommissioned, to indicate that
1384 the device is no longer owned by the enterprise. The manufacturer's
1385 Initial identity keys must be preserved, as they contain no
1386 information that's not already printed on the device's serial number
1387 plate.
1389 5.5. Other Factors for Trustworthy Operation
1391 In addition to trustworthy provisioning of keys, RIV depends on a
1392 number of other factors for trustworthy operation.
1394 * Secure identity depends on mechanisms to prevent per-device secret
1395 keys from being compromised. The TPM provides this capability as
1396 a Root of Trust for Storage.
1398 * Attestation depends on an unbroken chain of measurements, starting
1399 from the very first measurement. See Section 9.1 for background
1400 on TPM practices.
1402 * That first measurement is made by code called the Root of Trust
1403 for Measurement, typically done by trusted firmware stored in boot
1404 flash. Mechanisms for maintaining the trustworthiness of the RTM
1405 are out of scope for RIV, but could include immutable firmware,
1406 signed updates, or a vendor-specific hardware verification
1407 technique. See Section 9.2 for background on roots of trust.
1409 * The device owner SHOULD provide some level of physical defense for
1410 the device. If a TPM that has already been programmed with an
1411 authentic DevID is stolen and inserted into a counterfeit device,
1412 attestation of that counterfeit device may become
1413 indistinguishable from an authentic device.
1415 RIV also depends on reliable Reference Values, as expressed by the
1416 RIM [RIM]. The definition of trust procedures for RIMs is out of
1417 scope for RIV, and the device owner is free to use any policy to
1418 validate a set of reference measurements. It should also be noted
1419 that, while RIV can provide a reliable indication that a known
1420 software package is in use by the device, and that the package has
1421 not been tampered, it is the device owner's responsibility to
1422 determine that it's the correct package for the application.
1424 RIMs may be conveyed out-of-band or in-band, as part of the
1425 attestation process (see Section 3.1.3). But for network devices,
1426 where software is usually shipped as a self-contained package, RIMs
1427 signed by the manufacturer and delivered in-band may be more
1428 convenient for the device owner.
1430 The validity of RIV attestation results is also influenced by
1431 procedures used to create Reference Values:
1433 * While the RIM itself is signed, supply-chains SHOULD be carefully
1434 scrutinized to ensure that the values are not subject to
1435 unexpected manipulation prior to signing. Insider-attacks against
1436 code bases and build chains are particularly hard to spot.
1438 * Designers SHOULD guard against hash collision attacks. Reference
1439 Integrity Manifests often give hashes for large objects of
1440 indeterminate size; if one of the measured objects can be replaced
1441 with an implant engineered to produce the same hash, RIV will be
1442 unable to detect the substitution. TPM1.2 uses SHA-1 hashes only,
1443 which have been shown to be susceptible to collision attack.
1444 TPM2.0 will produce quotes with SHA-256, which so far has resisted
1445 such attacks. Consequently, RIV implementations SHOULD use
1446 TPM2.0.
1448 6. IANA Considerations
1450 This document has no IANA actions.
1452 7. Conclusion
1454 TCG technologies can play an important part in the implementation of
1455 Remote Integrity Verification. Standards for many of the components
1456 needed for implementation of RIV already exist:
1458 * Platform identity can be based on IEEE 802.1AR Device Identity,
1459 coupled with careful supply-chain management by the manufacturer.
1461 * Complex supply chains can be certified using TCG Platform
1462 Certificates [Platform-Certificates].
1464 * The TCG TAP mechanism coupled with [I-D.ietf-rats-yang-tpm-charra]
1465 can be used to retrieve attestation evidence.
1467 * Reference Values must be conveyed from the software authority
1468 (e.g., the manufacturer) in Reference Integrity Manifests, to the
1469 system in which verification will take place. IETF and TCG SWID
1470 and CoSWID work ([I-D.ietf-sacm-coswid], [RIM]) forms the basis
1471 for this function.
1473 8. Acknowledgements
1475 The authors wish to thank numerous reviewers for generous assistance,
1476 including William Bellingrath, Mark Baushke, Ned Smith, Henk
1477 Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas
1478 Hardjono, Bill Sulzen, Willard (Monty) Wiseman, Kathleen Moriarty,
1479 Nancy Cam-Winget and Shwetha Bhandari
1481 9. Appendix
1483 9.1. Using a TPM for Attestation
1485 The Trusted Platform Module and surrounding ecosystem provide three
1486 interlocking capabilities to enable secure collection of evidence
1487 from a remote device, Platform Configuration Registers (PCRs), a
1488 Quote mechanism, and a standardized Event Log.
1490 Each TPM has at least eight and at most twenty-four PCRs (depending
1491 on the profile and vendor choices), each one large enough to hold one
1492 hash value (SHA-1, SHA-256, and other hash algorithms can be used,
1493 depending on TPM version). PCRs can't be accessed directly from
1494 outside the chip, but the TPM interface provides a way to "extend" a
1495 new security measurement hash into any PCR, a process by which the
1496 existing value in the PCR is hashed with the new security measurement
1497 hash, and the result placed back into the same PCR. The result is a
1498 composite fingerprint comprising the hash of all the security
1499 measurements extended into each PCR since the system was reset.
1501 Every time a PCR is extended, an entry should be added to the
1502 corresponding Event Log. Logs contain the security measurement hash
1503 plus informative fields offering hints as to which event generated
1504 the security measurement. The Event Log itself is protected against
1505 accidental manipulation, but it is implicitly tamper-evident - any
1506 verification process can read the security measurement hash from the
1507 log events, compute the composite value and compare that to what
1508 ended up in the PCR. If there's no discrepancy, the logs do provide
1509 an accurate view of what was placed into the PCR.
1511 Note that the composite hash-of-hashes recorded in PCRs is order-
1512 dependent, resulting in different PCR values for different ordering
1513 of the same set of events (e.g. Event A followed by Event B yields a
1514 different PCR value than B followed by A). For single-threaded code,
1515 where both the events and their order are fixed, a Verifier may
1516 validate a single PCR value, and use the log only to diagnose a
1517 mismatch from Reference Values. However, operating system code is
1518 usually non-deterministic, meaning that there may never be a single
1519 "known good" PCR value. In this case, the Verifier may have to
1520 verify that the log is correct, and then analyze each item in the log
1521 to determine if it represents an authorized event.
1523 In a conventional TPM Attestation environment, the first measurement
1524 must be made and extended into the TPM by trusted device code (called
1525 the Root of Trust for Measurement, RTM). That first measurement
1526 should cover the segment of code that is run immediately after the
1527 RTM, which then measures the next code segment before running it, and
1528 so on, forming an unbroken chain of trust. See [TCGRoT] for more on
1529 Mutable vs Immutable roots of trust.
1531 The TPM provides another mechanism called a Quote that can read the
1532 current value of the PCRs and package them, along with the Verifier's
1533 nonce, into a TPM-specific data structure signed by an Attestation
1534 private key, known only to the TPM.
1536 As noted above in Section 5 Security Considerations, it's important
1537 to note that the Quote data structure is signed inside the TPM. The
1538 trust model is preserved by retrieving the Quote in a way that does
1539 not invalidate the signature, as specified in
1540 [I-D.ietf-rats-yang-tpm-charra]. The structure of the command and
1541 response for a quote, including its signature, as generated by the
1542 TPM, can be seen in [TPM1.2] Part 3, Section 16.5, and [TPM2.0]
1543 Section 18.4.2.
1545 The Verifier uses the Quote and Log together. The Quote contains the
1546 composite hash of the complete sequence of security measurement
1547 hashes, signed by the TPM's private Attestation Key. The Log
1548 contains a record of each measurement extended into the TPM's PCRs.
1549 By computing the composite hash of all the measurements, the Verifier
1550 can verify the integrity of the Event Log, even though the Event Log
1551 itself is not signed. Each hash in the validated Event Log can then
1552 be compared to corresponding expected values in the set of Reference
1553 Values to validate overall system integrity.
1555 A summary of information exchanged in obtaining quotes from TPM1.2
1556 and TPM2.0 can be found in [TAP], Section 4. Detailed information
1557 about PCRs and Quote data structures can be found in [TPM1.2],
1558 [TPM2.0]. Recommended log formats include [PC-Client-BIOS-TPM-2.0],
1559 and [Canonical-Event-Log].
1561 9.2. Root of Trust for Measurement
1563 The measurements needed for attestation require that the device being
1564 attested is equipped with a Root of Trust for Measurement, that is,
1565 some trustworthy mechanism that can compute the first measurement in
1566 the chain of trust required to attest that each stage of system
1567 startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs)
1568 to record the results, and a Root of Trust for Reporting to report
1569 the results.
1571 While there are many complex aspects of Roots of Trust ( [TCGRoT],
1572 [SP800-155], [SP800-193]), two aspects that are important in the case
1573 of attestation are:
1575 * The first measurement computed by the Root of Trust for
1576 Measurement, and stored in the TPM's Root of Trust for Storage,
1577 must be assumed to be correct.
1579 * There must not be a way to reset the Root of Trust for Storage
1580 without re-entering the Root of Trust for Measurement code.
1582 The first measurement must be computed by code that is implicitly
1583 trusted; if that first measurement can be subverted, none of the
1584 remaining measurements can be trusted. (See [SP800-155])
1586 It's important to note that the trustworthiness of the RTM code
1587 cannot be assured by the TPM or TPM supplier - code or procedures
1588 external to the TPM must guarantee the security of the RTM.
1590 9.3. Layering Model for Network Equipment Attester and Verifier
1592 Retrieval of identity and attestation state uses one protocol stack,
1593 while retrieval of Reference Values uses a different set of
1594 protocols. Figure 5 shows the components involved.
1596 +-----------------------+ +-------------------------+
1597 | | | |
1598 | Attester |<-------------| Verifier |
1599 | (Device) |------------->| (Management Station) |
1600 | | | | |
1601 +-----------------------+ | +-------------------------+
1602 |
1603 -------------------- --------------------
1604 | |
1605 ------------------------------- ---------------------------------
1606 |Reference Values | | Attestation |
1607 ------------------------------- ---------------------------------
1609 ********************************************************************
1610 * IETF Attestation Reference Interaction Diagram *
1611 ********************************************************************
1613 ......................... .........................
1614 . Reference Integrity . . TAP (PTS2.0) Info .
1615 . Manifest . . Model and Canonical .
1616 . . . Log Format .
1617 ......................... .........................
1619 ************************* *************************
1620 * YANG SWID Module * * YANG Attestation *
1621 * I-D.ietf-sacm-coswid * * Module *
1622 * * * I-D.ietf-rats- *
1623 * * * yang-tpm-charra *
1624 ************************* *************************
1626 ************************* *************************
1627 * XML, JSON, CBOR (etc) * * XML, JSON, CBOR (etc) *
1628 ************************* *************************
1630 ************************* *************************
1631 * RESTCONF/NETCONF * * RESTCONF/NETCONF *
1632 ************************* *************************
1634 ************************* *************************
1635 * TLS, SSH * * TLS, SSH *
1636 ************************* *************************
1638 Figure 6: RIV Protocol Stacks
1640 IETF documents are captured in boxes surrounded by asterisks. TCG
1641 documents are shown in boxes surrounded by dots.
1643 9.4. Implementation Notes
1645 Figure 7 summarizes many of the actions needed to complete an
1646 Attestation system, with links to relevant documents. While
1647 documents are controlled by several standards organizations, the
1648 implied actions required for implementation are all the
1649 responsibility of the manufacturer of the device, unless otherwise
1650 noted.
1652 As noted, SWID tags can be generated many ways, but one possible tool
1653 is [SWID-Gen]
1655 +------------------------------------------------------------------+
1656 | Component | Controlling |
1657 | | Specification |
1658 --------------------------------------------------------------------
1659 | Make a Secure execution environment | TCG RoT |
1660 | o Attestation depends on a secure root of | UEFI.org |
1661 | trust for measurement outside the TPM, as | |
1662 | well as roots for storage and reporting | |
1663 | inside the TPM. | |
1664 | o Refer to TCG Root of Trust for Measurement.| |
1665 | o NIST SP 800-193 also provides guidelines | |
1666 | on Roots of Trust | |
1667 --------------------------------------------------------------------
1668 | Provision the TPM as described in |[Platform-DevID-TPM-2.0]|
1669 | TCG documents. | TCG Platform |
1670 | | Certificate |
1671 --------------------------------------------------------------------
1672 | Put a DevID or Platform Cert in the TPM | TCG TPM DevID |
1673 | o Install an Initial Attestation Key at the | TCG Platform |
1674 | same time so that Attestation can work out | Certificate |
1675 | of the box |-----------------
1676 | o Equipment suppliers and owners may want to | IEEE 802.1AR |
1677 | implement Local Device ID as well as | |
1678 | Initial Device ID | |
1679 --------------------------------------------------------------------
1680 | Connect the TPM to the TLS stack | Vendor TLS |
1681 | o Use the DevID in the TPM to authenticate | stack (This |
1682 | TAP connections, identifying the device | action is |
1683 | | configuring TLS|
1684 | | to use the DevID |
1685 | | as its client |
1686 | | certificate) |
1687 --------------------------------------------------------------------
1688 | Make CoSWID tags for BIOS/Loader/Kernel objects | IETF CoSWID |
1689 | o Add reference measurements into SWID tags | ISO/IEC 19770-2|
1690 | o Manufacturer should sign the SWID tags | NIST IR 8060 |
1691 | o The TCG RIM-IM identifies further | |
1692 | procedures to create signed RIM | |
1693 | documents that provide the necessary | |
1694 | reference information | |
1695 --------------------------------------------------------------------
1696 | Package the SWID tags with a vendor software | Retrieve tags |
1697 | release | with |
1698 | o A tag-generator plugin such | I-D.ietf-sacm-coswid|
1699 | as [SWID-Gen] can be used |----------------|
1700 | | TCG PC Client |
1701 | | RIM |
1702 --------------------------------------------------------------------
1703 | Use PC Client measurement definitions | TCG PC Client |
1704 | to define the use of PCRs | BIOS |
1705 | (although Windows OS is rare on Networking | |
1706 | Equipment, UEFI BIOS is not) | |
1707 --------------------------------------------------------------------
1708 | Use TAP to retrieve measurements | |
1709 | o Map to YANG | YANG Module for|
1710 | Use Canonical Log Format | Basic |
1711 | | Attestation |
1712 | | TCG Canonical |
1713 | | Log Format |
1714 --------------------------------------------------------------------
1715 | Posture Collection Server (as described in IETF | |
1716 | SACMs ECP) should request the | |
1717 | attestation and analyze the result | |
1718 | The Management application might be broken down | |
1719 | to several more components: | |
1720 | o A Posture Manager Server | |
1721 | which collects reports and stores them in | |
1722 | a database | |
1723 | o One or more Analyzers that can look at the| |
1724 | results and figure out what it means. | |
1725 --------------------------------------------------------------------
1727 Figure 7: Component Status
1729 10. References
1731 10.1. Normative References
1733 [Canonical-Event-Log]
1734 Trusted Computing Group, "Canonical Event Log Format
1735 Version 1.0 Revision .41, February 25, 2022", December
1736 2020, .
1739 [I-D.ietf-rats-architecture]
1740 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
1741 W. Pan, "Remote Attestation Procedures Architecture", Work
1742 in Progress, Internet-Draft, draft-ietf-rats-architecture-
1743 15, 8 February 2022, .
1746 [I-D.ietf-rats-yang-tpm-charra]
1747 Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen,
1748 B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A
1749 YANG Data Model for Challenge-Response-based Remote
1750 Attestation Procedures using TPMs", Work in Progress,
1751 Internet-Draft, draft-ietf-rats-yang-tpm-charra-18, 20
1752 March 2022, .
1755 [I-D.ietf-sacm-coswid]
1756 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
1757 Waltermire, "Concise Software Identification Tags", Work
1758 in Progress, Internet-Draft, draft-ietf-sacm-coswid-21, 7
1759 March 2022, .
1762 [IEEE-802-1AR]
1763 Seaman, M., "802.1AR-2018 - IEEE Standard for Local and
1764 Metropolitan Area Networks - Secure Device Identity, IEEE
1765 Computer Society", August 2018.
1767 [IMA] dsafford, kds_etu, mzohar, reinersailer, and serge_hallyn,
1768 "Integrity Measurement Architecture", June 2019,
1769 .
1771 [PC-Client-BIOS-TPM-2.0]
1772 Trusted Computing Group, "PC Client Specific Platform
1773 Firmware Profile Specification Family "2.0", Level 00
1774 Revision 1.05 Revision 23, May 7, 2021", May 2021,
1775 .
1778 [PC-Client-EFI-TPM-1.2]
1779 Trusted Computing Group, "TCG EFI Platform Specification
1780 for TPM Family 1.1 or 1.2, Specification Version 1.22,
1781 Revision 15", January 2014,
1782 .
1785 [PC-Client-RIM]
1786 Trusted Computing Group, "TCG PC Client Reference
1787 Integrity Manifest Specification, v1.04, Nov 4, 2020",
1788 December 2019,
1789 .
1792 [Platform-DevID-TPM-2.0]
1793 Trusted Computing Group, "TPM 2.0 Keys for Device Identity
1794 and Attestation, Specification Version 1.0, Revision 2",
1795 September 2020,
1796 .
1799 [Platform-ID-TPM-1.2]
1800 Trusted Computing Group, "TPM Keys for Platform Identity
1801 for TPM 1.2, Specification Version 1.0, Revision 3",
1802 August 2015, .
1805 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1806 Requirement Levels", BCP 14, RFC 2119,
1807 DOI 10.17487/RFC2119, March 1997,
1808 .
1810 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
1811 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
1812 January 2006, .
1814 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1815 Housley, R., and W. Polk, "Internet X.509 Public Key
1816 Infrastructure Certificate and Certificate Revocation List
1817 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1818 .
1820 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1821 and A. Bierman, Ed., "Network Configuration Protocol
1822 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1823 .
1825 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1826 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1827 May 2017, .
1829 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1830 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1831 .
1833 [RIM] Trusted Computing Group, "TCG Reference Integrity Manifest
1834 (RIM) Information Model, v1.0, Revision 0.16, Nov 12,
1835 2020", June 2019,
1836 .
1839 [SWID] The International Organization for Standardization/
1840 International Electrotechnical Commission, "Information
1841 Technology Software Asset Management Part 2: Software
1842 Identification Tag, ISO/IEC 19770-2", October 2015,
1843 .
1845 [TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol
1846 (TAP) Information Model for TPM Families 1.2 and 2.0 and
1847 DICE Family 1.0, Version 1.0, Revision 0.36", October
1848 2018, .
1851 10.2. Informative References
1853 [AK-Enrollment]
1854 Trusted Computing Group, "TCG Infrastructure Working Group
1855 - A CMC Profile for AIK Certificate Enrollment Version
1856 1.0, Revision 7", March 2011,
1857 .
1861 [I-D.birkholz-rats-network-device-subscription]
1862 Birkholz, H., Voit, E., and W. Pan, "Attestation Event
1863 Stream Subscription", Work in Progress, Internet-Draft,
1864 draft-birkholz-rats-network-device-subscription-03, 17
1865 August 2021, .
1868 [I-D.birkholz-rats-reference-interaction-model]
1869 Birkholz, H., Eckel, M., Newton, C., and L. Chen,
1870 "Reference Interaction Models for Remote Attestation
1871 Procedures", Work in Progress, Internet-Draft, draft-
1872 birkholz-rats-reference-interaction-model-03, 7 July 2020,
1873 .
1876 [I-D.birkholz-rats-tuda]
1877 Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann,
1878 "Time-Based Uni-Directional Attestation", Work in
1879 Progress, Internet-Draft, draft-birkholz-rats-tuda-06, 12
1880 January 2022, .
1883 [I-D.ietf-rats-eat]
1884 Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity
1885 Attestation Token (EAT)", Work in Progress, Internet-
1886 Draft, draft-ietf-rats-eat-12, 24 February 2022,
1887 .
1890 [I-D.richardson-rats-usecases]
1891 Richardson, M., Wallace, C., and W. Pan, "Use cases for
1892 Remote Attestation common encodings", Work in Progress,
1893 Internet-Draft, draft-richardson-rats-usecases-08, 2
1894 November 2020, .
1897 [IEEE-802.1AE]
1898 Seaman, M., "802.1AE MAC Security (MACsec)", 2018,
1899 .
1901 [IEEE-802.1X]
1902 IEEE Computer Society, "802.1X-2020 - IEEE Standard for
1903 Local and Metropolitan Area Networks--Port-Based Network
1904 Access Control", February 2020,
1905 .
1907 [LLDP] IEEE Computer Society, "802.1AB-2016 - IEEE Standard for
1908 Local and metropolitan area networks - Station and Media
1909 Access Control Connectivity Discovery", March 2016,
1910 .
1912 [NetEq] Trusted Computing Group, "TCG Guidance for Securing
1913 Network Equipment, Version 1.0, Revision 29", January
1914 2018, .
1917 [NIST-IR-8060]
1918 National Institute for Standards and Technology,
1919 "Guidelines for the Creation of Interoperable Software
1920 Identification (SWID) Tags", April 2016,
1921 .
1924 [Platform-Certificates]
1925 Trusted Computing Group, "TCG Platform Attribute
1926 Credential Profile, Specification Version 1.0, Revision
1927 16", January 2018,
1928 .
1931 [Provisioning-TPM-2.0]
1932 Trusted Computing Group, "TCG TPM v2.0 Provisioning
1933 Guidance, Version 1.0, Revision 1.0", March 2015,
1934 .
1937 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
1938 Levkowetz, Ed., "Extensible Authentication Protocol
1939 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
1940 .
1942 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1943 Verification of Domain-Based Application Service Identity
1944 within Internet Public Key Infrastructure Using X.509
1945 (PKIX) Certificates in the Context of Transport Layer
1946 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
1947 2011, .
1949 [RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment
1950 (NEA) Asokan Attack Analysis", RFC 6813,
1951 DOI 10.17487/RFC6813, December 2012,
1952 .
1954 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1955 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1956 .
1958 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
1959 Touch Provisioning (SZTP)", RFC 8572,
1960 DOI 10.17487/RFC8572, April 2019,
1961 .
1963 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
1964 and K. Watsen, "Bootstrapping Remote Secure Key
1965 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
1966 May 2021, .
1968 [SP800-155]
1969 National Institute of Standards and Technology, "BIOS
1970 Integrity Measurement Guidelines (Draft)", December 2011,
1971 .
1974 [SP800-193]
1975 National Institute for Standards and Technology, "NIST
1976 Special Publication 800-193: Platform Firmware Resiliency
1977 Guidelines", April 2018,
1978 .
1981 [SWID-Gen] Labs64, Munich, Germany, "SoftWare IDentification (SWID)
1982 Tags Generator (Maven Plugin)", n.d.,
1983 .
1985 [TCGRoT] Trusted Computing Group, "DRAFT: TCG Roots of Trust
1986 Specification", October 2018,
1987 .
1990 [TPM1.2] Trusted Computing Group, "TPM Main Specification Level 2
1991 Version 1.2, Revision 116", March 2011,
1992 .
1995 [TPM2.0] Trusted Computing Group, "Trusted Platform Module Library
1996 Specification, Family "2.0", Level 00, Revision 01.59",
1997 November 2019,
1998 .
2001 Authors' Addresses
2003 Guy Fedorkow (editor)
2004 Juniper Networks, Inc.
2005 10 Technology Park Drive
2006 Westford, Massachusetts 01886
2007 United States of America
2008 Email: gfedorkow@juniper.net
2010 Eric Voit
2011 Cisco Systems
2012 Email: evoit@cisco.com
2013 Jessica Fitzgerald-McKay
2014 National Security Agency
2015 9800 Savage Road
2016 Ft. Meade, Maryland 20755
2017 United States of America
2018 Email: jmfitz2@nsa.gov