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