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