Handling Multiple Verifiers in the RATS Architecture
draft-zhang-rats-multiverifiers-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | zhang jun , Houda Labiod , Tieyan Li , Thanassis Giannetsos , Henk Birkholz | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhang-rats-multiverifiers-01
RATS J. Zhang
Internet-Draft H. Labiod
Intended status: Standards Track Huawei Technologies France S.A.S.U.
Expires: 24 April 2025 T. Li
Shield Lab, Singapore Research Center, Huawei Technologies
T. Giannetsos
UBITECH Ltd.
H. Birkholz
Fraunhofer SIT
21 October 2024
Handling Multiple Verifiers in the RATS Architecture
draft-zhang-rats-multiverifiers-01
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 24 April 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires 24 April 2025 [Page 1]
Internet-Draft Multiple RATS Verifiers October 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Handing Multiple Verifiers . . . . . . . . . . . . . . . . . 6
3.1. Aggregation of Attestation Results from Multiple
Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Verifier Manager . . . . . . . . . . . . . . . . . . . . 8
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Consideration . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The Remote Attestation procedures (RATS) Architecture illustrates an
overview of the roles and data-flows between them in Section 3 of
[RFC9334]. Section 5 of [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.
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 include: a) RATS conceptual messages, such as
Reference Values, Endorsements, Appraisal Policy for Evidence for
different Verifiers, are not necessarily aligned, b) certain
Zhang, et al. Expires 24 April 2025 [Page 2]
Internet-Draft Multiple RATS Verifiers October 2024
Verifiers can be compromised, or c) some Verifiers follow different
Appraisal Policies 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
| | 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.
Zhang, et al. Expires 24 April 2025 [Page 3]
Internet-Draft Multiple RATS Verifiers October 2024
.-------------.
| | Compare Evidence
| Verifier A | against appraisal policy
| |
'--------+----'
^ |
Evidence | | Attestation
| | Result A (positive)
| v
.---+--------. .-------------. Compare
| +------------->| | Attestation
| Attester | Attestation | Relying | Result against
| | Result A | Party | appraisal
'---+--------' '-------------' policy
| ^
Evidence | | Attestation
| | Result B (negative)
| |
V |
.--------+----.
| | Compare Evidence
| Verifier B | against appraisal policy
| |
'-------------'
Figure 2: Passport Model with a 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., or hardware problems.
Zhang, et al. Expires 24 April 2025 [Page 4]
Internet-Draft Multiple RATS Verifiers October 2024
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 24 April 2025 [Page 5]
Internet-Draft Multiple RATS Verifiers October 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
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 show the data-flow to support robust aggregation
of the Attestation Results in an in an environment with many
Verifiers that may be heterogeneous. Here heterogeneous means that
the Verifiers may generate different Attestation Results according to
the same input of the Evidence.
Zhang, et al. Expires 24 April 2025 [Page 6]
Internet-Draft Multiple RATS Verifiers October 2024
Below are the examples that the Relying Party needs multiple
Verifiers. 1) To get Attestation Results from multiple Verifiers that
follow the same golden measurement, to provide resillience against
failure or compromisation of certain Verifiers. In this case, the
Attestation Results are expected to be the same from these Verifiers.
2) Different Verifiers provide different Attestation Results
according to different sub part of the same Evidence. The Relying
Party makes it own judgement according to its own logic to combine
these heterogeneous Attestation Results. In this case, the
Attestation Results can be expected to be different from different
Verifiers.
In terms of resilience, these Verifiers cannot be replaced by a
conceptual single (proxy) Verifier as this single Verifier may still
has the availability issue.
As an example, we extend the attestation data-flow based on the
Background-Check Model to handel multiple Verifiers that guarantee
the freshness of the Evidence from the Attester. The Verifier
Manager is introduced into the attestation system to help the Relying
Party choosing Verifiers that are aggregable according to its own
logic, that is, the Relying Party has one mechanism to combine
Attestation Results from these Verifiers to make the final
conclusion.
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, when the
Verifiers are expected to follow the same standard. The Attestation
Results can be aggregated to help the Relying Party making the
decision, or be aggregated as a new Attestation Result, which is
decided by the Relying Party itself.
Zhang, et al. Expires 24 April 2025 [Page 7]
Internet-Draft Multiple RATS Verifiers October 2024
.---------. .--------. .--------. .--------. .---.
| Attester| |Verifier| |Verifier| |Verifier| | RP|
| | | 1 | | 2 | | k | | |
'---------' '--------' '--------' '--------' '---'
| | | | |
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)
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.
The Verifier manager matches this list with its local database of the
groups of Verifiers, find Verifiers that matches the parameter. Then
the Verifier Manager sends these Verifiers back to the Relying Party,
as its recommended Verifiers list. In such a way, each Relying Party
can flexibly configure its policy for the trusted Verifier, without
knowing the detail of every Verifier. At the Verifier Manager side,
the Verifiers in the same group are expected to follow the same
Zhang, et al. Expires 24 April 2025 [Page 8]
Internet-Draft Multiple RATS Verifiers October 2024
golden measurement, that is, they are expected to generate the same
Attestation Results when they receive the same Evidences. The
example are the Verifiers that are deployed by the same company or
the alliance. Here the same for Evidences and Attestation Results
are in the sense of semantic, that is, they can be wrapped in
different formats, CWT or JWT for example, but the content itself is
the same. When a Relying Party receives certain minority attesation
results from certain Verifiers, it can inform the Verifier Manager
this incidence, and the Verifier Manager will reduce the reputation
of these verifiers, and reduce the probability to recommend these
Verifiers to Relying Parties. So in the long run, the misbehaved
Verifiers will be punished. The details on the reputation management
scheme for Verifiers are out of scope of this draft.
.---------. .----------. .----------. .--------------.
| Endorser| | Reference | | Verifier | | Relying Party|
'+--------' | Value | | Owner | | Owner |
| | Provider | '----+-----' '-----+--------'
| '------+----' | |
| | | |
| Endorsements | Reference | Appraisal | Appraisal
| | Values | Policy for | Policy for
| | | Evidence | Attestation
'-----------. | | | Results
| | | |
v v v |
.-------------------------. |
.------>| Verifier +------. |
| '-------------------------' | |
| | |
| Evidence Attestation | |
| Results | |
| | |
| v v
.-----+----. .---------------.
| Attester | | Relying Party |
'----------' '---------------'
| ^
Anchor seed Verifiers, | | Recommended
parameter | | Verifiers
| |
.------------------.
| Verifier Manager |
'------------------'
Figure 6: Revised Data Flow based on RFC9334
Zhang, et al. Expires 24 April 2025 [Page 9]
Internet-Draft Multiple RATS Verifiers October 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: Node Attestation for Trusted Routing
Need: Trustworthiness Assessment of routing nodes (Attesters) against
Verifier while ensuring the robustiness of the attestation
verification service (AVS)
Solution: Provide multiple Verifiers (primary and secondaries) to
ensure the availability of the AVS for nodes in the network
Source: Trusted Path Routine
[I-D.voit-rats-trustworthy-path-routing], network attestation for
secure routing [I-D.liu-nasr-requirements]
Use case 2: Intent-driven Attestation Classification for Data Center
Network Solutions
Need: In Data Centers, Data Processing Units (DPU) need to attest
other units (DPUs, CPUs, GPUs) to determine their states. There
might be hundreds of Verifiers (DPUs) for one Attester (DPU/CPU/GPU).
At the Attester side, to generate indididually one Evidence for each
Verifier could be prohibitive.
Solution: One Verifier works as the Relying Party to contact the
Attester, and marks other Verifiers that need to attest this Attester
in the same interesting group. sends the attestation request to the
Attester. The Evidence from the Attester is only generated once and
sent to this Verifier. This Verifier forwards the Evidence to other
Verifiers that in the same interesting group and obtain the
Attestation Results from them. It generates the Aggregated
Attestation Results and shares it within the Verifiers in the same
interesting group. In this manner, the Attester does not need to
generate the Evidence for every Verifier, and the attestation
procedure works even when certain Verifier does not work.
5. Security Consideration
[TBD]
6. IANA Considerations
[TBD]
7. References
Zhang, et al. Expires 24 April 2025 [Page 10]
Internet-Draft Multiple RATS Verifiers October 2024
7.1. Normative References
[I-D.voit-rats-trustworthy-path-routing]
Birkholz, H., Voit, E., Liu, P. C., Lopez, D., and M.
Chen, "Trusted Path Routing", Work in Progress, Internet-
Draft, draft-voit-rats-trustworthy-path-routing-10, 8 July
2024, <https://datatracker.ietf.org/doc/html/draft-voit-
rats-trustworthy-path-routing-10>.
[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, <https://www.rfc-editor.org/rfc/rfc9334>.
7.2. Informative References
[I-D.liu-nasr-requirements]
Liu, P. C., Iannone, L., Lopez, D., Pastor, A., Chen, M.,
and L. Su, "NASR Use Case and Requirements", Work in
Progress, Internet-Draft, draft-liu-nasr-requirements-03,
20 October 2024, <https://datatracker.ietf.org/doc/html/
draft-liu-nasr-requirements-03>.
[RFC9397] Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP)
Architecture", RFC 9397, DOI 10.17487/RFC9397, July 2023,
<https://www.rfc-editor.org/rfc/rfc9397>.
[TAP] Trusted Computing Group, "TCG Trusted Attestation Protocol
(TAP) Use Cases for TPM Families 1.2 and 2.0 and DICE",
1.0 , 5 November 2019, <https://trustedcomputinggroup.org/
wp-content/uploads/
TCG_TNC_TAP_Use_Cases_v1r0p35_published.pdf>.
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
Zhang, et al. Expires 24 April 2025 [Page 11]
Internet-Draft Multiple RATS Verifiers October 2024
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., 20 Science Park Road,
SINGAPORE 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
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@sit.fraunhofer.de
Zhang, et al. Expires 24 April 2025 [Page 12]