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