idnits 2.17.1 draft-ietf-rats-tpm-based-network-device-attest-02.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 (July 13, 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 517 -- Looks like a reference, but probably isn't: '2' on line 528 -- Looks like a reference, but probably isn't: '4' on line 530 -- Looks like a reference, but probably isn't: '8' on line 536 -- Looks like a reference, but probably isn't: '5' on line 533 == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-02 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-05 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-03 == Outdated reference: A later version (-22) exists of draft-ietf-rats-yang-tpm-charra-02 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-15 == Outdated reference: A later version (-08) exists of draft-richardson-rats-usecases-07 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. Fedorkow, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Informational E. Voit 5 Expires: January 14, 2021 Cisco Systems, Inc. 6 J. Fitzgerald-McKay 7 National Security Agency 8 July 13, 2020 10 TPM-based Network Device Remote Integrity Verification 11 draft-ietf-rats-tpm-based-network-device-attest-02 13 Abstract 15 This document describes a workflow for remote attestation of the 16 integrity of network devices. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 14, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4 55 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.4. Description of Remote Integrity Verification (RIV) . . . 5 57 1.5. Solution Requirements . . . . . . . . . . . . . . . . . . 7 58 1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 1.6.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8 60 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8 61 2.1. RIV Software Configuration Attestation using TPM . . . . 8 62 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 9 63 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 12 64 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 13 65 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 15 66 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 16 67 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 17 68 3. Standards Components . . . . . . . . . . . . . . . . . . . . 17 69 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 17 70 3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 18 71 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 18 72 3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 18 73 3.2. Reference Model for Challenge-Response . . . . . . . . . 19 74 3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 21 75 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 21 76 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 78 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 28 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 80 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 29 81 8.1. Layering Model for Network Equipment Attester and 82 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 29 83 8.1.1. Why is OS Attestation Different? . . . . . . . . . . 31 84 8.2. Implementation Notes . . . . . . . . . . . . . . . . . . 31 85 8.3. Root of Trust for Measurement . . . . . . . . . . . . . . 33 86 9. Informative References . . . . . . . . . . . . . . . . . . . 33 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 89 1. Introduction 91 There are many aspects to consider in fielding a trusted computing 92 device, from operating systems to applications. Mechanisms to prove 93 that a device installed at a customer's site is authentic (i.e., not 94 counterfeit) and has been configured with authorized software, all as 95 part of a trusted supply chain, are just a few of the many aspects 96 which need to be considered concurrently to have confidence that a 97 device is truly trustworthy. 99 A generic architecture for remote attestation has been defined in 100 [I-D.ietf-rats-architecture]. Additionally, the use case for 101 remotely attesting networking devices is within Section 6 of 102 [I-D.richardson-rats-usecases]. However, these documents do not 103 provide sufficient guidance for equipment vendors and network 104 operators to design, build, and deploy interoperable platforms. 106 The intent of this document is to provide such guidance. It does 107 this by outlining the Remote Integrity Verification (RIV) problem, 108 and then identifies elements that are necessary to get the complete, 109 scalable attestation procedure working with commercial networking 110 products such as routers, switches and firewalls. An underlying 111 assumption will be the availability within the device of a Trusted 112 Platform Module (TPM) compliant cryptoprocessor to enable the remote 113 trustworthy assessment of the device's software and hardware. 115 1.1. Terminology 117 A number of terms are reused from [I-D.ietf-rats-architecture]. 118 These include: Appraisal Policy for Attestation Result, Attestation 119 Result, Attester, Endorser, Evidence, Relying Party, Verifier, 120 Verifier Owner. 122 Additionally, this document defines the following terms: 124 Attestation: the process of creating, conveying and appraising 125 assertions about Platform trustworthiness characteristics, including 126 supply chain trust, identity, platform provenance, software 127 configuration, hardware configuration, platform composition, 128 compliance to test suites, functional and assurance evaluations, etc. 130 The goal of attestation is simply to assure an administrator that the 131 software that was launched when the device was last started is an 132 authentic and untampered copy of the software that the device vendor 133 shipped. 135 Within the Trusted Computing Group context, attestation is the 136 process by which an independent Verifier can obtain cryptographic 137 proof as to the identity of the device in question, evidence of the 138 integrity of software loaded on that device when it started up, and 139 then verify that what's there is what's supposed to be there. For 140 networking equipment, a verifier capability can be embedded in a 141 Network Management Station (NMS), a posture collection server, or 142 other network analytics tool (such as a software asset management 143 solution, or a threat detection and mitigation tool, etc.). While 144 informally referred to as attestation, this document focuses on a 145 subset defined here as Remote Integrity Verification (RIV). RIV 146 takes a network equipment centric perspective that includes a set of 147 protocols and procedures for determining whether a particular device 148 was launched with untampered software, starting from Roots of Trust. 149 While there are many ways to accomplish attestation, RIV sets out a 150 specific set of protocols and tools that work in environments 151 commonly found in Networking Equipment. RIV does not cover other 152 platform characteristics that could be attested (e.g. geographic 153 location, connectivity; see [I-D.richardson-rats-usecases]), although 154 it does provide evidence of a secure infrastructure to increase the 155 level of trust in other platform characteristics attested by other 156 means (e.g., by Entity Attestation Tokens [I-D.ietf-rats-eat]). 158 1.2. Document Organization 160 The remainder of this document is organized into several sections: 162 o The remainder of this section covers goals and requirements, plus 163 a top-level description of RIV 165 o The Solution Overview section outlines how RIV works 167 o The Standards Components section links components of RIV to 168 normative standards. 170 o Privacy and Security shows how specific features of RIV contribute 171 to the trustworthiness of the attestation result 173 o Supporting material is in an appendix at the end. 175 1.3. Goals 177 Network operators benefit from a trustworthy attestation mechanism 178 that provides assurance that their network comprises authentic 179 equipment, and has loaded software free of known vulnerabilities and 180 unauthorized tampering. In line with the overall goal of assuring 181 integrity, attestation can be used for asset management, 182 vulnerability and compliance assessment, plus configuration 183 management. 185 As a part of a trusted supply chain, the RIV attestation workflow 186 outlined in this document is intended to meet the following high- 187 level goals: 189 o Provable Device Identity - This specification requires that an 190 attesting device includes a cryptographic identifier unique to 191 each device. Effectively this means that the TPM or equivalent 192 cryptoprocessor must be so provisioned during the manufacturing 193 cycle. 195 o Software Inventory - A key goal is to identify the software 196 release installed on the attesting device, and to provide evidence 197 that the software stored within hasn't been altered 199 o Verifiability - Verification of software and configuration of the 200 device shows that the software that was authorized for 201 installation by the administrator has actually been launched. 203 In addition, RIV is designed to operate in a centralized environment, 204 such as with a central authority that manages and configures a number 205 of network devices, or 'peer-to-peer', where network devices 206 independently verify one another to establish a trust relationship. 207 (See Section 3.3 below, and also 208 [I-D.voit-rats-trusted-path-routing]) 210 1.4. Description of Remote Integrity Verification (RIV) 212 Attestation requires two interlocking services between the Attester 213 network device and the Verifier:: 215 o Platform Identity, the mechanism providing trusted identity, can 216 reassure network managers that the specific devices they ordered 217 from authorized manufacturers for attachment to their network are 218 those that were installed, and that they continue to be present in 219 their network. As part of the mechanism for Platform Identity, 220 cryptographic proof of the identity of the manufacturer is also 221 provided. 223 o Software Measurement is the mechanism that reports the state of 224 mutable software components on the device, and can assure network 225 managers that they have known, untampered software configured to 226 run in their network. 228 Using these two interlocking services, RIV provides a procedure that 229 assures a network operator that the equipment in their network can be 230 reliably identified, and that untampered software of a known version 231 is installed on each endpoint. Equipment in the network includes 232 devices that make up the network itself, such as routers, switches 233 and firewalls. 235 RIV includes several major processes: 237 1. Creation of Evidence is the process whereby an Attester generates 238 cryptographic proof (Evidence) of claims about platform 239 properties. In particular, the platform identity and its 240 software configuration are both of critical importance 242 2. Platform Identification refers to the mechanism assuring the 243 Relying Party (ultimately, a network administrator) of the 244 identity of devices that make up their network, and that their 245 manufacturers are known. 247 3. Software used to boot a platform can be described as a chain of 248 measurements, started by a Root of Trust for Measurement, that 249 normally ends when the system software is loaded. A measurement 250 signifies the identity, integrity and version of each software 251 component registered with an attesting device's TPM, so that the 252 subsequent appraisal stage can determine if the software 253 installed is authentic, up-to-date, and free of tampering. 255 4. Conveyance of Evidence reliably transports at least the minimum 256 amount of Evidence from Attester to a Verifier to allow a 257 management station to perform a meaningful appraisal in Step 5. 258 The transport is typically carried out via a management network. 259 The channel must provide integrity and authenticity, and, in some 260 use cases, may also require confidentiality. 262 5. Finally, Appraisal of Evidence occurs. As the Verifier and 263 Relying Party roles are often combined within RIV, this is the 264 process of verifying the Evidence received by a Verifier from the 265 Attesting device, and using an Appraisal Policy to develop an 266 Attestation Result, used to inform decision making. In practice, 267 this means comparing the device measurements reported as Evidence 268 with the Attester configuration expected by the Verifier. 269 Subsequently the Appraisal Policy for Attestation Results might 270 match what was found against Reference Integrity Measurements 271 (aka Golden Measurements) which represent the intended configured 272 state of the connected device. 274 All implementations supporting this RIV specification require the 275 support of the following three technologies: 1. Identity: Platform 276 identity can be based on IEEE 802.1AR Device Identity [IEEE-802-1AR], 277 coupled with careful supply-chain management by the manufacturer. 278 The DevID certificate contains a statement by the manufacturer that 279 establishes the identity of the device as it left the factory. Some 280 applications with a more-complex post-manufacture supply chain (e.g. 281 Value Added Resellers), or with different privacy concerns, may want 282 to use alternative mechanisms for platform authentication (for 283 example, TCG Platform Certificates [Platform-Certificates]). 285 1. Platform Attestation provides evidence of configuration of 286 software elements present in the device. This form of 287 attestation can be implemented with TPM PCR, Quote and Log 288 mechanisms, which provide an authenticated mechanism to report 289 what software was started on the device through the boot cycle. 291 Successful attestation requires an unbroken chain from a boot- 292 time root of trust through all layers of software needed to bring 293 the device to an operational state. 295 2. Reference Integrity Measurements must be conveyed from the 296 Endorser (the entity accepted as the software authority, often 297 the manufacturer for embedded systems) to the system in which 298 verification will take place 300 1.5. Solution Requirements 302 Remote Integrity Verification must address the "Lying Endpoint" 303 problem, in which malicious software on an endpoint may subvert the 304 intended function, and also prevent the endpoint from reporting its 305 compromised status. (See Section 5 for further Security 306 Considerations) 308 RIV attestation is designed to be simple to deploy at scale. RIV 309 should work "out of the box" as far as possible, that is, with the 310 fewest possible provisioning steps or configuration databases needed 311 at the end-user's site, as network equipment is often required to 312 "self-configure", to reliably reach out without manual intervention 313 to prove its identity and operating posture, then download its own 314 configuration. See [RFC8572] for an example of Secure Zero Touch 315 Provisioning. 317 1.6. Scope 319 Remote Attestation is a very general problem that could apply to most 320 network-connected computing devices. However, this document includes 321 several assumptions that limit the scope to Network Equipment (e.g. 322 routers, switches and firewalls): 324 o This solution is for use in non-privacy-preserving applications 325 (for example, networking, Industrial IoT), avoiding the need for a 326 Privacy Certificate Authority for attestation keys 327 [AIK-Enrollment] or TCG Platform Certificates 328 [Platform-Certificates] 330 o This document assumes network protocols that are common in 331 networking equipment such as YANG [RFC7950] and NETCONF [RFC6241], 332 but not generally used in other applications. 334 o The approach outlined in this document mandates the use of TPM 1.2 335 or TPM 2.0. Other roots of trust could be used with the same 336 information flow, although different data structures would likely 337 be called for. 339 1.6.1. Out of Scope 341 o Run-Time Attestation: Run-time attestation of Linux or other 342 multi-threaded operating system processes considerably expands the 343 scope of the problem. Many researchers are working on that 344 problem, but this document defers the run-time attestation 345 problem. 347 o Multi-Vendor Embedded Systems: Additional coordination would be 348 needed for devices that themselves comprise hardware and software 349 from multiple vendors, integrated by the end user. 351 o Processor Sleep Modes: Network equipment typically does not 352 "sleep", so sleep and hibernate modes are not considered. 353 Although out of scope for RIV, Trusted Computing Group 354 specifications do encompass sleep and hibernate states. 356 o Virtualization and Containerization: In a non-virtualized system, 357 the host OS is responsible for measuring each Userland file or 358 process, but that't the end of the chain of trust. For 359 virtualized systems, the host OS must verify the hypervisor, which 360 then manages its own chain of trust through the virtual machine. 361 Virtualization and containerization technologies are increasingly 362 used in Network equipment, but are not considered in this revision 363 of the document. 365 2. Solution Overview 367 2.1. RIV Software Configuration Attestation using TPM 369 RIV Attestation is a process which can be used to determine the 370 identity of software running on a specifically-identified device. 371 Remote Attestation is broken into two phases, shown in Figure 1: 373 o During system startup, each distinct software object is 374 "measured". Its identity, hash (i.e. cryptographic digest) and 375 version information are recorded in a log. Hashes are also 376 extended, or cryptographically folded, into the TPM, in a way that 377 can be used to validate the log entries. The measurement process 378 generally follows the Chain of Trust model used in Measured Boot, 379 where each stage of the system measures the next one, and extends 380 its measurement into the TPM, before launching it. 382 o Once the device is running and has operational network 383 connectivity, a separate, trusted Verifier will interrogate the 384 network device to retrieve the logs and a copy of the digests 385 collected by hashing each software object, signed by an 386 attestation private key known only to the TPM. 388 The result is that the Verifier can verify the device's identity by 389 checking the certificate containing the TPM's attestation public key, 390 and can validate the software that was launched by comparing digests 391 in the log with known-good values, and verifying their correctness by 392 comparing with the signed digests from the TPM. 394 It should be noted that attestation and identity are inextricably 395 linked; signed Evidence that a particular version of software was 396 loaded is of little value without cryptographic proof of the identity 397 of the Attester producing the Evidence. 399 +-------------------------------------------------------+ 400 | +--------+ +--------+ +--------+ +---------+ | 401 | | BIOS |--->| Loader |-->| Kernel |--->|Userland | | 402 | +--------+ +--------+ +--------+ +---------+ | 403 | | | | | 404 | | | | | 405 | +------------+-----------+-+ | 406 | Step 1 | | 407 | V | 408 | +--------+ | 409 | | TPM | | 410 | +--------+ | 411 | Router | | 412 +--------------------------------|----------------------+ 413 | 414 | Step 2 415 | +-----------+ 416 +--->| Verifier | 417 +-----------+ 419 Reset---------------flow-of-time-during-boot--...-------> 421 Figure 1: RIV Attestation Model 423 In Step 1, measurements are "extended" into the TPM as processes 424 start. In Step 2, signed PCR digests are retrieved from the TPM for 425 off-box analysis after the system is operational. 427 2.1.1. What Does RIV Attest? 429 TPM attestation is strongly focused on Platform Configuration 430 Registers (PCRs), but those registers are only vehicles for 431 certifying accompanying Evidence, conveyed in log entries. It is the 432 hashes in log entries that are extended into PCRs, where the final 433 digests can be retrieved in the form of a Quote signed by a key known 434 only to the TPM. The use of multiple PCRs serves only to provide 435 some independence between different classes of object, so that one 436 class of objects can be updated without changing the extended hash 437 for other classes. Although PCRs can be used for any purpose, this 438 section outlines the objects within the scope of this document which 439 may be extended into the TPM. 441 In general, PCRs are organized to independently attest three classes 442 of object: 444 o Code, i.e., instructions to be executed by a CPU. 446 o Configuration - Many devices offer numerous options controlled by 447 non-volatile configuration variables which can impact the device's 448 security posture. These settings may have vendor defaults, but 449 often can be changed by administrators, who may want to verify via 450 attestation that the settings they intend are still in place. 452 o Credentials - Administrators may wish to verify via attestation 453 that keys (and other credentials) outside the Root of Trust have 454 not been subject to unauthorized tampering. (By definition, keys 455 inside the root of trust can't be verified independently) 457 The TCG PC Client Platform Firmware Profile Specification 458 [PC-Client-BIOS-TPM-2.0] gives considerable detail on what is to be 459 measured during the boot phase of a platform boot using a UEFI BOIS 460 (www.uefi.org), but the goal is simply to measure every bit of code 461 executed in the process of starting the device, along with any 462 configuration information related to security posture, leaving no gap 463 for unmeasured code to subvert the chain. 465 For platforms using a UEFI BIOS, [PC-Client-BIOS-TPM-2.0] gives 466 detailed normative requirements for PCR usage. But for other 467 platform architectures, the table in Figure 2 gives guidance for PCR 468 assignment that generalizes the specific details of 469 [PC-Client-BIOS-TPM-2.0]. 471 By convention, most PCRs are allocated in pairs, which the even- 472 numbered PCR used to measure executable code, and the odd-numbered 473 PCR used to measure whatever data and configuration are associated 474 with that code. It is important to note that each PCR may contain 475 results from dozens (or even thousands) of individual measurements. 477 +------------------------------------------------------------------+ 478 | | Allocated PCR # | 479 | Function | Code | Configuration| 480 -------------------------------------------------------------------- 481 | Firmware Static Root of Trust, i.e., | 0 | 1 | 482 | initial boot firmware and drivers | | | 483 -------------------------------------------------------------------- 484 | Drivers and initialization for optional | 2 | 3 | 485 | or add-in devices | | | 486 -------------------------------------------------------------------- 487 | OS Loader code and configuration, i.e., | 4 | 5 | 488 | the code launched by firmware to load an | | | 489 | operating system kernel. These PCRs record | | | 490 | each boot attempt, and an identifier for | | | 491 | where the loader was found | | | 492 -------------------------------------------------------------------- 493 | Vendor Specific Measurements during boot | 6 | 6 | 494 -------------------------------------------------------------------- 495 | Secure Boot Policy. This PCR records keys | | 7 | 496 | and configuration used to validate the OS | | | 497 | loader | | | 498 -------------------------------------------------------------------- 499 | Measurements made by the OS Loader | 8 | 9 | 500 | (e.g GRUB2 for Linux) | | | 501 -------------------------------------------------------------------- 502 | Measurements made by OS (e.g. Linux IMA) | 10 | 10 | 503 +------------------------------------------------------------------+ 505 Figure 2: Attested Objects 507 Notes on PCR Allocations 509 It is important to recognize that PCR[0] is critical. The first 510 measurement into PCR[0] taken by the Root of Trust for Measurement, 511 is critical to establishing the chain of trust for all subsequent 512 measurements. If the PCR[0] measurement cannot be trusted, the 513 validity of the entire chain is put into question. 515 Distinctions Between PCR[0], PCR[2], PCR[4] and PCR[8] 517 o PCR[0] typically represents a consistent view of the Host Platform 518 between boot cycles, allowing Attestation and Sealed Storage 519 policies to be defined using the less changeable components of the 520 transitive trust chain. This PCR typically provides a consistent 521 view of the platform regardless of user selected options. 523 o PCR[2] is intended to represent a "user configurable" environment 524 where the user has the ability to alter the components that are 525 measured into PCR[2]. This is typically done by adding adapter 526 cards, etc., into user-accessible PCI or other slots. In UEFI 527 systems these devices may be configured by Option ROMsm easured 528 into PCR[2] and executed by the BIOS. 530 o PCR[4] is intended to represent the software that manages the 531 transition between the platform's Pre-Operating System Start and 532 the state of a system with the Operating System present. This 533 PCR, along with PCR[5], identifies the initial operating system 534 loader (e.g. GRUB for Linux) 536 o PCR[8] is used by the OS loader to record measurements of the 537 various components of the operating system. 539 Although the TCG PC Client document specifies the use of the first 540 eight PCRs very carefully to ensure interoperability among multiple 541 UEFI BIOS vendors, it should be noted that embedded software vendors 542 may have considerably more flexibility. Verifiers typically need to 543 know which log entries are consequential and which are not (possibly 544 controlled by local policies) but the verifier may not need to know 545 what each log entry means or why it was assigned to a particular PCR. 546 Designers must recognize that some PCRs may cover log entries that a 547 particular verifier considers critical and other log entries that are 548 not considered important, so differing PCR values may not on their 549 own constitute a check for authenticity. 551 Designers may allocate particular events to specific PCRs in order to 552 achieve a particular objective with Local Attestation, i.e., allowing 553 a procedure to execute only if a given PCR is in a given state. It 554 may also be important to designers to consider whether streaming 555 notification of PCR updates is required (see ID Rats Streaming). 556 Specific log entries can only be validated if the verifier receives 557 every log entry affecting the relevant PCR, so (for example) a 558 designer might want to separate rare, high-value events such as 559 configuration changes, from high-volume, routine measurements such as 560 IMA logs. 562 2.2. RIV Keying 564 RIV attestation relies on two keys: 566 o An identity key is required to certify the identity of the 567 Attester itself. RIV specifies the use of an IEEE 802.1AR DevID 568 [IEEE-802-1AR], signed by the device manufacturer, containing the 569 device serial number. 571 o An Attestation Key is required to sign the Quote generated by the 572 TPM to report evidence of software configuration. 574 In TPM application, the Attestation key must be protected by the TPM, 575 and the DevID should be as well. Depending on other TPM 576 configuration procedures, the two keys may be different. Some of the 577 considerations are outlined in TCG Guidance for Securing Network 578 Equipment [NetEq]. 580 TCG Guidance for Securing Network Equipment specifies further 581 conventions for these keys: 583 o When separate Identity and Attestation keys are used, the 584 Attestation Key (AK) and its x.509 certificate should parallel the 585 DevID, with the same device ID information as the DevID 586 certificate (i.e., the same Subject Name and Subject Alt Name, 587 even though the key pairs are different). This allows a quote 588 from the device, signed by an AK, to be linked directly to the 589 device that provided it, by examining the corresponding AK 590 certificate. 592 o Network devices that are expected to use secure zero touch 593 provisioning as specified in [RFC8572]) must be shipped by the 594 manufacturer with pre-provisioned keys (Initial DevID and AK, 595 called IDevID and IAK). Inclusion of an DevID and IAK by a vendor 596 does not preclude a mechanism whereby an Administrator can define 597 Local Identity and Attestation Keys (LDevID and LAK) if desired. 599 2.3. RIV Information Flow 601 RIV workflow for networking equipment is organized around a simple 602 use-case, where a network operator wishes to verify the integrity of 603 software installed in specific, fielded devices. This use-case 604 implies several components: 606 1. The Attesting Device, which the network operator wants to 607 examine. 609 2. A Verifier (which might be a network management station) 610 somewhere separate from the Device that will retrieve the 611 information and analyze it to pass judgment on the security 612 posture of the device. 614 3. A Relying Party, which can act on Attestation results. 615 Interaction between the Relying Party and the Verifier is 616 considered out of scope for RIV. 618 4. Signed Reference Integrity Manifests (RIMs), containing Reference 619 Integrity Measurements, can either be created by the device 620 manufacturer and shipped along with the device as part of its 621 software image, or alternatively, could be obtained several other 622 ways (direct to the Verifier from the manufacturer, from a third 623 party, from the owner's observation of what's thought to be a 624 "known good system", etc.). Retrieving RIMs from the device 625 itself allows attestation to be done in systems which may not 626 have access to the public internet, or by other devices that are 627 not management stations per-se (e.g., a peer device; See 628 Section 3.1.3). If reference measurements are obtained from 629 multiple sources, the Verifier may need to evaluate the relative 630 level of trust to be placed in each source in case of a 631 discrepancy. 633 These components are illustrated in Figure 2. 635 A more-detailed taxonomy of terms is given in 636 [I-D.ietf-rats-architecture] 638 +---------------+ +-------------+ +---------+--------+ 639 | | | Attester | Step 1 | Verifier| | 640 | Endorser | | (Device |<-------| (Network| Relying| 641 | (Device | | under |------->| Mngmt | Party | 642 | Manufacturer | | attestation)| Step 2 | Station)| | 643 | or other | | | | | | 644 | authority) | | | | | | 645 +---------------+ +-------------+ +---------+--------+ 646 | /\ 647 | Step 0 | 648 ----------------------------------------------- 650 Figure 3: RIV Reference Configuration for Network Equipment 652 In Step 0, The Endorser (the device manufacturer) provides a Software 653 Image to the Attester (the device under attestation), and makes one 654 or more Reference Integrity Manifests (RIMs) signed by the Endorser, 655 available to the Verifier (see Section 3.1.3 for "in-band" and "out 656 of band" ways to make this happen). In Step 1, the Verifier (Network 657 Management Station), on behalf of a Relying Party, requests Identity, 658 Measurement Values (and possibly RIMs) from the Attester. In Step 2, 659 the Attester responds to the request by providing a DevID, quotes 660 (measured values), and optionally RIMs, signed by the Attester. 662 The following standards components may be used: 664 1. TPM Keys are configured according to [Platform-DevID-TPM-2.0], 665 [PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2] 667 2. Measurements of firmware and bootable modules may be taken 668 according to TCG PC Client [PC-Client-BIOS-TPM-2.0] and Linux IMA 669 [IMA] 671 3. Device Identity is managed by IEEE 802.1AR certificates 672 [IEEE-802-1AR], with keys protected by TPMs. 674 4. Attestation logs may be formatted according to the Canonical 675 Event Log format [Canonical-Event-Log], although other 676 specialized formats may be used. 678 5. Quotes are retrieved from the TPM according to the TCG TAP 679 Information Model [TAP]. While the TAP IM gives a protocol- 680 independent description of the data elements involved, it's 681 important to note that quotes from the TPM are signed inside the 682 TPM, so must be retrieved in a way that does not invalidate the 683 signature, as specified in [I-D.ietf-rats-yang-tpm-charra], to 684 preserve the trust model. (See Section 5 Security 685 Considerations). 687 6. Reference Integrity Measurements may be encoded as CoSWID tags, 688 as defined in the TCG RIM document [RIM], compatible with NIST IR 689 8060 [NIST-IR-8060] and the IETF CoSWID draft 690 [I-D.ietf-sacm-coswid]. See Section 2.4.1. 692 2.4. RIV Simplifying Assumptions 694 This document makes the following simplifying assumptions to reduce 695 complexity: 697 o The product to be attested is shipped with an IEEE 802.1AR DevID 698 and an Initial Attestation Key (IAK) with certificate. The IAK 699 cert contains the same identity information as the DevID 700 (specifically, the same Subject Name and Subject Alt Name, signed 701 by the manufacturer), but it's a type of key that can be used to 702 sign a TPM Quote. This convention is described in TCG Guidance 703 for Securing Network Equipment [NetEq]. For network equipment, 704 which is generally non-privacy-sensitive, shipping a device with 705 both an IDevID and an IAK already provisioned substantially 706 simplifies initial startup. Privacy-sensitive applications may 707 use the TCG Platform Certificate and additional procedures to 708 install identity credentials on the platform after manufacture. 710 o The product is equipped with a Root of Trust for Measurement, Root 711 of Trust for Storage and Root of Trust for Reporting (as defined 712 in [GloPlaRoT]) that are capable of conforming to the TCG Trusted 713 Attestation Protocol (TAP) Information Model [TAP]. 715 o The vendor will ship Reference Integrity Measurements (i.e., 716 known-good measurements) in the form of signed CoSWID tags 717 [I-D.ietf-sacm-coswid], [SWID], as described in TCG Reference 718 Integrity Measurement Manifest Information Model [RIM]. 720 2.4.1. Reference Integrity Manifests (RIMs) 722 [I-D.ietf-rats-yang-tpm-charra] focuses on collecting and 723 transmitting evidence in the form of PCR measurements and attestation 724 logs. But the critical part of the process is enabling the verifier 725 to decide whether the measurements are "the right ones" or not. 727 While it must be up to network administrators to decide what they 728 want on their networks, the software supplier should supply the 729 Reference Integrity Measurements that may be used by a verifier to 730 determine if evidence shows known good, known bad or unknown software 731 configurations. 733 In general, there are two kinds of reference measurements: 735 1. Measurements of early system startup (e.g., BIOS, boot loader, OS 736 kernel) are essentially single threaded, and executed exactly 737 once, in a known sequence, before any results could be reported. 738 In this case, while the method for computing the hash and 739 extending relevant PCRs may be complicated, the net result is 740 that the software (more likely, firmware) vendor will have one 741 known good PCR value that "should" be present in the relevant 742 PCRs after the box has booted. In this case, the signed 743 reference measurement could simply list the expected hashes for 744 the given version. However, a RIM that contains the intermediate 745 hashes can be useful in debugging cases where the expected final 746 hash is not the one reported. 748 2. Measurements taken later in operation of the system, once an OS 749 has started (for example, Linux IMA[IMA]), may be more complex, 750 with unpredictable "final" PCR values. In this case, the 751 Verifier must have enough information to reconstruct the expected 752 PCR values from logs and signed reference measurements from a 753 trusted authority. 755 In both cases, the expected values can be expressed as signed SWID or 756 CoSWID tags, but the SWID structure in the second case is somewhat 757 more complex, as reconstruction of the extended hash in a PCR may 758 involve thousands of files and other objects. 760 The TCG has published an information model defining elements of 761 reference integrity manifests under the title TCG Reference Integrity 762 Manifest Information Model [RIM]. This information model outlines 763 how SWID tags should be structured to allow attestation, and defines 764 "bundles" of SWID tags that may be needed to describe a complete 765 software release. The RIM contains metadata relating to the software 766 release it belongs to, plus hashes for each individual file or other 767 object that could be attested. 769 TCG has also published the PC Client Reference Integrity Measurement 770 specification [PC-Client-RIM], which focuses on a SWID-compatible 771 format suitable for expressing expected measurement values in the 772 specific case of a UEFI-compatible BIOS, where the SWID focus on 773 files and file systems is not a direct fit. While the PC Client RIM 774 is not directly applicable to network equipment, many vendors do use 775 a conventional UEFI BIOS to launch their network OS. 777 2.4.2. Attestation Logs 779 Quotes from a TPM can provide evidence of the state of a device up to 780 the time the evidence was recorded, but to make sense of the quote in 781 most cases an event log that identifies which software modules 782 contributed which values to the quote during startup must also be 783 provided. The log must contain enough information to demonstrate its 784 integrity by allowing exact reconstruction of the digest conveyed in 785 the signed quote (i.e., PCR values). 787 There are multiple event log formats which may be supported as viable 788 formats of Evidence between the Attester and Verifier: 790 o Event log exports from [I-D.ietf-rats-yang-tpm-charra] 792 o IMA Event log file exports [IMA] 794 o TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM 795 Family 1.1 or 1.2, Section 7 [EFI-TPM]) 797 o TCG Canonical Event Log [Canonical-Event-Log] 799 3. Standards Components 801 3.1. Prerequisites for RIV 803 The Reference Interaction Model for Challenge-Response-based Remote 804 Attestation is based on the standard roles defined in 805 [I-D.ietf-rats-architecture]. However additional prerequisites must 806 be established to allow for interoperable RIV use case 807 implementations. These prerequisites are intended to provide 808 sufficient context information so that the Verifier can acquire and 809 evaluate Attester measurements. 811 3.1.1. Unique Device Identity 813 A Secure device Identity (DevID) in the form of an IEEE 802.1AR 814 certificate [IEEE-802-1AR] must be provisioned in the Attester's 815 TPMs. 817 3.1.2. Keys 819 The Attestation Identity Key (AIK) and certificate must also be 820 provisioned on the Attester according to [Platform-DevID-TPM-2.0], 821 [PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2]. 823 The Attester's TPM Keys must be associated with the DevID on the 824 Verifier (see Section 5 Security Considerations). 826 3.1.3. Appraisal Policy for Evidence 828 (Editor's Note - terminology in this section must be brought back 829 into line with the RATS Architecture definitions) 831 The Verifier must obtain the Appraisal Policy for Evidence. This 832 policy may be in the form of reference measurements (e.g., Known Good 833 Values, CoSWID tags [I-D.birkholz-yang-swid]). These reference 834 measurements will eventually be compared to signed PCR Evidence 835 acquired from an Attester's TPM. 837 This document does not specify the format or contents for the 838 Appraisal Policy for Evidence. But acquiring this policy may happen 839 in one of two ways: 841 1. a Verifier obtains reference measurements directly from a 842 Verifier Owner (i.e., a Device Configuration Authority) chosen by 843 the Verifier administrator. 845 2. Signed reference measurements may be distributed by the Verifier 846 Owner to the Attester. From there, the reference measurement may 847 be acquired by the Verifier. 849 ************* .-------------. .-----------. 850 * Verifier * | Attester | | Verifier/ | 851 * Owner * | | | Relying | 852 *(Device *----2--->| (Network |----2--->| Party | 853 * config * | Device) | |(Ntwk Mgmt | 854 * Authority)* | | | Station) | 855 ************* '-------------' '-----------' 856 | ^ 857 | | 858 '----------------1--------------------------' 860 Figure 4: Appraisal Policy for Evidence Prerequisites 862 In either case the Appraisal Policy for Evidence must be generated, 863 acquired and delivered in a secure way. This includes reference 864 measurements of: 866 o firmware and bootable modules taken according to TCG PC Client 867 [PC-Client-BIOS-TPM-2.0] and Linux IMA [IMA] 869 o encoded CoSWID tags signed by the device manufacturer, are as 870 defined in the TCG RIM document [RIM], compatible with NIST IR 871 8060 [NIST-IR-8060] and the IETF CoSWID draft 872 [I-D.ietf-sacm-coswid]. 874 3.2. Reference Model for Challenge-Response 876 Once the prerequisites for RIV are met, a Verifier may acquire 877 Evidence from an Attester. The following diagram illustrates a RIV 878 information flow between a Verifier and an Attester, derived from 879 Section 8.1 of [I-D.birkholz-rats-reference-interaction-model]. 880 Event times shown correspond to the time types described within 881 Appendix A of [I-D.ietf-rats-architecture]: 883 .----------. .--------------------------. 884 | Attester | | Relying Party / Verifier | 885 '----------' '--------------------------' 886 time(VG) | 887 valueGeneration(targetEnvironment) | 888 | => claims | 889 | | 890 | <--------------requestEvidence(nonce, PcrSelection)-----time(NS) 891 | | 892 time(EG) | 893 evidenceGeneration(nonce, PcrSelection, collectedClaims) | 894 | => SignedPcrEvidence(nonce, PcrSelection) | 895 | => LogEvidence(collectedClaims) | 896 | | 897 | returnSignedPcrEvidence----------------------------------> | 898 | returnLogEvidence----------------------------------------> | 899 | | 900 | time(RG,RA) 901 | evidenceAppraisal(SignedPcrEvidence, eventLog, refClaims) 902 | attestationResult <= | 903 ~ ~ 904 | time(RX) 906 Figure 5: IETF Attestation Information Flow 908 o time(VG): One or more Attesting Network Device PCRs are extended 909 with measurements. 911 o time(NS): The Verifier generates a unique nonce ("number used 912 once"), and makes a request attestation data for one or more PCRs 913 from an Attester. This can be accomplished via a YANG [RFC7950] 914 interface that implements the TCG TAP model (e.g. YANG Module for 915 Basic Challenge-Response-based Remote Attestation Procedures 916 [I-D.ietf-rats-yang-tpm-charra]). 918 o time(EG): On the Attester, measured values are retrieved from the 919 Attester's TPM. This requested PCR evidence is signed by the 920 Attestation Identity Key (AIK) associated with the DevID. Quotes 921 are retrieved according to TCG TAP Information Model [TAP]. While 922 the TAP IM gives a protocol-independent description of the data 923 elements involved, it's important to note that quotes from the TPM 924 are signed inside the TPM, so must be retrieved in a way that does 925 not invalidate the signature, as specified in 926 [I-D.ietf-rats-yang-tpm-charra], to preserve the trust model. 927 (See Section 5 Security Considerations). At the same time, the 928 Attester collects log evidence showing what values have been 929 extended into that PCR. 931 o Collected Evidence is passed from the Attester to the Verifier 933 o time(RG,RA): The Verifier reviews the Evidence and takes action as 934 needed. As the Relying Party and Verifier are assumed co- 935 resident, this can happen in one step. 937 * If the signed PCR values do not match the set of log entries 938 which have extended a particular PCR, the device should not be 939 trusted. 941 * If the log entries that the verifier considers important do not 942 match known good values, the device should not be trusted. We 943 note that the process of collecting and analyzing the log can 944 be omitted if the value in the relevant PCR is already a known- 945 good value. 947 * If the set of log entries are not seen as acceptable by the 948 Appraisal Policy for Evidence, the device should not be 949 trusted. 951 * If the AIK signature is not correct, or freshness such as that 952 provided by the nonce is not included in the response, the 953 device should not be trusted. 955 o time(RX): At some point after the verification of Evidence, the 956 Attester can no longer be considered Attested as trustworthy. 958 3.2.1. Transport and Encoding 960 Network Management systems may retrieve signed PCR based Evidence as 961 shown in Figure 5, and can be accomplished via: 963 o XML, JSON, or CBOR encoded Evidence, using 965 o RESTCONF or NETCONF transport, over a 967 o TLS or SSH secure tunnel 969 Retrieval of Log Evidence will be via log interfaces on the network 970 device. (For example, see [I-D.ietf-rats-yang-tpm-charra]). 972 3.3. Centralized vs Peer-to-Peer 974 Figure 5 above assumes that the Verifier is implicitly trusted, while 975 the Attesting device is not. In a Peer-to-Peer application such as 976 two routers negotiating a trust relationship 977 [I-D.voit-rats-trusted-path-routing], the two peers can each ask the 978 other to prove software integrity. In this application, the 979 information flow is the same, but each side plays a role both as an 980 Attester and a Verifier. Each device issues a challenge, and each 981 device responds to the other's challenge, as shown in Figure 6. 982 Peer-to-peer challenges, particularly if used to establish a trust 983 relationship between routers, require devices to carry their own 984 signed reference measurements (RIMs) so that each device has 985 everything needed for attestation, without having to resort to a 986 central authority. 988 +---------------+ +---------------+ 989 | | | | 990 | Endorser A | | Endorser B | 991 | Firmware | | Firmware | 992 | Configuration | | Configuration | 993 | Authority | | Authority | 994 | | | | 995 +---------------+ +---------------+ 996 | | 997 | +-------------+ +------------+ | 998 | | | Step 1 | | | \ 999 | | Attester |<------>| Verifier | | | 1000 | | |<------>| | | | Router B 1001 +------>| | Step 2 | | | |- Challenges 1002 Step 0A| | | | | | Router A 1003 | |------->| | | | 1004 |- Router A --| Step 3 |- Router B -| | / 1005 | | | | | 1006 | | | | | 1007 | | Step 1 | | | \ 1008 | Verifier |<------>| Attester |<-+ | Router A 1009 | |<------>| | |- Challenges 1010 | | Step 2 | | | Router B 1011 | | | | | 1012 | |<-------| | | 1013 +-------------+ Step 3 +------------+ / 1015 Figure 6: Peer-to-Peer Attestation Information Flow 1017 In this application, each device may need to be equipped with signed 1018 RIMs to act as an Attester, and also a selection of trusted x.509 1019 root certificates to allow the device to act as a Verifier. An 1020 existing link layer protocol such as 802.1x [IEEE-802.1x] or 802.1AE 1021 [IEEE-802.1ae], with Evidence being enclosed over a variant of EAP 1022 [RFC3748] or LLDP [LLDP] are suitable methods for such an exchange. 1024 4. Privacy Considerations 1026 Networking Equipment, such as routers, switches and firewalls, has a 1027 key role to play in guarding the privacy of individuals using the 1028 network: 1030 o Packets passing through the device must not be sent to 1031 unauthorized destinations. For example: 1033 * Routers often act as Policy Enforcement Points, where 1034 individual subscribers may be checked for authorization to 1035 access a network. Subscriber login information must not be 1036 released to unauthorized parties. 1038 * Networking Equipment is often called upon to block access to 1039 protected resources from unauthorized users. 1041 o Routing information, such as the identity of a router's peers, 1042 must not be leaked to unauthorized neighbors. 1044 o If configured, encryption and decryption of traffic must be 1045 carried out reliably, while protecting keys and credentials. 1047 Functions that protect privacy are implemented as part of each layer 1048 of hardware and software that makes up the networking device. In 1049 light of these requirements for protecting the privacy of users of 1050 the network, the Network Equipment must identify itself, and its boot 1051 configuration and measured device state (for example, PCR values), to 1052 the Equipment's Administrator, so there's no uncertainty as to what 1053 function each device and configuration is configured to carry out. 1054 This allows the administrator to ensure that the network provides 1055 individual and peer privacy guarantees. 1057 RIV specifically addresses the collection of information from 1058 enterprise network devices by authorized agents of the enterprise. 1059 As such, privacy is a fundamental concern for those deploying this 1060 solution, given EU GDPR, California CCPA, and many other privacy 1061 regulations. The enterprise should implement and enforce their duty 1062 of care. 1064 See [NetEq] for more context on privacy in networking devices 1066 5. Security Considerations 1068 Attestation results from the RIV procedure are subject to a number of 1069 attacks: 1071 o Keys may be compromised 1072 o A counterfeit device may attempt to impersonate (spoof) a known 1073 authentic device 1075 o Man-in-the-middle attacks may be used by a counterfeit device to 1076 attempt to deliver responses that originate in an actual authentic 1077 device 1079 o Replay attacks may be attempted by a compromised device 1081 Trustworthiness of RIV attestation depends strongly on the validity 1082 of keys used for identity and attestation reports. RIV takes full 1083 advantage of TPM capabilities to ensure that results can be trusted. 1085 Two sets of keys are relevant to RIV attestation 1087 o A DevID key is used to certify the identity of the device in which 1088 the TPM is installed. 1090 o An Attestation Key (AK) key signs attestation reports, (called 1091 'quotes' in TCG documents), used to provide evidence for integrity 1092 of the software on the device. 1094 TPM practices usually require that these keys be different, as a way 1095 of ensuring that a general-purpose signing key cannot be used to 1096 spoof an attestation quote. 1098 In each case, the private half of the key is known only to the TPM, 1099 and cannot be retrieved externally, even by a trusted party. To 1100 ensure that's the case, specification-compliant private/public key- 1101 pairs are generated inside the TPM, where they're never exposed, and 1102 cannot be extracted (See [Platform-DevID-TPM-2.0]). 1104 Keeping keys safe is just part of attestation security; knowing which 1105 keys are bound to the device in question is just as important. 1107 While there are many ways to manage keys in a TPM (See 1108 [Platform-DevID-TPM-2.0]), RIV includes support for "zero touch" 1109 provisioning (also known as zero-touch onboarding) of fielded devices 1110 (e.g. Secure ZTP, [RFC8572]), where keys which have predictable 1111 trust properties are provisioned by the device vendor. 1113 Device identity in RIV is based on IEEE 802.1AR DevID. This 1114 specification provides several elements 1116 o A DevID requires a unique key pair for each device, accompanied by 1117 an x.509 certificate 1119 o The private portion of the DevID key is to be stored in the 1120 device, in a manner that provides confidentiality (Section 6.2.5 1121 [IEEE-802-1AR]) 1123 The x.509 certificate contains several components 1125 o The public part of the unique DevID key assigned to that device 1127 o An identifying string that's unique to the manufacturer of the 1128 device. This is normally the serial number of the unit, which 1129 might also be printed on a label on the device. 1131 o The certificate must be signed by a key traceable to the 1132 manufacturer's root key. 1134 With these elements, the device's manufacturer and serial number can 1135 be identified by analyzing the DevID certificate plus the chain of 1136 intermediate certs leading back to the manufacturer's root 1137 certificate. As is conventional in TLS connections, a nonce must be 1138 signed by the device in response to a challenge, proving possession 1139 of its DevID private key. 1141 RIV uses the DevID to validate a TLS connection to the device as the 1142 attestation session begins. Security of this process derives from 1143 TLS security, with the DevID providing proof that the TLS session 1144 terminates on the intended device. [RFC8446]. 1146 Evidence of software integrity is delivered in the form of a quote 1147 signed by the TPM itself. Because the contents of the quote are 1148 signed inside the TPM, any external modification (including 1149 reformatting to a different data format) will be detected as 1150 tampering. 1152 A critical feature of the YANG model described in 1153 [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data 1154 structures in their native format, without requiring any changes to 1155 the structures as they were signed and delivered by the TPM. While 1156 alternate methods of conveying TPM quotes could compress out 1157 redundant information, or add an additional layer of signing using 1158 external keys, the important part is to preserve the TPM signing, so 1159 that tampering anywhere in the path between the TPM itself and the 1160 Verifier can be detected. 1162 Prevention of spoofing attacks against attestation systems is also 1163 important. There are two cases to consider: 1165 o The entire device could be spoofed, that is, when the Verifier 1166 goes to verify a specific device, it might be redirected to a 1167 different device. Use of the 802.1AR identity in the TPM ensures 1168 that the Verifier's TLS session is in fact terminating on the 1169 right device. 1171 o A compromised device could respond with a spoofed attestation 1172 result, that is, a compromised OS could return a fabricated quote. 1174 Protection against spoofed quotes from a device with valid identity 1175 is a bit more complex. An identity key must be available to sign any 1176 kind of nonce or hash offered by the verifier, and consequently, 1177 could be used to sign a fabricated quote. To block spoofed 1178 attestation result, the quote generated inside the TPM must be signed 1179 by a key that's different from the DevID, called an Attestation Key 1180 (AK). 1182 Given separate Attestation and DevID keys, the binding between the AK 1183 and the same device must also be proven to prevent a man-in-the- 1184 middle attack (e.g. the 'Asokan Attack' [RFC6813]). 1186 This is accomplished in RIV through use of an AK certificate with the 1187 same elements as the DevID (i.e., same manufacturer's serial number, 1188 signed by the same manufacturer's key), but containing the device's 1189 unique AK public key instead of the DevID public key. 1190 [Editor's Note: does this require an OID that says the key is known 1191 by the CA to be an Attestation key?] 1193 These two keys and certificates are used together: 1195 o The DevID is used to validate a TLS connection terminating on the 1196 device with a known serial number. 1198 o The AK is used to sign attestation quotes, providing proof that 1199 the attestation evidence comes from the same device. 1201 Replay attacks, where results of a previous attestation are submitted 1202 in response to subsequent requests, are usually prevented by 1203 inclusion of a nonce in the request to the TPM for a quote. Each 1204 request from the Verifier includes a new random number (a nonce). 1205 The resulting quote signed by the TPM contains the same nonce, 1206 allowing the verifier to determine freshness, i.e., that the 1207 resulting quote was generated in response to the verifier's specific 1208 request. Time-Based Uni-directional Attestation 1209 [I-D.birkholz-rats-tuda] provides an alternate mechanism to verify 1210 freshness without requiring a request/response cycle. 1212 Requiring results of attestation of the operating software to be 1213 signed by a key known only to the TPM also removes the need to trust 1214 the device's operating software (beyond the first measurement; see 1215 below); any changes to the quote, generated and signed by the TPM 1216 itself, made by malicious device software, or in the path back to the 1217 verifier, will invalidate the signature on the quote. 1219 Although RIV recommends that device manufacturers pre-provision 1220 devices with easily-verified DevID and AK certs, use of those 1221 credentials is not mandatory. IEEE 802.1AR incorporates the idea of 1222 an Initial Device ID (IDevID), provisioned by the manufacturer, and a 1223 Local Device ID (LDevID) provisioned by the owner of the device. RIV 1224 extends that concept by defining an Initial Attestation Key (IAK) and 1225 Local Attestation Key (LAK) with the same properties. 1227 Device owners can use any method to provision the Local credentials. 1229 o TCG document [Platform-DevID-TPM-2.0] shows how the initial 1230 Attestation keys can be used to certify LDevID and LAK keys. Use 1231 of the LDevID and LAK allows the device owner to use a uniform 1232 identity structure across device types from multiple manufacturers 1233 (in the same way that an "Asset Tag" is used by many enterprises 1234 to identify devices they own). TCG doc [Provisioning-TPM-2.0] 1235 also contains guidance on provisioning identity keys in TPM 2.0. 1237 o But device owners can use any other mechanism they want to assure 1238 themselves that Local identity certificates are inserted into the 1239 intended device, including physical inspection and programming in 1240 a secure location, if they prefer to avoid placing trust in the 1241 manufacturer-provided keys. 1243 Clearly, Local keys can't be used for secure Zero Touch provisioning; 1244 installation of the Local keys can only be done by some process that 1245 runs before the device is configured for network operation. 1247 On the other end of the device life cycle, provision should be made 1248 to wipe Local keys when a device is decommissioned, to indicate that 1249 the device is no longer owned by the enterprise. The manufacturer's 1250 Initial identity keys must be preserved, as they contain no 1251 information that's not already printed on the device's serial number 1252 plate. 1254 In addition to trustworthy provisioning of keys, RIV depends on other 1255 trust anchors. (See [GloPlaRoT] for definitions of Roots of Trust.) 1257 o Secure identity depends on mechanisms to prevent per-device secret 1258 keys from being compromised. The TPM provides this capability as 1259 a Root of Trust for Storage 1261 o Attestation depends on an unbroken chain of measurements, starting 1262 from the very first measurement. That first measurement is made 1263 by code called the Root of Trust for Measurement, typically done 1264 by trusted firmware stored in boot flash. Mechanisms for 1265 maintaining the trustworthiness of the RTM are out of scope for 1266 RIV, but could include immutable firmware, signed updates, or a 1267 vendor-specific hardware verification technique. 1269 o RIV assumes some level of physical defense for the device. If a 1270 TPM that has already been programmed with an authentic DevID is 1271 stolen and inserted into a counterfeit device, attestation of that 1272 counterfeit device may become indistinguishable from an authentic 1273 device. 1275 RIV also depends on reliable reference measurements, as expressed by 1276 the RIM [RIM]. The definition of trust procedures for RIMs is out of 1277 scope for RIV, and the device owner is free to use any policy to 1278 validate a set of reference measurements. RIMs may be conveyed out- 1279 of-band or in-band, as part of the attestation process (see 1280 Section 3.1.3). But for embedded devices, where software is usually 1281 shipped as a self-contained package, RIMs signed by the manufacturer 1282 and delivered in-band may be more convenient for the device owner. 1284 6. Conclusion 1286 TCG technologies can play an important part in the implementation of 1287 Remote Integrity Verification. Standards for many of the components 1288 needed for implementation of RIV already exist: 1290 o Platform identity can be based on IEEE 802.1AR Device identity, 1291 coupled with careful supply-chain management by the manufacturer. 1293 o Complex supply chains can be certified using TCG Platform 1294 Certificates [Platform-Certificates] 1296 o The TCG TAP mechanism can be used to retrieve attestation 1297 evidence. Work is needed on a YANG model for this protocol. 1299 o Reference Measurements must be conveyed from the software 1300 authority (e.g., the manufacturer) to the system in which 1301 verification will take place. IETF CoSWID work forms the basis 1302 for this, but new work is needed to create an information model 1303 and YANG implementation. 1305 7. IANA Considerations 1307 This memo includes no request to IANA. 1309 8. Appendix 1311 8.1. Layering Model for Network Equipment Attester and Verifier 1313 Retrieval of identity and attestation state uses one protocol stack, 1314 while retrieval of Reference Measurements uses a different set of 1315 protocols. Figure 5 shows the components involved. 1317 +-----------------------+ +-------------------------+ 1318 | | | | 1319 | Attester |<-------------| Verifier | 1320 | (Device) |------------->| (Management Station) | 1321 | | | | | 1322 +-----------------------+ | +-------------------------+ 1323 | 1324 -------------------- -------------------- 1325 | | 1326 ---------------------------------- --------------------------------- 1327 |Reference Integrity Measurements| | Attestation | 1328 ---------------------------------- --------------------------------- 1330 ******************************************************************** 1331 * IETF Attestation Reference Interaction Diagram * 1332 ******************************************************************** 1334 ....................... ....................... 1335 . Reference Integrity . . TAP (PTS2.0) Info . 1336 . Manifest . . Model and Canonical . 1337 . . . Log Format . 1338 ....................... ....................... 1340 ************************* .............. ********************** 1341 * YANG SWID Module * . TCG . * YANG Attestation * 1342 * I-D.birkholz-yang-swid* . Attestation. * Module * 1343 * * . MIB . * I-D.ietf-rats- * 1344 * * . . * yang-tpm-charra * 1345 ************************* .............. ********************** 1347 ************************* ************ ************************ 1348 * XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)* 1349 ************************* ************ ************************ 1351 ************************* ************************ 1352 * RESTCONF/NETCONF * * RESTCONF/NETCONF * 1353 ************************ ************************* 1355 ************************* ************************ 1356 * TLS, SSH * * TLS, SSH * 1357 ************************* ************************ 1359 Figure 7: RIV Protocol Stacks 1361 IETF documents are captured in boxes surrounded by asterisks. TCG 1362 documents are shown in boxes surrounded by dots. The IETF 1363 Attestation Reference Interaction Diagram, Reference Integrity 1364 Manifest, TAP Information Model and Canonical Log Format, and both 1365 YANG modules are works in progress. Information Model layers 1366 describe abstract data objects that can be requested, and the 1367 corresponding response SNMP is still widely used, but the industry is 1368 transitioning to YANG, so in some cases, both will be required. TLS 1369 Authentication with TPM has been shown to work; SSH authentication 1370 using TPM-protected keys is not as easily done [as of 2019] 1372 8.1.1. Why is OS Attestation Different? 1374 Even in embedded systems, adding Attestation at the OS level (e.g. 1375 Linux IMA, Integrity Measurement Architecture [IMA]) increases the 1376 number of objects to be attested by one or two orders of magnitude, 1377 involves software that's updated and changed frequently, and 1378 introduces processes that begin in an unpredictable order. 1380 TCG and others (including the Linux community) are working on methods 1381 and procedures for attesting the operating system and application 1382 software, but standardization is still in process. 1384 8.2. Implementation Notes 1386 Table 1 summarizes many of the actions needed to complete an 1387 Attestation system, with links to relevant documents. While 1388 documents are controlled by several standards organizations, the 1389 implied actions required for implementation are all the 1390 responsibility of the manufacturer of the device, unless otherwise 1391 noted. 1393 +------------------------------------------------------------------+ 1394 | Component | Controlling | 1395 | | Specification | 1396 -------------------------------------------------------------------- 1397 | Make a Secure execution environment | TCG RoT | 1398 | o Attestation depends on a secure root of | UEFI.org | 1399 | trust for measurement outside the TPM, as | | 1400 | well as roots for storage and reporting | | 1401 | inside the TPM. | | 1402 | o Refer to TCG Root of Trust for Measurement.| | 1403 | o NIST SP 800-193 also provides guidelines | | 1404 | on Roots of Trust | | 1405 -------------------------------------------------------------------- 1406 | Provision the TPM as described in | TCG TPM DevID | 1407 | TCG documents. | TCG Platform | 1408 | | Certificate | 1409 -------------------------------------------------------------------- 1410 | Put a DevID or Platform Cert in the TPM | TCG TPM DevID | 1411 | o Install an Initial Attestation Key at the | TCG Platform | 1412 | same time so that Attestation can work out | Certificate | 1413 | of the box |----------------- 1414 | o Equipment suppliers and owners may want to | IEEE 802.1AR | 1415 | implement Local Device ID as well as | | 1416 | Initial Device ID | | 1417 -------------------------------------------------------------------- 1418 | Connect the TPM to the TLS stack | Vendor TLS | 1419 | o Use the DevID in the TPM to authenticate | stack (This | 1420 | TAP connections, identifying the device | action is | 1421 | | simply | 1422 | | configuring TLS| 1423 | | to use the | 1424 | | DevID as its | 1425 | | trust anchor.) | 1426 -------------------------------------------------------------------- 1427 | Make CoSWID tags for BIOS/LoaderLKernel objects | IETF CoSWID | 1428 | o Add reference measurements into SWID tags | ISO/IEC 19770-2| 1429 | o Manufacturer should sign the SWID tags | NIST IR 8060 | 1430 | o The TCG RIM-IM identifies further | | 1431 | procedures to create signed RIM | | 1432 | documents that provide the necessary | | 1433 | reference information | | 1434 -------------------------------------------------------------------- 1435 | Package the SWID tags with a vendor software | Retrieve tags | 1436 | release | with | 1437 | o A tag-generator plugin such | {{I-D.birkholz-yang-swid}}| 1438 | as https://github.com/Labs64/swid-maven-plugin | 1439 | can be used |----------------| 1440 | | TCG PC Client | 1441 | | RIM | 1442 -------------------------------------------------------------------- 1443 | Use PC Client measurement definitions | TCG PC Client | 1444 | to define the use of PCRs | BIOS | 1445 | (although Windows OS is rare on Networking | | 1446 | Equipment, UEFI BIOS is not) | | 1447 -------------------------------------------------------------------- 1448 | Use TAP to retrieve measurements | | 1449 | o Map TAP to SNMP | TCG SNMP MIB | 1450 | o Map to YANG | YANG Module for| 1451 | Use Canonical Log Format | Basic | 1452 | | Attestation | 1453 | | TCG Canonical | 1454 | | Log Format | 1455 -------------------------------------------------------------------- 1456 | Posture Collection Server (as described in IETF | | 1457 | SACMs ECP) should request the | | 1458 | attestation and analyze the result | | 1459 | The Management application might be broken down | | 1460 | to several more components: | | 1461 | o A Posture Manager Server | | 1462 | which collects reports and stores them in | | 1463 | a database | | 1464 | o One or more Analyzers that can look at the| | 1465 | results and figure out what it means. | | 1466 -------------------------------------------------------------------- 1468 Figure 8: Component Status 1470 8.3. Root of Trust for Measurement 1472 The measurements needed for attestation require that the device being 1473 attested is equipped with a Root of Trust for Measurement, i.e., some 1474 trustworthy mechanism that can compute the first measurement in the 1475 chain of trust required to attest that each stage of system startup 1476 is verified, a Root of Trust for Storage (i.e., the TPM PCRs) to 1477 record the results, and a Root of Trust for Reporting to report the 1478 results [TCGRoT], [GloPlaRoT]. 1480 While there are many complex aspects of a Root of Trust, two aspects 1481 that are important in the case of attestation are: 1483 o The first measurement computed by the Root of Trust for 1484 Measurement, and stored in the TPM's Root of Trust for Storage, is 1485 presumed to be correct. 1487 o There must not be a way to reset the Root of Trust for Storage 1488 without re-entering the Root of Trust for Measurement code. 1490 The first measurement must be computed by code that is implicitly 1491 trusted; if that first measurement can be subverted, none of the 1492 remaining measurements can be trusted. (See [NIST-SP-800-155]) 1494 9. Informative References 1496 [AIK-Enrollment] 1497 Trusted Computing Group, "TCG Infrastructure Working 1498 GroupA CMC Profile for AIK Certificate Enrollment Version 1499 1.0, Revision 7", March 2011, 1500 . 1503 [Canonical-Event-Log] 1504 Trusted Computing Group, "DRAFT Canonical Event Log Format 1505 Version: 1.0, Revision: .12", October 2018. 1507 [EFI-TPM] Trusted Computing Group, "TCG EFI Platform Specification 1508 for TPM Family 1.1 or 1.2, Specification Version 1.22, 1509 Revision 15", January 2014, 1510 . 1513 [GloPlaRoT] 1514 GlobalPlatform Technology, "Root of Trust Definitions and 1515 Requirements Version 1.1", June 2018, 1516 . 1519 [I-D.birkholz-rats-reference-interaction-model] 1520 Birkholz, H., Eckel, M., Newton, C., and L. Chen, 1521 "Reference Interaction Models for Remote Attestation 1522 Procedures", draft-birkholz-rats-reference-interaction- 1523 model-03 (work in progress), July 2020. 1525 [I-D.birkholz-rats-tuda] 1526 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 1527 "Time-Based Uni-Directional Attestation", draft-birkholz- 1528 rats-tuda-02 (work in progress), March 2020. 1530 [I-D.birkholz-yang-swid] 1531 Birkholz, H., "Software Inventory YANG module based on 1532 Software Identifiers", draft-birkholz-yang-swid-02 (work 1533 in progress), October 2018. 1535 [I-D.ietf-rats-architecture] 1536 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1537 W. Pan, "Remote Attestation Procedures Architecture", 1538 draft-ietf-rats-architecture-05 (work in progress), July 1539 2020. 1541 [I-D.ietf-rats-eat] 1542 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 1543 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 1544 ietf-rats-eat-03 (work in progress), February 2020. 1546 [I-D.ietf-rats-yang-tpm-charra] 1547 Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit, 1548 E., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data 1549 Model for Challenge-Response-based Remote Attestation 1550 Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-02 1551 (work in progress), June 2020. 1553 [I-D.ietf-sacm-coswid] 1554 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 1555 Waltermire, "Concise Software Identification Tags", draft- 1556 ietf-sacm-coswid-15 (work in progress), May 2020. 1558 [I-D.richardson-rats-usecases] 1559 Richardson, M., Wallace, C., and W. Pan, "Use cases for 1560 Remote Attestation common encodings", draft-richardson- 1561 rats-usecases-07 (work in progress), March 2020. 1563 [I-D.voit-rats-trusted-path-routing] 1564 Voit, E., "Trusted Path Routing", draft-voit-rats-trusted- 1565 path-routing-02 (work in progress), June 2020. 1567 [IEEE-802-1AR] 1568 Seaman, M., "802.1AR-2018 - IEEE Standard for Local and 1569 Metropolitan Area Networks - Secure Device Identity, IEEE 1570 Computer Society", August 2018. 1572 [IEEE-802.1ae] 1573 Seaman, M., "802.1AE MAC Security (MACsec)", 2018, 1574 . 1576 [IEEE-802.1x] 1577 IEEE Computer Society, "802.1X-2020 - IEEE Standard for 1578 Local and Metropolitan Area Networks--Port-Based Network 1579 Access Control", February 2020, 1580 . 1582 [IMA] and , "Integrity Measurement Architecture", June 2019, 1583 . 1585 [LLDP] IEEE Computer Society, "802.1AB-2016 - IEEE Standard for 1586 Local and metropolitan area networks - Station and Media 1587 Access Control Connectivity Discovery", March 2016, 1588 . 1590 [NetEq] Trusted Computing Group, "TCG Guidance for Securing 1591 Network Equipment", January 2018, 1592 . 1595 [NIST-IR-8060] 1596 National Institute for Standards and Technology, 1597 "Guidelines for the Creation of Interoperable Software 1598 Identification (SWID) Tags", April 2016, 1599 . 1602 [NIST-SP-800-155] 1603 National Institute for Standards and Technology, "BIOS 1604 Integrity Measurement Guidelines (Draft)", December 2011, 1605 . 1608 [PC-Client-BIOS-TPM-1.2] 1609 Trusted Computing Group, "TCG PC Client Specific 1610 Implementation Specification for Conventional BIOS, 1611 Specification Version 1.21 Errata, Revision 1.00", 1612 February 2012, . 1615 [PC-Client-BIOS-TPM-2.0] 1616 Trusted Computing Group, "PC Client Specific Platform 1617 Firmware Profile Specification Family "2.0", Level 00 1618 Revision 1.04", June 2019, 1619 . 1622 [PC-Client-RIM] 1623 Trusted Computing Group, "DRAFT: TCG PC Client Reference 1624 Integrity Manifest Specification, v.09", December 2019, 1625 . 1627 [Platform-Certificates] 1628 Trusted Computing Group, "DRAFT: TCG Platform Attribute 1629 Credential Profile, Specification Version 1.0, Revision 1630 15, 07 December 2017", December 2017. 1632 [Platform-DevID-TPM-2.0] 1633 Trusted Computing Group, "DRAFT: TPM Keys for Platform 1634 DevID for TPM2, Specification Version 0.7, Revision 0", 1635 October 2018. 1637 [Platform-ID-TPM-1.2] 1638 Trusted Computing Group, "TPM Keys for Platform Identity 1639 for TPM 1.2, Specification Version 1.0, Revision 3", 1640 August 2015, . 1644 [Provisioning-TPM-2.0] 1645 Trusted Computing Group, "TCG TPM v2.0 Provisioning 1646 Guidance", March 2015, . 1650 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1651 Levkowetz, Ed., "Extensible Authentication Protocol 1652 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1653 . 1655 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1656 and A. Bierman, Ed., "Network Configuration Protocol 1657 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1658 . 1660 [RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment 1661 (NEA) Asokan Attack Analysis", RFC 6813, 1662 DOI 10.17487/RFC6813, December 2012, 1663 . 1665 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1666 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1667 . 1669 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1670 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1671 . 1673 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1674 Touch Provisioning (SZTP)", RFC 8572, 1675 DOI 10.17487/RFC8572, April 2019, 1676 . 1678 [RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity 1679 Manifest Information Model", June 2019, 1680 . 1683 [SWID] The International Organization for Standardization/ 1684 International Electrotechnical Commission, "Information 1685 Technology Software Asset Management Part 2: Software 1686 Identification Tag, ISO/IEC 19770-2", October 2015, 1687 . 1689 [TAP] Trusted Computing Group, "DRAFT: TCG Trusted Attestation 1690 Protocol (TAP) Information Model for TPM Families 1.2 and 1691 2.0 and DICE Family 1.0, Version 1.0, Revision 0.29", 1692 October 2018. 1694 [TCGRoT] Trusted Computing Group, "TCG Roots of Trust 1695 Specification", October 2018, 1696 . 1699 Authors' Addresses 1701 Guy Fedorkow (editor) 1702 Juniper Networks, Inc. 1703 US 1705 Email: gfedorkow@juniper.net 1707 Eric Voit 1708 Cisco Systems, Inc. 1709 US 1711 Email: evoit@cisco.com 1713 Jessica Fitzgerald-McKay 1714 National Security Agency 1715 US 1717 Email: jmfitz2@nsa.gov