--- 1/draft-ietf-rats-tpm-based-network-device-attest-05.txt 2020-12-07 07:13:50.770216179 -0800 +++ 2/draft-ietf-rats-tpm-based-network-device-attest-06.txt 2020-12-07 07:13:50.898219410 -0800 @@ -1,21 +1,21 @@ RATS Working Group G. Fedorkow, Ed. Internet-Draft Juniper Networks, Inc. Intended status: Informational E. Voit -Expires: April 29, 2021 Cisco Systems, Inc. +Expires: June 10, 2021 Cisco Systems, Inc. J. Fitzgerald-McKay National Security Agency - October 26, 2020 + December 07, 2020 TPM-based Network Device Remote Integrity Verification - draft-ietf-rats-tpm-based-network-device-attest-05 + draft-ietf-rats-tpm-based-network-device-attest-06 Abstract This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by the Trusted Computing Group (TCG). Status of This Memo @@ -25,21 +25,21 @@ 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 April 29, 2021. + This Internet-Draft will expire on June 10, 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 @@ -78,30 +78,30 @@ 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 26 5.2. Prevention of Spoofing and Man-in-the-Middle Attacks . . 28 5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29 5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 29 5.5. Other Factors for Trustworthy Operation . . . . . . . . . 30 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 - 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 8.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 32 - 8.2. Root of Trust for Measurement . . . . . . . . . . . . . . 33 - 8.3. Layering Model for Network Equipment Attester and + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 + 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 9.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 32 + 9.2. Root of Trust for Measurement . . . . . . . . . . . . . . 33 + 9.3. Layering Model for Network Equipment Attester and Verifier . . . . . . . . . . . . . . . . . . . . . . . . 34 - 8.4. Implementation Notes . . . . . . . . . . . . . . . . . . 36 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 37 - 9.2. Informative References . . . . . . . . . . . . . . . . . 40 - + 9.4. Implementation Notes . . . . . . . . . . . . . . . . . . 36 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 + 10.2. Informative References . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction There are many aspects to consider in fielding a trusted computing device, from operating systems to applications. Mechanisms to prove that a device installed at a customer's site is authentic (i.e., not counterfeit) and has been configured with authorized software, all as part of a trusted supply chain, are just a few of the many aspects which need to be considered concurrently to have confidence that a @@ -246,21 +246,21 @@ Using these two interlocking mechanisms, RIV is a component in a chain of procedures that can assure a network operator that the equipment in their network can be reliably identified, and that authentic software of a known version is installed on each device. Equipment in the network includes devices that make up the network itself, such as routers, switches and firewalls. Software used to boot a device can be described as recording a chain of measurements, anchored at the start by a Root of Trust for - Measurement (see Section 8.2), each measuring the next stage, that + Measurement (see Section 9.2), each measuring the next stage, that normally ends when the system software is loaded. A measurement signifies the identity, integrity and version of each software component registered with an Attester's TPM [TPM1.2], [TPM2.0], so that a subsequent verification stage can determine if the software installed is authentic, up-to-date, and free of tampering. RIV includes several major processes: 1. Generation of Evidence is the process whereby an Attester generates cryptographic proof (Evidence) of claims about device @@ -309,21 +309,21 @@ attestation can be implemented with TPM Platform Configuration Registers (PCRs), Quote and Log mechanisms, which provide cryptographically authenticated evidence 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 signed evidence called a Quote (see - Section 8.1 for an overview of TPM operation, or [TPM1.2] and + Section 9.1 for an overview of TPM operation, or [TPM1.2] and [TPM2.0] for many more details). 3. Signed Reference Values (aka Reference Integrity Measurements) must be conveyed from the Reference Value Provider (the entity accepted as the software authority, often the manufacturer for embedded systems) to the Verifier. 1.5. Solution Requirements Remote Integrity Verification must address the "Lying Endpoint" @@ -846,21 +846,21 @@ Quotes from a TPM can provide evidence of the state of a device up to the time the evidence was recorded, but to make sense of the quote in most cases an event log that identifies which software modules contributed which values to the quote during startup MUST also be provided. The log MUST contain enough information to demonstrate its integrity by allowing exact reconstruction of the digest conveyed in the signed quote (that is, calculating the hash of all the hashes in the log should produce the same values as contained in the PCRs; if they don't match, the log may have been tampered with. See - Section 8.1). + Section 9.1). There are multiple event log formats which may be supported as viable formats of Evidence between the Attester and Verifier: o IMA Event log file exports [IMA] o TCG UEFI BIOS event log (TCG EFI Platform Specification for TPM Family 1.1 or 1.2, Section 7) [EFI-TPM] o TCG Canonical Event Log [Canonical-Event-Log] @@ -947,22 +947,22 @@ 3.2. Reference Model for Challenge-Response Once the prerequisites for RIV are met, a Verifier is able to acquire Evidence from an Attester. The following diagram illustrates a RIV information flow between a Verifier and an Attester, derived from Section 8.1 of [I-D.birkholz-rats-reference-interaction-model]. Event times shown correspond to the time types described within Appendix A of [I-D.ietf-rats-architecture]: - .---------. .--------------------------. - | Atteser | | Relying Party / Verifier | + .----------. .--------------------------. + | Attester | | Relying Party / Verifier | '---------' '--------------------------' time(VG) | valueGeneration(targetEnvironment) | | => claims | | | | <-----------requestEvidence(nonce, PcrSelection)----time(NS) | | time(EG) | evidenceGeneration(nonce, PcrSelection, collectedClaims) | | => SignedPcrEvidence(nonce, PcrSelection) | @@ -992,21 +992,21 @@ TCG TAP model (e.g., YANG Module for Basic Challenge-Response- based Remote Attestation Procedures [I-D.ietf-rats-yang-tpm-charra]). o Step 3 (time(EG)): On the Attester, measured values are retrieved from the Attester's TPM. This requested PCR evidence, along with the Verifier's nonce, called a Quote, is signed by the Attestation Key (AK) associated with the DevID. Quotes are retrieved according to TCG TAP Information Model [TAP]. At the same time, the Attester collects log evidence showing the values have been - extended into that PCR. Section 8.1 gives more detail on how this + extended into that PCR. Section 9.1 gives more detail on how this works. o Step 4: Collected Evidence is passed from the Attester to the Verifier o Step 5 (time(RG,RA)): The Verifier reviews the Evidence and takes action as needed. As the interaction between Relying Party and Verifier is out of scope for RIV, this can be described as one step. @@ -1091,21 +1091,21 @@ | | | | | | |<-------| | | +------------+ Step 3 +------------+ / Figure 6: Peer-to-Peer Attestation Information Flow In this application, each device may need to be equipped with signed RIMs to act as an Attester, and also an Appraisal Policy for Evidence and a selection of trusted X.509 root certificates, to allow the device to act as a Verifier. An existing link layer protocol such as - 802.1x [IEEE-802.1x] or 802.1AE [IEEE-802.1AE], with Evidence being + 802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable methods for such an exchange. 4. Privacy Considerations Network equipment, such as routers, switches and firewalls, has a key role to play in guarding the privacy of individuals using the network. Network equipment generally adheres to several rules to protect privacy: @@ -1358,29 +1358,29 @@ 5.5. Other Factors for Trustworthy Operation In addition to trustworthy provisioning of keys, RIV depends on a number of other factors for trustworthy operation. 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. See Section 8.1 for background + from the very first measurement. See Section 9.1 for background on TPM practices. o 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 RIV, but could include immutable firmware, signed updates, or a vendor-specific hardware verification - technique. See Section 8.2 for background on roots of trust. + technique. See Section 9.2 for background on roots of trust. o The device owner SHOULD provide some level of physical defense for the device. If a TPM that has already been programmed with an authentic DevID is stolen and inserted into a counterfeit device, attestation of that counterfeit device may become indistinguishable from an authentic device. RIV also depends on reliable Reference Values, 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 @@ -1426,23 +1426,31 @@ o Reference Values must be conveyed from the software authority (e.g., the manufacturer) in Reference Integrity Manifests, to the system in which verification will take place. IETF and TCG SWID and CoSWID work ([I-D.birkholz-yang-swid], [RIM])) forms the basis for this function. 7. IANA Considerations This memo includes no request to IANA. -8. Appendix +8. Acknowledgements -8.1. Using a TPM for Attestation + The authors wish to thank numerous reviewers for generous assistance, + including William Bellingrath, Mark Baushke, Ned Smith, Henk + Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas + Hardjono, Bill Sulzen, Monty Wiseman, Kathleen Moriarty, Nancy Cam- + Winget and Shwetha Bhandari + +9. Appendix + +9.1. Using a TPM for Attestation The Trusted Platform Module and surrounding ecosystem provide three interlocking capabilities to enable secure collection of evidence from a remote device, Platform Configuration Registers (PCRs), a Quote mechanism, and a standardized Event Log. Each TPM has at least eight and at most twenty-four PCRs (depending on the profile and vendor choices), each one large enough to hold one hash value (SHA-1, SHA-256, and other hash algorithms can be used, depending on TPM version). PCRs can't be accessed directly from @@ -1464,23 +1472,23 @@ an accurate view of what was placed into the PCR. Note that the composite hash-of-hashes recorded in PCRs is order- dependent, resulting in different PCR values for different ordering of the same set of events (e.g. Event A followed by Event B yields a different PCR value than B followed by A). For single-threaded code, where both the events and their order are fixed, a Verifier may validate a single PCR value, and use the log only to diagnose a mismatch from Reference Values. However, operating system code is usually non-deterministic, meaning that there may never be a single - "known good" PCR value. In this case, the Verifier may have verify - that the log is correct, and then analyze each item in the log to - determine if it represents an authorized event. + "known good" PCR value. In this case, the Verifier may have to + verify that the log is correct, and then analyze each item in the log + to determine if it represents an authorized event. In a conventional TPM Attestation environment, the first measurement must be made and extended into the TPM by trusted device code (called the Root of Trust for Measurement, RTM). That first measurement should cover the segment of code that is run immediately after the RTM, which then measures the next code segment before running it, and so on, forming an unbroken chain of trust. See [TCGRoT] for more on Mutable vs Immutable roots of trust. The TPM provides another mechanism called a Quote that can read the @@ -1503,21 +1511,21 @@ itself is not signed. Each hash in the validated Event Log can then be compared to corresponding expected values in the set of Reference Values to validate overall system integrity. A summary of information exchanged in obtaining quotes from TPM1.2 and TPM2.0 can be found in [TAP], Section 4. Detailed information about PCRs and Quote data structures can be found in [TPM1.2], [TPM2.0]. Recommended log formats include [PC-Client-BIOS-TPM-2.0] and [Canonical-Event-Log]. -8.2. Root of Trust for Measurement +9.2. 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, that is, 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], [SP800-155], [SP800-193]. While there are many complex aspects of a Root of Trust, two aspects @@ -1531,21 +1539,21 @@ 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 [SP800-155]) It's important to note that the trustworthiness of the RTM code cannot be assured by the TPM or TPM supplier - code or procedures external to the TPM must guarantee the security of the RTM. -8.3. Layering Model for Network Equipment Attester and Verifier +9.3. Layering Model for Network Equipment Attester and Verifier Retrieval of identity and attestation state uses one protocol stack, while retrieval of Reference Values uses a different set of protocols. Figure 5 shows the components involved. +-----------------------+ +-------------------------+ | | | | | Attester |<-------------| Verifier | | (Device) |------------->| (Management Station) | | | | | | @@ -1584,21 +1592,21 @@ ************************* ************************ * TLS, SSH * * TLS, SSH * ************************* ************************ Figure 7: RIV Protocol Stacks IETF documents are captured in boxes surrounded by asterisks. TCG documents are shown in boxes surrounded by dots. -8.4. Implementation Notes +9.4. Implementation Notes Figure 8 summarizes many of the actions needed to complete an Attestation system, with links to relevant documents. While documents are controlled by several standards organizations, the implied actions required for implementation are all the responsibility of the manufacturer of the device, unless otherwise noted. It should be noted that, while the YANG model is RECOMMENDED for attestation, this table identifies an optional SNMP MIB as well, [Attest-MIB]. @@ -1671,44 +1679,44 @@ | to several more components: | | | o A Posture Manager Server | | | which collects reports and stores them in | | | a database | | | o One or more Analyzers that can look at the| | | results and figure out what it means. | | -------------------------------------------------------------------- Figure 8: Component Status -9. References +10. References -9.1. Normative References +10.1. Normative References [Canonical-Event-Log] Trusted Computing Group, "DRAFT Canonical Event Log Format Version: 1.0, Revision: .12", October 2018. [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-yang-tpm-charra] Birkholz, H., Eckel, M., Voit, E., Bhandari, S., Sulzen, B., Xia, L., Laffey, T., and G. Fedorkow, "A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs", draft-ietf-rats-yang-tpm-charra-03 (work in progress), September 2020. [I-D.ietf-sacm-coswid] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Waltermire, "Concise Software Identification Tags", draft- - ietf-sacm-coswid-15 (work in progress), May 2020. + ietf-sacm-coswid-16 (work in progress), November 2020. [IEEE-802-1AR] Seaman, M., "802.1AR-2018 - IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity, IEEE Computer Society", August 2018. [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", @@ -1736,20 +1744,25 @@ September 2020, . [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, . + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, . [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, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", @@ -1775,21 +1788,21 @@ Technology Software Asset Management Part 2: Software Identification Tag, ISO/IEC 19770-2", October 2015, . [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, . -9.2. Informative References +10.2. Informative References [AK-Enrollment] Trusted Computing Group, "TCG Infrastructure Working Group - A CMC Profile for AIK Certificate Enrollment Version 1.0, Revision 7", March 2011, . [Attest-MIB] @@ -1823,36 +1836,36 @@ [I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", draft-ietf-rats-architecture-07 (work in progress), October 2020. [I-D.ietf-rats-eat] Mandyam, G., Lundblade, L., Ballesteros, M., and J. O'Donoghue, "The Entity Attestation Token (EAT)", draft- - ietf-rats-eat-04 (work in progress), August 2020. + ietf-rats-eat-06 (work in progress), December 2020. [I-D.richardson-rats-usecases] Richardson, M., Wallace, C., and W. Pan, "Use cases for Remote Attestation common encodings", draft-richardson- - rats-usecases-07 (work in progress), March 2020. + rats-usecases-08 (work in progress), November 2020. [I-D.voit-rats-trusted-path-routing] Voit, E., "Trusted Path Routing", draft-voit-rats-trusted- path-routing-02 (work in progress), June 2020. [IEEE-802.1AE] Seaman, M., "802.1AE MAC Security (MACsec)", 2018, . - [IEEE-802.1x] + [IEEE-802.1X] IEEE Computer Society, "802.1X-2020 - IEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access Control", February 2020, . [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