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/