| < draft-ietf-rats-tpm-based-network-device-attest-13.txt | draft-ietf-rats-tpm-based-network-device-attest-14.txt > | |||
|---|---|---|---|---|
| RATS Working Group G. C. Fedorkow, Ed. | RATS Working Group G. C. Fedorkow, Ed. | |||
| Internet-Draft Juniper Networks, Inc. | Internet-Draft Juniper Networks, Inc. | |||
| Intended status: Informational E. Voit | Intended status: Informational E. Voit | |||
| Expires: 2 September 2022 Cisco | Expires: 23 September 2022 Cisco | |||
| J. Fitzgerald-McKay | J. Fitzgerald-McKay | |||
| National Security Agency | National Security Agency | |||
| 1 March 2022 | 22 March 2022 | |||
| TPM-based Network Device Remote Integrity Verification | 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 | Abstract | |||
| This document describes a workflow for remote attestation of the | This document describes a workflow for remote attestation of the | |||
| integrity of firmware and software installed on network devices that | integrity of firmware and software installed on network devices that | |||
| contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by | contain Trusted Platform Modules [TPM1.2], [TPM2.0], as defined by | |||
| the Trusted Computing Group (TCG)), or equivalent hardware | the Trusted Computing Group (TCG)), or equivalent hardware | |||
| implementations that include the protected capabilities, as provided | implementations that include the protected capabilities, as provided | |||
| by TPMs. | by TPMs. | |||
| skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | 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 Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 7, line 13 ¶ | skipping to change at page 7, line 13 ¶ | |||
| configuration are both of critical importance. | configuration are both of critical importance. | |||
| 2. Device Identification refers to the mechanism assuring the | 2. Device Identification refers to the mechanism assuring the | |||
| Relying Party (ultimately, a network administrator) of the | Relying Party (ultimately, a network administrator) of the | |||
| identity of devices that make up their network, and that their | identity of devices that make up their network, and that their | |||
| manufacturers are known. | manufacturers are known. | |||
| 3. Conveyance of Evidence reliably transports the collected Evidence | 3. Conveyance of Evidence reliably transports the collected Evidence | |||
| from Attester to a Verifier to allow a management station to | from Attester to a Verifier to allow a management station to | |||
| perform a meaningful appraisal in Step 4. The transport is | perform a meaningful appraisal in Step 4. The transport is | |||
| typically carried out via a management network. The channel must | typically carried out via a management network. While not | |||
| provide integrity and authenticity, and, in some use cases, may | required for reliable attestation, an encrypted channel may be | |||
| also require confidentiality. It should be noted that critical | 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 | 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 | to TPM, and is not dependent on encyption carried out as part of | |||
| a reliable transport. | a reliable transport. | |||
| 4. Finally, Appraisal of Evidence occurs. This is the process of | 4. Finally, Appraisal of Evidence occurs. This is the process of | |||
| verifying the Evidence received by a Verifier from the Attester, | verifying the Evidence received by a Verifier from the Attester, | |||
| and using an Appraisal Policy to develop an Attestation Result, | 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 | 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 | the Appraisal Policy for Evidence might match Evidence found | |||
| against Reference Values (aka Golden Measurements), which | against Reference Values (aka Golden Measurements), which | |||
| represent the intended configured state of the connected device. | represent the intended configured state of the connected device. | |||
| All implementations supporting this RIV specification require the | All implementations supporting this RIV specification require the | |||
| support of the following three technologies: | support of the following three technologies: | |||
| 1. Identity: Device identity in RIV is based on IEEE 802.1AR Device | 1. Identity: Device identity in RIV is based on IEEE 802.1AR Device | |||
| Identity (DevID) [IEEE-802-1AR], coupled with careful supply- | Identity (DevID) [IEEE-802-1AR], coupled with careful supply- | |||
| chain management by the manufacturer. The Initial DevID (IDevID) | chain management by the manufacturer. The Initial DevID (IDevID) | |||
| skipping to change at page 13, line 28 ¶ | skipping to change at page 13, line 28 ¶ | |||
| | each boot attempt, and an identifier for | | | | | each boot attempt, and an identifier for | | | | |||
| | where the loader was found | | | | | where the loader was found | | | | |||
| -------------------------------------------------------------------- | -------------------------------------------------------------------- | |||
| | Vendor Specific Measurements during boot | 6 | 6 | | | Vendor Specific Measurements during boot | 6 | 6 | | |||
| -------------------------------------------------------------------- | -------------------------------------------------------------------- | |||
| | Secure Boot Policy. This PCR records keys | | 7 | | | Secure Boot Policy. This PCR records keys | | 7 | | |||
| | and configuration used to validate the OS | | | | | and configuration used to validate the OS | | | | |||
| | loader | | | | | loader | | | | |||
| -------------------------------------------------------------------- | -------------------------------------------------------------------- | |||
| | Measurements made by the OS Loader | 8 | 9 | | | 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 | | | Measurements made by OS (e.g., Linux IMA) | 10 | 10 | | |||
| +------------------------------------------------------------------+ | +------------------------------------------------------------------+ | |||
| Figure 2: Attested Objects | Figure 2: Attested Objects | |||
| 2.1.2. Notes on PCR Allocations | 2.1.2. Notes on PCR Allocations | |||
| It is important to recognize that PCR[0] is critical. The first | It is important to recognize that PCR[0] is critical. The first | |||
| measurement into PCR[0] is taken by the Root of Trust for | measurement into PCR[0] is taken by the Root of Trust for | |||
| skipping to change at page 20, line 38 ¶ | skipping to change at page 20, line 38 ¶ | |||
| * TCG Canonical Event Log [Canonical-Event-Log] | * TCG Canonical Event Log [Canonical-Event-Log] | |||
| 3. Standards Components | 3. Standards Components | |||
| 3.1. Prerequisites for RIV | 3.1. Prerequisites for RIV | |||
| The Reference Interaction Model for Challenge-Response-based Remote | The Reference Interaction Model for Challenge-Response-based Remote | |||
| Attestation ([I-D.birkholz-rats-reference-interaction-model]) is | Attestation ([I-D.birkholz-rats-reference-interaction-model]) is | |||
| based on the standard roles defined in [I-D.ietf-rats-architecture]. | 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 | interoperable RIV use case implementations. These prerequisites are | |||
| intended to provide sufficient context information so that the | intended to provide sufficient context information so that the | |||
| Verifier can acquire and evaluate measurements collected by the | Verifier can acquire and evaluate measurements collected by the | |||
| Attester. | Attester. | |||
| 3.1.1. Unique Device Identity | 3.1.1. Unique Device Identity | |||
| A secure Device Identity (DevID) in the form of an IEEE 802.1AR DevID | 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 | certificate [IEEE-802-1AR] must be provisioned in the Attester's | |||
| TPMs. | TPMs. | |||
| skipping to change at page 24, line 19 ¶ | skipping to change at page 24, line 19 ¶ | |||
| negotiating a trust relationship, the two peers can each ask the | negotiating a trust relationship, the two peers can each ask the | |||
| other to prove software integrity. In this application, the | other to prove software integrity. In this application, the | |||
| information flow is the same, but each side plays a role both as an | 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 | Attester and a Verifier. Each device issues a challenge, and each | |||
| device responds to the other's challenge, as shown in Figure 5. | device responds to the other's challenge, as shown in Figure 5. | |||
| Peer-to-peer challenges, particularly if used to establish a trust | Peer-to-peer challenges, particularly if used to establish a trust | |||
| relationship between routers, require devices to carry their own | relationship between routers, require devices to carry their own | |||
| signed reference measurements (RIMs). Devices may also have to carry | signed reference measurements (RIMs). Devices may also have to carry | |||
| Appraisal Policy for Evidence for each possible peer device so that | Appraisal Policy for Evidence for each possible peer device so that | |||
| each device has everything needed for remote attestation, without | each device has everything needed for remote attestation, without | |||
| having to resort to a central authority. Details of peer-to-peer | having to resort to a central authority. | |||
| operation are out of scope for this document. | ||||
| +---------------+ +---------------+ | +---------------+ +---------------+ | |||
| | RefVal | | RefVal | | | RefVal | | RefVal | | |||
| | Provider A | | Provider B | | | Provider A | | Provider B | | |||
| | Firmware | | Firmware | | | Firmware | | Firmware | | |||
| | Configuration | | Configuration | | | Configuration | | Configuration | | |||
| | Authority | | Authority | | | Authority | | Authority | | |||
| | | | | | | | | | | |||
| +---------------+ +---------------+ | +---------------+ +---------------+ | |||
| | | | | | | |||
| skipping to change at page 25, line 11 ¶ | skipping to change at page 25, line 11 ¶ | |||
| +------------+ Step 3 +------------+ / | +------------+ Step 3 +------------+ / | |||
| Figure 5: Peer-to-Peer Attestation Information Flow | Figure 5: Peer-to-Peer Attestation Information Flow | |||
| In this application, each device may need to be equipped with signed | 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 | 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 | 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 | 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 | 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 | 4. Privacy Considerations | |||
| Network equipment, such as routers, switches and firewalls, has a key | Network equipment, such as routers, switches and firewalls, has a key | |||
| role to play in guarding the privacy of individuals using the | role to play in guarding the privacy of individuals using the | |||
| network. Network equipment generally adheres to several rules to | network. Network equipment generally adheres to several rules to | |||
| protect privacy: | protect privacy: | |||
| * Packets passing through the device must not be sent to | * Packets passing through the device must not be sent to | |||
| unauthorized destinations. For example: | unauthorized destinations. For example: | |||
| skipping to change at page 28, line 30 ¶ | skipping to change at page 28, line 30 ¶ | |||
| Requiring measurements of the operating software to be signed by a | 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 | 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 | operating software (beyond the first measurement in the RTM; see | |||
| below); any changes to the quote, generated and signed by the TPM | 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 | itself, made by malicious device software, or in the path back to the | |||
| Verifier, will invalidate the signature on the quote. | Verifier, will invalidate the signature on the quote. | |||
| A critical feature of the YANG model described in | A critical feature of the YANG model described in | |||
| [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data | [I-D.ietf-rats-yang-tpm-charra] is the ability to carry TPM data | |||
| structures in their native format, without requiring any changes to | structures in their TCG-defined format, without requiring any changes | |||
| the structures as they were signed and delivered by the TPM. While | to the structures as they were signed and delivered by the TPM. | |||
| alternate methods of conveying TPM quotes could compress out | While alternate methods of conveying TPM quotes could compress out | |||
| redundant information, or add an additional layer of signing using | redundant information, or add another layer of signing using external | |||
| external keys, the implementation MUST preserve the TPM signing, so | keys, the implementation MUST preserve the TPM signing, so that | |||
| that tampering anywhere in the path between the TPM itself and the | tampering anywhere in the path between the TPM itself and the | |||
| Verifier can be detected. | Verifier can be detected. | |||
| 5.2. Prevention of Spoofing and Person-in-the-Middle Attacks | 5.2. Prevention of Spoofing and Person-in-the-Middle Attacks | |||
| Prevention of spoofing attacks against attestation systems is also | Prevention of spoofing attacks against attestation systems is also | |||
| important. There are several cases to consider: | important. There are several cases to consider: | |||
| * The entire device could be spoofed. If the Verifier goes to | * The entire device could be spoofed. If the Verifier goes to | |||
| appraise a specific Attester, it might be redirected to a | appraise a specific Attester, it might be redirected to a | |||
| different Attester. | different Attester. | |||
| skipping to change at page 39, line 17 ¶ | skipping to change at page 39, line 17 ¶ | |||
| W. Pan, "Remote Attestation Procedures Architecture", Work | W. Pan, "Remote Attestation Procedures Architecture", Work | |||
| in Progress, Internet-Draft, draft-ietf-rats-architecture- | in Progress, Internet-Draft, draft-ietf-rats-architecture- | |||
| 15, 8 February 2022, <https://www.ietf.org/archive/id/ | 15, 8 February 2022, <https://www.ietf.org/archive/id/ | |||
| draft-ietf-rats-architecture-15.txt>. | draft-ietf-rats-architecture-15.txt>. | |||
| [I-D.ietf-rats-yang-tpm-charra] | [I-D.ietf-rats-yang-tpm-charra] | |||
| Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen, | Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen, | |||
| B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A | B., (Frank), L. X., Laffey, T., and G. C. Fedorkow, "A | |||
| YANG Data Model for Challenge-Response-based Remote | YANG Data Model for Challenge-Response-based Remote | |||
| Attestation Procedures using TPMs", Work in Progress, | Attestation Procedures using TPMs", Work in Progress, | |||
| Internet-Draft, draft-ietf-rats-yang-tpm-charra-15, 28 | Internet-Draft, draft-ietf-rats-yang-tpm-charra-18, 20 | |||
| February 2022, <https://www.ietf.org/archive/id/draft- | March 2022, <https://www.ietf.org/archive/id/draft-ietf- | |||
| ietf-rats-yang-tpm-charra-15.txt>. | rats-yang-tpm-charra-18.txt>. | |||
| [I-D.ietf-sacm-coswid] | [I-D.ietf-sacm-coswid] | |||
| Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. | Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. | |||
| Waltermire, "Concise Software Identification Tags", Work | Waltermire, "Concise Software Identification Tags", Work | |||
| in Progress, Internet-Draft, draft-ietf-sacm-coswid-20, 26 | in Progress, Internet-Draft, draft-ietf-sacm-coswid-21, 7 | |||
| January 2022, <https://www.ietf.org/archive/id/draft-ietf- | March 2022, <https://www.ietf.org/archive/id/draft-ietf- | |||
| sacm-coswid-20.txt>. | sacm-coswid-21.txt>. | |||
| [IEEE-802-1AR] | [IEEE-802-1AR] | |||
| Seaman, M., "802.1AR-2018 - IEEE Standard for Local and | Seaman, M., "802.1AR-2018 - IEEE Standard for Local and | |||
| Metropolitan Area Networks - Secure Device Identity, IEEE | Metropolitan Area Networks - Secure Device Identity, IEEE | |||
| Computer Society", August 2018. | Computer Society", August 2018. | |||
| [IMA] dsafford, kds_etu, mzohar, reinersailer, and serge_hallyn, | [IMA] dsafford, kds_etu, mzohar, reinersailer, and serge_hallyn, | |||
| "Integrity Measurement Architecture", June 2019, | "Integrity Measurement Architecture", June 2019, | |||
| <https://sourceforge.net/p/linux-ima/wiki/Home/>. | <https://sourceforge.net/p/linux-ima/wiki/Home/>. | |||
| End of changes. 14 change blocks. | ||||
| 26 lines changed or deleted | 27 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||