RATS Working Group J. Zhang Internet-Draft H. Labiod Intended status: Informational T. Li Expires: 4 January 2025 Huawei Technologies T. Giannetsos UbiTech H. Birkholz Fraunhofer SIT 3 July 2024 Handling multiple verifiers in RATS architecture draft-zhang-rats-multiverifiers-00 Abstract In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and generates Attestation Results needed by Relying Parties. This document provides a solution to inconsistent behaviors of the Verifier in the RATS architecture by introducing a mechanism to aggregate Attestation Results collected from multiple Verifiers at the Relying Party while simplifying its policy and operation. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 December 26, 2024. Zhang, et al. Expires 4 January, 2025 [Page 1] Internet-Draft Multiple RATS Verifiers July 2024 Copyright Notice Copyright (c) 2024 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. Table of Contents 1. Introduction................................................2 1.1 Passport model cases.......................................3 1.2 Background check model cases...............................4 2. Terminology................................................5 3. Handing multiple verifiers.................................8 3.1 Aggregation of attestation results from multiple verifiers.8 3.2 Verifier manager..........................................8 4. Use cases...................................................10 5. Security Considerations.....................................11 6. IANA Considerations.........................................13 7. References..................................................13 7.1. Normative References......................................13 7.2. Informative References....................................14 Authors' Addresses.............................................15 1. Introduction Section 3 in the Remote Attestation procedures (RATS) Architecture [RFC9334] gives an overview of the roles and data-flows between them, while Section 5 in [RFC9334] refines the data-flow diagram by describing two reference models: Passport Model and Background- check Model. As discussed in that document, a Verifier accepts Evidence from Attesters, appraises it using Appraisal Policy, and generates Attestation Results needed by Relying Parties. As a single Verifier can introduce a single point of failure, either as the target of a denial of service attack, due to compromization, service congestion, or broken Internet connectivity to the Verifier, relying on a single trusted entity can introduce significant risk. Zhang, et al. Expires 4 January, 2025 [Page 2] Internet-Draft Multiple RATS Verifiers July 2024 The architectural pattern of using multiple Verifiers are one approach to counter such risks. Nevertheless, it is not guaranteed that different Verifiers generate the same Attestation Results. Some exemplary reasons inculde: a) RATS conceptual messages, such as Reference Values, Endorsements, Appraisal Policy for Evidence for different Verifiers, are not necessarily aligned, b) certain Verifiers can be compromised, or c) some Verifiers follow different Appraisal Policy for Evidence. This lack of alignment can result in significant issues in both Passport Model and Background-check Model, which is detailed as follows. The Solution to address the problem of the lack of alignment is detailed in Section 3. 1.1. Passport Model Cases Under the Passport Model, an Attester sends Evidence to a Verifier. The Verifier generates the Attestation Results and sends these back to the Attester. The Attester conveys the Attestation Results to the Relying Party to proof its trustworthiness. Fig. 1 and 2 show scenarios that multiple heterogeneous Verifiers can introduce issues in a Passport Model based system. In Fig. 1, if Verifier A is not trusted by the Relying Party, Attestation Results sent by the Attester can always be rejected by the Relying Party, which means that the Attester may end up in a loop of producing and conveying Attestation Evidence and wait for Attestation Results in vain, repeatedly. In Fig. 2, Verifier A generates positive Attestation Results for an Attester, while Verifier B generates negative Attestation Results for the same Attester. To trick a Relying Party into putting unjustified trust in the Attester, an Attester can act maliciously by selectively forwarding only Attestation Results from Verifier A and not Verifier B. Such malicious behavior would render a trustworthiness assessment of Attesters by the Relying Party biased or unreliable. .-------------. | | Compare Evidence | Verifier A | against appraisal policy | | '--------+----' ^ | Evidence | | Attestation Zhang, et al. Expires 4 January, 2025 [Page 3] Internet-Draft Multiple RATS Verifiers July 2024 | | Result | v .---+--------. .-------------. Compare | +------------>X| | Attestation | Attester | Attestation | Relying | Result against | | Result | Party | appraisal '------------' '-------------' policy Figure 1: Passport Model with Verifier A not trusted by Relying Party. .-------------. | | Compare Evidence | Verifier A | against appraisal policy | | '--------+----' ^ | Evidence | | Attestation | | Result A (positive) | v .---+--------. .-------------. Compare | +------------->| | Attestation | Attester | Attestation | Relying | Result against Zhang, et al. Expires 26 Dec, 2024 [Page 4] Internet-Draft Multiple RATS Verifiers July 2024 | | Result A | Party | appraisal '---+--------' '-------------' policy | ^ Evidence | | Attestation | | Result B (negative) | | V | .--------+----. | | Compare Evidence | Verifier B | against appraisal policy | | '-------------' Figure 2: Passport Model with cheating Attester 1.2. Background-check Model Cases Under the Background-check Model, an Attester sends Evidence to a Verifier via a Relaying Party, and the Verifier generates the Attestation Results and sends them back to the Relying Party. Fig. 3 and 4 show scenarios where multiple heterogeneous Verifiers introduce potential issues in a Background-check Model. In Fig. 3, even if a Verifier is trusted by a Relying Party, there is no assurance that it is working as intended and only does what it is supposed to do and nothing else. If multiple Verifiers exist, neither Evidence might reach all Verifiers nor all Attestation Results might reach the Relying Party due to failing conveyance mechanisms, or due to the Verifier itself being compromised or malfunctioning. Zhang, et al. Expires 4 January, 2025 [Page 5] Internet-Draft Multiple RATS Verifiers July 2024 or hardware problems. In Fig. 4, a Relying Party is able to alternate between Verifiers. When these Verifiers are heterogeneous though, a Relying Party might receive different or conflicting Attestation Results from them, which means the trustworthy assessment of the Attester can rely (and fail) on a specific selection of Verifiers made by at the Relying Party side. .-------------. | | Compare Evidence | Verifier | against | | appraisal | x(2) | policy '--------+----' ^ x(3) Evidence | | Attestation x(1)| Result | v .------------. .----|--------. | +-------------->|---' | Compare | | | | Attestation | Attester | Evidence | Relying | Result against | | | Party | appraisal policy '------------' '-------------' Figure 3: A Background-Check Model where a Verifier is not available because of 1) a Relying Party not being reachable by the Verifier, 2) a malfunction of the Verifier. Zhang, et al. Expires 4 January, 2025 [Page 6] Internet-Draft Multiple RATS Verifiers July 2024 .-------------. | | Compare Evidence | Verifier | against | A | appraisal '--------+----' policy ^ | Evidence | | Attestation | | Result (positive) | v .------------. .----|--------. Compare | +-------------->|---' | Attestation | Attester | Evidence | Relying | Result against | | | Party | appraisal policy '------------' '----+--------' | ^ Evidence | | Attestation | | Result (negative) v | .--------+----. | | Compare Evidence | Verifier | against | B | appraisal '-------------' policy Zhang, et al. Expires 4 January, 2025 [Page 7] Internet-Draft Multiple RATS Verifiers July 2024 Figure 4: A Background-Check Model conveying conflicting Attestation Results originating from multiple Verifiers. 2. Terminology The following terms are imported from [RFC9334]: Attester, Evidence, Endorsement, Reference value, Appraisal Policy, Relying Party, and Verifier. Also imported are the time definitions time(VG), time(NS), time(EG), time(ER), time(RG),time(RX), and time(OP) from that document's Appendix A. New relevant Events over Time: time(AG): the time at the event that the Attestation Results for the same attester is aggregated. 3. Handing Multiple Verifiers In this section, we follow the attestation data-flow based on the Background-Check Model, to support robust aggregation of the Attestation Results in an environment with heterogeneous verifiers. 3.1. Aggregation of Attestation Results from Multiple Verifiers Fig. 5 below is a sequence diagram which updates Fig. 14 in [RFC9334] to support the aggregation of Attestation Results from multiple Verifiers in a Background-check Model. The nonce is generated by the Relying Party, in place of each Verifier, so as to reduce the amount of Evidence generated. The aggregation method implemented by the Relying Party is out of scope of this draft. For example, the majority vote could be viewed as a possible solution. .---------. .--------. .--------. .--------. .---. | Attester| |Verifier| |Verifier| |Verifier| | RP| | | | 1 | | 2 | | k | | | Zhang, et al. Expires 4 January, 2025 [Page 8] Internet-Draft Multiple RATS Verifiers July 2024 '---------' '--------' '--------' '--------' '---' | | | | | Time(VG_a) ~ ~ ~ ~ | | | | | |<----Nonce---------------------------------------time(NS_r) Time(EG_a) | | | | | | | | | |-----Evidence{Nonce}------------------------------------>| | | time(ER_r_1) | |<-----Evidence{Nonce}---------------------| | | | | time(ER_r_2) | time(RG_v_1) |<-Evidence{Nonce}---------------| | | time(RG_v_2) | time(ER_r_k) | | | |<-Evidence{Nonce}--| | | | time(RG_v_k) | | |--Attestation Result--------------------->| | | {time(RX_v_1)-time(RG_v_1)} | | | |----Attestation Result--------->| | | | {time(RX_v_2)-time(RG_v_2)} | | | | |--------AR------->| | | | {time(RX_v_k)-time(RG_v_k)} | | | | | time(AG_r) | | | | time(OP_r) Zhang, et al. Expires 4 January, 2025 [Page 9] Internet-Draft Multiple RATS Verifiers July 2024 Figure 5: Background-Check Model with the support of the aggregation of Attestation Results from multiple Verifiers. 3.2. Verifier Manager Manually configuring the Verifiers in each Relying Party is not well adapted to the changing of the network environment. As there is no guarantee of the availability and consolidation of these Verifiers in the long term. We introduce a new entity in RATS architecture, which is the Verifier manager, to address these issues. As shown in Fig. 6, after configuring the anchor seed Verifiers in the Relying Party, which is typically a small set of trusted Verifiers by the Relying Party. The Relying Party can communicate with the Verifier manager with this list of Verifiers, in together with certain parameters n, for example, the number of Verifiers that it expects to collect Attestation Results from. The Verifier manager matches this list with its local database of the groups of Verifiers, find the groups of Vherifiers that behave most close to the majority of the Verifiers in this list, and picks n Verifiers out of it. Then the Verifier manager sends these n Verifiers back to the Relying Party, as its recommended Verifiers. In such a way, each Relying Party can flexibly configure its policy for the trusted Verifier. .---------. .---------. .--------. .-------------. | Endorser| | Reference | | Verifier | | Relying Party| '-+-------' | Value | | Owner | | Owner | | | Provider | '---+----' '----+--------' | '-----+---' | | | | | | | Endorsements | Reference | Appraisal | Appraisal | | Values | Policy for | Policy for | | | Evidence | Attestation '-----------. | | | Results | | | | v v v | Zhang, et al. Expires 4 January, 2025 [Page 10] Internet-Draft Multiple RATS Verifiers July 2024 .-------------------------. | .------>| Verifier +-----. | | '-------------------------' | | | | | | Evidence Attestation | | | Results | | | | | | v v .-----+----. .---------------. | Attester | | Relying Party | '----------' '---------------' | ^ Anchor seed Verifiers, | | Recommended parameter | | Verifiers | | .------------------. | Verifier Manager | '------------------' Figure 6: Revised Data Flow based RFC9334 Zhang, et al. Expires 4 January, 2025 [Page 11] Internet-Draft Multiple RATS Verifiers July 2024 4. Use Cases This Section illustrates some use cases that can benefit from an architecture that takes multiple Verifiers into account. Use case 1: Intent-driven Attestation Classification for Data Center Network Solutions Need: Establishment of trust in a complex data center environment comprising multiple VMs instantiated on heterogeneous CPU architectures Solution: Attestation Verification Service based on a harmonized set of components to be leveraged by multiple Verifiers Source: TCG Trusted Application Protocol (TAP) Use Cases [TAP] Use case 2: Enhancing TEE Device Interface Security Protocol (TDISP) Need: Enhance Trusted Execution Environment Provisioning (TEEP) Architecture with TEE-I/O capabilities for the direct verification assignment of specific system characteristics to targeted (remote) Verifiers Solution: Harmonized Trusted Computing Base to Achieve Secure interfaces and Key Management with Multiple Verifiers attesting different device properties Source: [RFC9397] on TEEP Architecture Use case 3: Intra- and Inter-Domain Trusted Path Routing Need: Trustworthiness Assessment of routing nodes (Attesters) against multiple Verifiers (Control Plane Orchestrators) residing in different network administrative domain Solution: Verification of multiple attestation formats supporting reference integrity manifest with constrained disclosure Source: Trusted Path Routine Zhang, et al. Expires 4 January, 2025 [Page 12] Internet-Draft Multiple RATS Verifiers July 2024 [I-D.voit-rats-trustworthy-path-routing], network attestation for secure routing [I-D.liu-nasr-requirements] Use case 4: network endpoint assessment Need: provide resilience in the attestation service Source: use case from [RFC9334] Use case 5: Confidential Data Protection Need: avoid single Verifier corruption, which leads to the leakage of data privacy. Source: use case from [RFC9334] 5. Security Considerations [TBD] 6. IANA Considerations [TBD] 7. References 7.1. Normative References [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [I-D.voit-rats-trustworthy-path-routing] Voit, E., Gaddam, C. R., Fedorkow, G., Birkholz, H., and M. Chen, "Trusted Path Routing", Work in Progress, Internet-Draft, draft-voit-rats-trustworthy-path-routing- 09, 22 February 2024, . Zhang, et al. Expires 4 January, 2025 [Page 13] Internet-Draft Multiple RATS Verifiers July 2024 7.2. Informative References [RFC9397] Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, "Trusted Execution Environment Provisioning (TEEP) Architecture", RFC 9397, DOI 10.17487/RFC9397, July 2023, . [I-D.liu-nasr-requirements] Liu, P. C., "NASR Use Case and Requirements", Work in Progress, Internet-Draft, draft- liu-nasr-requirements-01, 8 February 2024, . [TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol (TAP) Information Model for TPM Families 1.2 and 2.0 and DICE Family 1.0", September 2019, . Zhang, et al. Expires 4 January, 2025 [Page 14] Internet-Draft Multiple RATS Verifiers July 2024 Authors' Addresses Jun Zhang Huawei Technologies France S.A.S.U. 18, Quai du Point du Jour, 92100 Boulogne-Billancourt, France Email: junzhang1@huawei.com Houda Labiod Huawei Technologies France S.A.S.U. 18, Quai du Point du Jour, 92100 Boulogne-Billancourt, France Email: houda.labiod@huawei.com Tieyan Li Shield Lab, Singapore Research Center, Huawei Technologies Science Park II., Singapore-Singapore-20 Science Park Road, #03-31, Teletech Park, Singapore Email: Li.Tieyan@huawei.com Thanassis Giannetsos UBITECH Ltd., Thessalias 8 and Etolias 10, GR-15231 Chalandri, Greece. Email: agiannetsos@ubitech.eu Henk Birkholz Fraunhofer SIT Email: henk.birkholz@sit.fraunhofer.de Zhang, et al. Expires 4 January, 2025 [Page 15]