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