--- 1/draft-ietf-rats-tpm-based-network-device-attest-02.txt 2020-08-13 06:13:15.446888414 -0700 +++ 2/draft-ietf-rats-tpm-based-network-device-attest-03.txt 2020-08-13 06:13:15.554891142 -0700 @@ -1,89 +1,95 @@ RATS Working Group G. Fedorkow, Ed. Internet-Draft Juniper Networks, Inc. Intended status: Informational E. Voit -Expires: January 14, 2021 Cisco Systems, Inc. +Expires: February 14, 2021 Cisco Systems, Inc. J. Fitzgerald-McKay National Security Agency - July 13, 2020 + August 13, 2020 TPM-based Network Device Remote Integrity Verification - draft-ietf-rats-tpm-based-network-device-attest-02 + draft-ietf-rats-tpm-based-network-device-attest-03 Abstract This document describes a workflow for remote attestation of the - integrity of network devices. + integrity of firmware and software installed on network devices that + contain Trusted Platform Modules [TPM]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 14, 2021. + This Internet-Draft will expire on February 14, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Document Organization . . . . . . . . . . . . . . . . . . 4 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Description of Remote Integrity Verification (RIV) . . . 5 1.5. Solution Requirements . . . . . . . . . . . . . . . . . . 7 1.6. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6.1. Out of Scope . . . . . . . . . . . . . . . . . . . . 8 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8 2.1. RIV Software Configuration Attestation using TPM . . . . 8 - 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 9 + 2.1.1. What Does RIV Attest? . . . . . . . . . . . . . . . . 10 2.2. RIV Keying . . . . . . . . . . . . . . . . . . . . . . . 12 2.3. RIV Information Flow . . . . . . . . . . . . . . . . . . 13 2.4. RIV Simplifying Assumptions . . . . . . . . . . . . . . . 15 2.4.1. Reference Integrity Manifests (RIMs) . . . . . . . . 16 2.4.2. Attestation Logs . . . . . . . . . . . . . . . . . . 17 3. Standards Components . . . . . . . . . . . . . . . . . . . . 17 - 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 17 + 3.1. Prerequisites for RIV . . . . . . . . . . . . . . . . . . 18 3.1.1. Unique Device Identity . . . . . . . . . . . . . . . 18 3.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.3. Appraisal Policy for Evidence . . . . . . . . . . . . 18 3.2. Reference Model for Challenge-Response . . . . . . . . . 19 3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 21 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 21 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 24 + 5.2. Prevention of Spoofing and Man-in-the-Middle Attacks . . 26 + 5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 27 + 5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 27 + 5.5. Other Trust Anchors . . . . . . . . . . . . . . . . . . . 28 + 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. Layering Model for Network Equipment Attester and Verifier . . . . . . . . . . . . . . . . . . . . . . . . 29 8.1.1. Why is OS Attestation Different? . . . . . . . . . . 31 8.2. Implementation Notes . . . . . . . . . . . . . . . . . . 31 8.3. Root of Trust for Measurement . . . . . . . . . . . . . . 33 9. Informative References . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction @@ -102,21 +108,21 @@ [I-D.richardson-rats-usecases]. However, these documents do not provide sufficient guidance for equipment vendors and network operators to design, build, and deploy interoperable platforms. The intent of this document is to provide such guidance. It does this by outlining the Remote Integrity Verification (RIV) problem, and then identifies elements that are necessary to get the complete, scalable attestation procedure working with commercial networking products such as routers, switches and firewalls. An underlying assumption will be the availability within the device of a Trusted - Platform Module (TPM) compliant cryptoprocessor to enable the remote + Platform Module [TPM] compliant cryptoprocessor to enable the remote trustworthy assessment of the device's software and hardware. 1.1. Terminology A number of terms are reused from [I-D.ietf-rats-architecture]. These include: Appraisal Policy for Attestation Result, Attestation Result, Attester, Endorser, Evidence, Relying Party, Verifier, Verifier Owner. Additionally, this document defines the following terms: @@ -181,43 +187,42 @@ integrity, attestation can be used for asset management, vulnerability and compliance assessment, plus configuration management. As a part of a trusted supply chain, the RIV attestation workflow outlined in this document is intended to meet the following high- level goals: o Provable Device Identity - This specification requires that an attesting device includes a cryptographic identifier unique to - each device. Effectively this means that the TPM or equivalent - cryptoprocessor must be so provisioned during the manufacturing - cycle. + each device. Effectively this means that the TPM must be so + provisioned during the manufacturing cycle. o Software Inventory - A key goal is to identify the software release installed on the attesting device, and to provide evidence that the software stored within hasn't been altered o Verifiability - Verification of software and configuration of the device shows that the software that was authorized for installation by the administrator has actually been launched. In addition, RIV is designed to operate in a centralized environment, such as with a central authority that manages and configures a number of network devices, or 'peer-to-peer', where network devices independently verify one another to establish a trust relationship. (See Section 3.3 below, and also [I-D.voit-rats-trusted-path-routing]) 1.4. Description of Remote Integrity Verification (RIV) Attestation requires two interlocking services between the Attester - network device and the Verifier:: + network device and the Verifier: o Platform Identity, the mechanism providing trusted identity, can reassure network managers that the specific devices they ordered from authorized manufacturers for attachment to their network are those that were installed, and that they continue to be present in their network. As part of the mechanism for Platform Identity, cryptographic proof of the identity of the manufacturer is also provided. o Software Measurement is the mechanism that reports the state of @@ -241,22 +246,22 @@ 2. Platform Identification refers to the mechanism assuring the Relying Party (ultimately, a network administrator) of the identity of devices that make up their network, and that their manufacturers are known. 3. Software used to boot a platform can be described as a chain of measurements, started by a Root of Trust for Measurement, that normally ends when the system software is loaded. A measurement signifies the identity, integrity and version of each software - component registered with an attesting device's TPM, so that the - subsequent appraisal stage can determine if the software + component registered with an attesting device's TPM [TPM], so + that the subsequent appraisal stage can determine if the software installed is authentic, up-to-date, and free of tampering. 4. Conveyance of Evidence reliably transports at least the minimum amount of Evidence from Attester to a Verifier to allow a management station to perform a meaningful appraisal in Step 5. The transport is typically carried out via a management network. The channel must provide integrity and authenticity, and, in some use cases, may also require confidentiality. 5. Finally, Appraisal of Evidence occurs. As the Verifier and @@ -277,27 +282,30 @@ coupled with careful supply-chain management by the manufacturer. The DevID certificate contains a statement by the manufacturer that establishes the identity of the device as it left the factory. Some applications with a more-complex post-manufacture supply chain (e.g. Value Added Resellers), or with different privacy concerns, may want to use alternative mechanisms for platform authentication (for example, TCG Platform Certificates [Platform-Certificates]). 1. Platform Attestation provides evidence of configuration of software elements present in the device. This form of - attestation can be implemented with TPM PCR, Quote and Log - mechanisms, which provide an authenticated mechanism to report - what software was started on the device through the boot cycle. - - Successful attestation requires an unbroken chain from a boot- - time root of trust through all layers of software needed to bring - the device to an operational state. + attestation can be implemented with TPM Platform Configuration + Registers (PCRs), Quote and Log mechanisms, which provide an + authenticated mechanism to report what software was started on + the device through the boot cycle. Successful attestation + requires an unbroken chain from a boot-time root of trust through + all layers of software needed to bring the device to an + operational state, in which each stage measures components of the + next stage, updates the attestation log, and extends hashes into + a PCR. The TPM can then report the hashes of all the measured + hashes as a signed Quote (see [TPM] for many more details). 2. Reference Integrity Measurements must be conveyed from the Endorser (the entity accepted as the software authority, often the manufacturer for embedded systems) to the system in which verification will take place 1.5. Solution Requirements Remote Integrity Verification must address the "Lying Endpoint" problem, in which malicious software on an endpoint may subvert the @@ -317,31 +325,32 @@ 1.6. Scope Remote Attestation is a very general problem that could apply to most network-connected computing devices. However, this document includes several assumptions that limit the scope to Network Equipment (e.g. routers, switches and firewalls): o This solution is for use in non-privacy-preserving applications (for example, networking, Industrial IoT), avoiding the need for a Privacy Certificate Authority for attestation keys + [AIK-Enrollment] or TCG Platform Certificates [Platform-Certificates] o This document assumes network protocols that are common in networking equipment such as YANG [RFC7950] and NETCONF [RFC6241], but not generally used in other applications. - o The approach outlined in this document mandates the use of TPM 1.2 - or TPM 2.0. Other roots of trust could be used with the same - information flow, although different data structures would likely - be called for. + o The approach outlined in this document mandates the use of a + compliant TPM [TPM]. Other roots of trust could be used with the + same information flow, although they're out of scope for this + document. 1.6.1. Out of Scope o Run-Time Attestation: Run-time attestation of Linux or other multi-threaded operating system processes considerably expands the scope of the problem. Many researchers are working on that problem, but this document defers the run-time attestation problem. o Multi-Vendor Embedded Systems: Additional coordination would be @@ -702,21 +711,21 @@ sign a TPM Quote. This convention is described in TCG Guidance for Securing Network Equipment [NetEq]. For network equipment, which is generally non-privacy-sensitive, shipping a device with both an IDevID and an IAK already provisioned substantially simplifies initial startup. Privacy-sensitive applications may use the TCG Platform Certificate and additional procedures to install identity credentials on the platform after manufacture. o The product is equipped with a Root of Trust for Measurement, Root of Trust for Storage and Root of Trust for Reporting (as defined - in [GloPlaRoT]) that are capable of conforming to the TCG Trusted + in [SP800-155]) that are capable of conforming to the TCG Trusted Attestation Protocol (TAP) Information Model [TAP]. o The vendor will ship Reference Integrity Measurements (i.e., known-good measurements) in the form of signed CoSWID tags [I-D.ietf-sacm-coswid], [SWID], as described in TCG Reference Integrity Measurement Manifest Information Model [RIM]. 2.4.1. Reference Integrity Manifests (RIMs) [I-D.ietf-rats-yang-tpm-charra] focuses on collecting and @@ -1071,20 +1079,22 @@ o Keys may be compromised o A counterfeit device may attempt to impersonate (spoof) a known authentic device o Man-in-the-middle attacks may be used by a counterfeit device to attempt to deliver responses that originate in an actual authentic device o Replay attacks may be attempted by a compromised device +5.1. Keys Used in RIV + Trustworthiness of RIV attestation depends strongly on the validity of keys used for identity and attestation reports. RIV takes full advantage of TPM capabilities to ensure that results can be trusted. Two sets of keys are relevant to RIV attestation o A DevID key is used to certify the identity of the device in which the TPM is installed. o An Attestation Key (AK) key signs attestation reports, (called @@ -1142,30 +1152,39 @@ attestation session begins. Security of this process derives from TLS security, with the DevID providing proof that the TLS session terminates on the intended device. [RFC8446]. Evidence of software integrity is delivered in the form of a quote signed by the TPM itself. Because the contents of the quote are signed inside the TPM, any external modification (including reformatting to a different data format) will be detected as tampering. + Requiring results of attestation of the operating software to be + signed by a key known only to the TPM also removes the need to trust + the device's operating software (beyond the first measurement; see + below); any changes to the quote, generated and signed by the TPM + itself, made by malicious device software, or in the path back to the + verifier, will invalidate the signature on the quote. + A critical feature of the YANG model described in [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data structures in their native format, without requiring any changes to the structures as they were signed and delivered by the TPM. While alternate methods of conveying TPM quotes could compress out redundant information, or add an additional layer of signing using external keys, the important part is to preserve the TPM signing, so that tampering anywhere in the path between the TPM itself and the Verifier can be detected. +5.2. Prevention of Spoofing and Man-in-the-Middle Attacks + Prevention of spoofing attacks against attestation systems is also important. There are two cases to consider: o The entire device could be spoofed, that is, when the Verifier goes to verify a specific device, it might be redirected to a different device. Use of the 802.1AR identity in the TPM ensures that the Verifier's TLS session is in fact terminating on the right device. o A compromised device could respond with a spoofed attestation @@ -1191,37 +1210,34 @@ by the CA to be an Attestation key?] These two keys and certificates are used together: o The DevID is used to validate a TLS connection terminating on the device with a known serial number. o The AK is used to sign attestation quotes, providing proof that the attestation evidence comes from the same device. +5.3. Replay Attacks + Replay attacks, where results of a previous attestation are submitted in response to subsequent requests, are usually prevented by inclusion of a nonce in the request to the TPM for a quote. Each request from the Verifier includes a new random number (a nonce). The resulting quote signed by the TPM contains the same nonce, allowing the verifier to determine freshness, i.e., that the resulting quote was generated in response to the verifier's specific request. Time-Based Uni-directional Attestation [I-D.birkholz-rats-tuda] provides an alternate mechanism to verify freshness without requiring a request/response cycle. - Requiring results of attestation of the operating software to be - signed by a key known only to the TPM also removes the need to trust - the device's operating software (beyond the first measurement; see - below); any changes to the quote, generated and signed by the TPM - itself, made by malicious device software, or in the path back to the - verifier, will invalidate the signature on the quote. +5.4. Owner-Signed Keys Although RIV recommends that device manufacturers pre-provision devices with easily-verified DevID and AK certs, use of those credentials is not mandatory. IEEE 802.1AR incorporates the idea of an Initial Device ID (IDevID), provisioned by the manufacturer, and a Local Device ID (LDevID) provisioned by the owner of the device. RIV extends that concept by defining an Initial Attestation Key (IAK) and Local Attestation Key (LAK) with the same properties. Device owners can use any method to provision the Local credentials. @@ -1244,22 +1260,24 @@ installation of the Local keys can only be done by some process that runs before the device is configured for network operation. On the other end of the device life cycle, provision should be made to wipe Local keys when a device is decommissioned, to indicate that the device is no longer owned by the enterprise. The manufacturer's Initial identity keys must be preserved, as they contain no information that's not already printed on the device's serial number plate. +5.5. Other Trust Anchors + In addition to trustworthy provisioning of keys, RIV depends on other - trust anchors. (See [GloPlaRoT] for definitions of Roots of Trust.) + trust anchors. (See [SP800-155] for definitions of Roots of Trust.) o Secure identity depends on mechanisms to prevent per-device secret keys from being compromised. The TPM provides this capability as a Root of Trust for Storage o Attestation depends on an unbroken chain of measurements, starting from the very first measurement. That first measurement is made by code called the Root of Trust for Measurement, typically done by trusted firmware stored in boot flash. Mechanisms for maintaining the trustworthiness of the RTM are out of scope for @@ -1274,20 +1292,37 @@ RIV also depends on reliable reference measurements, as expressed by the RIM [RIM]. The definition of trust procedures for RIMs is out of scope for RIV, and the device owner is free to use any policy to validate a set of reference measurements. RIMs may be conveyed out- of-band or in-band, as part of the attestation process (see Section 3.1.3). But for embedded devices, where software is usually shipped as a self-contained package, RIMs signed by the manufacturer and delivered in-band may be more convenient for the device owner. + The validity of RIV attestation results is also influenced by + procedures used to create reference measurements: + + o While the RIM itself is signed, supply-chains must be carefully + scrutinized to ensure that the values are not subject to + unexpected manipulation prior to signing. Insider-attacks against + code bases and build chains are particularly hard to spot. + + o Designers must guard against hash collision attacks. Reference + measurements often give hashes for large objects of indeterminate + size; if one of the measured objects can be replaced with an + implant engineered to produce the same hash, RIV will be unable to + detect the substitution. TPM1.2 uses SHA-1 hashes only, which + have been shown to be susceptible to collision attack. TPM2.0 + will produce quotes with SHA-256, which so far has resisted such + attacks, and consequently is preferred. + 6. Conclusion TCG technologies can play an important part in the implementation of Remote Integrity Verification. Standards for many of the components needed for implementation of RIV already exist: o Platform identity can be based on IEEE 802.1AR Device identity, coupled with careful supply-chain management by the manufacturer. o Complex supply chains can be certified using TCG Platform @@ -1468,71 +1503,66 @@ Figure 8: Component Status 8.3. Root of Trust for Measurement The measurements needed for attestation require that the device being attested is equipped with a Root of Trust for Measurement, i.e., some trustworthy mechanism that can compute the first measurement in the chain of trust required to attest that each stage of system startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs) to record the results, and a Root of Trust for Reporting to report the - results [TCGRoT], [GloPlaRoT]. + results [TCGRoT], [SP800-155]. While there are many complex aspects of a Root of Trust, two aspects that are important in the case of attestation are: o The first measurement computed by the Root of Trust for Measurement, and stored in the TPM's Root of Trust for Storage, is presumed to be correct. o There must not be a way to reset the Root of Trust for Storage without re-entering the Root of Trust for Measurement code. The first measurement must be computed by code that is implicitly trusted; if that first measurement can be subverted, none of the remaining measurements can be trusted. (See [NIST-SP-800-155]) 9. Informative References [AIK-Enrollment] - Trusted Computing Group, "TCG Infrastructure Working - GroupA CMC Profile for AIK Certificate Enrollment Version + Trusted Computing Group, "TCG Infrastructure Working Group + - A CMC Profile for AIK Certificate Enrollment Version 1.0, Revision 7", March 2011, - . + . [Canonical-Event-Log] Trusted Computing Group, "DRAFT Canonical Event Log Format Version: 1.0, Revision: .12", October 2018. [EFI-TPM] Trusted Computing Group, "TCG EFI Platform Specification for TPM Family 1.1 or 1.2, Specification Version 1.22, Revision 15", January 2014, - . - - [GloPlaRoT] - GlobalPlatform Technology, "Root of Trust Definitions and - Requirements Version 1.1", June 2018, - . + . [I-D.birkholz-rats-reference-interaction-model] Birkholz, H., Eckel, M., Newton, C., and L. Chen, "Reference Interaction Models for Remote Attestation Procedures", draft-birkholz-rats-reference-interaction- model-03 (work in progress), July 2020. [I-D.birkholz-rats-tuda] Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, "Time-Based Uni-Directional Attestation", draft-birkholz- - rats-tuda-02 (work in progress), March 2020. + rats-tuda-03 (work in progress), July 2020. [I-D.birkholz-yang-swid] Birkholz, H., "Software Inventory YANG module based on Software Identifiers", draft-birkholz-yang-swid-02 (work in progress), October 2018. [I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", draft-ietf-rats-architecture-05 (work in progress), July @@ -1581,78 +1611,82 @@ [IMA] and , "Integrity Measurement Architecture", June 2019, . [LLDP] IEEE Computer Society, "802.1AB-2016 - IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery", March 2016, . [NetEq] Trusted Computing Group, "TCG Guidance for Securing - Network Equipment", January 2018, - . + Network Equipment, Version 1.0, Revision 29", January + 2018, . [NIST-IR-8060] National Institute for Standards and Technology, "Guidelines for the Creation of Interoperable Software Identification (SWID) Tags", April 2016, . [NIST-SP-800-155] National Institute for Standards and Technology, "BIOS Integrity Measurement Guidelines (Draft)", December 2011, . [PC-Client-BIOS-TPM-1.2] Trusted Computing Group, "TCG PC Client Specific Implementation Specification for Conventional BIOS, Specification Version 1.21 Errata, Revision 1.00", - February 2012, . + February 2012, + . [PC-Client-BIOS-TPM-2.0] Trusted Computing Group, "PC Client Specific Platform Firmware Profile Specification Family "2.0", Level 00 Revision 1.04", June 2019, . [PC-Client-RIM] Trusted Computing Group, "DRAFT: TCG PC Client Reference Integrity Manifest Specification, v.09", December 2019, - . + . [Platform-Certificates] - Trusted Computing Group, "DRAFT: TCG Platform Attribute + Trusted Computing Group, "TCG Platform Attribute Credential Profile, Specification Version 1.0, Revision - 15, 07 December 2017", December 2017. + 16", January 2018, + . [Platform-DevID-TPM-2.0] Trusted Computing Group, "DRAFT: TPM Keys for Platform DevID for TPM2, Specification Version 0.7, Revision 0", October 2018. [Platform-ID-TPM-1.2] Trusted Computing Group, "TPM Keys for Platform Identity for TPM 1.2, Specification Version 1.0, Revision 3", - August 2015, . + August 2015, . [Provisioning-TPM-2.0] Trusted Computing Group, "TCG TPM v2.0 Provisioning - Guidance", March 2015, . + Guidance, Version 1.0, Revision 1.0", March 2015, + . [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . @@ -1673,36 +1707,48 @@ [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero Touch Provisioning (SZTP)", RFC 8572, DOI 10.17487/RFC8572, April 2019, . [RIM] Trusted Computing Group, "DRAFT: TCG Reference Integrity Manifest Information Model", June 2019, . + [SP800-155] + National Institute of Standards and Technology, "BIOS + Integrity Measurement Guidelines (Draft)", December 2011, + . + [SWID] The International Organization for Standardization/ International Electrotechnical Commission, "Information Technology Software Asset Management Part 2: Software Identification Tag, ISO/IEC 19770-2", October 2015, . - [TAP] Trusted Computing Group, "DRAFT: TCG Trusted Attestation - Protocol (TAP) Information Model for TPM Families 1.2 and - 2.0 and DICE Family 1.0, Version 1.0, Revision 0.29", - October 2018. + [TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol + (TAP) Information Model for TPM Families 1.2 and 2.0 and + DICE Family 1.0, Version 1.0, Revision 0.36", October + 2018, . - [TCGRoT] Trusted Computing Group, "TCG Roots of Trust + [TCGRoT] Trusted Computing Group, "DRAFT: TCG Roots of Trust Specification", October 2018, . + [TPM] ISO/IEC JTC 1 Information technology, "ISO/IEC + 11889-1:2015 Information technology -- Trusted platform + module library -- Part 1: Architecture", August 2015, + . + Authors' Addresses Guy Fedorkow (editor) Juniper Networks, Inc. US Email: gfedorkow@juniper.net Eric Voit Cisco Systems, Inc.