draft-ietf-rats-tpm-based-network-device-attest-09.txt   draft-ietf-rats-tpm-based-network-device-attest-10.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: 22 May 2022 Cisco Expires: 3 July 2022 Cisco
J. Fitzgerald-McKay J. Fitzgerald-McKay
National Security Agency National Security Agency
18 November 2021 30 December 2021
TPM-based Network Device Remote Integrity Verification TPM-based Network Device Remote Integrity Verification
draft-ietf-rats-tpm-based-network-device-attest-09 draft-ietf-rats-tpm-based-network-device-attest-10
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). the Trusted Computing Group (TCG).
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 22 May 2022. This Internet-Draft will expire on 3 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 10, line 45 skipping to change at page 10, line 45
* Once the device is running and has operational network * Once the device is running and has operational network
connectivity, verification can take place. A separate Verifier, connectivity, verification can take place. A separate Verifier,
running in its own trusted environment, will interrogate the running in its own trusted environment, will interrogate the
network device to retrieve the logs and a copy of the digests network device to retrieve the logs and a copy of the digests
collected by hashing each software object, signed by an collected by hashing each software object, signed by an
attestation private key secured by, but never released by, the attestation private key secured by, but never released by, the
TPM. The YANG model described in [I-D.ietf-rats-yang-tpm-charra] TPM. The YANG model described in [I-D.ietf-rats-yang-tpm-charra]
facilitates this operation. facilitates this operation.
The result is that the Verifier can verify the device's identity by The result is that the Verifier can verify the device's identity by
checking the subjectName and signature of the certificate containing checking the subject attribute of the distinguished name and
the TPM's attestation public key, and can validate the software that signature of the certificate containing the TPM's attestation public
was launched by verifying the correctness of the logs by comparing key, and can validate the software that was launched by verifying the
with the signed digests from the TPM, and comparing digests in the correctness of the logs by comparing with the signed digests from the
log with Reference Values. TPM, and comparing digests in the log with Reference Values.
It should be noted that attestation and identity are inextricably It should be noted that attestation and identity are inextricably
linked; signed Evidence that a particular version of software was linked; signed Evidence that a particular version of software was
loaded is of little value without cryptographic proof of the identity loaded is of little value without cryptographic proof of the identity
of the Attester producing the Evidence. of the Attester producing the Evidence.
+-------------------------------------------------------+ +-------------------------------------------------------+
| +--------+ +--------+ +--------+ +---------+ | | +---------+ +--------+ +--------+ +---------+ |
| | BIOS |--->| Loader |-->| Kernel |--->|Userland | | | |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |
| +--------+ +--------+ +--------+ +---------+ | | +---------+ +--------+ +--------+ +---------+ |
| | | | | | | | | |
| | | | | | | | | |
| +------------+-----------+-+ | | +------------+-----------+-+ |
| Boot Phase | | | Boot Phase | |
| V | | V |
| +--------+ | | +--------+ |
| | TPM | | | | TPM | |
| +--------+ | | +--------+ |
| Router | | | Router | |
+--------------------------------|----------------------+ +--------------------------------|----------------------+
skipping to change at page 15, line 32 skipping to change at page 15, line 32
configuration procedures, the two keys are likely be different; some configuration procedures, the two keys are likely be different; some
of the considerations are outlined in TCG "TPM 2.0 Keys for Device of the considerations are outlined in TCG "TPM 2.0 Keys for Device
Identity and Attestation" [Platform-DevID-TPM-2.0]. Identity and Attestation" [Platform-DevID-TPM-2.0].
The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies The TCG TPM 2.0 Keys document [Platform-DevID-TPM-2.0] specifies
further conventions for these keys: further conventions for these keys:
* When separate Identity and Attestation keys are used, the * When separate Identity and Attestation keys are used, the
Attestation Key (AK) and its X.509 certificate should parallel the Attestation Key (AK) and its X.509 certificate should parallel the
DevID, with the same device ID information as the DevID DevID, with the same device ID information as the DevID
certificate (that is, the same subjectName and subjectAltName (if certificate (that is, the same subject and subjectAltName (if
present), even though the key pairs are different). This allows a present), even though the key pairs are different). This allows a
quote from the device, signed by an AK, to be linked directly to quote from the device, signed by an AK, to be linked directly to
the device that provided it, by examining the corresponding AK the device that provided it, by examining the corresponding AK
certificate. If the subjectName in the AK certificate doesn't certificate. If the subject in the AK certificate doesn't match
match the corresponding DevID certificate, or they're signed by the corresponding DevID certificate, or they're signed by
differing authorities the Verifier may signal the detection of an differing authorities the Verifier may signal the detection of an
Asokan-style person-in-the-middle attack (see Section 5.2). Asokan-style person-in-the-middle attack (see Section 5.2).
* Network devices that are expected to use secure zero touch * Network devices that are expected to use secure zero touch
provisioning as specified in [RFC8572]) MUST be shipped by the provisioning as specified in [RFC8572]) MUST be shipped by the
manufacturer with pre-provisioned keys (Initial DevID and Initial manufacturer with pre-provisioned keys (Initial DevID and Initial
AK, called IDevID and IAK). IDevID and IAK certificates MUST both AK, called IDevID and IAK). IDevID and IAK certificates MUST both
be signed by the Endorser (typically the device manufacturer). be signed by the Endorser (typically the device manufacturer).
Inclusion of an IDevID and IAK by a vendor does not preclude a Inclusion of an IDevID and IAK by a vendor does not preclude a
mechanism whereby an administrator can define Local Identity and mechanism whereby an administrator can define Local Identity and
skipping to change at page 18, line 18 skipping to change at page 18, line 18
2.4. RIV Simplifying Assumptions 2.4. RIV Simplifying Assumptions
This document makes the following simplifying assumptions to reduce This document makes the following simplifying assumptions to reduce
complexity: complexity:
* The product to be attested MUST be shipped by the equipment vendor * The product to be attested MUST be shipped by the equipment vendor
with both an IEEE 802.1AR Device Identity and an Initial with both an IEEE 802.1AR Device Identity and an Initial
Attestation Key (IAK) with certificate in place. The IAK Attestation Key (IAK) with certificate in place. The IAK
certificate MUST contain the same identity information as the certificate MUST contain the same identity information as the
DevID (specifically, the same subjectName and subjectAltName (if DevID (specifically, the same subject and subjectAltName (if
used), signed by the manufacturer), but it's a type of key that used), signed by the manufacturer), but it's a type of key that
can be used to sign a TPM Quote, but not other objects (i.e., it's can be used to sign a TPM Quote, but not other objects (i.e., it's
marked as a TCG "Restricted" key; this convention is described in marked as a TCG "Restricted" key; this convention is described in
"TPM 2.0 Keys for Device Identity and Attestation" "TPM 2.0 Keys for Device Identity and Attestation"
[Platform-DevID-TPM-2.0]). For network equipment, which is [Platform-DevID-TPM-2.0]). For network equipment, which is
generally non-privacy-sensitive, shipping a device with both an generally non-privacy-sensitive, shipping a device with both an
IDevID and an IAK already provisioned substantially simplifies IDevID and an IAK already provisioned substantially simplifies
initial startup. initial startup.
* IEEE 802.1AR does not require a product serial number as part of * IEEE 802.1AR does not require a product serial number as part of
the subjectName, but RIV-compliant devices MUST include their the subject, but RIV-compliant devices MUST include their serial
serial numbers in the DevID/IAK certificates to simplify tracking numbers in the DevID/IAK certificates to simplify tracking
logistics for network equipment users. All other optional 802.1AR logistics for network equipment users. All other optional 802.1AR
fields remain optional in RIV fields remain optional in RIV
* The product MUST be equipped with a Root of Trust for Measurement * The product MUST be equipped with a Root of Trust for Measurement
(RTM), Root of Trust for Storage and Root of Trust for Reporting (RTM), Root of Trust for Storage and Root of Trust for Reporting
(as defined in [SP800-155]) which together are capable of (as defined in [SP800-155]) which together are capable of
conforming to TCG Trusted Attestation Protocol Information Model conforming to TCG Trusted Attestation Protocol Information Model
[TAP]. [TAP].
* The authorized software supplier MUST make available Reference * The authorized software supplier MUST make available Reference
skipping to change at page 36, line 51 skipping to change at page 36, line 51
-------------------------------------------------------------------- --------------------------------------------------------------------
| Connect the TPM to the TLS stack | Vendor TLS | | Connect the TPM to the TLS stack | Vendor TLS |
| o Use the DevID in the TPM to authenticate | stack (This | | o Use the DevID in the TPM to authenticate | stack (This |
| TAP connections, identifying the device | action is | | TAP connections, identifying the device | action is |
| | simply | | | simply |
| | configuring TLS| | | configuring TLS|
| | to use the DevID | | | to use the DevID |
| | as its client | | | as its client |
| | certificate) | | | certificate) |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Make CoSWID tags for BIOS/LoaderLKernel objects | IETF CoSWID | | Make CoSWID tags for BIOS/Loader/Kernel objects | IETF CoSWID |
| o Add reference measurements into SWID tags | ISO/IEC 19770-2| | o Add reference measurements into SWID tags | ISO/IEC 19770-2|
| o Manufacturer should sign the SWID tags | NIST IR 8060 | | o Manufacturer should sign the SWID tags | NIST IR 8060 |
| o The TCG RIM-IM identifies further | | | o The TCG RIM-IM identifies further | |
| procedures to create signed RIM | | | procedures to create signed RIM | |
| documents that provide the necessary | | | documents that provide the necessary | |
| reference information | | | reference information | |
-------------------------------------------------------------------- --------------------------------------------------------------------
| Package the SWID tags with a vendor software | Retrieve tags | | Package the SWID tags with a vendor software | Retrieve tags |
| release | with | | release | with |
| o A tag-generator plugin such | I-D.ietf-sacm-coswid| | o A tag-generator plugin such | I-D.ietf-sacm-coswid|
skipping to change at page 41, line 9 skipping to change at page 41, line 9
Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann, Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann,
"Time-Based Uni-Directional Attestation", Work in "Time-Based Uni-Directional Attestation", Work in
Progress, Internet-Draft, draft-birkholz-rats-tuda-05, 12 Progress, Internet-Draft, draft-birkholz-rats-tuda-05, 12
July 2021, <https://www.ietf.org/archive/id/draft- July 2021, <https://www.ietf.org/archive/id/draft-
birkholz-rats-tuda-05.txt>. birkholz-rats-tuda-05.txt>.
[I-D.ietf-rats-architecture] [I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
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-
13, 8 November 2021, <https://www.ietf.org/archive/id/ 14, 9 December 2021, <https://www.ietf.org/archive/id/
draft-ietf-rats-architecture-13.txt>. draft-ietf-rats-architecture-14.txt>.
[I-D.ietf-rats-eat] [I-D.ietf-rats-eat]
Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity
Attestation Token (EAT)", Work in Progress, Internet- Attestation Token (EAT)", Work in Progress, Internet-
Draft, draft-ietf-rats-eat-11, 24 October 2021, Draft, draft-ietf-rats-eat-11, 24 October 2021,
<https://www.ietf.org/archive/id/draft-ietf-rats-eat- <https://www.ietf.org/archive/id/draft-ietf-rats-eat-
11.txt>. 11.txt>.
[I-D.richardson-rats-usecases] [I-D.richardson-rats-usecases]
Richardson, M., Wallace, C., and W. Pan, "Use cases for Richardson, M., Wallace, C., and W. Pan, "Use cases for
 End of changes. 12 change blocks. 
21 lines changed or deleted 21 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/