--- 1/draft-ietf-rats-tpm-based-network-device-attest-13.txt 2022-03-22 06:13:11.400679639 -0700 +++ 2/draft-ietf-rats-tpm-based-network-device-attest-14.txt 2022-03-22 06:13:11.492681930 -0700 @@ -1,21 +1,21 @@ RATS Working Group G. C. Fedorkow, Ed. Internet-Draft Juniper Networks, Inc. Intended status: Informational E. Voit -Expires: 2 September 2022 Cisco +Expires: 23 September 2022 Cisco J. Fitzgerald-McKay National Security Agency - 1 March 2022 + 22 March 2022 TPM-based Network Device Remote Integrity Verification - draft-ietf-rats-tpm-based-network-device-attest-13 + draft-ietf-rats-tpm-based-network-device-attest-14 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)), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs. @@ -27,21 +27,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 2 September 2022. + This Internet-Draft will expire on 23 September 2022. Copyright Notice Copyright (c) 2022 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 @@ -288,33 +288,34 @@ configuration are both of critical importance. 2. Device 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. Conveyance of Evidence reliably transports the collected Evidence from Attester to a Verifier to allow a management station to perform a meaningful appraisal in Step 4. 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. It should be noted that critical + typically carried out via a management network. While not + required for reliable attestation, an encrypted channel may be + used to provide integrity, authenticity, or confidentiality once + attestation is complete. It should be noted that critical attestation evidence from the TPM is signed by a key known only to TPM, and is not dependent on encyption carried out as part of a reliable transport. 4. Finally, Appraisal of Evidence occurs. This is the process of verifying the Evidence received by a Verifier from the Attester, and using an Appraisal Policy to develop an Attestation Result, - used to inform decision making. In practice, this means + used to inform decision-making. In practice, this means comparing the Attester's measurements reported as Evidence with - the device configuration expected by the Verifier. Subsequently + the device configuration expected by the Verifier. Subsequently, the Appraisal Policy for Evidence might match Evidence found against Reference Values (aka Golden Measurements), which represent the intended configured state of the connected device. All implementations supporting this RIV specification require the support of the following three technologies: 1. Identity: Device identity in RIV is based on IEEE 802.1AR Device Identity (DevID) [IEEE-802-1AR], coupled with careful supply- chain management by the manufacturer. The Initial DevID (IDevID) @@ -561,21 +562,21 @@ | each boot attempt, and an identifier for | | | | where the loader was found | | | -------------------------------------------------------------------- | Vendor Specific Measurements during boot | 6 | 6 | -------------------------------------------------------------------- | Secure Boot Policy. This PCR records keys | | 7 | | and configuration used to validate the OS | | | | loader | | | -------------------------------------------------------------------- | Measurements made by the OS Loader | 8 | 9 | - | (e.g GRUB2 for Linux) | | | + | (e.g. GRUB2 for Linux) | | | -------------------------------------------------------------------- | Measurements made by OS (e.g., Linux IMA) | 10 | 10 | +------------------------------------------------------------------+ Figure 2: Attested Objects 2.1.2. Notes on PCR Allocations It is important to recognize that PCR[0] is critical. The first measurement into PCR[0] is taken by the Root of Trust for @@ -904,21 +905,21 @@ * TCG Canonical Event Log [Canonical-Event-Log] 3. Standards Components 3.1. Prerequisites for RIV The Reference Interaction Model for Challenge-Response-based Remote Attestation ([I-D.birkholz-rats-reference-interaction-model]) is based on the standard roles defined in [I-D.ietf-rats-architecture]. - However additional prerequisites have been established to allow for + However, additional prerequisites have been established to allow for interoperable RIV use case implementations. These prerequisites are intended to provide sufficient context information so that the Verifier can acquire and evaluate measurements collected by the Attester. 3.1.1. Unique Device Identity A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID certificate [IEEE-802-1AR] must be provisioned in the Attester's TPMs. @@ -1064,22 +1065,21 @@ negotiating a trust relationship, the two peers can each ask the other to prove software integrity. In this application, the information flow is the same, but each side plays a role both as an Attester and a Verifier. Each device issues a challenge, and each device responds to the other's challenge, as shown in Figure 5. Peer-to-peer challenges, particularly if used to establish a trust relationship between routers, require devices to carry their own signed reference measurements (RIMs). Devices may also have to carry Appraisal Policy for Evidence for each possible peer device so that each device has everything needed for remote attestation, without - having to resort to a central authority. Details of peer-to-peer - operation are out of scope for this document. + having to resort to a central authority. +---------------+ +---------------+ | RefVal | | RefVal | | Provider A | | Provider B | | Firmware | | Firmware | | Configuration | | Configuration | | Authority | | Authority | | | | | +---------------+ +---------------+ | | @@ -1103,21 +1103,22 @@ +------------+ Step 3 +------------+ / Figure 5: 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 enclosed over a variant of EAP [RFC3748] or LLDP [LLDP] are suitable - methods for such an exchange. + methods for such an exchange. Details of peer-to-peer operation are + out of scope for this document. 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: * Packets passing through the device must not be sent to unauthorized destinations. For example: @@ -1261,26 +1262,26 @@ Requiring measurements 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 in the RTM; 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 implementation MUST preserve the TPM signing, so - that tampering anywhere in the path between the TPM itself and the + structures in their TCG-defined 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 another layer of signing using external + keys, the implementation MUST 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 Person-in-the-Middle Attacks Prevention of spoofing attacks against attestation systems is also important. There are several cases to consider: * The entire device could be spoofed. If the Verifier goes to appraise a specific Attester, it might be redirected to a different Attester. @@ -1740,30 +1741,30 @@ W. Pan, "Remote Attestation Procedures Architecture", Work in Progress, Internet-Draft, draft-ietf-rats-architecture- 15, 8 February 2022, . [I-D.ietf-rats-yang-tpm-charra] Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen, B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A YANG Data Model for Challenge-Response-based Remote Attestation Procedures using TPMs", Work in Progress, - Internet-Draft, draft-ietf-rats-yang-tpm-charra-15, 28 - February 2022, . + Internet-Draft, draft-ietf-rats-yang-tpm-charra-18, 20 + March 2022, . [I-D.ietf-sacm-coswid] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Waltermire, "Concise Software Identification Tags", Work - in Progress, Internet-Draft, draft-ietf-sacm-coswid-20, 26 - January 2022, . + in Progress, Internet-Draft, draft-ietf-sacm-coswid-21, 7 + March 2022, . [IEEE-802-1AR] Seaman, M., "802.1AR-2018 - IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity, IEEE Computer Society", August 2018. [IMA] dsafford, kds_etu, mzohar, reinersailer, and serge_hallyn, "Integrity Measurement Architecture", June 2019, .