--- 1/draft-ietf-rats-tpm-based-network-device-attest-10.txt 2022-01-29 18:13:11.270601817 -0800 +++ 2/draft-ietf-rats-tpm-based-network-device-attest-11.txt 2022-01-29 18:13:11.362604146 -0800 @@ -1,21 +1,21 @@ RATS Working Group G.C. Fedorkow, Ed. Internet-Draft Juniper Networks, Inc. Intended status: Informational E. Voit -Expires: 3 July 2022 Cisco +Expires: 2 August 2022 Cisco J. Fitzgerald-McKay National Security Agency - 30 December 2021 + 29 January 2022 TPM-based Network Device Remote Integrity Verification - draft-ietf-rats-tpm-based-network-device-attest-10 + draft-ietf-rats-tpm-based-network-device-attest-11 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,25 +25,25 @@ 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 3 July 2022. + This Internet-Draft will expire on 2 August 2022. Copyright Notice - Copyright (c) 2021 IETF Trust and the persons identified as the + 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 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. @@ -77,22 +77,22 @@ 3.2.1. Transport and Encoding . . . . . . . . . . . . . . . 23 3.3. Centralized vs Peer-to-Peer . . . . . . . . . . . . . . . 24 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 5.1. Keys Used in RIV . . . . . . . . . . . . . . . . . . . . 26 5.2. Prevention of Spoofing and Person-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.3. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 29 5.4. Owner-Signed Keys . . . . . . . . . . . . . . . . . . . . 29 5.5. Other Factors for Trustworthy Operation . . . . . . . . . 30 - 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 + 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Using a TPM for Attestation . . . . . . . . . . . . . . . 32 9.2. Root of Trust for Measurement . . . . . . . . . . . . . . 34 9.3. Layering Model for Network Equipment Attester and Verifier . . . . . . . . . . . . . . . . . . . . . . . . 34 9.4. Implementation Notes . . . . . . . . . . . . . . . . . . 36 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 10.2. Informative References . . . . . . . . . . . . . . . . . 40 @@ -178,21 +178,21 @@ attested (e.g., geographic location, connectivity; see [I-D.richardson-rats-usecases]), although it does provide evidence of a secure infrastructure to increase the level of trust in other device characteristics attested by other means (e.g., by Entity Attestation Tokens [I-D.ietf-rats-eat]). In line with [I-D.ietf-rats-architecture] definitions, this document uses the term Endorser to refer to the role that signs identity and attestation certificates used by the Attester, while Reference Values are signed by a Reference Value Provider. Typically, the - manufacturer of an network device would be accepted as both the + manufacturer of a network device would be accepted as both the Endorser and Reference Value Provider, although the choice is ultimately up to the Verifier Owner. 1.3. Document Organization The remainder of this document is organized into several sections: * The remainder of this section covers goals and requirements, plus a top-level description of RIV. @@ -640,41 +640,41 @@ signed by the device manufacturer, containing the device serial number. This requirement goes slightly beyond 802.1AR; see Section 2.4 for notes. * An Attestation key pair and matching certificate is required to sign the Quote generated by the TPM to report evidence of software configuration. In a TPM application, both the Attestation private key and the DevID private key MUST be protected by the TPM. Depending on other TPM - 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]. + configuration procedures, the two keys are likely to 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 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 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 + 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 Attestation Keys (LDevID and LAK) if desired. 2.3. RIV Information Flow RIV workflow for network equipment is organized around a simple use @@ -1400,45 +1400,45 @@ * Designers SHOULD guard against hash collision attacks. Reference Integrity Manifests often give hashes for large objects of indeterminate size; if one of the measured objects can be replaced with an implant engineered to produce the same hash, RIV will be unable to detect the substitution. TPM1.2 uses SHA-1 hashes only, which have been shown to be susceptible to collision attack. TPM2.0 will produce quotes with SHA-256, which so far has resisted such attacks. Consequently, RIV implementations SHOULD use TPM2.0. -6. Conclusion +6. IANA Considerations + + This document has no IANA actions. + +7. Conclusion TCG technologies can play an important part in the implementation of Remote Integrity Verification. Standards for many of the components needed for implementation of RIV already exist: * Platform identity can be based on IEEE 802.1AR Device Identity, coupled with careful supply-chain management by the manufacturer. * Complex supply chains can be certified using TCG Platform Certificates [Platform-Certificates]. - * The TCG TAP mechanism couple with [I-D.ietf-rats-yang-tpm-charra] + * The TCG TAP mechanism coupled with [I-D.ietf-rats-yang-tpm-charra] can be used to retrieve attestation evidence. * Reference Values must be conveyed from the software authority (e.g., the manufacturer) in Reference Integrity Manifests, to the system in which verification will take place. IETF and TCG SWID - and CoSWID work [I-D.ietf-sacm-coswid], [RIM])) forms the basis + and CoSWID work ([I-D.ietf-sacm-coswid], [RIM]) forms the basis for this function. -7. IANA Considerations - - This memo includes no request to IANA. - 8. Acknowledgements The authors wish to thank numerous reviewers for generous assistance, including William Bellingrath, Mark Baushke, Ned Smith, Henk Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas Hardjono, Bill Sulzen, Willard (Monty) Wiseman, Kathleen Moriarty, Nancy Cam-Winget and Shwetha Bhandari 9. Appendix @@ -1696,30 +1696,30 @@ Trusted Computing Group, "DRAFT Canonical Event Log Format Version: 1.0, Revision: .30", December 2020, . [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-11, 26 - August 2021, . + Internet-Draft, draft-ietf-rats-yang-tpm-charra-12, 14 + January 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-19, 20 - October 2021, . + in Progress, Internet-Draft, draft-ietf-sacm-coswid-20, 26 + January 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, . @@ -1825,23 +1825,23 @@ Birkholz, H., Eckel, M., Newton, C., and L. Chen, "Reference Interaction Models for Remote Attestation Procedures", Work in Progress, Internet-Draft, draft- birkholz-rats-reference-interaction-model-03, 7 July 2020, . [I-D.birkholz-rats-tuda] 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, . + Progress, Internet-Draft, draft-birkholz-rats-tuda-06, 12 + January 2022, . [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- 14, 9 December 2021, . [I-D.ietf-rats-eat] Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity