idnits 2.17.1 draft-ietf-rats-tpm-based-network-device-attest-01.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 12, 2020) is 1382 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 == Unused Reference: 'I-D.birkholz-rats-reference-interaction-model' is defined on line 1518, but no explicit reference was found in the text == 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 (~~), 8 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 13, 2021 Cisco Systems, Inc. 6 J. Fitzgerald-McKay 7 National Security Agency 8 July 12, 2020 10 TPM-based Network Device Remote Integrity Verification 11 draft-ietf-rats-tpm-based-network-device-attest-01 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 13, 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. Event times 879 shown correspond to the time types described within Appendix A of 880 [I-D.ietf-rats-architecture]: 882 .----------. .--------------------------. 883 | Attester | | Relying Party / Verifier | 884 '----------' '--------------------------' 885 time(VG) | 886 valueGeneration(targetEnvironment) | 887 | => claims | 888 | | 889 | <--------------requestEvidence(nonce, PcrSelection)-----time(NS) 890 | | 891 time(EG) | 892 evidenceGeneration(nonce, PcrSelection, collectedClaims) | 893 | => SignedPcrEvidence(nonce, PcrSelection) | 894 | => LogEvidence(collectedClaims) | 895 | | 896 | returnSignedPcrEvidence----------------------------------> | 897 | returnLogEvidence----------------------------------------> | 898 | | 899 | time(RG,RA) 900 | evidenceAppraisal(SignedPcrEvidence, eventLog, refClaims) 901 | attestationResult <= | 902 ~ ~ 903 | time(RX) 905 Figure 5: IETF Attestation Information Flow 907 o time(VG): One or more Attesting Network Device PCRs are extended 908 with measurements. 910 o time(NS): The Verifier generates a unique nonce ("number used 911 once"), and makes a request attestation data for one or more PCRs 912 from an Attester. This can be accomplished via a YANG [RFC7950] 913 interface that implements the TCG TAP model (e.g. YANG Module for 914 Basic Challenge-Response-based Remote Attestation Procedures 915 [I-D.ietf-rats-yang-tpm-charra]). 917 o time(EG): On the Attester, measured values are retrieved from the 918 Attester's TPM. This requested PCR evidence is signed by the 919 Attestation Identity Key (AIK) associated with the DevID. Quotes 920 are retrieved according to TCG TAP Information Model [TAP]. While 921 the TAP IM gives a protocol-independent description of the data 922 elements involved, it's important to note that quotes from the TPM 923 are signed inside the TPM, so must be retrieved in a way that does 924 not invalidate the signature, as specified in 925 [I-D.ietf-rats-yang-tpm-charra], to preserve the trust model. 926 (See Section 5 Security Considerations). At the same time, the 927 Attester collects log evidence showing what values have been 928 extended into that PCR. 930 o Collected Evidence is passed from the Attester to the Verifier 932 o time(RG,RA): The Verifier reviews the Evidence and takes action as 933 needed. As the Relying Party and Verifier are assumed co- 934 resident, this can happen in one step. 936 * If the signed PCR values do not match the set of log entries 937 which have extended a particular PCR, the device should not be 938 trusted. 940 * If the log entries that the verifier considers important do not 941 match known good values, the device should not be trusted. We 942 note that the process of collecting and analyzing the log can 943 be omitted if the value in the relevant PCR is already a known- 944 good value. 946 * If the set of log entries are not seen as acceptable by the 947 Appraisal Policy for Evidence, the device should not be 948 trusted. 950 * If the AIK signature is not correct, or freshness such as that 951 provided by the nonce is not included in the response, the 952 device should not be trusted. 954 o time(RX): At some point after the verification of Evidence, the 955 Attester can no longer be considered Attested as trustworthy. 957 3.2.1. Transport and Encoding 959 Network Management systems may retrieve signed PCR based Evidence as 960 shown in Figure 5, and can be accomplished via: 962 o XML, JSON, or CBOR encoded Evidence, using 964 o RESTCONF or NETCONF transport, over a 966 o TLS or SSH secure tunnel 968 Retrieval of Log Evidence will be via log interfaces on the network 969 device. (For example, see [I-D.ietf-rats-yang-tpm-charra]). 971 3.3. Centralized vs Peer-to-Peer 973 Figure 5 above assumes that the Verifier is implicitly trusted, while 974 the Attesting device is not. In a Peer-to-Peer application such as 975 two routers negotiating a trust relationship 976 [I-D.voit-rats-trusted-path-routing], the two peers can each ask the 977 other to prove software integrity. In this application, the 978 information flow is the same, but each side plays a role both as an 979 Attester and a Verifier. Each device issues a challenge, and each 980 device responds to the other's challenge, as shown in Figure 6. 981 Peer-to-peer challenges, particularly if used to establish a trust 982 relationship between routers, require devices to carry their own 983 signed reference measurements (RIMs) so that each device has 984 everything needed for attestation, without having to resort to a 985 central authority. 987 +---------------+ +---------------+ 988 | | | | 989 | Endorser A | | Endorser B | 990 | Firmware | | Firmware | 991 | Configuration | | Configuration | 992 | Authority | | Authority | 993 | | | | 994 +---------------+ +---------------+ 995 | | 996 | +-------------+ +------------+ | 997 | | | Step 1 | | | \ 998 | | Attester |<------>| Verifier | | | 999 | | |<------>| | | | Router B 1000 +------>| | Step 2 | | | |- Challenges 1001 Step 0A| | | | | | Router A 1002 | |------->| | | | 1003 |- Router A --| Step 3 |- Router B -| | / 1004 | | | | | 1005 | | | | | 1006 | | Step 1 | | | \ 1007 | Verifier |<------>| Attester |<-+ | Router A 1008 | |<------>| | |- Challenges 1009 | | Step 2 | | | Router B 1010 | | | | | 1011 | |<-------| | | 1012 +-------------+ Step 3 +------------+ / 1014 Figure 6: Peer-to-Peer Attestation Information Flow 1016 In this application, each device may need to be equipped with signed 1017 RIMs to act as an Attester, and also a selection of trusted x.509 1018 root certificates to allow the device to act as a Verifier. An 1019 existing link layer protocol such as 802.1x [IEEE-802.1x] or 802.1AE 1020 [IEEE-802.1ae], with Evidence being enclosed over a variant of EAP 1021 [RFC3748] or LLDP [LLDP] are suitable methods for such an exchange. 1023 4. Privacy Considerations 1025 Networking Equipment, such as routers, switches and firewalls, has a 1026 key role to play in guarding the privacy of individuals using the 1027 network: 1029 o Packets passing through the device must not be sent to 1030 unauthorized destinations. For example: 1032 * Routers often act as Policy Enforcement Points, where 1033 individual subscribers may be checked for authorization to 1034 access a network. Subscriber login information must not be 1035 released to unauthorized parties. 1037 * Networking Equipment is often called upon to block access to 1038 protected resources from unauthorized users. 1040 o Routing information, such as the identity of a router's peers, 1041 must not be leaked to unauthorized neighbors. 1043 o If configured, encryption and decryption of traffic must be 1044 carried out reliably, while protecting keys and credentials. 1046 Functions that protect privacy are implemented as part of each layer 1047 of hardware and software that makes up the networking device. In 1048 light of these requirements for protecting the privacy of users of 1049 the network, the Network Equipment must identify itself, and its boot 1050 configuration and measured device state (for example, PCR values), to 1051 the Equipment's Administrator, so there's no uncertainty as to what 1052 function each device and configuration is configured to carry out. 1053 This allows the administrator to ensure that the network provides 1054 individual and peer privacy guarantees. 1056 RIV specifically addresses the collection of information from 1057 enterprise network devices by authorized agents of the enterprise. 1058 As such, privacy is a fundamental concern for those deploying this 1059 solution, given EU GDPR, California CCPA, and many other privacy 1060 regulations. The enterprise should implement and enforce their duty 1061 of care. 1063 See [NetEq] for more context on privacy in networking devices 1065 5. Security Considerations 1067 Attestation results from the RIV procedure are subject to a number of 1068 attacks: 1070 o Keys may be compromised 1071 o A counterfeit device may attempt to impersonate (spoof) a known 1072 authentic device 1074 o Man-in-the-middle attacks may be used by a counterfeit device to 1075 attempt to deliver responses that originate in an actual authentic 1076 device 1078 o Replay attacks may be attempted by a compromised device 1080 Trustworthiness of RIV attestation depends strongly on the validity 1081 of keys used for identity and attestation reports. RIV takes full 1082 advantage of TPM capabilities to ensure that results can be trusted. 1084 Two sets of keys are relevant to RIV attestation 1086 o A DevID key is used to certify the identity of the device in which 1087 the TPM is installed. 1089 o An Attestation Key (AK) key signs attestation reports, (called 1090 'quotes' in TCG documents), used to provide evidence for integrity 1091 of the software on the device. 1093 TPM practices usually require that these keys be different, as a way 1094 of ensuring that a general-purpose signing key cannot be used to 1095 spoof an attestation quote. 1097 In each case, the private half of the key is known only to the TPM, 1098 and cannot be retrieved externally, even by a trusted party. To 1099 ensure that's the case, specification-compliant private/public key- 1100 pairs are generated inside the TPM, where they're never exposed, and 1101 cannot be extracted (See [Platform-DevID-TPM-2.0]). 1103 Keeping keys safe is just part of attestation security; knowing which 1104 keys are bound to the device in question is just as important. 1106 While there are many ways to manage keys in a TPM (See 1107 [Platform-DevID-TPM-2.0]), RIV includes support for "zero touch" 1108 provisioning (also known as zero-touch onboarding) of fielded devices 1109 (e.g. Secure ZTP, [RFC8572]), where keys which have predictable 1110 trust properties are provisioned by the device vendor. 1112 Device identity in RIV is based on IEEE 802.1AR DevID. This 1113 specification provides several elements 1115 o A DevID requires a unique key pair for each device, accompanied by 1116 an x.509 certificate 1118 o The private portion of the DevID key is to be stored in the 1119 device, in a manner that provides confidentiality (Section 6.2.5 1120 [IEEE-802-1AR]) 1122 The x.509 certificate contains several components 1124 o The public part of the unique DevID key assigned to that device 1126 o An identifying string that's unique to the manufacturer of the 1127 device. This is normally the serial number of the unit, which 1128 might also be printed on a label on the device. 1130 o The certificate must be signed by a key traceable to the 1131 manufacturer's root key. 1133 With these elements, the device's manufacturer and serial number can 1134 be identified by analyzing the DevID certificate plus the chain of 1135 intermediate certs leading back to the manufacturer's root 1136 certificate. As is conventional in TLS connections, a nonce must be 1137 signed by the device in response to a challenge, proving possession 1138 of its DevID private key. 1140 RIV uses the DevID to validate a TLS connection to the device as the 1141 attestation session begins. Security of this process derives from 1142 TLS security, with the DevID providing proof that the TLS session 1143 terminates on the intended device. [RFC8446]. 1145 Evidence of software integrity is delivered in the form of a quote 1146 signed by the TPM itself. Because the contents of the quote are 1147 signed inside the TPM, any external modification (including 1148 reformatting to a different data format) will be detected as 1149 tampering. 1151 A critical feature of the YANG model described in 1152 [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data 1153 structures in their native format, without requiring any changes to 1154 the structures as they were signed and delivered by the TPM. While 1155 alternate methods of conveying TPM quotes could compress out 1156 redundant information, or add an additional layer of signing using 1157 external keys, the important part is to preserve the TPM signing, so 1158 that tampering anywhere in the path between the TPM itself and the 1159 Verifier can be detected. 1161 Prevention of spoofing attacks against attestation systems is also 1162 important. There are two cases to consider: 1164 o The entire device could be spoofed, that is, when the Verifier 1165 goes to verify a specific device, it might be redirected to a 1166 different device. Use of the 802.1AR identity in the TPM ensures 1167 that the Verifier's TLS session is in fact terminating on the 1168 right device. 1170 o A compromised device could respond with a spoofed attestation 1171 result, that is, a compromised OS could return a fabricated quote. 1173 Protection against spoofed quotes from a device with valid identity 1174 is a bit more complex. An identity key must be available to sign any 1175 kind of nonce or hash offered by the verifier, and consequently, 1176 could be used to sign a fabricated quote. To block spoofed 1177 attestation result, the quote generated inside the TPM must be signed 1178 by a key that's different from the DevID, called an Attestation Key 1179 (AK). 1181 Given separate Attestation and DevID keys, the binding between the AK 1182 and the same device must also be proven to prevent a man-in-the- 1183 middle attack (e.g. the 'Asokan Attack' [RFC6813]). 1185 This is accomplished in RIV through use of an AK certificate with the 1186 same elements as the DevID (i.e., same manufacturer's serial number, 1187 signed by the same manufacturer's key), but containing the device's 1188 unique AK public key instead of the DevID public key. 1189 [Editor's Note: does this require an OID that says the key is known 1190 by the CA to be an Attestation key?] 1192 These two keys and certificates are used together: 1194 o The DevID is used to validate a TLS connection terminating on the 1195 device with a known serial number. 1197 o The AK is used to sign attestation quotes, providing proof that 1198 the attestation evidence comes from the same device. 1200 Replay attacks, where results of a previous attestation are submitted 1201 in response to subsequent requests, are usually prevented by 1202 inclusion of a nonce in the request to the TPM for a quote. Each 1203 request from the Verifier includes a new random number (a nonce). 1204 The resulting quote signed by the TPM contains the same nonce, 1205 allowing the verifier to determine freshness, i.e., that the 1206 resulting quote was generated in response to the verifier's specific 1207 request. Time-Based Uni-directional Attestation 1208 [I-D.birkholz-rats-tuda] provides an alternate mechanism to verify 1209 freshness without requiring a request/response cycle. 1211 Requiring results of attestation of the operating software to be 1212 signed by a key known only to the TPM also removes the need to trust 1213 the device's operating software (beyond the first measurement; see 1214 below); any changes to the quote, generated and signed by the TPM 1215 itself, made by malicious device software, or in the path back to the 1216 verifier, will invalidate the signature on the quote. 1218 Although RIV recommends that device manufacturers pre-provision 1219 devices with easily-verified DevID and AK certs, use of those 1220 credentials is not mandatory. IEEE 802.1AR incorporates the idea of 1221 an Initial Device ID (IDevID), provisioned by the manufacturer, and a 1222 Local Device ID (LDevID) provisioned by the owner of the device. RIV 1223 extends that concept by defining an Initial Attestation Key (IAK) and 1224 Local Attestation Key (LAK) with the same properties. 1226 Device owners can use any method to provision the Local credentials. 1228 o TCG document [Platform-DevID-TPM-2.0] shows how the initial 1229 Attestation keys can be used to certify LDevID and LAK keys. Use 1230 of the LDevID and LAK allows the device owner to use a uniform 1231 identity structure across device types from multiple manufacturers 1232 (in the same way that an "Asset Tag" is used by many enterprises 1233 to identify devices they own). TCG doc [Provisioning-TPM-2.0] 1234 also contains guidance on provisioning identity keys in TPM 2.0. 1236 o But device owners can use any other mechanism they want to assure 1237 themselves that Local identity certificates are inserted into the 1238 intended device, including physical inspection and programming in 1239 a secure location, if they prefer to avoid placing trust in the 1240 manufacturer-provided keys. 1242 Clearly, Local keys can't be used for secure Zero Touch provisioning; 1243 installation of the Local keys can only be done by some process that 1244 runs before the device is configured for network operation. 1246 On the other end of the device life cycle, provision should be made 1247 to wipe Local keys when a device is decommissioned, to indicate that 1248 the device is no longer owned by the enterprise. The manufacturer's 1249 Initial identity keys must be preserved, as they contain no 1250 information that's not already printed on the device's serial number 1251 plate. 1253 In addition to trustworthy provisioning of keys, RIV depends on other 1254 trust anchors. (See [GloPlaRoT] for definitions of Roots of Trust.) 1256 o Secure identity depends on mechanisms to prevent per-device secret 1257 keys from being compromised. The TPM provides this capability as 1258 a Root of Trust for Storage 1260 o Attestation depends on an unbroken chain of measurements, starting 1261 from the very first measurement. That first measurement is made 1262 by code called the Root of Trust for Measurement, typically done 1263 by trusted firmware stored in boot flash. Mechanisms for 1264 maintaining the trustworthiness of the RTM are out of scope for 1265 RIV, but could include immutable firmware, signed updates, or a 1266 vendor-specific hardware verification technique. 1268 o RIV assumes some level of physical defense for the device. If a 1269 TPM that has already been programmed with an authentic DevID is 1270 stolen and inserted into a counterfeit device, attestation of that 1271 counterfeit device may become indistinguishable from an authentic 1272 device. 1274 RIV also depends on reliable reference measurements, as expressed by 1275 the RIM [RIM]. The definition of trust procedures for RIMs is out of 1276 scope for RIV, and the device owner is free to use any policy to 1277 validate a set of reference measurements. RIMs may be conveyed out- 1278 of-band or in-band, as part of the attestation process (see 1279 Section 3.1.3). But for embedded devices, where software is usually 1280 shipped as a self-contained package, RIMs signed by the manufacturer 1281 and delivered in-band may be more convenient for the device owner. 1283 6. Conclusion 1285 TCG technologies can play an important part in the implementation of 1286 Remote Integrity Verification. Standards for many of the components 1287 needed for implementation of RIV already exist: 1289 o Platform identity can be based on IEEE 802.1AR Device identity, 1290 coupled with careful supply-chain management by the manufacturer. 1292 o Complex supply chains can be certified using TCG Platform 1293 Certificates [Platform-Certificates] 1295 o The TCG TAP mechanism can be used to retrieve attestation 1296 evidence. Work is needed on a YANG model for this protocol. 1298 o Reference Measurements must be conveyed from the software 1299 authority (e.g., the manufacturer) to the system in which 1300 verification will take place. IETF CoSWID work forms the basis 1301 for this, but new work is needed to create an information model 1302 and YANG implementation. 1304 7. IANA Considerations 1306 This memo includes no request to IANA. 1308 8. Appendix 1310 8.1. Layering Model for Network Equipment Attester and Verifier 1312 Retrieval of identity and attestation state uses one protocol stack, 1313 while retrieval of Reference Measurements uses a different set of 1314 protocols. Figure 5 shows the components involved. 1316 +-----------------------+ +-------------------------+ 1317 | | | | 1318 | Attester |<-------------| Verifier | 1319 | (Device) |------------->| (Management Station) | 1320 | | | | | 1321 +-----------------------+ | +-------------------------+ 1322 | 1323 -------------------- -------------------- 1324 | | 1325 ---------------------------------- --------------------------------- 1326 |Reference Integrity Measurements| | Attestation | 1327 ---------------------------------- --------------------------------- 1329 ******************************************************************** 1330 * IETF Attestation Reference Interaction Diagram * 1331 ******************************************************************** 1333 ....................... ....................... 1334 . Reference Integrity . . TAP (PTS2.0) Info . 1335 . Manifest . . Model and Canonical . 1336 . . . Log Format . 1337 ....................... ....................... 1339 ************************* .............. ********************** 1340 * YANG SWID Module * . TCG . * YANG Attestation * 1341 * I-D.birkholz-yang-swid* . Attestation. * Module * 1342 * * . MIB . * I-D.ietf-rats- * 1343 * * . . * yang-tpm-charra * 1344 ************************* .............. ********************** 1346 ************************* ************ ************************ 1347 * XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)* 1348 ************************* ************ ************************ 1350 ************************* ************************ 1351 * RESTCONF/NETCONF * * RESTCONF/NETCONF * 1352 ************************ ************************* 1354 ************************* ************************ 1355 * TLS, SSH * * TLS, SSH * 1356 ************************* ************************ 1358 Figure 7: RIV Protocol Stacks 1360 IETF documents are captured in boxes surrounded by asterisks. TCG 1361 documents are shown in boxes surrounded by dots. The IETF 1362 Attestation Reference Interaction Diagram, Reference Integrity 1363 Manifest, TAP Information Model and Canonical Log Format, and both 1364 YANG modules are works in progress. Information Model layers 1365 describe abstract data objects that can be requested, and the 1366 corresponding response SNMP is still widely used, but the industry is 1367 transitioning to YANG, so in some cases, both will be required. TLS 1368 Authentication with TPM has been shown to work; SSH authentication 1369 using TPM-protected keys is not as easily done [as of 2019] 1371 8.1.1. Why is OS Attestation Different? 1373 Even in embedded systems, adding Attestation at the OS level (e.g. 1374 Linux IMA, Integrity Measurement Architecture [IMA]) increases the 1375 number of objects to be attested by one or two orders of magnitude, 1376 involves software that's updated and changed frequently, and 1377 introduces processes that begin in an unpredictable order. 1379 TCG and others (including the Linux community) are working on methods 1380 and procedures for attesting the operating system and application 1381 software, but standardization is still in process. 1383 8.2. Implementation Notes 1385 Table 1 summarizes many of the actions needed to complete an 1386 Attestation system, with links to relevant documents. While 1387 documents are controlled by several standards organizations, the 1388 implied actions required for implementation are all the 1389 responsibility of the manufacturer of the device, unless otherwise 1390 noted. 1392 +------------------------------------------------------------------+ 1393 | Component | Controlling | 1394 | | Specification | 1395 -------------------------------------------------------------------- 1396 | Make a Secure execution environment | TCG RoT | 1397 | o Attestation depends on a secure root of | UEFI.org | 1398 | trust for measurement outside the TPM, as | | 1399 | well as roots for storage and reporting | | 1400 | inside the TPM. | | 1401 | o Refer to TCG Root of Trust for Measurement.| | 1402 | o NIST SP 800-193 also provides guidelines | | 1403 | on Roots of Trust | | 1404 -------------------------------------------------------------------- 1405 | Provision the TPM as described in | TCG TPM DevID | 1406 | TCG documents. | TCG Platform | 1407 | | Certificate | 1408 -------------------------------------------------------------------- 1409 | Put a DevID or Platform Cert in the TPM | TCG TPM DevID | 1410 | o Install an Initial Attestation Key at the | TCG Platform | 1411 | same time so that Attestation can work out | Certificate | 1412 | of the box |----------------- 1413 | o Equipment suppliers and owners may want to | IEEE 802.1AR | 1414 | implement Local Device ID as well as | | 1415 | Initial Device ID | | 1416 -------------------------------------------------------------------- 1417 | Connect the TPM to the TLS stack | Vendor TLS | 1418 | o Use the DevID in the TPM to authenticate | stack (This | 1419 | TAP connections, identifying the device | action is | 1420 | | simply | 1421 | | configuring TLS| 1422 | | to use the | 1423 | | DevID as its | 1424 | | trust anchor.) | 1425 -------------------------------------------------------------------- 1426 | Make CoSWID tags for BIOS/LoaderLKernel objects | IETF CoSWID | 1427 | o Add reference measurements into SWID tags | ISO/IEC 19770-2| 1428 | o Manufacturer should sign the SWID tags | NIST IR 8060 | 1429 | o The TCG RIM-IM identifies further | | 1430 | procedures to create signed RIM | | 1431 | documents that provide the necessary | | 1432 | reference information | | 1433 -------------------------------------------------------------------- 1434 | Package the SWID tags with a vendor software | Retrieve tags | 1435 | release | with | 1436 | o A tag-generator plugin such | {{I-D.birkholz-yang-swid}}| 1437 | as https://github.com/Labs64/swid-maven-plugin | 1438 | can be used |----------------| 1439 | | TCG PC Client | 1440 | | RIM | 1441 -------------------------------------------------------------------- 1442 | Use PC Client measurement definitions | TCG PC Client | 1443 | to define the use of PCRs | BIOS | 1444 | (although Windows OS is rare on Networking | | 1445 | Equipment, UEFI BIOS is not) | | 1446 -------------------------------------------------------------------- 1447 | Use TAP to retrieve measurements | | 1448 | o Map TAP to SNMP | TCG SNMP MIB | 1449 | o Map to YANG | YANG Module for| 1450 | Use Canonical Log Format | Basic | 1451 | | Attestation | 1452 | | TCG Canonical | 1453 | | Log Format | 1454 -------------------------------------------------------------------- 1455 | Posture Collection Server (as described in IETF | | 1456 | SACMs ECP) should request the | | 1457 | attestation and analyze the result | | 1458 | The Management application might be broken down | | 1459 | to several more components: | | 1460 | o A Posture Manager Server | | 1461 | which collects reports and stores them in | | 1462 | a database | | 1463 | o One or more Analyzers that can look at the| | 1464 | results and figure out what it means. | | 1465 -------------------------------------------------------------------- 1467 Figure 8: Component Status 1469 8.3. Root of Trust for Measurement 1471 The measurements needed for attestation require that the device being 1472 attested is equipped with a Root of Trust for Measurement, i.e., some 1473 trustworthy mechanism that can compute the first measurement in the 1474 chain of trust required to attest that each stage of system startup 1475 is verified, a Root of Trust for Storage (i.e., the TPM PCRs) to 1476 record the results, and a Root of Trust for Reporting to report the 1477 results [TCGRoT], [GloPlaRoT]. 1479 While there are many complex aspects of a Root of Trust, two aspects 1480 that are important in the case of attestation are: 1482 o The first measurement computed by the Root of Trust for 1483 Measurement, and stored in the TPM's Root of Trust for Storage, is 1484 presumed to be correct. 1486 o There must not be a way to reset the Root of Trust for Storage 1487 without re-entering the Root of Trust for Measurement code. 1489 The first measurement must be computed by code that is implicitly 1490 trusted; if that first measurement can be subverted, none of the 1491 remaining measurements can be trusted. (See [NIST-SP-800-155]) 1493 9. Informative References 1495 [AIK-Enrollment] 1496 Trusted Computing Group, "TCG Infrastructure Working 1497 GroupA CMC Profile for AIK Certificate Enrollment Version 1498 1.0, Revision 7", March 2011, 1499 . 1502 [Canonical-Event-Log] 1503 Trusted Computing Group, "DRAFT Canonical Event Log Format 1504 Version: 1.0, Revision: .12", October 2018. 1506 [EFI-TPM] Trusted Computing Group, "TCG EFI Platform Specification 1507 for TPM Family 1.1 or 1.2, Specification Version 1.22, 1508 Revision 15", January 2014, 1509 . 1512 [GloPlaRoT] 1513 GlobalPlatform Technology, "Root of Trust Definitions and 1514 Requirements Version 1.1", June 2018, 1515 . 1518 [I-D.birkholz-rats-reference-interaction-model] 1519 Birkholz, H., Eckel, M., Newton, C., and L. Chen, 1520 "Reference Interaction Models for Remote Attestation 1521 Procedures", draft-birkholz-rats-reference-interaction- 1522 model-03 (work in progress), July 2020. 1524 [I-D.birkholz-rats-tuda] 1525 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 1526 "Time-Based Uni-Directional Attestation", draft-birkholz- 1527 rats-tuda-02 (work in progress), March 2020. 1529 [I-D.birkholz-yang-swid] 1530 Birkholz, H., "Software Inventory YANG module based on 1531 Software Identifiers", draft-birkholz-yang-swid-02 (work 1532 in progress), October 2018. 1534 [I-D.ietf-rats-architecture] 1535 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 1536 W. Pan, "Remote Attestation Procedures Architecture", 1537 draft-ietf-rats-architecture-05 (work in progress), July 1538 2020. 1540 [I-D.ietf-rats-eat] 1541 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 1542 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 1543 ietf-rats-eat-03 (work in progress), February 2020. 1545 [I-D.ietf-rats-yang-tpm-charra] 1546 Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit, 1547 E., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data 1548 Model for Challenge-Response-based Remote Attestation 1549 Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-02 1550 (work in progress), June 2020. 1552 [I-D.ietf-sacm-coswid] 1553 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 1554 Waltermire, "Concise Software Identification Tags", draft- 1555 ietf-sacm-coswid-15 (work in progress), May 2020. 1557 [I-D.richardson-rats-usecases] 1558 Richardson, M., Wallace, C., and W. Pan, "Use cases for 1559 Remote Attestation common encodings", draft-richardson- 1560 rats-usecases-07 (work in progress), March 2020. 1562 [I-D.voit-rats-trusted-path-routing] 1563 Voit, E., "Trusted Path Routing", draft-voit-rats-trusted- 1564 path-routing-02 (work in progress), June 2020. 1566 [IEEE-802-1AR] 1567 Seaman, M., "802.1AR-2018 - IEEE Standard for Local and 1568 Metropolitan Area Networks - Secure Device Identity, IEEE 1569 Computer Society", August 2018. 1571 [IEEE-802.1ae] 1572 Seaman, M., "802.1AE MAC Security (MACsec)", 2018, 1573 . 1575 [IEEE-802.1x] 1576 IEEE Computer Society, "802.1X-2020 - IEEE Standard for 1577 Local and Metropolitan Area Networks--Port-Based Network 1578 Access Control", February 2020, 1579 . 1581 [IMA] and , "Integrity Measurement Architecture", June 2019, 1582 . 1584 [LLDP] IEEE Computer Society, "802.1AB-2016 - IEEE Standard for 1585 Local and metropolitan area networks - Station and Media 1586 Access Control Connectivity Discovery", March 2016, 1587 . 1589 [NetEq] Trusted Computing Group, "TCG Guidance for Securing 1590 Network Equipment", January 2018, 1591 . 1594 [NIST-IR-8060] 1595 National Institute for Standards and Technology, 1596 "Guidelines for the Creation of Interoperable Software 1597 Identification (SWID) Tags", April 2016, 1598 . 1601 [NIST-SP-800-155] 1602 National Institute for Standards and Technology, "BIOS 1603 Integrity Measurement Guidelines (Draft)", December 2011, 1604 . 1607 [PC-Client-BIOS-TPM-1.2] 1608 Trusted Computing Group, "TCG PC Client Specific 1609 Implementation Specification for Conventional BIOS, 1610 Specification Version 1.21 Errata, Revision 1.00", 1611 February 2012, . 1614 [PC-Client-BIOS-TPM-2.0] 1615 Trusted Computing Group, "PC Client Specific Platform 1616 Firmware Profile Specification Family "2.0", Level 00 1617 Revision 1.04", June 2019, 1618 . 1621 [PC-Client-RIM] 1622 Trusted Computing Group, "DRAFT: TCG PC Client Reference 1623 Integrity Manifest Specification, v.09", December 2019, 1624 . 1626 [Platform-Certificates] 1627 Trusted Computing Group, "DRAFT: TCG Platform Attribute 1628 Credential Profile, Specification Version 1.0, Revision 1629 15, 07 December 2017", December 2017. 1631 [Platform-DevID-TPM-2.0] 1632 Trusted Computing Group, "DRAFT: TPM Keys for Platform 1633 DevID for TPM2, Specification Version 0.7, Revision 0", 1634 October 2018. 1636 [Platform-ID-TPM-1.2] 1637 Trusted Computing Group, "TPM Keys for Platform Identity 1638 for TPM 1.2, Specification Version 1.0, Revision 3", 1639 August 2015, . 1643 [Provisioning-TPM-2.0] 1644 Trusted Computing Group, "TCG TPM v2.0 Provisioning 1645 Guidance", March 2015, . 1649 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1650 Levkowetz, Ed., "Extensible Authentication Protocol 1651 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1652 . 1654 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1655 and A. Bierman, Ed., "Network Configuration Protocol 1656 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1657 . 1659 [RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment 1660 (NEA) Asokan Attack Analysis", RFC 6813, 1661 DOI 10.17487/RFC6813, December 2012, 1662 . 1664 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1665 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1666 . 1668 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1669 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1670 . 1672 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1673 Touch Provisioning (SZTP)", RFC 8572, 1674 DOI 10.17487/RFC8572, April 2019, 1675 . 1677 [RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity 1678 Manifest Information Model", June 2019, 1679 . 1682 [SWID] The International Organization for Standardization/ 1683 International Electrotechnical Commission, "Information 1684 Technology Software Asset Management Part 2: Software 1685 Identification Tag, ISO/IEC 19770-2", October 2015, 1686 . 1688 [TAP] Trusted Computing Group, "DRAFT: TCG Trusted Attestation 1689 Protocol (TAP) Information Model for TPM Families 1.2 and 1690 2.0 and DICE Family 1.0, Version 1.0, Revision 0.29", 1691 October 2018. 1693 [TCGRoT] Trusted Computing Group, "TCG Roots of Trust 1694 Specification", October 2018, 1695 . 1698 Authors' Addresses 1700 Guy Fedorkow (editor) 1701 Juniper Networks, Inc. 1702 US 1704 Email: gfedorkow@juniper.net 1706 Eric Voit 1707 Cisco Systems, Inc. 1708 US 1710 Email: evoit@cisco.com 1712 Jessica Fitzgerald-McKay 1713 National Security Agency 1714 US 1716 Email: jmfitz2@nsa.gov