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