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