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