idnits 2.17.1 draft-fedorkow-rats-network-device-attestation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 1, 2019) is 1784 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-birkholz-rats-architecture-02 == Outdated reference: A later version (-03) exists of draft-birkholz-rats-reference-interaction-model-01 == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-01 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-12 Summary: 0 errors (**), 0 flaws (~~), 5 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 J. Fitzgerald-McKay 5 Expires: December 3, 2019 National Security Agency 6 June 1, 2019 8 Network Device Attestation Workflow 9 draft-fedorkow-rats-network-device-attestation-01 11 Abstract 13 This document describes a workflow for network device attestation. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on December 3, 2019. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 51 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.3. Description of Remote Integrity Verification (RIV) . . . 5 53 1.4. Solution Requirements . . . . . . . . . . . . . . . . . . 6 54 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 1.5.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8 56 1.5.2. Why Remote Integrity Verification? . . . . . . . . . 8 57 1.5.3. Network Device Attestation Challenges . . . . . . . . 8 58 1.5.4. Why is OS Attestation Different? . . . . . . . . . . 10 59 2. Solution Outline . . . . . . . . . . . . . . . . . . . . . . 10 60 2.1. RIV Software Configuration Attestation using TPM . . . . 10 61 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 11 62 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 12 63 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 13 64 2.4.1. DevID Alternatives . . . . . . . . . . . . . . . . . 14 65 2.4.2. Additional Attestation of Platform Characteristics . 14 66 2.4.3. Root of Trust for Measurement . . . . . . . . . . . . 15 67 2.4.4. Reference Integrity Manifests (RIMs) . . . . . . . . 15 68 2.4.5. Attestation Logs . . . . . . . . . . . . . . . . . . 16 69 3. Standards Components . . . . . . . . . . . . . . . . . . . . 17 70 3.1. Reference Models . . . . . . . . . . . . . . . . . . . . 17 71 3.1.1. IETF Reference Model for Challenge-Response Remote 72 Attestation . . . . . . . . . . . . . . . . . . . . . 17 73 3.2. RIV Workflow . . . . . . . . . . . . . . . . . . . . . . 18 74 3.3. Layering Model for Network Equipment Attester and 75 Verifier . . . . . . . . . . . . . . . . . . . . . . . . 20 76 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 78 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 26 79 7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 27 80 7.1. Implementation Notes . . . . . . . . . . . . . . . . . . 27 81 7.2. Comparison with TCG PTS / IETF NEA . . . . . . . . . . . 30 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 83 9. Informative References . . . . . . . . . . . . . . . . . . . 31 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 86 1. Introduction 88 There are many aspects to consider in fielding a trusted computing 89 device, from operating systems to applications. Mechanisms to prove 90 that a device installed at a customer's site is authentic (i.e., not 91 counterfeit) and has been configured with authorized software, all as 92 part of a trusted supply chain, is one of those aspects that's easily 93 overlooked. 95 Attestation is defined here as the process of creating, conveying and 96 appraising assertions about Platform trustworthiness characteristics, 97 including supply chain trust, identity, platform provenance, software 98 configuration, hardware configuration, platform composition, 99 compliance to test suites, functional and assurance evaluations, etc. 101 The supply chain itself has many elements, from validating suppliers 102 of electronic components, to ensuring that shipping procedures 103 protect against tampering through many stages of distribution and 104 warehousing. One element that helps maintain the integrity of the 105 supply chain after manufacturing is Attestation, by assuring an 106 administrator that the software that was launched when the device was 107 started is the same as the software that the device vendor initially 108 shipped. 110 Within the Trusted Computing Group context, attestation is the 111 process by which an independent Verifier can obtain cryptographic 112 proof as to the identity of the device in question, evidence of the 113 integrity of software loaded on that device when it started up, and 114 then verify that what's there is what's supposed to be there. For 115 networking equipment, a verifier capability can be embedded in a 116 Network Management Station (NMS), a posture collection server, or 117 other network analytics tool (such as a software asset management 118 solution, or a threat detection and mitigation tool, etc.). While 119 informally referred to as attestation, this document focuses on a 120 subset defined here as Remote Integrity Verification (RIV). RIV 121 takes a network equipment centric perspective that includes a set of 122 protocols and procedures for determining whether a particular device 123 was launched with untampered software, starting from Roots of Trust. 124 While there are many ways to accomplish attestation, RIV sets out a 125 specific set of protocols and tools that work in environments 126 commonly found in Networking Equipment. RIV does not cover other 127 platform characteristics that could be attested, although it does 128 provide evidence of a secure infrastructure to increase the level of 129 trust in other platform characteristics attested by other means. 131 This profile outlines the RIV problem, and then identifies elements 132 that are necessary to get the complete attestation procedure working 133 in a scalable solution using commercial products. 135 This document focuses primarily on software integrity verification 136 using the Trusted Platform Module (TPM) to ensure a trustworthy 137 result. 139 The integrity of attestation information must be protected by means 140 of cryptographic techniques, to assure its validity. 142 It's important to note that TCG technologies are available to use 143 either symmetric key encryption with shared keys, or public key 144 cryptography using private/public key pairs. 145 The two techniques can each produce secure results, but do require 146 different provisioning mechanisms. 147 The RIV document currently focuses on asymmetric keying approaches 148 only; future work might include techniques for attestation using 149 symmetric keys. 151 1.1. Requirements Language 153 This document itself is non-normative; the document does not define 154 protocols, but rather identifies protocols that can be used together 155 to achieve the goals above, and in some cases, highlights gaps in 156 existing protocols. 158 1.2. Goals 160 Attestation requires two interlocking services on the device: 162 o Platform Identity, the mechanism providing trusted identity, can 163 reassure network managers that the specific devices they ordered 164 from authorized manufacturers for attachment to their network are 165 those that were installed, and that they continue to be present in 166 their network. As part of the mechanism for Platform Identity, 167 cryptographic proof of the identity of the manufacturer is also 168 provided. 170 o Software Measurement is the mechanism that reports the state of 171 mutable software components on the device, and can assure network 172 managers that they have known, untampered software configured to 173 run in their network. 175 As a part of a trusted supply chain, the RIV attestation workflow 176 outlined in this document is intended to meet the following high- 177 level goals: 179 o Provable Device Identity - The ability to identify a device using 180 a cryptographic identifier is a critical prerequisite to software 181 inventory attestation. 183 o Software Inventory - A key goal is to identify the software 184 release installed on the device, and to provide evidence of its 185 integrity. 187 o Verifiability - Verification of software and configuration of the 188 device shows that the software that's supposed to be installed on 189 there actually has been launched. Verification against reference 190 manifests signed by the supplier of the software provides 191 assurance that the software is free of unauthorized modification. 193 1.3. Description of Remote Integrity Verification (RIV) 195 RIV is a procedure that assures a network operator that the equipment 196 on their network can be reliably identified, and that untampered 197 software of a known version is installed on each endpoint. In this 198 context, endpoint might include the conventional connected devices 199 like servers and laptops, but also connected devices that make up the 200 network equipment itself, such as routers, switches and firewalls. 202 RIV can be viewed as a link in a trusted supply chain that ensures 203 that devices launch software without unauthorized modification, and 204 includes three major processes: 206 1. Creation of Evidence is the process whereby an endpoint generates 207 cryptographic proof (evidence) of claims about platform 208 properties. In particular, the platform identity and its 209 software configuration are of critical importance 211 o Platform Identity refers to the mechanism assuring the attestation 212 relying party (typically a network administrator) of the identity 213 of devices that make up their network, and that their 214 manufacturers are known. 216 o Software used to boot a platform can be described as a chain of 217 measurements, started by a Root of Trust for Measurement, that 218 normally ends when the system software is loaded. A measurement 219 signifies the identity, integrity and version of each software 220 component registered with the TPM, so that the subsequent 221 appraisal stage can determine if the software installed is 222 authentic, up-to-date, and free of tampering. 224 Clearly the second part of the problem, attesting the state of 225 mutable components of a given device, is of little value without 226 reliable identification of the device in question. By the same 227 token, unambiguous identity of a device is necessary, but is 228 insufficient to assure the operator of the provenance of the device 229 through the supply chain, or that the device is configured to behave 230 properly. 232 1. Conveyance of Evidence is the process of reliably transporting 233 evidence from the point in a connected device where a measurement 234 is stored to an appraiser/verifier, e.g. a management station. 235 The transport is typically carried out via a management network. 236 The channel must provide integrity and authenticity, and, in some 237 use cases, may also require confidentiality. 239 2. Appraisal of Evidence is the process of verifying the evidence 240 received by a verifier/appraiser from a device, and using 241 verified evidence to inform decision making. In this context, 242 verification means comparing the device measurements reported as 243 evidence with the configuration expected by the system 244 administrator. This step can work only when there is a way to 245 express what should be there, often referred to as golden 246 measurements, or Reference Integrity Measurements, representing 247 the intended configured state of the connected device. 249 An implementation of RIV requires three technologies 251 1. Identity: Platform identity can be based on IEEE 802.1AR Device 252 Identity [IEEE-802-1AR], coupled with careful supply-chain 253 management by the manufacturer. The DevID certificate contains a 254 statement by the manufacturer that establishes the provenance of 255 the device as it left the factory. Some applications with a 256 more-complex post-manufacture supply chain (e.g. Value Added 257 Resellers), or with different privacy concerns, may want to use 258 an alternate mechanism for platform authentication based on TCG 259 Platform Certificates [Platform-Certificates]. 260 RIV currently relies on asymmetric keying for identity; alternate 261 approaches might use symmetric keys. 263 2. Platform Attestation provides evidence of configuration of 264 software elements throughout the product lifecycle. This form of 265 attestation can be implemented with TPM PCR, Quote and log 266 mechanisms, which provide an authenticated mechanism to report 267 what software actually starts up on the device each time it 268 reboots. 270 3. Reference Integrity Measurements must be conveyed from the 271 software authority (often the manufacturer for embedded systems) 272 to the system in which verification will take place 274 Service Providers benefit from a trustworthy attestation mechanism 275 that provides assurance that their network comprises authentic 276 equipment, and has loaded software free of known vulnerabilities and 277 unauthorized tampering. 279 1.4. Solution Requirements 281 The RIV attestation solution must meet a number of requirements to 282 make it simple to deploy at scale. 284 1. Easy to Use - This solution should work "out of the box" as far 285 as possible, that is, with the fewest possible steps needed at 286 the end-user's site. Eliminate complicated databases or 287 provisioning steps that would have to be executed by the owner of 288 a new device. Network equipment is often required to "self- 289 configure", to reliably reach out without manual intervention to 290 prove its identity and operating posture, then download its own 291 configuration. See [RFC8572] for an example of Secure Zero Touch 292 Provisioning. 294 2. Multi-Vendor - This solution should identify standards-based 295 interfaces that allow attestation to work with attestation- 296 capable devices and verifiers supplied by different vendors in 297 one network. 299 3. Scalable - The solution must not depend on choke points that 300 limit the number of endpoints that could be evaluated in one 301 network domain. 303 4. Extensible - A network equipment attestation solution needs to 304 expand over time as new features are added. The solution must 305 allow new features to be added easily, providing for a smooth 306 transition and allowing newer and older architectural components 307 to continue to work together. Further, a network equipment 308 attestation solution and the specifications referenced here must 309 define safe extensibility mechanisms that enable innovation 310 without breaking interoperability. 312 5. Efficient - A network equipment attestation solution should, to 313 the greatest extent feasible, continuously monitor the health and 314 posture status of network devices. Posture measurements should 315 be updated in real-time as changes to device posture occur and 316 should be published to remote integrity validators. Validation 317 reports should also be shared with their relying parties (for 318 example, network administrators, or network analytics that rely 319 on these reports for posture assessment) as soon as they are 320 available. 322 1.5. Scope 324 This document includes a number of assumptions to limit the scope: 326 o This solution is for use in non-privacy-preserving applications 327 (for example, networking, Industrial IoT), avoiding the need for a 328 Privacy Certificate Authority for attestation keys 329 [AIK-Enrollment] 331 o This document applies primarily to "embedded" applications, where 332 the device manufacturer ships the software image for the device. 334 o The approach outlined in this document assumes the use of TPM 1.2 335 or TPM 2.0. 337 1.5.1. Out of Scope 339 o Run-Time Attestation: Run-time attestation of Linux or other 340 multi-threaded operating system processes considerably expands the 341 scope of the problem. Many researchers are working on that 342 problem, but this document defers the run-time attestation 343 problem. 345 o Multi-Vendor Embedded Systems: Additional coordination would be 346 needed for devices that themselves comprise hardware and software 347 from multiple vendors, integrated by the end user. 349 o Processor Sleep Modes: Network equipment typically does not 350 "sleep", so sleep and hibernate modes are not considered. 352 o Virtualization and Containerization: These technologies are 353 increasingly used in Network equipment, but are not considered in 354 this revision of the document. 356 1.5.2. Why Remote Integrity Verification? 358 Remote Integrity Verification can go a long way to solving the "Lying 359 Endpoint" problem, in which malicious software on an endpoint may 360 both subvert the intended function, and also prevent the endpoint 361 from reporting its compromised status. Man-in-the Middle attacks are 362 also made more difficult through a strong focus on device identity 364 Attestation data can be used for asset management, vulnerability and 365 compliance assessment, plus configuration management. 367 1.5.3. Network Device Attestation Challenges 369 There have been demonstrations of attestation using TPMs for years, 370 accompanied by compelling security reasons for adopting attestation. 371 Despite this, the technology has not been widely adopted, in part, 372 due to the difficulties in deploying TPM-based attestation. Some of 373 those difficulties are: 375 o Standardizing device identity. Creating and using unique device 376 identifiers is difficult, especially in a privacy-sensitive 377 environment. But attestation is of limited value if the operator 378 is unable to determine which devices pass attestation validation 379 tests, and which fail. This problem is substantially simplified 380 for infrastructure devices like network equipment, where identity 381 can be explicitly coded using IEEE 802.1AR, but doing so relies on 382 adoption of 802.1AR [IEEE-802-1AR] by manufacturers and hardware 383 system integrators. 385 o Standardizing attestation representations and conveyance. 386 Interoperable remote attestation has a fundamental dependence on 387 vendors agreeing to a limited set of network protocols commonly 388 used in existing network equipment for communicating attestation 389 data. Network device vendors will be slow to adopt the changes 390 necessary to implement remote attestation without a fully-realized 391 plan for deployment. 393 o Interoperability. Networking equipment operates in a 394 fundamentally multi-vendor environment, putting additional 395 emphasis on the need for standardized procedures and protocols. 397 o Attestation evidence is complex. Operating systems used in larger 398 embedded devices are often multi-threaded, so the order of 399 completion for individual processes is non-deterministic. While 400 the hash of a specific component is stable, once extended into a 401 PCR, the resulting values are dependent on the (non-deterministic) 402 ordering of events, so there will never be a single known-good 403 value for some PCRs. Careful analysis of event logs can provide 404 proof that the expected modules loaded, but it's much more 405 complicated than simply comparing reported and expected digests, 406 as collected in TPM Platform Configuration Registers (PCRs). 408 o Software configurations can have seemingly infinite variability. 409 This problem is nearly intractable on PC and Server equipment, 410 where end users have unending needs for customization and new 411 applications. However, embedded systems, like networking 412 equipment, are often simpler, in that there are fewer variations 413 and releases, with vendors typically offering fewer options for 414 mixing and matching. 416 o Standards-based mechanisms to encode and distribute Reference 417 Integrity Measurements, (i.e., expected values) are still in 418 development. 420 o Software updates can be complex. Even the most organized network 421 operator may have many different releases in their network at any 422 given time, with the result that there's never a single digest or 423 fingerprint that indicates the software is "correct"; digests 424 formed by hashing software modules on a device can only show the 425 correct combination of versions for a specific device at a 426 specific time. 428 None of these issues are insurmountable, but together, they've made 429 deployment of attestation a major challenge. The intent of this 430 document is to outline an attestation profile that's simple enough to 431 deploy, while yielding enough security to be useful. 433 1.5.4. Why is OS Attestation Different? 435 Even in embedded systems, adding Attestation at the OS level (e.g. 436 Linux IMA, Integrity Measurement Architecture [IMA]) increases the 437 number of objects to be attested by one or two orders of magnitude, 438 involves software that's updated and changed frequently, and 439 introduces processes that begin in unpredictable order. 441 TCG and others (including the Linux community) are working on methods 442 and procedures for attesting the operating system and application 443 software, but standardization is still in process. 445 2. Solution Outline 447 2.1. RIV Software Configuration Attestation using TPM 449 RIV Attestation is a process for determining the identity of software 450 running on a specifically-identified device. Remote Attestation is 451 broken into two phases, shown in Figure 1: 453 o During system startup, measurements (i.e., digests computed as 454 fingerprints of files) are extended, or cryptographically folded, 455 into the TPM. Entries are also added to an informational log. 456 The measurement process generally follows the Chain of Trust model 457 used in Measured Boot, where each stage of the system measures the 458 next one, and extends its measurement into the TPM, before 459 launching it. 461 o Once the device is running and has operational network 462 connectivity, a separate, trusted server (called a Verifier in 463 this document) can interrogate the network device to retrieve the 464 logs and a copy of the digests collected by hashing each software 465 object, signed by an attestation private key known only to the 466 TPM. 468 The result is that the Verifier can verify the device's identity by 469 checking the certificate containing the TPM's attestation public key, 470 and can validate the software that was launched by comparing digests 471 in the log with known-good values, and verifying their correctness by 472 comparing with the signed digests from the TPM. 474 It should be noted that attestation and identity are inextricably 475 linked; signed evidence that a particular version of software was 476 loaded is of little value without cryptographic proof of the identity 477 of the device producing the evidence. 479 +-------------------------------------------------------+ 480 | +--------+ +--------+ +--------+ +---------+ | 481 | | BIOS |--->| Loader |-->| Kernel |--->|Userland | | 482 | +--------+ +--------+ +--------+ +---------+ | 483 | | | | | 484 | | | | | 485 | +------------+-----------+-+ | 486 | Step 1 | | 487 | V | 488 | +--------+ | 489 | | TPM | | 490 | +--------+ | 491 | Router | | 492 +--------------------------------|----------------------+ 493 | 494 | Step 2 495 | +-----------+ 496 +--->| Verifier | 497 +-----------+ 499 Reset---------------flow-of-time-during-boot--...-------> 501 Figure 1: RIV Attestation Model 503 In Step 1, measurements are "extended" into the TPM as processes 504 start. In Step 2, signed PCR digests are retrieved from the TPM for 505 off-box analysis after the system is operational. 507 2.2. RIV Keying 509 TPM 1.2 and TPM 2.0 have a variety of rules separating the functions 510 of identity and attestation, allowing for use-cases where software 511 configuration must be attested, but privacy must be maintained. 513 To accommodate these rules, enforced inside the TPM, in an 514 environment where device privacy is not normally a requirement, the 515 TCG Guidance for Securing Network Equipment [NetEq] suggests using 516 separate keys for Identity (i.e., DevID) and Attestation (i.e., 517 signing a quote of the contents of the PCRs), but provisioning an 518 Initial Attestation Key (IAK) and x.509 certificate that parallels 519 the IDevID, with the same device ID information as the IDevID 520 certificate (i.e., the same Subject Name and Subject Alt Name, even 521 though the key pairs are different). This allows a quote from the 522 device, signed by the IAK, to be linked directly to the device that 523 provided it, by examining the corresponding IAK certificate. 525 Inclusion of an IAK by a vendor does not preclude a mechanism whereby 526 an Administrator can define Local Attestation Keys (LAKs) if desired. 528 2.3. RIV Information Flow 530 RIV workflow for networking equipment is organized around a simple 531 use-case, where a network operator wishes to verify the integrity of 532 software installed in specific, fielded devices. This use-case 533 implies several components: 535 1. A Device (e.g. a router or other embedded device, also known as 536 an Attester) somewhere and the network operator wants to examine 537 its boot state. 539 2. A Verifier (which might be a network management station) 540 somewhere separate from the Device that will retrieve the 541 information and analyze it to pass judgement on the security 542 posture of the device. 544 3. A Relying Party, which has access to the Verifier to request 545 attestation and to act on results. Interaction between the 546 Relying Party and the Verifier is considered out of scope for 547 RIV. 549 4. This document assumes that signed Reference Integrity Manifests 550 (RIMs) (containing "golden measurements", or Reference Integrity 551 Measurements) can either be created by the device manufacturer 552 and shipped along with the device as part of its software image, 553 or alternatively, could be obtained a number of other ways 554 (direct to the verifier from the manufacturer, from a third 555 party, from the owner's observation of what's thought to be a 556 "known good system", etc.). Retrieving RIMs from the device 557 itself allows attestation to be done in systems which may not 558 have access to the public internet, or by other devices that are 559 not management stations per-se (e.g., a peer device). If 560 reference measurements are obtained from multiple sources, the 561 Verifier may need to evaluate the relative level of trust to be 562 placed in each source in case of a discrepancy. 564 These components are illustrated in Figure 2. 566 A more-detailed taxonomy of terms is given in 567 [I-D.birkholz-rats-architecture] 568 +---------------+ +-------------+ +---------+--------+ 569 | | | Attester | Step 1 | Verifier| | 570 | Asserter | | (Device |<-------| (Network| Relying| 571 | (Device | | under |------->| Mngmt | Party | 572 | Manufacturer | | attestation)| Step 2 | Station)| | 573 | or other | | | | | | 574 | authority) | | | | | | 575 +---------------+ +-------------+ +---------+--------+ 576 | /\ 577 | Step 0 | 578 ----------------------------------------------- 580 Figure 2: RIV Reference Configuration for Network Equipment 582 In Step 0, The Asserter (the device manufacturer) provides a Software 583 Image accompanied by one or more Reference Integrity Manifests (RIMs) 584 to the Attester (the device under attestation) signed by the 585 asserter. In Step 1, the Verifier (Network Management Station), on 586 behalf of a Relying Party, requests Identity, Measurement Values (and 587 possibly RIMs) from the Attester. In Step 2, the Attester responds 588 to the request by providing a DevID, quotes (measured values), and 589 optionally RIMs, signed by the Attester. 591 See [I-D.birkholz-rats-reference-interaction-model] for more narrowly 592 defined terms related to Attestation 594 2.4. RIV Simplifying Assumptions 596 This document makes the following simplifying assumptions to reduce 597 complexity: 599 o The product to be attested is shipped with an IEEE 802.1AR DevID 600 and an Initial Attestation Key (IAK) with certificate. The IAK 601 cert contains the same identity information as the DevID 602 (specifically, the same Subject Name and Subject Alt Name, signed 603 by the manufacturer), but it's a type of key that can be used to 604 sign a TPM Quote. This convention is described in TCG Guidance 605 for Securing Network Equipment [NetEq]. For network equipment, 606 which is generally non-privacy-sensitive, shipping a device with 607 both an IDevID and an IAK already provisioned substantially 608 simplifies initial startup. Privacy-sensitive applications may 609 use the TCG Platform Certificate and additional procedures to 610 install identity credentials on the platform after manufacture. 611 (See Section 2.3.1 below for the Platform Certificate alternative) 613 o The product is equipped with a Root of Trust for Measurement, Root 614 of Trust for Storage and Root of Trust for Reporting (as defined 615 in [GloPlaRoT]) that are capable of conforming to the TCG Trusted 616 Attestation Protocol (TAP) Information Model [TAP]. 618 o The vendor will ship Reference Integrity Measurements (i.e., 619 known-good measurements) in the form of signed CoSWID tags 620 [I-D.ietf-sacm-coswid], [SWID], as described in TCG Reference 621 Integrity Measurement Manifest [RIM]. 623 2.4.1. DevID Alternatives 625 Some situations may have privacy-sensitive requirements that preclude 626 shipping every device with an Initial Device ID installed. In these 627 cases, the IDevID can be installed remotely using the TCG Platform 628 Certificate [Platform-Certificates]. 630 Some administrators may want to install their own identity 631 credentials to certify device identity and attestation results. IEEE 632 802.1AR [IEEE-802-1AR] allows for both Initial Device Identity 633 credentials, installed by the manufacturer, (analogous to a physical 634 serial number plate), or Local Device Identity credentials installed 635 by the administrator of the device (analogous to the physical Asset 636 Tag used by many enterprises to identify their property). TCG TPM 637 2.0 Keys documents [Platform-DevID-TPM-2.0] and 638 [PC-Client-BIOS-TPM-2.0] specifies parallel Initial and Local 639 Attestation Keys (IAK and LAK), and contains figures showing the 640 relationship between IDevID, LDevID, IAK and LAK keys. 642 Device administrators are free to use any number of criteria to judge 643 authenticity of a device before installing local identity keys, as 644 part of an on-boarding process. The TCG TPM 2.0 Keys document 645 [Platform-DevID-TPM-2.0] also outlines procedures for creating Local 646 Attestation Keys and Local Device IDs (LDevIDs) rooted in the 647 manufacturer's IDevID as a check to reduce the chances that 648 counterfeit devices are installed in the network. 650 Note that many networking devices are expected to self-configure (aka 651 Zero Touch Provisioning). Current standardized zero-touch mechanisms 652 such as [RFC8572] assume that identity keys are already in place 653 before network on-boarding can start, and as such, are compatible 654 with IDevID and IAK keys installed by the manufacturer, but not with 655 LDevID and LAK keys, which would have to be installed by the 656 administrator. 658 2.4.2. Additional Attestation of Platform Characteristics 660 The Platform Attribute Credential [Platform-Certificates] can also be 661 used to convey additional information about a platform from the 662 manufacturer or other entities in the supply chain. While outside 663 the scope of RIV, the Platform Attribute Credential can deliver 664 information such as lists of serial numbers for components embedded 665 in a device or security assertions related to the platform, signed by 666 the manufacturer, system integrator or value-added-reseller. 668 2.4.3. Root of Trust for Measurement 670 The measurements needed for attestation require that the device being 671 attested is equipped with a Root of Trust for Measurement, i.e., some 672 trustworthy mechanism that can compute the first measurement in the 673 chain of trust required to attest that each stage of system startup 674 is verified, and a Root of Trust for Reporting to report the results 675 [TCGRoT], [GloPlaRoT]. 677 While there are many complex aspects of a Root of Trust, two aspects 678 that are important in the case of attestation are: 680 o The first measurement computed by the Root of Trust for 681 Measurement, and stored in the TPM's Root of Trust for Storage, is 682 presumed to be correct. 684 o There must not be a way to reset the RTS without re-entering the 685 RTM code. 687 The first measurement must be computed by code that is implicitly 688 trusted; if that first measurement can be subverted, none of the 689 remaining measurements can be trusted. (See [NIST-SP-800-155]) 691 2.4.4. Reference Integrity Manifests (RIMs) 693 Much of attestation focuses on collecting and transmitting evidence 694 in the form of PCR measurements and attestation logs. But the 695 critical part of the process is enabling the verifier to decide 696 whether the measurements are "the right ones" or not. 698 While it must be up to network administrators to decide what they 699 want on their networks, the software supplier should supply the 700 Reference Integrity Measurements, (aka Golden Measurements or "known 701 good" digests) that may be used by a verifier to determine if 702 evidence shows known good, known bad or unknown software 703 configurations. 705 In general, there are two kinds of reference measurements: 707 1. Measurements of early system startup (e.g., BIOS, boot loader, OS 708 kernel) are essentially single threaded, and executed exactly 709 once, in a known sequence, before any results could be reported. 710 In this case, while the method for computing the hash and 711 extending relevant PCRs may be complicated, the net result is 712 that the software (more likely, firmware) vendor will have one 713 known good PCR value that "should" be present in the PCR after 714 the box has booted. In this case, the signed reference 715 measurement simply lists the expected hash for the given version. 717 2. Measurements taken later in operation of the system, once an OS 718 has started (for example, Linux IMA[IMA]), may be more complex, 719 with unpredictable "final" PCR values. In this case, the 720 Verifier must have enough information to reconstruct the expected 721 PCR values from logs and signed reference measurements from a 722 trusted authority. 724 In both cases, the expected values can be expressed as signed CoSWID 725 tags, but the SWID structure in the second case is somewhat more 726 complex. An example of how CoSWIDs could be incorporated into a 727 reference manifest can be found in the IETF Internet-Draft "A SUIT 728 Manifest Extension for Concise Software Identifiers" 729 [I-D.birkholz-suit-coswid-manifest]. 731 The TCG has done exploratory work in defining formats for reference 732 integrity manifests under the working title TCG Reference Integrity 733 Manifest [RIM]. 735 2.4.5. Attestation Logs 737 Quotes from a TPM can provide evidence of the state of a device up to 738 the time the evidence was recorded, but to make sense of the quote in 739 most cases an event log of what software modules contributed which 740 values to the quote during startup must also be provided. The log 741 must contain enough information to demonstrate its integrity by 742 allowing exact reconstruction of the digest conveyed in the signed 743 quote (e.g., PCR values). 745 TCG has defined several event log formats: 747 o Legacy BIOS event log (TCG PC Client Specific Implementation 748 Specification for Conventional BIOS, 749 Section 11.3[PC-Client-BIOS-TPM-1.2]) 751 o UEFI BIOS event log (TCG EFI Platform Specification for TPM Family 752 1.1 or 1.2, Section 7 [EFI]) 754 o Canonical Event Log [Canonical-Event-Log] 756 It should be noted that a given device might use more than one event 757 log format (e.g., a UEFI log during initial boot, switching to 758 Canonical Log when the host OS launches). 760 The TCG SNMP Attestation MIB [SNMP-Attestation-MIB] will support any 761 record-oriented log format, including the three TCG-defined formats, 762 but it currently leaves figuring out which log(s) are in what format 763 up to the Verifier. 765 3. Standards Components 767 3.1. Reference Models 769 3.1.1. IETF Reference Model for Challenge-Response Remote Attestation 771 Initial work at IETF defines remote attestation as follows: 773 The Reference Interaction Model for Challenge-Response-based Remote 774 Attestation is based on the standard roles defined in 775 [I-D.birkholz-rats-architecture]: 777 o Attester: The role that designates the subject of the remote 778 attestation. A system entity that is the provider of evidence 779 takes on the role of an Attester. 781 o Verifier: The role that designates the system entity and that is 782 the appraiser of evidence provided by the Attester. A system 783 entity that is the consumer of evidence takes on the role of a 784 Verifier. 786 The following diagram illustrates a common information flow between a 787 Verifier and an Attester, specified in 788 [I-D.birkholz-rats-reference-interaction-model]: 790 Attester Verifier 791 | | 792 | <------- requestAttestation(nonce, authSecID, claimSelection) | 793 | | 794 collectAssertions(assertionsSelection) | 795 | => assertions | 796 | | 797 signAttestationEvidence(authSecID, assertions, nonce) | 798 | => signedAttestationEvidence | 799 | | 800 | signedAttestationEvidence ----------------------------------> | 801 | | 802 | verifyAttestationEvidence(signedAttestatEvidence, refassertions) 803 | attestationResult <= | 804 | | 806 Figure 3: IETF Attestation Information Flow 808 The RIV approach outlined in this document aligns with the RATS 809 reference model. 811 3.2. RIV Workflow 813 The overall flow for an attestation session is shown in Figure 4. In 814 this diagram: 816 o Step 0, obtaining the signed reference measurements, may happen in 817 two ways: 819 o Step 0A below shows a verifier obtaining reference measurements 820 directly from a software configuration authority, whether it's the 821 vendor or another authority chosen by the system administrator. 822 The reference measurements are signed by the Asserter (i.e., the 823 software configuration authority). 825 o - Or - Step 0B, the reference measurements, signed by the 826 Asserter, may be distributed as part of software installation, 827 long before the attestation session begins. Software installation 828 is usually vendor-dependent, so there are no standards involved in 829 this step. However, the verifier can use the same protocol to 830 obtain the reference measurements from the device as it would have 831 used with an external reference authority 833 o In Step 1, the Verifier initiates an attestation session by 834 opening a TLS session, validated using the DevID to prove that the 835 connection is attesting the right box. 837 o In Step 2, measured values are retrieved from the Attester's TPM 838 using a YANG [RFC8348] or SNMP [RFC3413] interface that implements 839 the TCG TAP model (e.g. YANG Module for Basic Challenge-Response- 840 based Remote Attestation Procedures 841 [I-D.birkholz-yang-basic-remote-attestation]). 843 o In Step 3, the Attester also delivers a copy of the signed 844 reference measurements, using Software Inventory YANG module based 845 on Software Identifiers [I-D.birkholz-yang-swid]. 847 These steps yield enough information for the Verifier to verify 848 measurements against reference values. Of course in all cases, the 849 signatures protecting quotes and RIMs must be checked before the 850 contents are used. 852 +---------------+ +-------------+ +---------+ 853 | | | | Step 1 | | 854 | | | Attester |<------>| Verifier| 855 | Asserter | | (Device |<------>| (Network| 856 |(Configuration |------->| under | Step 2 | Mngmt | 857 | Authority) | Step 0A| attestation)| | Station)| 858 | | | |------->| | 859 +---------------+ +-------------+ Step 3 +---------+ 860 | /|\ 861 | | 862 ---------------------------------------------- 863 Step 0B 865 Figure 4: RIV Protocol and Encoding Summary 867 Either CoSWID-encoded reference measurements are signed by a trusted 868 authority and retrieved directly prior to attestation (as shown in 869 Step 0A), or CoSWID-encoded reference measurements are signed by the 870 device manufacturer, installed on the device by a proprietary 871 installer, and delivered during attestation (as shown in Step 0B). 872 In Step 1, the Verifier initiates a connection for attestation. The 873 Attester's identity is validated using DevID with TLS. In Step 2, a 874 nonce, quotes (measured values) and measurement log are conveyed via 875 TAP with a protocol-specific binding (e.g. SNMP). Logs are sent in 876 the Canonical Log Format In Step 3, CoSWID-encoded reference 877 measurements are retrieved from the Attester using the YANG 878 ([I-D.birkholz-yang-swid]. . 880 The following components are used: 882 1. TPM Keys are configured according to [Platform-DevID-TPM-2.0], 883 [PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2] 885 2. Measurements of bootable modules are taken according to TCG PC 886 Client [PC-Client-BIOS-TPM-2.0] and Linux IMA [IMA] 888 3. Device Identity is managed by IEEE 802.1AR certificates 889 [IEEE-802-1AR], with keys protected by TPMs. 891 4. Quotes are retrieved according to TCG TAP Information Model [TAP] 893 5. Reference Integrity Measurements are encoded as CoSWID tags, as 894 defined in the TCG RIM document [RIM], compatible with NIST IR 895 8060 [NIST-IR-8060] and the IETF CoSWID draft 896 [I-D.ietf-sacm-coswid]. Reference measurements are signed by the 897 device manufacturer. 899 3.3. Layering Model for Network Equipment Attester and Verifier 901 Retrieval of identity and attestation state uses one protocol stack, 902 while retrieval of Reference Measurements uses a different set of 903 protocols. Figure 5 shows the components involved. 905 +-----------------------+ +-------------------------+ 906 | | | | 907 | Attester |<-------------| Verifier | 908 | (Device) |------------->| (Management Station) | 909 | | | | | 910 +-----------------------+ | +-------------------------+ 911 | 912 -------------------- -------------------- 913 | | 914 ---------------------------------- --------------------------------- 915 |Reference Integrity Measurements| | Attestation | 916 ---------------------------------- --------------------------------- 918 ******************************************************************** 919 * IETF Attestation Reference Interaction Diagram * 920 ******************************************************************** 922 ....................... ....................... 923 . Reference Integrity . . TAP (PTS2.0) Info . 924 . Manifest . . Model and Canonical . 925 . . . Log Format . 926 ....................... ....................... 928 ************************* .............. ********************** 929 * YANG SWID Module * . TCG . * YANG Attestation * 930 * I-D.birkholz-yang-swid* . Attestation. * Module * 931 * * . MIB . * I-D.birkholz-yang- * 932 * * . . * basic-remote- * 933 * * . . * attestation * 934 ************************* .............. ********************** 936 ************************* ************ ************************ 937 * XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)* 938 ************************* ************ ************************ 940 ************************* ************************ 941 * RESTCONF/NETCONF * * RESTCONF/NETCONF * 942 ************************ ************************* 944 ************************* ************************ 945 * TLS, SSH * * TLS, SSH * 946 ************************* ************************ 948 Figure 5: RIV Protocol Stacks 950 IETF documents are captured in boxes surrounded by asterisks. TCG 951 documents are shown in boxes surrounded by dots. The IETF 952 Attestation Reference Interaction Diagram, Reference Integrity 953 Manifest, TAP Information Model and Canonical Log Format, and both 954 YANG modules are works in progress. Information Model layers 955 describe abstract data objects that can be requested, and the 956 corresponding response SNMP is still widely used, but the industry is 957 transitioning to YANG, so in some cases, both will be required. TLS 958 Authentication with TPM has been shown to work; SSH authentication 959 using TPM-protected keys is not as easily done [as of 2019] 961 4. Privacy Considerations 963 Networking Equipment such as routers, switches and firewalls has a 964 key role to play in guarding the privacy of individuals using the 965 network: * Packets passing through the device must not be sent to 966 unauthorized destinations. For example * Routers often act as Policy 967 Enforcement Points, where individual subscribers may be checked for 968 authorization to access a network. Subscriber login information must 969 not be released to unauthorized parties. * Networking Equipment is 970 often called upon to block access to protected resources, or from 971 unauthorized users. * Routing information, such as the identity of a 972 router's peers, must not be leaked to unauthorized neighbors. * If 973 configured, encryption and decryption of traffic must be carried out 974 reliably, while protecting keys and credentials. Functions that 975 protect privacy are implemented as part of each layer of hardware and 976 software that makes up the networking device. In light of these 977 requirements for protecting the privacy of users of the network, the 978 Network Equipment must identify itself, and its boot configuration 979 and measured device state (for example, PCR values), to the 980 Equipment's Administrator, so there's no uncertainty as to what 981 function each device and configuration is configured to carry out . 982 This allows the administrator to ensure that the network provides 983 individual and peer privacy guarantees. 985 RIV specifically addresses the collection information from enterprise 986 network devices by an enterprise network. As such, privacy is a 987 fundamental concern for those deploying this solution, given EU GDPR, 988 California CCPA, and many other privacy regulations. The enterprise 989 should implement and enforce their duty of care. 991 See [NetEq] for more context on privacy in networking devices 993 5. Security Considerations 995 Attestation results from the RIV procedure are subject to a number of 996 attacks: 998 o Keys may be compromised 999 o A counterfeit device may attempt to impersonate (spoof) a known 1000 authentic device 1002 o Man-in-the-middle attacks may be used by a counterfeit device to 1003 attempt to deliver responses that originate in an actual authentic 1004 device *Replay attacks may be attempted by a compromised device 1006 Trustworthiness of RIV attestation depends strongly on the validity 1007 of keys used for identity and attestation reports. RIV takes full 1008 advantage of TPM capabilities to ensure that results can be trusted. 1010 Two sets of keys are relevant to RIV attestation 1012 o A DevID key is used to certify the identity of the device in which 1013 the TPM is installed. 1015 o An Attestation Key (AK) key signs attestation reports, (called 1016 'quotes' in TCG documents), used to provide evidence for integrity 1017 of the software on the device. 1019 TPM practices require that these keys be different, as a way of 1020 ensuring that a general-purpose signing key cannot be used to spoof 1021 an attestation quote. 1023 In each case, the private half of the key is known only to the TPM, 1024 and cannot be retrieved externally, even by a trusted party. To 1025 ensure that's the case, specification-compliant private/public key- 1026 pairs are generated inside the TPM, where they're never exposed, and 1027 cannot be extracted (See [Platform-DevID-TPM-2.0]). 1029 Keeping keys safe is just part of attestation security; knowing which 1030 keys are bound to the device in question is just as important. 1032 While there are many ways to manage keys in a TPM (See 1033 [Platform-DevID-TPM-2.0]), RIV includes support for "zero touch" 1034 provisioning (also known as zero-touch onboarding) of fielded devices 1035 (e.g. Secure ZTP, [RFC8572]}), where keys which have predictable 1036 trust properties are provisioned by the device vendor. 1038 Device identity in RIV is based on IEEE 802.1AR DevID. This 1039 specification provides several elements 1041 o A DevID requires a unique key pair for each device, accompanied by 1042 an x.509 certificate 1044 o The private portion of the DevID key is to be stored in the 1045 device, in a manner that provides confidentiality (Section 6.2.5 1046 [IEEE-802-1AR]) 1048 The x.509 certificate contains several components 1050 o The public part of the unique DevID key assigned to that device 1052 o An identifying string that's unique to the manufacturer of the 1053 device. This is normally the serial number of the unit, which 1054 might also be printed on label on the device. 1056 o The certificate must be signed by a key traceable to the 1057 manufacturer's root key. 1059 With these elements, the device's manufacturer and serial number can 1060 be identified by analyzing the DevID certificate plus the chain of 1061 intermediate certs leading back to the manufacturer's root 1062 certificate. As is conventional in TLS connections, a nonce must be 1063 signed by the device in response to a challenge, proving posession of 1064 its DevID private key. 1066 RIV uses the DevID to validate a TLS connection to the device as the 1067 attestation session begins. Security of this process derives from 1068 TLS security, with the DevID providing proof that the TLS session 1069 terminates on the intended device. [RFC8446]. 1071 Evidence of software integrity is delivered in the form of a quote 1072 signed by the TPM itself. Because the contents of the quote are 1073 signed inside the TPM, any external modification (including 1074 reformatting to a different data format) will be detected as 1075 tampering. 1077 To prevent spoofing, the quote generated inside the TPM must by 1078 signed by a key that's different from the DevID, called an 1079 Attestation Key (AK). But the binding between the AK and the same 1080 device must also be proven to prevent a man-in-the-middle attack 1081 (e.g. the 'Asokan Attack' [RFC6813]). 1083 This is accomplished in RIV through use of an AK certificate with the 1084 same elements as the DevID (i.e., same manufacturer's serial number, 1085 signed by the same manufacturer's key), but containing the device's 1086 unique AK public key instead of the DevID public key. [this will 1087 require an OID that says the key is known by the CA to be an 1088 Attestation key] 1090 These two keys and certificates are used together: 1092 o The DevID is used to validate a TLS connection terminating on the 1093 device with a known serial number. 1095 o The AK is used to sign attestation quotes, providing proof that 1096 the attestation evidence comes from the same device. 1098 Replay attacks, where results of a previous attestation are submitted 1099 in response to subsequent requests, are usually prevented by 1100 inclusion of a nonce in the request to the TPM for a quote. Each 1101 request from the Verifier includes a new random number (a nonce). 1102 The resulting quote signed by the TPM contains the same nonce, 1103 allowing the verifier to determine freshness, i.e., that the 1104 resulting quote was generated in response to the verifier's specific 1105 request. 1106 Time-Based Uni-directional Attestation [I-D.birkholz-rats-tuda] 1107 provides an alternate mechanism to verify freshness without requiring 1108 a request/response cycle. 1110 Requiring results of attestation of the operating software to be 1111 signed by a key known only to the TPM also removes the need to trust 1112 the device's operating software (beyond the first measurement; see 1113 below); any changes to the quote, generated and signed by the TPM 1114 itself, made by malicious device software, or in the path back to the 1115 verifier, will invalidate the signature on the quote. 1117 Although RIV recommends that device manufacturers pre-provision 1118 devices with easily-verified DevID and AK certs, use of those 1119 credentials is not mandatory. IEEE 802.1AR incorporates the idea of 1120 an Initial Device ID (IDevID), provisioned by the manufacturer, and a 1121 Local Device ID (LDevID) provisioned by the owner of the device. RIV 1122 extends that concept by defining an Initial Attestation Key (IAK) and 1123 Local Attestation Key (LAK) with the same properties. 1125 Device owners can use any method to provision the Local credentials. 1127 o TCG doc [Platform-DevID-TPM-2.0] shows how the initial Attestation 1128 keys can be used to certify LDevID and LAK keys. Use of the 1129 LDevID and LAK allows the device owner to use a uniform identity 1130 structure across device types from multiple manufacturers (in the 1131 same way that an "Asset Tag" is used by many enterprises use to 1132 identify devices they own). TCG doc [Provisioning-TPM-2.0] also 1133 contains guidance on provisioning identity keys in TPM 2.0. 1135 o But device owners can use any other mechanism they want to assure 1136 themselves that Local identity certificates are inserted into the 1137 intended device, including physical inspection and programming in 1138 a secure location, if they prefer to avoid placing trust in the 1139 manufacturer-provided keys. 1141 Clearly, Local keys can't be used for secure Zero Touch provisioning; 1142 installation of the Local keys can only be done by some process that 1143 runs before the device is configured for network operation. 1145 On the other end of the device life cycle, provision should be made 1146 to wipe Local keys when a device is decommissioned, to indicate that 1147 the device is no longer owned by the enterprise. The manufacturer's 1148 Initial identity keys must be preserved, as they contain no 1149 information that's not already printed on the device's serial number 1150 plate. 1152 In addition to trustworthy provisioning of keys, RIV depends on other 1153 trust anchors. (See [GloPlaRoT] for definitions of Roots of Trust.) 1155 o Secure identity depends on mechanisms to prevent per-device secret 1156 keys from being compromised. The TPM provides this capability as 1157 a Root of Trust for Storage 1159 o Attestation depends on an unbroken chain of measurements, starting 1160 from the very first measurement. 1161 That first measurement is made by code called the Root of Trust 1162 for Measurement, typically done by trusted firmware stored in boot 1163 flash. Mechanisms for maintaining the trustworthiness of the RTM 1164 are out of scope for RIV, but could include immutable firmware, 1165 signed updates, or a vendor-specific hardware verification 1166 technique. 1168 o RIV assumes some level of physical defense for the device. If a 1169 TPM that has already been programmed with an authentic DevID is 1170 stolen and inserted into a counterfeit device, attestation of that 1171 counterfeit device may become indistinguishable from an authentic 1172 device. 1174 RIV also depends on reliable reference measurements, as expressed by 1175 the RIM [RIM]. The definition of trust procedures for RIMs is out of 1176 scope for RIV, and the device owner is free to use any policy to 1177 validate a set of reference measurements. RIMs may be conveyed out- 1178 of-band or in-band, as part of the attestation process (see 1179 Section 3.2). But for embedded devices, where software is usually 1180 shipped as a self-contained package, RIMs signed by the manufacturer 1181 and delivered in-band may be more convenient for the device owner. 1183 6. Conclusion 1185 TCG technologies can play an important part in the implementation of 1186 Remote Integrity Verification. Standards for many of the components 1187 needed for implementation of RIV already exist: 1189 o Platform identity can be based on IEEE 802.1AR Device identity, 1190 coupled with careful supply-chain management by the manufacturer. 1192 o Complex supply chains can be certified using TCG Platform 1193 Certificates [Platform-Certificates] 1195 o The TCG TAP mechanism can be used to retrieve attestation 1196 evidence. Work is needed on a YANG model for this protocol. 1198 o Reference Measurements must be conveyed from the software 1199 authority (e.g., the manufacturer) to the system in which 1200 verification will take place. IETF CoSWID work forms the basis 1201 for this, but new work is needed to create an information model 1202 and YANG implementation. 1204 Gaps still exist for implementation in Network Equipment (as of May 1205 2019): 1207 o Coordination of YANG model development with the IETF is still 1208 needed 1210 o Specifications for management of signed Reference Integrity 1211 Manifests must still be completed 1213 7. Appendix 1215 7.1. Implementation Notes 1217 Table 1 summarizes many of the actions needed to complete an 1218 Attestation system, with links to relevant documents. While 1219 documents are controlled by a number of standards organizations, the 1220 implied actions required for implementation are all the 1221 responsibility of the manufacturer of the device, unless otherwise 1222 noted. 1224 +------------------------------------------------------------------+ 1225 | Component | Controlling | 1226 | | Specification | 1227 -------------------------------------------------------------------- 1228 | Make a Secure execution environment | TCG RoT | 1229 | o Attestation depends on a secure root of | UEFI.org | 1230 | trust for measurement outside the TPM, as | | 1231 | well as roots for storage amd reporting | | 1232 | inside the TPM. | | 1233 | o Refer to TCG Root of Trust for Measurement.| | 1234 | o NIST SP 800-193 also provides guidelines | | 1235 | on Roots of Trust | | 1236 -------------------------------------------------------------------- 1237 | Provision the TPM as described in | TCG TPM DevID | 1238 | TCG documents. | TCG Platform | 1239 | | Certificate | 1240 -------------------------------------------------------------------- 1241 | Put a DevID or Platform Cert in the TPM | TCG TPM DevID | 1242 | o Install an Initial Attestation Key at the | TCG Platform | 1243 | same time so that Attestation can work out | Certificate | 1244 | of the box |----------------- 1245 | o Equipment suppliers and owners may want to | IEEE 802.1AR | 1246 | implement Local Device ID as well as | | 1247 | Initial Device ID | | 1248 -------------------------------------------------------------------- 1249 | Connect the TPM to the TLS stack | Vendor TLS | 1250 | o Use the DevID in the TPM to authenticate | stack (This | 1251 | TAP connections, identifying the device | action is | 1252 | | simply | 1253 | | configuring TLS| 1254 | | to use the | 1255 | | DevID as its | 1256 | | trust anchor.) | 1257 -------------------------------------------------------------------- 1258 | Make CoSWID tags for BIOS/LoaderLKernel objects | IETF CoSWID | 1259 | o Add reference measurements into SWID tags | ISO/IEC 19770-2| 1260 | o Manufacturer should sign the SWID tags | NIST IR 8060 | 1261 | o This should be covered in a new TCG | TagVault SWID | 1262 | Reference Integrity Manifest document | Tag Signing | 1263 | - IWG should define the literal SWID | Guidance | 1264 | format |----------------- 1265 | - IWG should evaluate whether IETF SUIT | TCG RIM | 1266 | is a suitable manifest when multiple | | 1267 | SWID tags are involved | | 1268 | - There could be a proof-of-concept | | 1269 | project to actually make sample SWID | | 1270 | tags (a gap might appear in the | | 1271 | process) | | 1272 -------------------------------------------------------------------- 1273 | Package the SWID tags with a vendor software | There is no | 1274 | release | need to specify| 1275 | o A tag-generator plugin could help | where the tags | 1276 | (i.e., a plugin for common development | are stored in a| 1277 | environments. NIST has something that | vendor OS, as | 1278 | plugs into Maven Build Environment) | long as there | 1279 | | is a standards-| 1280 | | based mechanism| 1281 | | to retrieve | 1282 | | them. | 1283 | |----------------- 1284 | | TCG RIM | 1285 -------------------------------------------------------------------- 1286 | BIOS SWIDs might be hard to manage on an OS | | 1287 | disk-- maybe keep them in the BIOS flash? | TCG RIM | 1288 | o Maybe a UEFI Var? Would its name have to be| | 1289 | specified by UEFI.org? | | 1290 | o How big is a BIOS SWID tag? Do we need to | | 1291 | use a tag ID instead of an actual tag? | | 1292 | o Note that the presence of Option ROMs turns | | 1293 | the BIOS reference measurements into a | | 1294 | multi-vendor interoperability problem | | 1295 -------------------------------------------------------------------- 1296 | Use PC Client measurement definitions as a | TCG PC Client | 1297 | starting point to define the use of PCRs | BIOS | 1298 | (although Windows OS is rare on Networking |----------------- 1299 | Equipment) | There have been| 1300 | | proposals for | 1301 | | non-PC-Client | 1302 | | allocation of | 1303 | | PCRs, although | 1304 | | no specific | 1305 | | document exists| 1306 | | yet. | 1307 -------------------------------------------------------------------- 1308 | Use TAP to retrieve measurements | | 1309 | o Map TAP to SNMP | TCG SNMP MIB | 1310 | o Map to YANG | YANG Module for| 1311 | o Complete Canonical Log Format | Basic | 1312 | | Attestation | 1313 | | TCG Canonical | 1314 | | Log Format | 1315 -------------------------------------------------------------------- 1316 | Posture Collection Server (as described in IETF | | 1317 | SACMs ECP) would have to request the | | 1318 | attestation and analyze the result | | 1319 | The Management application might be broken down | | 1320 | to several more components: | | 1321 | o A Posture Manager Server | | 1322 | which collects reports and stores them in | | 1323 | a database | | 1324 | o One or more Analyzers that can look at the| | 1325 | results and figure out what it means. | | 1326 -------------------------------------------------------------------- 1328 Figure 6: Component Status 1330 7.2. Comparison with TCG PTS / IETF NEA 1332 Some components of an Attestation system have been implemented for 1333 end-user machines such as PCs and laptops. Figure 7 shows the 1334 corresponding protocol stacks. 1336 +-----------------------+ +-------------------------+ 1337 | | | | 1338 | Attester |<-------------| Verifier | 1339 | (Device) |------------->| (Management Station) | 1340 | | | | | 1341 +-----------------------+ | +-------------------------+ 1342 | 1343 -------------------- -------------------- 1344 | | 1345 ---------------------------------- --------------------------------- 1346 |Reference Integrity Measurements| | Attestation | 1347 ---------------------------------- --------------------------------- 1349 -------------------------------------------------------------------- 1350 | IETF Attestation Reference Interaction Diagram | 1351 ------------------------------------------------------------------- 1353 ....................... -------------------------------- 1354 . No Existing . | TAPS (PTS2.0) Info Model and| 1355 . Reference Integrity . | Canonical Log Format | 1356 . Manifest . | | 1357 . Protocols Exist . -------------------------------- 1358 . . 1359 . . ---------------------- ---------- 1360 . . | YANG Attestation | |IETF NEA| 1361 . . | Module | | Msg and| 1362 . . | I-D.birkholz-yang- | | Attrib.| 1363 . . | basic-remote- | | for PA-| 1364 . . | attestation | | TNC | 1365 . . ---------------------- ---------- 1366 . . ---------------------- ---------- 1367 . . | XML, JSON, CBOR | | PT-TLS | 1368 . . ---------------------- | (for | 1369 . . ---------------------- |endpoint| 1370 . . | NETCONF, RESTCONF, | |mcahines| 1371 . . | COAP | | | 1372 ....................... ---------------------- ---------- 1373 ---------------------------------------------------------------- 1374 | TLS, SSH | 1375 ---------------------------------------------------------------- 1377 Figure 7: Attestation for End User Computers 1379 8. IANA Considerations 1381 This memo includes no request to IANA. 1383 9. Informative References 1385 [AIK-Enrollment] 1386 Trusted Computing Group, "TCG Infrastructure Working 1387 GroupA CMC Profile for AIK Certificate Enrollment Version 1388 1.0, Revision 7", March 2011, 1389 . 1392 [Canonical-Event-Log] 1393 Trusted Computing Group, "DRAFT Canonical Event Log Format 1394 Version: 1.0, Revision: .12", October 2018. 1396 [EFI] Trusted Computing Group, "TCG EFI Platform Specification 1397 for TPM Family 1.1 or 1.2, Specification Version 1.22, 1398 Revision 15", January 2014, 1399 . 1402 [GloPlaRoT] 1403 GlobalPlatform Technology, "Root of Trust Definitions and 1404 Requirements Version 1.1", June 2018, 1405 . 1408 [I-D.birkholz-rats-architecture] 1409 Birkholz, H., Wiseman, M., Tschofenig, H., and N. Smith, 1410 "Remote Attestation Procedures Architecture", draft- 1411 birkholz-rats-architecture-02 (work in progress), 1412 September 2019. 1414 [I-D.birkholz-rats-reference-interaction-model] 1415 Birkholz, H. and M. Eckel, "Reference Interaction Model 1416 for Challenge-Response-based Remote Attestation", draft- 1417 birkholz-rats-reference-interaction-model-01 (work in 1418 progress), July 2019. 1420 [I-D.birkholz-rats-tuda] 1421 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 1422 "Time-Based Uni-Directional Attestation", draft-birkholz- 1423 rats-tuda-01 (work in progress), September 2019. 1425 [I-D.birkholz-suit-coswid-manifest] 1426 Birkholz, H., "A SUIT Manifest Extension for Concise 1427 Software Identifiers", draft-birkholz-suit-coswid- 1428 manifest-00 (work in progress), July 2018. 1430 [I-D.birkholz-yang-basic-remote-attestation] 1431 Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit, 1432 E., and G. Fedorkow, "YANG Module for Basic Challenge- 1433 Response-based Remote Attestation Procedures", draft- 1434 birkholz-yang-basic-remote-attestation-01 (work in 1435 progress), October 2018. 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-sacm-coswid] 1443 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 1444 Waltermire, "Concise Software Identification Tags", draft- 1445 ietf-sacm-coswid-12 (work in progress), July 2019. 1447 [IEEE-802-1AR] 1448 Seaman, M., "802.1AR-2018 - IEEE Standard for Local and 1449 Metropolitan Area Networks - Secure Device Identity, IEEE 1450 Computer Society", August 2018. 1452 [IMA] and , "Integrity Measurement Architecture", June 2019, 1453 . 1455 [NetEq] Trusted Computing Group, "TCG Guidance for Securing 1456 Network Equipment", January 2018, 1457 . 1460 [NIST-IR-8060] 1461 National Institute for Standards and Technology, 1462 "Guidelines for the Creation of Interoperable Software 1463 Identification (SWID) Tags", April 2016, 1464 . 1467 [NIST-SP-800-155] 1468 National Institute for Standards and Technology, "BIOS 1469 Integrity Measurement Guidelines (Draft)", December 2011, 1470 . 1473 [PC-Client-BIOS-TPM-1.2] 1474 Trusted Computing Group, "TCG PC Client Specific 1475 Implementation Specification for Conventional BIOS, 1476 Specification Version 1.21 Errata, Revision 1.00", 1477 February 2012, . 1480 [PC-Client-BIOS-TPM-2.0] 1481 Trusted Computing Group, "PC Client Specific Platform 1482 Firmware Profile Specification Family "2.0", Level 00 1483 Revision 1.04", June 2019, 1484 . 1487 [Platform-Certificates] 1488 Trusted Computing Group, "DRAFT: TCG Platform Attribute 1489 Credential Profile, Specification Version 1.0, Revision 1490 15, 07 December 2017", December 2017. 1492 [Platform-DevID-TPM-2.0] 1493 Trusted Computing Group, "DRAFT: TPM Keys for Platform 1494 DevID for TPM2, Specification Version 0.7, Revision 0", 1495 October 2018. 1497 [Platform-ID-TPM-1.2] 1498 Trusted Computing Group, "TPM Keys for Platform Identity 1499 for TPM 1.2, Specification Version 1.0, Revision 3", 1500 August 2015, . 1504 [Provisioning-TPM-2.0] 1505 Trusted Computing Group, "TCG TPM v2.0 Provisioning 1506 Guidance", March 2015, . 1510 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 1511 Management Protocol (SNMP) Applications", STD 62, 1512 RFC 3413, DOI 10.17487/RFC3413, December 2002, 1513 . 1515 [RFC6813] Salowey, J. and S. Hanna, "The Network Endpoint Assessment 1516 (NEA) Asokan Attack Analysis", RFC 6813, 1517 DOI 10.17487/RFC6813, December 2012, 1518 . 1520 [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A 1521 YANG Data Model for Hardware Management", RFC 8348, 1522 DOI 10.17487/RFC8348, March 2018, 1523 . 1525 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1526 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1527 . 1529 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1530 Touch Provisioning (SZTP)", RFC 8572, 1531 DOI 10.17487/RFC8572, April 2019, 1532 . 1534 [RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity 1535 Manifest", June 2019. 1537 [SNMP-Attestation-MIB] 1538 Trusted Computing Group, "DRAFT: SNMP MIB for TPM-Based 1539 Attestation, Specification Version 0.8, Revision 0.02", 1540 May 2018. 1542 [SWID] The International Organization for Standardization/ 1543 International Electrotechnical Commission, "Information 1544 Technology Software Asset Management Part 2: Software 1545 Identification Tag, ISO/IEC 19770-2", October 2015, 1546 . 1548 [TAP] Trusted Computing Group, "DRAFT: TCG Trusted Attestation 1549 Protocol (TAP) Information Model for TPM Families 1.2 and 1550 2.0 and DICE Family 1.0, Version 1.0, Revision 0.29", 1551 October 2018. 1553 [TCGRoT] Trusted Computing Group, "TCG Roots of Trust 1554 Specification", October 2018, 1555 . 1558 Authors' Addresses 1560 Guy Fedorkow (editor) 1561 Juniper Networks, Inc. 1562 US 1564 Email: gfedorkow@juniper.net 1565 Jessica Fitzgerald-McKay 1566 National Security Agency 1567 US 1569 Email: jmfitz2@nsa.gov