idnits 2.17.00 (12 Aug 2021) /tmp/idnits5732/draft-fedorkow-rats-network-device-attestation-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 30, 2019) is 1055 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Firmware-Profile' is defined on line 1146, but no explicit reference was found in the text == Unused Reference: 'RFC7049' is defined on line 1249, but no explicit reference was found in the text == Unused Reference: 'RFC8348' is defined on line 1257, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-birkholz-rats-architecture-01 == Outdated reference: A later version (-03) exists of draft-birkholz-rats-reference-interaction-model-00 == Outdated reference: A later version (-21) exists of draft-ietf-sacm-coswid-11 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group G. Fedorkow, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Informational J. Fitzgerald-McKay 5 Expires: January 1, 2020 National Security Agency 6 June 30, 2019 8 Network Device Attestation Workflow 9 draft-fedorkow-rats-network-device-attestation-00 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 January 1, 2020. 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 . . . . . . . . . . . . . . . . . . 3 51 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.3. Problem Description . . . . . . . . . . . . . . . . . . . 4 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? . . . . . . . . . . 9 59 2. Solution Outline . . . . . . . . . . . . . . . . . . . . . . 10 60 2.1. 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 Measurements (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. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 5. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 5.1. Implementation Notes . . . . . . . . . . . . . . . . . . 22 79 5.2. Comparison with TCG PTS / IETF NEA . . . . . . . . . . . 24 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 82 8. Informative References . . . . . . . . . . . . . . . . . . . 26 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 85 1. Introduction 87 There are many components to consider in fielding a trusted computing 88 device, from operating systems to applications. Part of that is a 89 trusted supply chain, where manufacturers can certify that the 90 product they intended to build is actually the one that was installed 91 at a customer's site. 93 Attestation is defined here as the process of creating, conveying and 94 appraising assertions about Platform trustworthiness characteristics, 95 including Roots of Trust, supply chain trust, identity, platform 96 provenance, shielded locations, protected capabilities, software 97 configuration, hardware configuration, platform composition, 98 compliance to test suites, functional and assurance evaluations, etc. 100 The supply chain itself has many elements, from validating suppliers 101 of electronic components, to ensuring that shipping procedures 102 protect against tampering through many stages of distribution and 103 warehousing. One element that helps maintain the integrity of the 104 supply chain after manufacturing is Attestation. 106 Within the Trusted Computing Group context, attestation is the 107 process by which an independent Verifier can obtain cryptographic 108 proof as to the identity of the device in question, evidence of the 109 integrity of software loaded on that device when it started up, and 110 then verify that what's there is what's supposed to be there. For 111 networking equipment, a verifier capability can be embedded in a 112 Network Management Station (NMS), a posture collection server, or 113 other network analytics tool (such as a software asset management 114 solution, or a threat detection and mitigation tool, etc.). While 115 informally referred to as attestation, this document focuses on a 116 subset defined here as Remote Integrity Verification (RIV). RIV 117 takes a network equipment centric perspective that includes a set of 118 protocols and procedures for determining whether a particular device 119 was launched with untampered software, starting from Roots of Trust. 120 While there are many ways to accomplish attestation, RIV sets out a 121 specific set of protocols and tools that work in environments 122 commonly found in Networking Equipment. RIV does not cover other 123 platform characteristics that could be attested, although it does 124 provide evidence of a secure infrastructure to increase the level of 125 trust in other platform characteristics attested by other means. 127 This profile outlines the RIV problem, and then identifies components 128 that are necessary to get the complete attestation procedure working 129 in a scalable solution using commercial products. 131 This document focuses primarily on software integrity verification 132 using the Trusted Platform Module (TPM) as a root of trust. 134 1.1. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in 139 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 1.2. Goals 144 The RIV attestation workflow outlined in this document is intended to 145 meet the following high-level goals: 147 o Provable Device Identity - The ability to identify a device using 148 a cryptographic identifier is a critical prerequisite to software 149 inventory attestation. 151 o Software Inventory - A key goal is to identify the software 152 release installed on the device, and to provide evidence of its 153 integrity. 155 o Verification - Verification of software and configuration of the 156 device shows that the software that's supposed to be installed on 157 there actually has been launched, without unauthorized 158 modification. 160 This document itself is non-normative; the document does not define 161 protocols, but rather identifies protocols that can be used together 162 to achieve the goals above, and in some cases, highlights gaps in 163 existing protocols. 165 1.3. Problem Description 167 RIV is a procedure that assures a network operator that the equipment 168 on their network can be reliably identified, and that untampered 169 software of a known version is installed on each endpoint. In this 170 context, endpoint might include the conventional endpoints like 171 servers and laptops, but also network equipment itself, such as 172 routers, switches and firewalls. 174 RIV can be viewed as a link in a trusted supply chain, and includes 175 three major processes: 177 o Creation of Evidence is the process whereby an endpoint generates 178 cryptographic proof (evidence) of claims about platform 179 properties. In particular, the platform identity and its software 180 configuration are of critical importance. 182 * Platform Identity refers to the mechanism assuring the 183 attestation verifier (typically a network administrator) 184 that the equipment on their network can be reliably identified, 185 and that its manufacturer is certified by a trusted authority. 186 This certification provides the verifier with assurance that 187 the Root of Trust elements of the device were verified by the 188 manufacturer before the device was shipped. 190 * Software used to boot a platform can be described as a chain 191 of measurements, starting from a Root of Trust for Measurement, 192 that normally ends when the system software is loaded. 193 Measurement records the identity, integrity and version of each 194 software component registered with the TPM, so that the 195 subsequent appraisal stage can determine whether the software 196 installed is authentic and free of tampering. Clearly the second 197 part of the problem, attesting the state of mutable components 198 of a given device, is of little value without the first part, 199 reliable identification of the device in question. By the 200 same token, unambiguous identity of a device is necessary, 201 but is insufficient to assure the operator of the provenance 202 of the device through the supply chain, or that the device is 203 configured to behave properly. 205 o Conveyance of Evidence is the process of reliably transporting 206 evidence from an endpoint to an appraiser/verifier, e.g. a 207 management station. The transport is typically carried out via a 208 management network. The channel must provide integrity and 209 authenticity, and, in some use cases, may also require 210 confidentiality. 212 o Appraisal of Evidence is the process of verifying the evidence 213 received by a verifier/appraiser from a device, and using verified 214 evidence to inform decision making. In this context, verification 215 means comparing the device characteristics reported as evidence 216 with the configuration expected by the system administrator. This 217 step can work only when there is a way to express what should be 218 there, often referred to as golden measurements, or Reference 219 Integrity Measurements, representing the intended configured state 220 of an endpoint. 222 As a part of a trusted supply chain, RIV attestation provides two 223 important benefits: 225 o Platform Identity is the mechanism providing trusted identity can 226 reassure network managers that the specific devices they ordered 227 from authorized manufacturers for attachment to their network are 228 the ones that were installed, and that they continue to be present 229 in their network. As part of the mechanism for Platform Identity, 230 cryptographic proof of the identity of the manufacturer is also 231 provided. 233 o Software Configuration is the mechanism that reports the state of 234 mutable components on the device can assure network managers that 235 they have known, untampered software configured to run in their 236 network. 238 An implementation of RIV requires three technologies 240 1. Identity: Platform identity can be based on IEEE 802.1AR Device 241 Identity [IEEE-802-1AR], coupled with careful supply-chain 242 management by the manufacturer. The DevID certificate contains a 243 statement by the manufacturer that establishes the provenance of 244 the device as it left the factory. Some applications with a 245 more-complex post-manufacture supply chain (e.g. Value Added 246 Resellers), or with privacy concerns, may want to use an 247 alternate mechanism for platform authentication based on TCG 248 Platform Certificates [Platform-Certificates]. 250 2. Platform Attestation provides evidence of configuration of 251 software elements throughout the product lifecycle. This form of 252 attestation can be implemented with TPM PCR, Quote and log 253 mechanisms, which provide an authenticated mechanism to report 254 what software actually starts up on the device each time it 255 reboots. Note that the TPM requires separate keys for identity 256 DevID) and attestation (PCR Quotes0) (see Section 2.2). 258 3. Reference Integrity Measurements must be conveyed from the 259 software authority (often the manufacturer for embedded systems) 260 to the system in which verification will take place 262 Network operators benefit from a trustworthy attestation mechanism 263 that provides assurance that their comprises authentic equipment, and 264 has loaded software free of known vulnerabilities and unauthorized 265 tampering. 267 1.4. Solution Requirements 269 An Attestation solution must meet a number of requirements to make it 270 simple to deploy at scale. 272 1. Easy to Use - This solution should work "out of the box" as far 273 as possible, that is, with the fewest possible steps needed at 274 the end-user's site. Eliminate complicated databases or 275 provisioning steps that would have to be executed by the owner of 276 a new device. Network equipment is often required to "self- 277 configure", to reliably reach out without manual intervention to 278 prove its identity and operating posture, then download its own 279 configuration. See [RFC8572] for an example of Secure Zero Touch 280 Provisioning. 282 2. Multi-Vendor - This solution should identify standards-based 283 interfaces that allow attestation to work with attestation- 284 capable devices and verifiers supplied by different vendors in 285 one network. 287 3. Scalable - The solution must not depend on choke points that 288 limit the number of endpoints that could be evaluated in one 289 network domain. 291 4. Extensible - A network equipment attestation solution needs to 292 expand over time as new features are added. The solution must 293 allow new features to be added easily, providing for a smooth 294 transition and allowing newer and older architectural components 295 to continue to work together. Further, a network equipment 296 attestation solution and the specifications referenced here must 297 define safe extensibility mechanisms that enable innovation 298 without breaking interoperability. 300 5. Efficient - A network equipment attestation solution should, to 301 the greatest extent feasible, continuously monitor the health and 302 posture status of network devices. Posture measurements should 303 be updated in real-time as changes to device posture occur and 304 should be published to remote integrity validators. Validation 305 reports should also be shared with their relying parties (for 306 example, network administrators, or network analytics that rely 307 on these reports for posture assessment) as soon as they are 308 available. 310 1.5. Scope 312 This document includes a number of assumptions to limit the scope: 314 o This solution is for use in non-privacy-preserving applications 315 (for example, networking, Industrial IoT), avoiding the need for a 316 Privacy Certificate Authority for attestation keys 318 o This document applies primarily to "embedded" applications, where 319 the device manufacturer ships the software image for the device. 321 o The approach outlined in this document assumes a physical TPM. 323 1.5.1. Out of Scope 325 o Run-Time Attestation: Run-time attestation of Linux or other 326 multi-threaded operating system processes considerably expands the 327 scope of the problem. Many researchers are working on that 328 problem, but this document defers the run-time attestation 329 problem. 331 o Multi-Vendor Embedded Systems: Additional coordination would be 332 needed for devices that themselves comprise hardware and software 333 from multiple vendors, integrated by the end user. 335 o Processor Sleep Modes: Embedded equipment typically does not 336 "sleep", so sleep and hibernate modes are not considered. 338 o Virtualization and Containerization: These technologies are 339 increasingly used in embedded systems, but are not considered in 340 this revision of the document. 342 1.5.2. Why Remote Integrity Verification? 344 Remote Integrity Verification can go a long way to solving the "Lying 345 Endpoint" problem, in which malicious software on an endpoint may 346 both subvert the intended function, and also prevent the endpoint 347 from reporting its compromised status. Man-in-the Middle attacks are 348 also made more difficult through a strong focus on device identity 350 Attestation data can be used for asset management, vulnerability and 351 compliance assessment, plus configuration management. 353 1.5.3. Network Device Attestation Challenges 355 There have been demonstrations of attestation using TPMs for years, 356 accompanied by compelling security reasons for adopting attestation. 357 Despite this, the technology has not been widely adopted, in part, 358 due to the difficulties in deploying TPM-based attestation. Some of 359 those difficulties are: 361 o Standardizing device identity. Creating and using unique device 362 identifiers is difficult, especially in a privacy-sensitive 363 environment. But attestation is of limited value if the operator 364 is unable to determine which devices pass attestation validation 365 tests, and which fail. This problem is substantially simplified 366 for infrastructure devices like network equipment, where identity 367 can be explicitly coded using IEEE 802.1AR, but doing so relies on 368 adoption of 802.1AR [IEEE-802-1AR] by manufacturers and hardware 369 system integrators. 371 o Standardizing attestation representations and conveyance. 372 Interoperable remote attestation has a fundamental dependence on 373 vendors agreeing to a limited set of network protocols for 374 communicating attestation data. Network device vendors will be 375 slow to adopt the protocols necessary to implement remote 376 attestation without a fully-realized plan for deployment. 378 o Interoperability. Networking equipment operates in a 379 fundamentally multi-vendor environment, putting additional 380 emphasis on the need for standardized procedures and protocols. 382 o Attestation evidence is complex. Operating systems used in larger 383 embedded devices are often multi-threaded, so the order of 384 completion for individual processes is non-deterministic. While 385 the hash of a specific component is stable, once extended into a 386 PCR, the resulting values are dependent on the (non-deterministic) 387 ordering of events, so there will never be a single known-good 388 value for some PCRs. Careful analysis of event logs can provide 389 proof that the expected modules loaded, but it's much more 390 complicated than simply comparing hashes. 392 o Software configurations can have seemingly infinite variability. 393 This problem is nearly intractable on PC and Server equipment, 394 where end users have unending needs for customization and new 395 applications. However, embedded systems, like networking 396 equipment, are often simpler, in that there are fewer variations 397 and releases, with vendors typically offering fewer options for 398 mixing and matching. 400 o Software updates can be complex. Even the most organized network 401 operator may have many different releases in their network at any 402 given time, with the result that there's never a single digest or 403 fingerprint that indicates the software is "correct"; digests 404 formed by hashing software modules on a device can only show the 405 correct combination of versions for a specific device at a 406 specific time. 408 None of these issues are insurmountable, but together, they've made 409 deployment of attestation a major challenge. The intent of this 410 document is to outline an attestation profile that's simple enough to 411 deploy, while yielding enough security to be useful. 413 1.5.4. Why is OS Attestation Different? 415 Even in embedded systems, adding Attestation at the OS level (e.g. 416 Linux IMA, Integrity Measurement Architecture [IMA]) increases the 417 number of objects to be attested by one or two orders of magnitude, 418 involves software that's updated and changed frequently, and 419 introduces processes that complete in unpredictable order. 421 TCG and others (including the Linux community) are working on methods 422 and procedures for attesting the operating system and application 423 software, but standardization is still in process. 425 2. Solution Outline 427 2.1. 2.1 RIV Software Configuration Attestation using TPM 429 RIV Attestation is a process for determining the identity of software 430 running on a specifically-identified device. Remote Attestation is 431 broken into two phases, shown in Figure 1: 433 o During system startup, measurements (i.e., hashes computed as 434 fingerprints of files) are extended, or cryptographically folded, 435 into the TPM. Entries are also added to an informational log. 436 The measurement process generally follows the Chain of Trust model 437 used in Measured Boot, where each stage of the system measures the 438 next one before launching it. 440 o Once the device is running and has operational network 441 connectivity, a separate, trusted server (called a Verifier in 442 this document) can interrogate the network device to retrieve the 443 logs and a copy of the digests collected by hashing each software 444 object, signed by an attestation private key known only to the 445 TPM. 447 The result is that the Verifier can verify the device's identity by 448 checking the certificate corresponding to the TPM's attestation 449 private key, and can validate the software that was launched by 450 comparing digests in the log with known-good values, and verifying 451 their correctness by comparing with the signed digests from the TPM. 453 It should be noted that attestation and identity are inextricably 454 linked; signed evidence that a particular version of software was 455 loaded is of little value without cryptographic proof of the identity 456 of the device producing the evidence. 458 +-------------------------------------------------------+ 459 | +--------+ +--------+ +--------+ +---------+ | 460 | | BIOS |--->| Loader |-->| Kernel |--->|Userland | | 461 | +--------+ +--------+ +--------+ +---------+ | 462 | | | | | 463 | | | | | 464 | +------------+-----------+-+ | 465 | Step 1 | | 466 | V | 467 | +--------+ | 468 | | TPM | | 469 | +--------+ | 470 | Router | | 471 +--------------------------------|----------------------+ 472 | 473 | Step 2 474 | +-----------+ 475 +--->| Verifier | 476 +-----------+ 478 Reset---------------flow-of-time-during-boot--...-------> 480 In Step 1, measurements are "extended" into the TPM as processes 481 start. In Step 2, signed PCR digests are retreived from the TPM for 482 offbox analysis after the system is operational. 484 Figure 1: TCG Attestation Model 486 2.2. RIV Keying 488 TPM 1.2 and TPM 2.0 have a variety of rules separating the functions 489 of identity and attestation, allowing for use-cases where software 490 configuration must be attested, but privacy must be maintained. 492 To accommodate these rules in an environment where device privacy is 493 not normally a requirement, the TCG Guidance for Securing Network 494 Equipment [NetEq] suggests using separate keys for Identity (i.e., 495 DevID) and Attestation (i.e., signing a quote of the contents of the 496 PCRs). 498 In this case, the device manufacturer should provision an Initial 499 Attestation Key (IAK) and x.509 certificate that parallels the 500 IDevID, with the same device ID information as the IDevID certificate 501 (i.e., the same Subject Name and Subject Alt Name, even though the 502 key pairs are different). This allows a quote from the device, 503 signed by the IAK, to be linked directly to the device that provided 504 it, by examining the corresponding IAK certificate. 506 Inclusion of an IAK by a vendor does not preclude a mechanism whereby 507 an Administrator can define Local Attestation Keys (LAKs) if desired. 509 2.3. RIV Information Flow 511 RIV workflow for networking equipment is organized around a simple 512 use-case, where a network operator wishes to verify the integrity of 513 software installed in specific, fielded devices. This use-case 514 implies several components: 516 1. A Device (e.g. a router or other embedded device, also known as 517 an Attester) somewhere and the network operator wants to examine 518 its boot state. 520 2. A Verifier (which might be a network management station) 521 somewhere separate from the Device that will retrieve the 522 information and analyze it to pass judgement on the security 523 posture of the device. 525 3. A Relying Party, which has access to the Verifier to request 526 attestation and to act on results. 528 4. This document assumes that signed Reference Integrity 529 Measurements (RIMs) (aka "golden measurements") can either be 530 created by the device manufacturer and shipped along with the 531 device as part of its software image, or alternatively, could be 532 obtained a number of other ways (direct to the verifier from the 533 manufacturer, from a third party, from the owner's observation of 534 what's thought to be a "known good system", etc.). Retrieving 535 RIMs from the device itself allows attestation to be done in 536 systems which may not have access to the public internet, or by 537 other devices that are not management stations per-se (e.g., a 538 peer device). If reference measurements are obtained from 539 multiple sources, the Verifier may need to evaluate the relative 540 level of trust to be placed in each source in case of a 541 discrepancy. 543 These components are illustrated in Figure 2. 545 A more-detailed taxonomy of terms is given in [I-D.birkholz-rats- 546 architecture] 547 +---------------+ +-------------+ +---------+--------+ 548 | | | Attester | Step 1 | Verifier| | 549 | Asserter | | (Device |<-------| (Network| Relying| 550 | (Device | | under |------->| Mngmt | Party | 551 | Manufacturer | | attestation)| Step 2 | Station)| | 552 | or other | | | | | | 553 | authroity) | | | | | | 554 +---------------+ +-------------+ +---------+--------+ 555 | /\ 556 | Step 0 | 557 ----------------------------------------------- 559 In Step 0, The Asserter (the device manufacturer) provides a Software 560 Image accompanied by Reference Integrity Measurements (RIMs) to the 561 Attester (the device under attestation) signed by the asserter. In 562 Step 1, the Verifier (Network Management Station), on behalf of a 563 Relying Party, requests Identity, Measurement Values (and possibly 564 RIMs) from the Attester. In Step 2, the Attester responds to the 565 request by providing a DevID, Quotes (measured values), and 566 optionally RIMs, signed by the Attester. 568 Figure 2: RIV Reference Configuration for Network Equipment 570 See Section 3.1.1 for more narrowly defined terms related to 571 Attestation 573 2.4. RIV Simplifying Assumptions 575 This document makes the following simplifying assumptions to reduce 576 complexity: 578 o The product to be attested is shipped with an IEEE 802.1AR DevID 579 and an Initial Attestation Key (IAK) with certificate. The IAK 580 cert contains the same identity information as the DevID 581 (specifically, the same Subject Name and Subject Alt Name, signed 582 by the manufacturer), but it's a type of key that can be used to 583 sign a TPM Quote. This convention is described in TCG Guidance 584 for Securing Network Equipment [NetEq]. For network equipment, 585 which is generally non-privacy-sensitive, shipping a device with 586 both an IDevID and an IAK already provisioned substantially 587 simplifies initial startup. Privacy-sensitive applications may 588 use the TCG Platform Certificate and additional procedures to 589 install identity credentials on the platform after manufacture. 590 (See Section 2.3.1 below for the Platform Certificate alternative) 592 o The product is equipped with a Root of Trust for Measurement, Root 593 of Trust for Storage and Root of Trust for Reporting that is 594 capable of conforming to the TCG Trusted Attestation Protocol 595 (TAP) Information Model [TAP]. 597 o The vendor will ship Reference Integrity Measurements (i.e., 598 known-good measurements) in the form of signed CoSWID tags 599 [I-D.ietf-sacm-coswid], [SWID], as described in TCG Reference 600 Integrity Measurement Manifest [RIM]. 602 2.4.1. DevID Alternatives 604 Some situations may have privacy-sensitive requirements that preclude 605 shipping every device with an Initial Device ID installed. In these 606 cases, the IDevID can be installed remotely using the TCG Platform 607 Certificate [Platform-Certificates]. 609 Some security-sensitive administrators may want to install their own 610 identity credentials to certify platform identity and attestation 611 results. IEEE 802.1AR [IEEE-802-1AR] allows for both Initial Device 612 Identity credentials, installed by the manufacturer, or Local Device 613 Identity credentials installed by the administrator of the platform. 614 TCG TPM 2.0 Keys documents [Platform-DevID-TPM-2.0] and 615 [PC-Client-BIOS-TPM-2.0] specifies analogous Initial and Local 616 Attestation Keys (IAK and LAK), and contains figures showing the 617 relationship between IDevID, LDevID, IAK and LAK keys. 619 Platform administrators are free to use any number of criteria to 620 judge authenticity of a platform before installing local identity 621 keys, as part of an on-boarding process. The TCG TPM 2.0 Keys 622 document [Platform-DevID-TPM-2.0] also outlines procedures for 623 creating Local Attestation Keys and Local Device IDs (LDevIDs) rooted 624 in the manufacturer's IDevID as a check to reduce the chances that 625 counterfeit devices are installed in the network. 627 Note that many networking devices are expected to self-configure (aka 628 Zero Touch Provisioning). Current standardized zero-touch mechanisms 629 such as [RFC8572] assume that identity keys are already in place 630 before network on-boarding can start. 632 2.4.2. Additional Attestation of Platform Characteristics 634 The Platform Attribute Credential [Platform-Certificates] can also be 635 used to convey additional information about a platform from the 636 manufacturer or other entities in the supply chain. While outside 637 the scope of RIV, the Platform Attribute Credential can deliver 638 information such as lists of serial numbers for components embedded 639 in a device or security assertions related to the platform, signed by 640 the manufacturer, system integrator or value-added-reseller. 642 2.4.3. Root of Trust for Measurement 644 The measurements needed for attestation require that the device being 645 attested is equipped with a Root of Trust for Measurement, i.e., some 646 trustworthy mechanism that can take the first measurement in the 647 chain of trust required to attest that each stage of system startup 648 is verified, and a Root of Trust for Reporting to report the results 649 [Roots-of-Trust]. 651 While there are many complex aspects of a Root of Trust, two aspects 652 that are important in the case of attestation are: 654 o The first measurement taken by the Root of Trust for Measurement, 655 and stored in the Root of Trust for Storage, is presumed to be 656 correct. 658 o There must not be a way to reset the RTM without re-entering the 659 RTS code. 661 The first measurement can't be checked by a code that's been 662 previously checked by something further back up the chain (it's the 663 first, after all); if that first measurement can be subverted, none 664 of the remaining measurements can be trusted. (See [NIST-SP-800-155] 666 2.4.4. Reference Integrity Measurements (RIMs) 668 Much of attestation focuses on collecting and transmitting 'evidence' 669 in the form of PCR measurements and attestation logs. But the 670 critical part of the process is enabling the verifier to decide 671 whether the measured hashes are "the right ones" or not. 673 While it must be up to network administrators to decide what they 674 want on their networks, the software supplier should supply the 675 Reference Integrity Measurements, (aka Golden Measurements or "known 676 good" hash digests) that may be used by a verifier to determine if 677 evidence shows known good, known bad or unknown software 678 configurations. 680 In general, there are two kinds of reference measurements: 682 1. Measurements of early system startup (e.g., BIOS, boot loader, OS 683 kernel) are essentially single threaded, and executed exactly 684 once, in a known sequence, before any results could be reported. 685 In this case, while the method for computing the hash and 686 extending relevant PCRs may be complicated, the net result is 687 that the software (more likely, firmware) vendor will have one 688 known good PCR value that "should" be present in the PCR after 689 the box has booted. In this case, the signed reference 690 measurement simply lists the expected hash for the given version. 692 2. Measurements taken later in operation of the system, once an OS 693 has started (for example, Linux IMA[16.]), may be more complex, 694 with unpredictable "final" PCR values. In this case, the 695 Verifier must have enough information to reconstruct the expected 696 PCR values from logs and signed reference measurements from a 697 trusted authority. 699 In both cases, the expected values can be expressed as signed CoSWID 700 tags, but the SWID structure in the second case is somewhat more 701 complex. An example of how CoSWIDs could be incorporated into a 702 reference manifest can be found in the IETF Internet-Draft "A SUIT 703 Manifest Extension for Concise Software Identifiers" 704 [I-D.birkholz-suit-coswid-manifest]. 706 The TCG has done exploratory work in defining formats for reference 707 integrity manifests under the working title TCG Reference Integrity 708 Manifest [RIM]. 710 2.4.5. Attestation Logs 712 Quotes from a TPM can provide evidence of the state of a device at 713 the time the quote was requested, but to make sense of the quote in 714 most cases an event log of what software modules contributed which 715 values to the quote during startup must also be provided. The log 716 needs not be secured, but it is essential that the logs contain 717 enough information to exactly reconstruct the state of whatever went 718 into the quote (e.g., PCR values). 720 TCG has defined several event log formats: 722 o Legacy BIOS event log (TCG PC Client Specific Implementation 723 Specification for Conventional BIOS, 724 Section 11.3[PC-Client-BIOS-TPM-1.2]) 726 o UEFI BIOS event log (TCG EFI Platform Specification for TPM Family 727 1.1 or 1.2, Section 7 [EFI]) 729 o Canonical Event Log [Canonical-Event-Log] 731 It should be noted that a given device might use more than one event 732 log format (e.g., a UEFI log during initial boot, switching to 733 Canonical Log when the host OS launches). 735 The TCG SNMP Attestation MIB [SNMP-Attestation-MIB] will support any 736 record-oriented log format, including the three TCG-defined formats, 737 but it currently leaves figuring out which log(s) are in what format 738 up to the Verifier. 740 3. Standards Components 742 3.1. Reference Models 744 3.1.1. IETF Reference Model for Challenge-Response Remote Attestation 746 Initial work at IETF defines remote attestation as follows: 748 o The Reference Interaction Model for Challenge-Response-based 749 Remote Attestation is based on the standard roles defined in 750 [I-D.birkholz-rats-architecture]: 752 o 754 * Attester: The role that designates the subject of the remote 755 attestation. A system entity that is the provider of evidence 756 takes on the role of an Attester. 758 * Verifier: The role that designates the system entity and that 759 is the appraiser of evidence provided by the Attester. A 760 system entity that is the consumer of evidence takes on the 761 role of a Verifier. 763 The following diagram illustrates a common information flow between a 764 Verifier and an Attester, specified in 765 [I-D.birkholz-rats-reference-interaction-model]: 767 Attester Verifier 768 | | 769 | <------- requestAttestation(nonce, authSecID, claimSelection) | 770 | | 771 collectAssertions(assertionsSelection) | 772 | => assertions | 773 | | 774 signAttestationEvidence(authSecID, assertions, nonce) | 775 | => signedAttestationEvidence | 776 | | 777 | signedAttestationEvidence ----------------------------------> | 778 | | 779 | verifyAttestationEvidence(signedAttestationEvidence, refassertions) 780 | attestationResult <= | 781 | | 783 Figure 3: IETF Attestation Information Flow 785 The RIV approach outlined in this document aligns with the RATS 786 reference model. 788 3.2. RIV Workflow 790 The overall flow for an attestation session is shown in Figure 4. In 791 this diagram: 793 o Step 0, positioning of the signed reference measurements, may 794 happen in two ways: 796 o Step 0A below shows a verifier obtaining reference measurements 797 directly from a software configuration authority, whether it's the 798 vendor or another authority chosen by the system administrator. 799 The reference measurements are signed by the Asserter (i.e., the 800 software configuration authority). 802 o - Or - Step 0B, the reference measurements, signed by the 803 Asserter, may be distributed as part of software installation, 804 long before the attestation session begins. Software installation 805 is usually vendor-dependent, so there are no standards involved in 806 this step. However, the verifier can use the same protocol to 807 obtain the reference measurements from the device as it would have 808 used with an external reference authority 810 o In Step 1, the Verifier initiates an attestation session by 811 opening a TLS session, validated using the DevID to prove that the 812 connection is attesting the right box. 814 o In Step 2, measured values are retrieved from the Attester's TPM 815 using a YANG or SNMP interface that implements the TCG TAP model 816 (e.g. YANG Module for Basic Challenge-Response-based Remote 817 Attestation Procedures 818 [I-D.birkholz-yang-basic-remote-attestation]). 820 o In Step 3, the Attester also delivers a copy of the signed 821 reference measurements, using Software Inventory YANG module based 822 on Software Identifiers [I-D.birkholz-yang-swid]. 824 +---------------+ +-------------+ +---------+ 825 | | | | Step 1 | | 826 | | | Attester |<------>| Verifier| 827 | Asserter | | (Device |<------>| (Network| 828 |(Configuration |------->| under | Step 2 | Mngmt | 829 | Authority) | Step 0A| attestation)| | Station)| 830 | | | |------->| | 831 +---------------+ +-------------+ Step 3 +---------+ 832 | /|\ 833 | | 834 ---------------------------------------------- 835 Step 0B 837 Either CoSWID-encoded reference measurements are signed by a trusted 838 authority and retrieved directly prior to attestation (as shown in 839 Step 0A), or CoSWID-encoded reference measurements are signed by the 840 device manufacturer, installed on the device by a proprietary 841 installer, and delivered during attestation (as shown in Step 0B). 842 In Step 1, the Verifier initiates a connection for attestation. The 843 Attester's identity is validated using DevID with TLS. In Step 2, a 844 nonce, quotes (measured values) and measurement log are conveyed via 845 TAP with a protocol-specific binding (e.g. SNMP). Logs are sent in 846 the Canonical Log Format In Step 3, CoSWID-encoded reference 847 measurements are retrieved from the Attester using the YANG 848 ([I-D.birkholz-yang-swid]. . 850 Figure 4: RIV Protocol and Encoding Summary 852 The following components are used: 854 1. TPM Keys are configured according to [Platform-DevID-TPM-2.0], 855 [PC-Client-BIOS-TPM-1.2], or [Platform-ID-TPM-1.2] 857 2. Measurements of bootable modules are taken according to TCG PC 858 Client [PC-Client-BIOS-TPM-2.0] and Linux IMA [IMA] 860 3. Device Identity is managed by IEEE 802.1AR certificates 861 [IEEE-802-1AR], with keys protected by TPMs. 863 4. Quotes are retrieved according to TCG TAP Information Model [TAP] 865 5. Reference Integrity Measurements are encoded as CoSWID tags, as 866 defined in the TCG RIM document [RIM], compatible with NIST IR 867 8060 [NIST-IR-8060] and the IETF CoSWID draft 868 [I-D.ietf-sacm-coswid]. Reference measurements are signed by the 869 device manufacturer. 871 3.3. Layering Model for Network Equipment Attester and Verifier 873 Retrieval of identity and attestation state uses one protocol stack, 874 while retrieval of Reference Measurements uses a different set of 875 protocols. Figure 5 shows the components involved. 877 +-----------------------+ +-------------------------+ 878 | | | | 879 | Attester |<-------------| Verifier | 880 | (Device) |------------->| (Management Station) | 881 | | | | | 882 +-----------------------+ | +-------------------------+ 883 | 884 -------------------- -------------------- 885 | | 886 ---------------------------------- --------------------------------- 887 |Reference Integrity Measurements| | Attestation | 888 ---------------------------------- --------------------------------- 890 ******************************************************************** 891 * IETF Attestation Reference Interaction Diagram * 892 ******************************************************************** 894 ....................... ....................... 895 . Reference Integrity . . TAPS (PTS2.0) Info . 896 . Measurement . . Model and Canonical . 897 . Manifest . . Log Format . 898 ....................... ....................... 900 ************************* .............. ********************** 901 * YANG SWID Module * . TCG . * YANG Attestation * 902 * I-D.birkholz-yang-swid* . Attestation. * Module * 903 * * . MIB . * I-D.birkholz-yang- * 904 * * . . * basic-remote- * 905 * * . . * attestation * 906 ************************* .............. ********************** 908 ************************* ************ ************************ 909 * XML, JSON, CBOR (etc) * * UDP * * XML, JSON, CBOR (etc)* 910 ************************* ************ ************************ 912 ************************* ************************ 913 * RESTCONF/NETCONF * * RESTCONF/NETCONF * 914 ************************ ************************* 916 ************************* ************************ 917 * TLS, SSH * * TLS, SSH * 918 ************************* ************************ 920 IETF documents are captured in boxes surrounded by asterisks. TCG 921 documements are shown in boxes surrounded by dots. The IETF 922 Attestation Reference Interaction Diagram, Reference Intefrity 923 Measurment Manifest, TAPS Information Model and Canonical Log Format, 924 and both YANG modules are works in progress. Information Model 925 layers describe abstract data objects that can be requested, and the 926 corresponding response SNMP is still widely used, but the industry is 927 transitioning to YANG, so in some cases, both will be required. TLS 928 Authentication with TPM has been shown to work; SSH authentication 929 using TPM-protected keys is not as easily done [as of 2019] 931 Figure 5: RIV Protocol Stacks 933 4. Conclusion 935 TCG technologies can play an important part in the implementation of 936 Remote Integrity Verification. Standards for many of the components 937 needed for implementation of RIV already exist: 939 o Platform identity can be based on IEEE 802.1AR Device identity, 940 coupled with careful supply-chain management by the manufacturer. 942 o Complex supply chains can be certified using TCG Platform 943 Certificates [Platform-Certificates] 945 o The TCG TAP mechanism can be used to retrieve attestation 946 evidence. Work is needed on a YANG model for this protocol. 948 o Reference Measurements must be conveyed from the software 949 authority (e.g., the manufacturer) to the system in which 950 verification will take place. IETF CoSWID work forms the basis 951 for this, but new work is needed to create an information model 952 and YANG implementation. 954 Gaps still exist for implementation in Network Equipment (as of May 955 2019): 957 o Coordination of YANG model development with the IETF is still 958 needed 960 o Specifications for management of signed Reference Integrity 961 Measurements must still be completed 963 5. Appendix 964 5.1. Implementation Notes 966 Table 1 summarizes many of the actions needed to complete an 967 Attestation system, with links to relevant documents. While 968 documents are controlled by a number of standards organizations, the 969 implied actions required for implementation are all the 970 responsibility of the manufacturer of the device, unless otherwise 971 noted. 973 +------------------------------------------------------------------+ 974 | Component | Controlling | 975 | | Specification | 976 -------------------------------------------------------------------- 977 | Make a Secure execution environment | TCG RoT | 978 | o Attestation depends entirely on a secure | UEFI.org | 979 | root of trust for measurement. | | 980 | o Refer to TCG Root of Trust for Measurement.| | 981 | o NIST SP 800-193 also provides guidelines | | 982 | on Roots of Trust | | 983 -------------------------------------------------------------------- 984 | Get a TPM properly provisioned as described in | TCG TPM DevID | 985 | TCG documents. | TCG Platform | 986 | | Certificate | 987 -------------------------------------------------------------------- 988 | Put a DevID or Platform Cert in the TPM | TCG TPM DevID | 989 | o Install an Initial Attestation Key at the | TCG Platform | 990 | same time so that Attestation can work out | Certificate | 991 | of the box |----------------- 992 | o Equipment suppliers and owners may want to | IEEE 802.1AR | 993 | implement Local Device ID as well as | | 994 | Initial Device ID | | 995 -------------------------------------------------------------------- 996 | Connect the TPM to the TLS stack | Vendor TLS | 997 | o Use the DevID in the TPM to authenticate | stack (This | 998 | TAP connections, identifying the device | action is | 999 | | simply | 1000 | | configuring TLS| 1001 | | to use the | 1002 | | DevID as its | 1003 | | trust anchor.) | 1004 -------------------------------------------------------------------- 1005 | Make CoSWID tags for BIOS/LoaderLKernel objects | IETF CoSWID | 1006 | o Add reference measurements into SWID tags | ISO/IEC 19770-2| 1007 | o Manufacturer should sign the SWID tags | NIST IR 8060 | 1008 | o This should be covered in a new TCG | TagVault SWID | 1009 | Reference Integrity Manifest document | Tag Signing | 1010 | - IWG should define the literal SWID | Guidance | 1011 | format |----------------- 1012 | - IWG should evaluate whether IETF SUIT | TCG RIM | 1013 | is a suitable manifest when multiple | | 1014 | SWID tags are involved | | 1015 | - There could be a proof-of-concept | | 1016 | project to actually make sample SWID | | 1017 | tags (a gap might appear in the | | 1018 | process) | | 1019 -------------------------------------------------------------------- 1020 | Package the SWID tags with a vendor software | There is no | 1021 | release | need to specify| 1022 | o A tag-generator plugin could help | where the tags | 1023 | (i.e., a plugin for common development | are stored in a| 1024 | environments. NIST has something that | vendor OS, as | 1025 | plugs into Maven Build Environment) | long as there | 1026 | | is a standards-| 1027 | | based mechanism| 1028 | | to retrieve | 1029 | | them. | 1030 | |----------------- 1031 | | TCG RIM | 1032 -------------------------------------------------------------------- 1033 | BIOS SWIDs might be hard to manage on an OS | | 1034 | disk-- maybe keep them in the BIOS flash? | TCG RIM | 1035 | o Maybe a UEFI Var? Would its name have to be| | 1036 | specified by UEFI.org? | | 1037 | o How big is a BIOS SWID tag? Do we need to | | 1038 | use a tag ID instead of an actual tag? | | 1039 | o Note that the presence of Option ROMs turns | | 1040 | the BIOS reference measurements into a | | 1041 | multi-vendor interoperability problem | | 1042 -------------------------------------------------------------------- 1043 | Use PC Client measurement definitions as a | TCG PC Client | 1044 | starting point to define the use of PCRs | BIOS | 1045 | (although Windows OS is rare on Networking |----------------- 1046 | Equipment) | There have been| 1047 | | proposals for | 1048 | | non-PC-Client | 1049 | | allocation of | 1050 | | PCRs, although | 1051 | | no specific | 1052 | | document exists| 1053 | | yet. | 1054 -------------------------------------------------------------------- 1055 | Use TAP to retrieve measurements | | 1056 | o Map TAP to SNMP | TCG SNMP MIB | 1057 | o Map to YANG | YANG Module for| 1058 | o Complete Canonical Log Format | Basic | 1059 | | Attestation | 1060 | | TCG Canonical | 1061 | | Log Format | 1062 -------------------------------------------------------------------- 1063 | Posture Collection Server (as described in IETF | | 1064 | SACMs ECP) would have to request the | | 1065 | attestation and analyze the result | | 1066 | The Management application might be broken down | | 1067 | to several more components: | | 1068 | o A Posture Manager Server | | 1069 | which collects reports and stores them in | | 1070 | a database | | 1071 | o One or more Analyzers that can look at the| | 1072 | results and figure out what it means. | | 1073 -------------------------------------------------------------------- 1075 Figure 6: Component Status 1077 5.2. Comparison with TCG PTS / IETF NEA 1079 Some components of an Attestation system have been implemented for 1080 end-user machines such as PCs and laptops. Figure 7 shows the 1081 corresponding protocol stacks. 1083 +-----------------------+ +-------------------------+ 1084 | | | | 1085 | Attester |<-------------| Verifier | 1086 | (Device) |------------->| (Management Station) | 1087 | | | | | 1088 +-----------------------+ | +-------------------------+ 1089 | 1090 -------------------- -------------------- 1091 | | 1092 ---------------------------------- --------------------------------- 1093 |Reference Integrity Measurements| | Attestation | 1094 ---------------------------------- --------------------------------- 1096 -------------------------------------------------------------------- 1097 | IETF Attestation Reference Interaction Diagram | 1098 ------------------------------------------------------------------- 1100 ....................... -------------------------------- 1101 . No Existing . | TAPS (PTS2.0) Info Model and| 1102 . Reference Integrity . | Canonical Log Format | 1103 . Measurement Manifest. | | 1104 . Protocols Exist . -------------------------------- 1105 . . 1106 . . ---------------------- ---------- 1107 . . | YANG Attestation | |IETF NEA| 1108 . . | Module | | Msg and| 1109 . . | I-D.birkholz-yang- | | Attrib.| 1110 . . | basic-remote- | | for PA-| 1111 . . | attestation | | TNC | 1112 . . ---------------------- ---------- 1113 . . ---------------------- ---------- 1114 . . | XML, JSON, CBOR | | PT-TLS | 1115 . . ---------------------- | (for | 1116 . . ---------------------- |endpoint| 1117 . . | NETCONF, RESTCONF, | |mcahines| 1118 . . | COAP | | | 1119 ....................... ---------------------- ---------- 1120 ---------------------------------------------------------------- 1121 | TLS, SSH | 1122 ---------------------------------------------------------------- 1124 Figure 7: Attestation for End User Computers 1126 6. IANA Considerations 1128 This memo includes no request to IANA. 1130 7. Security Considerations 1132 TBD 1134 8. Informative References 1136 [Canonical-Event-Log] 1137 Trusted Computing Group, "DRAFT Canonical Event Log Format 1138 Version: 1.0, Revision: .12", October 2018. 1140 [EFI] Trusted Computing Group, "TCG EFI Platform Specification 1141 for TPM Family 1.1 or 1.2, Specification Version 1.22, 1142 Revision 15", January 2014, 1143 . 1146 [Firmware-Profile] 1147 Trusted Computing Group, "Trusted Computing Group, PC 1148 Client Specific Platform Firmware Profile Specification 1149 Family "2.0", Level 00 Revision 1.03 Version 51", June 1150 2019, . 1153 [I-D.birkholz-rats-architecture] 1154 Birkholz, H., Wiseman, M., Tschofenig, H., and N. Smith, 1155 "Architecture and Reference Terminology for Remote 1156 Attestation Procedures", draft-birkholz-rats- 1157 architecture-01 (work in progress), March 2019. 1159 [I-D.birkholz-rats-reference-interaction-model] 1160 Birkholz, H. and M. Eckel, "Reference Interaction Model 1161 for Challenge-Response-based Remote Attestation", draft- 1162 birkholz-rats-reference-interaction-model-00 (work in 1163 progress), March 2019. 1165 [I-D.birkholz-suit-coswid-manifest] 1166 Birkholz, H., "A SUIT Manifest Extension for Concise 1167 Software Identifiers", draft-birkholz-suit-coswid- 1168 manifest-00 (work in progress), July 2018. 1170 [I-D.birkholz-yang-basic-remote-attestation] 1171 Birkholz, H., Eckel, M., Bhandari, S., Sulzen, B., Voit, 1172 E., and G. Fedorkow, "YANG Module for Basic Challenge- 1173 Response-based Remote Attestation Procedures", draft- 1174 birkholz-yang-basic-remote-attestation-01 (work in 1175 progress), October 2018. 1177 [I-D.birkholz-yang-swid] 1178 Birkholz, H., "Software Inventory YANG module based on 1179 Software Identifiers", draft-birkholz-yang-swid-02 (work 1180 in progress), October 2018. 1182 [I-D.ietf-sacm-coswid] 1183 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 1184 Waltermire, "Concise Software Identification Tags", draft- 1185 ietf-sacm-coswid-11 (work in progress), June 2019. 1187 [IEEE-802-1AR] 1188 Seaman, M., "802.1AR-2018 - IEEE Standard for Local and 1189 Metropolitan Area Networks - Secure Device Identity, IEEE 1190 Computer Society", August 2018. 1192 [IMA] and , "Integrity Measurement Architecture", June 2019, 1193 . 1195 [NetEq] Trusted Computing Group, "TCG Guidance for Securing 1196 Network Equipment", January 2018, 1197 . 1200 [NIST-IR-8060] 1201 National Institute for Standards and Technology, 1202 "Guidelines for the Creation of Interoperable Software 1203 Identification (SWID) Tags", April 2016, 1204 . 1207 [NIST-SP-800-155] 1208 National Institute for Standards and Technology, "BIOS 1209 Integrity Measurement Guidelines (Draft)", December 2011, 1210 . 1213 [PC-Client-BIOS-TPM-1.2] 1214 Trusted Computing Group, "TCG PC Client Specific 1215 Implementation Specification for Conventional BIOS, 1216 Specification Version 1.21 Errata, Revision 1.00", 1217 February 2012, . 1220 [PC-Client-BIOS-TPM-2.0] 1221 Trusted Computing Group, "PC Client Specific Platform 1222 Firmware Profile Specification Family "2.0", Level 00 1223 Revision 1.04", June 2019, 1224 . 1227 [Platform-Certificates] 1228 Trusted Computing Group, "DRAFT: TCG Platform Attribute 1229 Credential Profile, Specification Version 1.0, Revision 1230 15, 07 December 2017", December 2017. 1232 [Platform-DevID-TPM-2.0] 1233 Trusted Computing Group, "DRAFT: TPM Keys for Platform 1234 DevID for TPM2, Specification Version 0.7, Revision 0", 1235 October 2018. 1237 [Platform-ID-TPM-1.2] 1238 Trusted Computing Group, "TPM Keys for Platform Identity 1239 for TPM 1.2, Specification Version 1.0, Revision 3", 1240 August 2015, . 1244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1245 Requirement Levels", BCP 14, RFC 2119, 1246 DOI 10.17487/RFC2119, March 1997, 1247 . 1249 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1250 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1251 October 2013, . 1253 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1254 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1255 May 2017, . 1257 [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A 1258 YANG Data Model for Hardware Management", RFC 8348, 1259 DOI 10.17487/RFC8348, March 2018, 1260 . 1262 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 1263 Touch Provisioning (SZTP)", RFC 8572, 1264 DOI 10.17487/RFC8572, April 2019, 1265 . 1267 [RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity 1268 Manifest", June 2019. 1270 [Roots-of-Trust] 1271 Trusted Computing Group, "TCG Roots of Trust 1272 Specification", October 2018, 1273 . 1276 [SNMP-Attestation-MIB] 1277 Trusted Computing Group, "DRAFT: SNMP MIB for TPM-Based 1278 Attestation, Specification Version 0.8, Revision 0.02", 1279 May 2018. 1281 [SWID] The International Organization for Standardization/ 1282 International Electrotechnical Commission, "Information 1283 Technology Software Asset Management Part 2: Software 1284 Identification Tag, ISO/IEC 19770-2", October 2015, 1285 . 1287 [TAP] Trusted Computing Group, "DRAFT: TCG Trusted Attestation 1288 Protocol (TAP) Information Model for TPM Families 1.2 and 1289 2.0 and DICE Family 1.0, Version 1.0, Revision 0.29", 1290 October 2018. 1292 Authors' Addresses 1294 Guy Fedorkow (editor) 1295 Juniper Networks, Inc. 1296 US 1298 Email: gfedorkow@juniper.net 1300 Jessica Fitzgerald-McKay 1301 National Security Agency 1302 US 1304 Email: jmfitz2@nsa.gov