RFC 9334
Remote ATtestation procedureS (RATS) Architecture
Remote ATtestation procedureS (RATS) Architecture ✨
okay bestie, this is RFC 9334 🎀 It's an IETF doc with Informational category, which means it's published for info and isn't a Standards Track spec 💅 It's from January 2023 and the ISSN is 2070-1721. The Request for Comments number is 9334.
The authors are H. Birkholz (Fraunhofer SIT), D. Thaler (Microsoft), M. Richardson (Sandelman Software Works), N. Smith (Intel), and W. Pan (Huawei). Iconic team 👑
Abstract 🌸
so in network protocol exchanges, it's often super useful for one end of a conversation to know whether the other end is in an intended operating state 🫶 This doc gives an architectural overview of the entities that make those tests possible, through generating, conveying, and evaluating evidentiary Claims. It's neutral toward processor architectures, the content of Claims, and protocols, so it's flexible af ✨
Status of This Memo 🧚
this doc is not an Internet Standards Track spec. It's just published for informational purposes 🦋
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). BUT not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 if you want the deets 🤓
For the current status, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc9334 💜
Copyright Notice 🌈
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, bestie, because they explain your rights and restrictions for this doc 📜
Code Components pulled out of this doc have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Revised BSD License ⚠️
Table of Contents 📑
1. Introduction
2. Reference Use Cases
2.1. Network Endpoint Assessment
2.2. Confidential Machine Learning Model Protection
2.3. Confidential Data Protection
2.4. Critical Infrastructure Control
2.5. Trusted Execution Environment Provisioning
2.6. Hardware Watchdog
2.7. FIDO Biometric Authentication
3. Architectural Overview
3.1. Two Types of Environments of an Attester
3.2. Layered Attestation Environments
3.3. Composite Device
3.4. Implementation Considerations
4. Terminology
4.1. Roles
4.2. Artifacts
5. Topological Patterns
5.1. Passport Model
5.2. Background-Check Model
5.3. Combinations
6. Roles and Entities
7. Trust Model
7.1. Relying Party
7.2. Attester
7.3. Relying Party Owner
7.4. Verifier
7.5. Endorser, Reference Value Provider, and Verifier Owner
8. Conceptual Messages
8.1. Evidence
8.2. Endorsements
8.3. Reference Values
8.4. Attestation Results
8.5. Appraisal Policies
9. Claims Encoding Formats
10. Freshness
10.1. Explicit Timekeeping Using Synchronized Clocks
10.2. Implicit Timekeeping Using Nonces
10.3. Implicit Timekeeping Using Epoch IDs
10.4. Discussion
11. Privacy Considerations
12. Security Considerations
12.1. Attester and Attestation Key Protection
12.1.1. On-Device Attester and Key Protection
12.1.2. Attestation Key Provisioning Processes
12.2. Conceptual Message Protection
12.3. Attestation Based on Epoch ID
12.4. Trust Anchor Protection
13. IANA Considerations
14. References
14.1. Normative References
14.2. Informative References
Appendix A. Time Considerations
A.1. Example 1: Timestamp-Based Passport Model
A.2. Example 2: Nonce-Based Passport Model
A.3. Example 3: Passport Model Based on Epoch ID
A.4. Example 4: Timestamp-Based Background-Check Model
A.5. Example 5: Nonce-Based Background-Check Model
Acknowledgments
Contributors
Authors' Addresses1. Introduction 💖
the question of how one system can know that another system can be trusted has gotten SO much attention lately, because trusted computing elements are maturing in processor architectures 🧠✨
systems that have been attested and verified to be in a good state (for some value of "good") can improve overall system posture 💅 And the flip side: systems that can't be attested and verified as good can get reduced access or privileges, be taken out of service, or just get flagged for repair 🚩
for example:
- A bank backend system might refuse to transact with another system that is not known to be in a good state. 🏦
- A healthcare system might refuse to transmit electronic healthcare records to a system that is not known to be in a good state. 🩺
in Remote ATtestation procedureS (RATS), one peer (the "Attester") produces believable information about itself ("Evidence") so a remote peer (the "Relying Party") can decide whether or not to consider that Attester trustworthy 🦋 Remote attestation procedures also rely on another vital party, the "Verifier" 👑
the Verifier appraises Evidence using appraisal policies, and creates the Attestation Results that help Relying Parties make their decisions 🎯 This doc defines a flexible architecture made of attestation roles and how they interact through conceptual messages. It also defines a universal set of terms that can be mapped onto lots of existing and emerging remote attestation procedures 🌈 It walks through common topological patterns and the data flows that go with them, like the "Passport Model" and the "Background-Check Model" 🧚 The whole point is to define useful terminology and help readers map their own solution architecture onto this canonical one. Having shared terms for stuff like roles, device composition, topological patterns, and appraisal procedures is vital for semantic interoperability across solutions and platforms with multiple vendors and providers 🫶
this doc is also about trust and trustworthiness, and the difference is subtle but crucial 🙈 Trust is a choice one makes about another system. Trustworthiness is a quality of that other system that you can use when deciding whether to trust it. Knowing that difference is key to using this doc well 💜 It also specifies the concepts of freshness and trust relationships, so implementers can pick appropriate solutions for composing their remote attestation procedures ✨
2. Reference Use Cases 🍓
this section covers a bunch of representative, generic use cases for remote attestation, without tying them to any specific solution. The goal is to give motivation for different parts of the architecture in this doc. There are lots of other use cases out there, and this doc doesn't try to list them all. It just illustrates a set of use cases that together cover all the functionality required in the architecture 🌸
each use case has a description, then a quick summary of the Attester and Relying Party roles that come out of it 💅
2.1. Network Endpoint Assessment 🛜
network operators want trustworthy reports with identity and version info about the hardware and software on the machines attached to their network 📊 Those reports might be for inventory summaries, audit results, or anomaly notifications (which usually involve keeping log records or trend reports). The operator might also want a policy where full access is only granted to devices that meet some definition of hygiene, so they want Claims about that info and a way to verify it's valid 🧼 Remote attestation is wanted so vulnerable or compromised devices can't get onto the network and potentially harm others 🚫
usually a solution starts with a specific component (sometimes called a "root of trust") that often provides a trustworthy device identity and runs a series of operations so other components can be appraised for trustworthiness 🔐 Those components do their own operations to help determine the trustworthiness of yet other components, by collecting, protecting, or signing measurements. Measurements signed by these components are Evidence that either supports or refutes a claim of trustworthiness when it's evaluated ✅ Measurements can describe all kinds of attributes of system components, like hardware, firmware, BIOS, software, and how they're hardened 🛡️
- Attester: A device desiring access to a network. 💻
- Relying Party: Network equipment (such as a router, switch, or access point) that is responsible for admission of the device into the network. 📡
2.2. Confidential Machine Learning Model Protection 🤖
a device manufacturer wants to protect its intellectual property 💼 The IP mostly covers the machine learning (ML) model that gets deployed in the devices its customers buy. The protection goals include stopping attackers (and potentially the customer themselves) from seeing the details of the model 👀
usually this works by having some protected environment in the device go through remote attestation with a manufacturer service that can assess its trustworthiness 🔍 If attestation succeeds, the manufacturer service releases either the model, or a key to decrypt a model that's already on the Attester in encrypted form, to the requester 🔓
- Attester: A device desiring to run an ML model. 🧠
- Relying Party: A server or service holding ML models it desires to protect. 🏰
2.3. Confidential Data Protection 🗝️
this is basically a generalization of the ML model use case above, where the data can be any highly confidential data, like health data about customers, payroll data about employees, or future business plans 📁 As part of the attestation procedure, an assessment is made against a set of policies to evaluate the state of the system requesting the confidential data. Attestation is wanted to stop data from leaking through compromised devices 🚨
- Attester: An entity desiring to retrieve confidential data. 🙋♀️
- Relying Party: An entity that holds confidential data for release to authorized entities. 🫧
2.4. Critical Infrastructure Control
okay so picture the power grid, traffic lights, or a hazardous chemical plant 🏭. all that seriously dangerous physical equipment is hooked up to a network to keep critical infrastructure running. 😭 the organization managing it has to make sure ONLY authorized code and users can control those critical processes, and that nobody can mess with them or get at them through any other threat. 🚨
when a protocol operation can affect a critical system component, the devices attached to that component need some assurances, depending on the security context. that includes knowing a requesting device or app hasn't been compromised, and that the requesters and actors are following the applicable policies. 🫶 so remote attestation can be used to only accept commands from requesters that are within policy. iconic behavior, honestly 💅
- Attester: A device or application wishing to control physical equipment.
- Relying Party: A device or application connected to potentially dangerous physical equipment (hazardous chemical processing, traffic control, power grid, etc.).
2.5. Trusted Execution Environment Provisioning
okay this one is giving management energy 👑. a Trusted Application Manager (TAM) server is in charge of managing the applications running in a Trusted Execution Environment (TEE) of a client device, as described in [TEEP-ARCH]. ✨
to do its job, the TAM needs to assess the state of a TEE, or of the applications inside it, on a client device. the TEE runs remote attestation procedures with the TAM, and then the TAM can decide whether the TEE is already compliant with its latest policy. 🎀 if it isn't, the TAM has to uninstall, update, or install approved applications in the TEE to get it back into compliance with its policy. the glow-up is real 🦋
- Attester: A device with a TEE capable of running trusted applications that can be updated.
- Relying Party: A TAM.
2.6. Hardware Watchdog
ngl this one is scary 💀. there's a class of malware that holds a device hostage and won't let it reboot, so updates never get applied. 😭 that's a huge problem, because it means a whole fleet of devices can be held hostage for ransom.
the fix is a watchdog timer running in a protected environment, like a Trusted Platform Module (TPM), as described in Section 43.3 of [TCGarch]. 🛡️ if the watchdog doesn't keep getting regular and fresh Attestation Results about the system's health, it forces a reboot. main character energy for the watchdog, no cap 🔥
- Attester: The device that should be protected from being held hostage for a long period of time.
- Relying Party: A watchdog capable of triggering a procedure that resets a device into a known, good operational state.
2.7. FIDO Biometric Authentication
bestie, FIDO is so cool 🧚. in the Fast IDentity Online (FIDO) protocol [WebAuthN] [CTAP], the device in the user's hand is what authenticates the human, whether that's through biometrics (like fingerprints) or a PIN and password. 🔐
here's the tea: FIDO puts a LOT more trust in the device than typical password auth does, because it's the device that checks the biometric, PIN, and password inputs from the user, not the server. 👀 so for the Relying Party to know the authentication is trustworthy, it needs to know the Authenticator part of the device is trustworthy too. the FIDO protocol uses remote attestation for exactly this. 🌈
the FIDO protocol supports several remote attestation protocols, plus a mechanism for registering and adding new ones. so remote attestation as defined by the RATS architecture is a candidate for use in FIDO. 💜
- Attester: FIDO Authenticator.
- Relying Party: Any website, mobile application backend, or service that relies on authentication data based on biometric information.
3. Architectural Overview
okay this is the big picture 🦋. Figure 1 shows the data flowing between the different roles, no matter the protocol or use case.
.--------. .---------. .--------. .-------------.
| 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 |
'----------' '---------------'
Figure 1: Conceptual Data Flowthe text below sums up what each role does in Figure 1 ✨. roles get assigned to entities, and entities are often system components [RFC4949], like devices. since "device" is usually more intuitive than "entity" or "system component," this doc often uses device as an illustrative synonym. 🧸
the Attester role goes to entities that create Evidence and send it to a Verifier. 📨
the Verifier role goes to entities that take the Evidence, any Reference Values from Reference Value Providers, and any Endorsements from Endorsers, and apply an Appraisal Policy for Evidence to assess the trustworthiness of the Attester. this is called the "appraisal of Evidence." 🔍
after that, the Verifier role generates Attestation Results for Relying Parties to use. 💌
the Appraisal Policy for Evidence might come from the Verifier Owner through some protocol mechanism, be configured into the Verifier by the Verifier Owner, be programmed into the Verifier, or be obtained some other way. 🍓
the Relying Party role goes to an entity that uses Attestation Results and applies its own appraisal policy to make application-specific decisions, like authorization decisions. this is called the "appraisal of Attestation Results." 🌸
the Appraisal Policy for Attestation Results might come from the Relying Party Owner through some protocol mechanism, be configured into the Relying Party by the Relying Party Owner, be programmed into the Relying Party, or be obtained some other way. 🫶
for more on the conceptual messages in Figure 1, check out Section 8 💜. Section 4 has the full definitions of all the RATS roles.
3.1. Two Types of Environments of an Attester
okay so this part is about what's inside an Attester 🧚. as Figure 2 shows, an Attester has at least one Attesting Environment and at least one Target Environment, all co-located in one entity. in some implementations, the Attesting and Target Environments might be combined into a single environment. other implementations might have multiple Attesting and Target Environments, like the examples in Sections 3.2 and 3.3. other examples may exist too. 🌈 every composition of Attesting and Target Environments discussed in this architecture can be combined into more complex implementations.
.--------------------------------.
| |
| Verifier |
| |
'--------------------------------'
^
|
.-------------------------|----------.
| | |
| .----------------. | |
| | Target | | |
| | Environment | | |
| | | | Evidence |
| '--------------+-' | |
| | | |
| | | |
| Collect | | |
| Claims | | |
| | | |
| v | |
| .-------+-----. |
| | Attesting | |
| | Environment | |
| | | |
| '-------------' |
| Attester |
'------------------------------------'
Figure 2: Two Types of Environments within an Attesternow the good part 🎀. Claims get collected from Target Environments. Attesting Environments collect the values and information that go into Claims by reading system registers and variables, calling into subsystems, and taking measurements on code, memory, or other relevant assets of the Target Environment. then they format the Claims properly, and usually they use key material and cryptographic functions, like signing or cipher algorithms, to generate Evidence. 🔐 there's no limit or requirement on which hardware or software environments can implement an Attesting Environment. examples include TEEs, embedded Secure Elements (eSEs), TPMs [TCGarch], or BIOS firmware. wild range, iykyk 🤭
an arbitrary execution environment might not be capable of Claims collection for a given Target Environment by default 🙈. so the execution environments specifically designed to collect Claims are called "Attesting Environments" in this document. for example, a TPM doesn't actively collect Claims on its own. instead, it needs another component to feed it various values. so in that case, the Attesting Environment is the combo of the TPM plus whatever component is feeding it the measurements. teamwork makes the dream work 🫶💅
3.2. Layered Attestation Environments ✨
okay so by definition, the Attester role is the one that generates Evidence 🫶 An Attester can be made up of one or more nested environments, which we call layers 🧁 The bottom layer has an Attesting Environment that is usually designed to be immutable, or at least really hard for malicious code to change 🔒 To appraise Evidence from an Attester, the Verifier has to trust the various layers, including that bottom Attesting Environment. There are different ways to set up that trust, and we go over them in Section 7.4 💜
In layered attestation, Claims can be collected from or about each layer, starting with an initial layer 🌸 The Claims can be organized in a nested way that matches how the Attester's layers are nested. Normally, Claims are not self-asserted. Instead, a previous layer acts as the Attesting Environment for the next layer, which is giving chain of custody energy 🔗 Claims about an initial layer are usually asserted by an Endorser 🎀
Figure 3 shows an example device with (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an operating system kernel 🦋
.-------------. Endorsement for ROM
| Endorser +-----------------------.
'-------------' |
|
v
.-------------. Reference .----------.
| Reference | Values for | |
| Value +----------------->| Verifier |
| Provider(s) | ROM, bootloader, | |
'-------------' and kernel '----------'
^
.------------------------------------. |
| | |
| .---------------------------. | |
| | Kernel(C) | | |
| | | | | Layered
| | Target | | | Evidence
| | Environment | | | for
| '---------------+-----------' | | bootloader
| Collect | | | and
| Claims | | | kernel
| .---------------|-----------. | |
| | Bootloader(B) v | | |
| | .-----------. | | |
| | Target | Attesting | | | |
| | Environment |Environment+-----------'
| | | | | |
| | '-----------' | |
| | ^ | |
| '--------------+--|---------' |
| Collect | | Evidence for |
| Claims v | bootloader |
| .-----------------+---------. |
| | ROM(A) | |
| | | |
| | Attesting | |
| | Environment | |
| '---------------------------' |
| |
'------------------------------------'
Figure 3: Layered Attesterokay the first Attesting Environment (the ROM in this example) has to make sure the bootloader (the first Target Environment) has intact integrity 🛡️ There could be multiple kernels to boot, and the bootloader is the one that decides which one. Only a bootloader with intact integrity will make a proper decision, so the Claims about the bootloader's integrity have to be measured securely 🔐 At this point in the boot cycle, the Claims that get collected typically can't be composed into Evidence yet 🙈
Once the boot sequence starts, the BIOS does the most important and defining thing in layered attestation: the bootloader, now successfully measured, becomes (or contains) an Attesting Environment for the next layer ✨ This procedure is sometimes called "staging," and it's giving main character energy 👑 It's important that the bootloader can't alter any Claims about itself that the BIOS collected. This can be ensured by having those Claims either signed by the BIOS or stored in a tamper-proof manner by the BIOS 💅
Continuing the example, the bootloader's Attesting Environment is now in charge of collecting Claims about the next Target Environment, which here is the kernel being booted 🧚 So the final Evidence ends up with two sets of Claims: one set about the bootloader as measured and signed by the BIOS, and another set about the kernel as measured and signed by the bootloader 💖
This example could go further. The kernel could become another Attesting Environment for an application, which is a separate Target Environment. That would add a third set of Claims to the Evidence, about that application 🌈
The big picture here is a cascade of staged environments 🫧 Each environment is responsible for measuring the next environment before that next environment gets started. In general, the number of layers can vary by device or implementation. Also, an Attesting Environment might measure multiple Target Environments, not just one like the example in Figure 3 🦋
3.3. Composite Device 🍓
okay so a composite device is an entity made up of multiple sub-entities, and its trustworthiness has to be determined by appraising all of those sub-entities together 🫶
Each sub-entity has at least one Attesting Environment that collects Claims from at least one Target Environment. Then that sub-entity generates Evidence about its own trustworthiness, so each sub-entity can be called an "Attester" 💅 Not every Attester has to be able to talk to the Verifier, though. Some of them can and some of them can't 🙈
For example, a carrier-grade router is made of a chassis and multiple slots. The router's trustworthiness depends on the trustworthiness of all its slots 🔥 Each slot has an Attesting Environment, such as a TEE, that collects the Claims of its boot process, and after that it generates Evidence from those Claims 🎀
Only a "main" slot can communicate with the Verifier, while the other slots can't. However, the other slots can talk to the main slot through the links between them inside the router 🔗 The main slot collects the Evidence from the other slots, produces the final Evidence for the whole router, and sends that final Evidence to the Verifier. So the router is a composite device, each slot is an Attester, and the main slot is the lead Attester 👑
Another example is a multi-chassis router made of multiple single carrier-grade routers 🌸 Multi-chassis router setups create redundancy groups that give higher throughput by connecting multiple routers in those groups, which can be treated as one logical router to make management simpler 🧁 A multi-chassis router setup has a management point that connects to the Verifier. Typically, one router in the group is designated as the main router. The other routers are connected only to the main router through physical network links, so they get managed and appraised with the main router's help 💜 That makes a multi-chassis router setup a composite device, each router an Attester, and the main router the lead Attester ✨
Figure 4 shows the conceptual data flow for a composite device 🦋
.-----------------------------.
| Verifier |
'-----------------------------'
^
|
| Evidence of
| Composite Device
|
.----------------------------------|-------------------------------.
| .--------------------------------|-----. .------------. |
| | Collect .---------+--. | | | |
| | Claims .--------->| Attesting |<--------+ Attester B +-. |
| | | |Environment | | '-+----------' | |
| | .--------+-------. | |<----------+ Attester C +-. |
| | | Target | | | | '-+----------' | |
| | | Environment(s) | | |<------------+ ... | |
| | | | '------------' | Evidence '------------' |
| | '----------------' | of |
| | | Attesters |
| | lead Attester A | (via Internal Links or |
| '--------------------------------------' Network Connections) |
| |
| Composite Device |
'------------------------------------------------------------------'
Figure 4: Composite Deviceokay so in a composite device, each Attester generates its own Evidence by having its Attesting Environment(s) collect Claims from its Target Environment(s) 🫧 The lead Attester collects Evidence from the other Attesters and conveys it to a Verifier. Collecting Evidence from sub-entities can itself count as a form of Claims collection, which results in Evidence asserted by the lead Attester 💖 The lead Attester generates Evidence about the layout of the whole composite device, while the sub-Attesters generate Evidence about their own (sub-)modules 🌈
In this scenario, the trust model described in Section 7 can also be applied to an inside Verifier 🧚
3.4. Implementation Considerations 💅
an entity can take on multiple RATS roles (like Attester, Verifier, Relying Party, and so on) at the same time 🫶 Multiple entities can also cooperate to implement a single RATS role. Honestly, the combinations of roles and entities can be pretty much arbitrary 🎀 For example, in the composite device scenario, the entity inside the lead Attester can also take on the Verifier role, and the outer entity acting as the Verifier can take on the Relying Party role 👑
After collecting the Evidence of other Attesters, this inside Verifier uses Endorsements and appraisal policies (obtained the same way as by any other Verifier) as part of the appraisal procedures that generate Attestation Results 🔍 The inside Verifier then conveys the Attestation Results of the other Attesters to the outside Verifier, either in the same conveyance protocol as the Evidence or not 🦋
As explained in Section 4, there are a variety of roles in the RATS architecture, and each one is defined by the unique combination of artifacts it produces and consumes ✨ It also works the other way around: artifacts are defined by the roles that produce or consume them 💜 To produce an artifact means that a given role introduces it into the RATS architecture. To consume an artifact means that a given role is responsible for processing it in the RATS architecture. Roles can also perform additional actions, like caching or forwarding artifacts as opaque data 🌸 As depicted in Section 5, these additional actions can be performed by several roles 🧁
4. Terminology ✨
okay bestie, let's talk vocab 💅 [RFC4949] already defined a bunch of terms that we also use here. some are almost the same but not quite, so wherever they're close, we point it out with a reference 🙈 as explained in Section 2.6 of [RFC4949], when this doc says "Compare:", the terminology used here is significantly different from the definition in the reference. the subsections below are the terms we're using 🎀
4.1. Roles
Attester 🦋: a role performed by an entity (typically a device) whose Evidence must be appraised so we can infer how trustworthy the Attester is considered to be, like when deciding whether it's authorized to perform some operation.
- Produces: Evidence
Relying Party 💖: a role performed by an entity that depends on the validity of information about an Attester so it can reliably apply application-specific actions. Compare: relying party [RFC4949].
- Consumes: Attestation Results, Appraisal Policy for Attestation Results
Verifier 🔍: a role performed by an entity that appraises the validity of Evidence about an Attester and produces Attestation Results for a Relying Party to use.
- Consumes: Evidence, Reference Values, Endorsements, Appraisal Policy for Evidence
- Produces: Attestation Results
Relying Party Owner 👑: a role performed by an entity (typically an administrator) that is authorized to configure an Appraisal Policy for Attestation Results in a Relying Party.
- Produces: Appraisal Policy for Attestation Results
Verifier Owner 🧚: a role performed by an entity (typically an administrator) that is authorized to configure an Appraisal Policy for Evidence in a Verifier.
- Produces: Appraisal Policy for Evidence
Endorser 🌸: a role performed by an entity (typically a manufacturer) whose Endorsements may help Verifiers appraise the authenticity of Evidence and infer further capabilities of the Attester.
- Produces: Endorsements
Reference Value Provider 🍓: a role performed by an entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence and determine whether acceptable known Claims have been recorded by the Attester.
- Produces: Reference Values
4.2. Artifacts
Claim ⭐: a piece of asserted information, often in the form of a name/value pair. Claims make up the usual structure of Evidence and other RATS conceptual messages. Compare: claim [RFC7519].
Endorsement 🫶: a secure statement that an Endorser vouches for the integrity of an Attester's various capabilities, such as Claims collection and Evidence signing.
- Consumed By: Verifier
- Produced By: Endorser
Evidence 🔥: a set of Claims generated by an Attester to be appraised by a Verifier. Evidence may include configuration data, measurements, telemetry, or inferences.
- Consumed By: Verifier
- Produced By: Attester
Attestation Result 🌈: the output generated by a Verifier, typically including information about an Attester, where the Verifier vouches for the validity of the results.
- Consumed By: Relying Party
- Produced By: Verifier
Appraisal Policy for Evidence 📜: a set of rules that a Verifier uses to evaluate the validity of information about an Attester. Compare: security policy [RFC4949].
- Consumed By: Verifier
- Produced By: Verifier Owner
Appraisal Policy for Attestation Results 🎯: a set of rules that direct how a Relying Party uses the Attestation Results regarding an Attester generated by the Verifiers. Compare: security policy [RFC4949].
- Consumed by: Relying Party
- Produced by: Relying Party Owner
Reference Values 💜: a set of values against which values of Claims can be compared as part of applying an Appraisal Policy for Evidence. Reference Values are sometimes called "known-good values", "golden measurements", or "nominal values" in other documents. Those terms typically assume comparison for equality, whereas here, Reference Values might be more general and be used in any sort of comparison.
- Consumed By: Verifier
- Produced By: Reference Value Provider
5. Topological Patterns 🌸
Figure 1 shows a data flow diagram for communication between an Attester, a Verifier, and a Relying Party. The Attester conveys its Evidence to the Verifier for appraisal, and the Relying Party receives the Attestation Result from the Verifier. This section refines the data-flow diagram by describing two reference models, plus one example composition of them. The discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented models.
5.1. Passport Model
The Passport Model is named after how nations issue passports to their citizens, and it's giving real-life vibes ✈️ The kind of Evidence an individual has to hand over to their local authority is specific to the country involved. The citizen keeps the resulting passport and shows it to other entities whenever they need to assert a citizenship or identity Claim, like at an airport immigration desk. The passport is considered sufficient because it vouches for the citizenship and identity Claims and was issued by a trusted authority.
So in this immigration desk analogy, the citizen is the Attester, the passport-issuing agency is a Verifier, and the passport application plus identifying info (e.g., birth certificate) is the Evidence. The passport is an Attestation Result, and the immigration desk is a Relying Party. 🛂
In this model, an Attester sends Evidence to a Verifier, which compares it against its appraisal policy. The Verifier then gives back an Attestation Result that the Attester treats as opaque data. 🫠
The Attester does not consume the Attestation Result, but it might cache it. The Attester can then present the Attestation Result (and possibly additional Claims) to a Relying Party, which compares this information against its own appraisal policy. The Attester may also present the same Attestation Result to other Relying Parties. ✨
There are three ways the process can fail 💀
- First, the Verifier may not issue a positive Attestation Result because the Evidence didn't pass the Appraisal Policy for Evidence.
- The second way is when the Attestation Result is examined by the Relying Party and, based upon the Appraisal Policy for Attestation Results, the result doesn't comply with the policy.
- The third way is when the Verifier is unreachable or unavailable.
As with any other information the Relying Party needs to make an authorization decision, an Attestation Result can be carried in a resource access protocol between the Attester and Relying Party. In this model, the details of that resource access protocol constrain the serialization format of the Attestation Result. On the other hand, the format of the Evidence is only constrained by the Attester-Verifier remote attestation protocol. This implies that interoperability and standardization are more relevant for Attestation Results than they are for Evidence. 🧠
.------------.
| | Compare Evidence
| Verifier | against appraisal policy
| |
'--------+---'
^ |
Evidence | | Attestation
| | Result
| v
.---+--------. .-------------.
| +------------->| | Compare Attestation
| Attester | Attestation | Relying | Result against
| | Result | Party | appraisal policy
'------------' '-------------'
Figure 5: Passport Model5.2. Background-Check Model
The Background-Check Model is named after how employers and volunteer organizations run background checks, and honestly it's a whole vibe 🕵️♀️ When a prospective employee gives Claims about their education or previous experience, the employer contacts the respective institutions or former employers to validate the Claim. Volunteer organizations often run police background checks on volunteers to figure out their trustworthiness. So in this analogy, a prospective volunteer is the Attester, the organization is the Relying Party, and the organization that issues a report is a Verifier. 📋
In this model, an Attester sends Evidence to a Relying Party, which treats it as opaque and simply forwards it on to a Verifier. The Verifier compares the Evidence against its appraisal policy and returns an Attestation Result to the Relying Party. Then the Relying Party compares the Attestation Result against its own appraisal policy. 🔄
The resource access protocol between the Attester and Relying Party includes Evidence rather than an Attestation Result, but that Evidence is not processed by the Relying Party. 🙅♀️
Since the Evidence is merely forwarded to a trusted Verifier, any serialization format can be used for Evidence, because the Relying Party doesn't need a parser for it. The only requirement is that the Evidence can be encapsulated in the format required by the resource access protocol between the Attester and Relying Party. 📦
However, as we saw in the Passport Model, an Attestation Result is still consumed by the Relying Party. Code footprint and attack surface area can be minimized by using a serialization format the Relying Party already needs a parser for to support the protocol between the Attester and Relying Party, which may be an existing standard or widely deployed resource access protocol. That kind of minimization is especially important if the Relying Party is a constrained node. 🔒
.-------------.
| | Compare Evidence
| Verifier | against appraisal
| | policy
'--------+----'
^ |
Evidence | | Attestation
| | Result
| v
.------------. .----|--------.
| +-------------->|---' | Compare Attestation
| Attester | Evidence | Relying | Result against
| | | Party | appraisal policy
'------------' '-------------'
Figure 6: Background-Check Model5.3. Combinations ✨
okay so one variation of the Background-Check Model is where the Relying Party and the Verifier are on the same machine, doing both jobs together 🫶. bc they're literally in the same box, there's no need for a protocol between the two 💅
ngl it's also worth pointing out that the model you pick depends on the use case, and different Relying Parties can totally use different topological patterns 🦋
the same device might need to make Evidence for different Relying Parties and/or different use cases 🎀. like, it could use one model to show Evidence to a network infrastructure device to get network access, and a different model to show Evidence to a server holding confidential data so it can get into that data 🔐. so both models can be in use by the same device at the same time, no cap ✨
Figure 7 shows another combo where Relying Party 1 uses the Passport Model, while Relying Party 2 uses an extension of the Background-Check Model 🌈. basically, on top of the basic stuff in Figure 6, Relying Party 2 actually sends the Attestation Result back to the Attester so the Attester can use it with other Relying Parties 👑. this is the model the TAM plans to support in the TEEP architecture [TEEP-ARCH] 💜
.-------------.
| | Compare Evidence
| Verifier | against appraisal policy
| |
'--------+----'
^ |
Evidence | | Attestation
| | Result
| v
.----+--------.
| | Compare
| Relying | Attestation Result
| Party 2 | against appraisal policy
'--------+----'
^ |
Evidence | | Attestation
| | Result
| v
.----+--------. .-------------.
| +-------------->| | Compare Attestation
| Attester | Attestation | Relying | Result against
| | Result | Party 1 | appraisal policy
'-------------' '-------------'
Figure 7: Example Combination6. Roles and Entities 🧚
an entity in the RATS architecture includes at least one of the roles defined in this document 💖
an entity can aggregate more than one role into itself, like being both a Verifier and a Relying Party, or being both a Reference Value Provider and an Endorser 🌸. so any conceptual messages (see Section 8 for more discussion) coming from those roles might get combined too 🎀. for example, Reference Values might be conveyed as part of an appraisal policy if the Verifier Owner and Reference Value Provider roles are combined ✨. similarly, Reference Values might be conveyed as part of an Endorsement if the Endorser and Reference Value Provider roles are combined 🦋
interactions between roles aggregated into the same entity don't necessarily use the Internet Protocol 🌈. they might use a loopback device or other IP-based communication between separate environments, but they don't have to 💅. alternative channels for conveying conceptual messages include function calls, sockets, General-Purpose Input/Output (GPIO) interfaces, local buses, or hypervisor calls 🔥. this kind of conveyance is typically found in composite devices 🧚. most importantly, these conveyance methods are out of scope of the RATS architecture, but they're presumed to exist so conceptual messages can get between roles properly 🫶
in essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this document 👑
7. Trust Model 🌸
7.1. Relying Party
okay this document covers scenarios where a Relying Party trusts a Verifier that can appraise how trustworthy the information about an Attester is 🫶. that trust gets expressed by storing one or more "trust anchors" in a secure location known as a "trust anchor store" 🔐
as defined in [RFC6024]:
A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative.
the trust anchor might be a certificate, or it might be a raw public key along with extra data if needed, like its public key algorithm and parameters 💅. in the context of this document, a trust anchor might also be a symmetric key, as in [TCG-DICE-SIBDA], or the symmetric mode described in [RATS-PSA-TOKEN] ✨
so trusting a Verifier might be expressed by having the Relying Party store the Verifier's key or certificate in its trust anchor store 💖. it might also be expressed by storing the public key or certificate of an entity (e.g., a Certificate Authority) that's in the Verifier's certificate path 🦋. for example, the Relying Party can verify that the Verifier is an expected one through out-of-band establishment of key material, combined with a protocol like TLS to communicate 🌈. there's an assumption that the Verifier hasn't been compromised between the establishment of the trusted key material and the creation of the Evidence 🙈
for a stronger level of security, the Relying Party might require that the Verifier first provide information about itself that the Relying Party can use to assess the Verifier's trustworthiness before accepting its Attestation Results 👑. this kind of process gives a stronger level of confidence in the correctness of the information provided, like a belief that the authentic Verifier hasn't been compromised by malware 💀
for example, one explicit way for a Relying Party "A" to build that confidence in a Verifier "B" would be for B to first act as an Attester, where A acts as a combined Verifier/Relying Party 🧚. if A then accepts B as trustworthy, it can choose to accept B as a Verifier for other Attesters 💜
similarly, the Relying Party also needs to trust the Relying Party Owner for providing its Appraisal Policy for Attestation Results 🎀. and in some scenarios, the Relying Party might even require the Relying Party Owner to go through a remote attestation procedure with it before the Relying Party accepts an updated policy 🔥. this can be done in a similar way to how a Relying Party could establish trust in a Verifier, as discussed above, i.e., verifying credentials against a trust anchor store and optionally requiring Attestation Results from the Relying Party Owner 🫶
7.2. Attester
in some scenarios, Evidence might contain sensitive information, like Personally Identifiable Information (PII) or system identifiable information 😭. so an Attester has to trust the entities it hands Evidence to, so they don't reveal sensitive data to unauthorized parties 🔐. the Verifier might share this information with other authorized parties according to a governing policy that handles sensitive information (possibly included in Appraisal Policies for Evidence) 🌸. in the Background-Check Model, this Evidence might also be revealed to Relying Parties 👀
when Evidence contains sensitive information, an Attester typically requires that a Verifier authenticates itself (e.g., at TLS session establishment) 🎀. it might even request a remote attestation before the Attester sends the sensitive Evidence 💅. this can be done by having the Attester first act as a Verifier/Relying Party, and the Verifier act as its own Attester, as discussed above ✨
7.3. Relying Party Owner
the Relying Party Owner might also require that the Relying Party first act as an Attester by providing Evidence the Owner can appraise 🦋. this happens before the Owner gives the Relying Party an updated policy that might contain sensitive information 🌈. in that case, authentication or attestation in both directions might be needed 🫶. typically, one side's Evidence has to be considered safe to share with an untrusted entity in order to bootstrap the sequence 🔥. see Section 11 for more discussion 💖
7.4. Verifier ✨
Okay bestie, the Verifier is the one that trusts a manufacturer or the manufacturer's hardware (or, more precisely, its security policy is written so that it's configured to trust them) so it can appraise how trustworthy that manufacturer's devices are. 💅 That trust is stored as one or more trust anchors in the Verifier's trust anchor store. 🔐
In a typical setup, a Verifier comes to trust an Attester indirectly. An Endorser (like a manufacturer) vouches for the Attester's ability to securely generate Evidence through Endorsements (see Section 8.2). Endorsements might describe how the Attester resists attacks, protects secrets, and measures Target Environments. So the Endorser's key material gets stored in the Verifier's trust anchor store, which lets Endorsements be authenticated and used in the appraisal process. 🦋
In some solutions, a Verifier might be set up to directly trust an Attester by holding the Attester's key material (instead of the Endorser's) in its trust anchor store. 🌸
That direct trust has to be set up first, when the trust anchor store is configured, either by checking with an Endorser at that time or by doing a security analysis of the specific device. Keeping the Attester directly in the trust anchor store narrows the Verifier's trust to specific devices, instead of every device the Endorser might vouch for, like all devices from the same manufacturer when the Endorser is a manufacturer. 🎀
That narrowing is a big deal, because physically holding a device can also be used to pull off a bunch of attacks. So a device in a physically secure place (like your own premises) may be considered trusted, while devices owned by others would not be. 🙈 This often leads owners to either run their own Endorser that only endorses devices they own, or to put Attesters directly in the trust anchor store. When there are many Attesters owned, using an Endorser gives way better scalability. 📈
Basically, a Verifier might appraise the trustworthiness of an application component, operating system component, or service on the assumption that the info the lower-layer firmware or software gives about it is true. 🤞 A stronger level of security assurance comes when info is vouched for by hardware or by ROM code, especially if that hardware is physically resistant to tampering. 💪 In most cases, components that have to be vouched for via Endorsements (because no Evidence is generated about them) are called "roots of trust". 👑
The manufacturer arranged for an Attesting Environment to be provisioned with key material to sign Evidence, so the Verifier needs some way to verify the signature on that Evidence. That could be an appropriate trust anchor, or the Verifier might get a database of public keys (rather than certificates), or even carefully curated and secured lists of symmetric keys. 🔑
How the Verifier manages to validate the signatures produced by the Attester is super critical to the secure operation of a remote attestation system, but it's not something this architecture standardizes. 😭
A conveyance protocol that provides authentication and integrity protection can be used to convey Evidence that is otherwise unprotected (e.g., not signed). Appropriate conveyance of unprotected Evidence (e.g., [RATS-UCCS]) relies on the following conveyance protocol's protection capabilities:
- The key material used to authenticate and integrity protect the conveyance channel is trusted by the Verifier to speak for the Attesting Environment(s) that collected Claims about the Target Environment(s).
- All unprotected Evidence that is conveyed is supplied exclusively by the Attesting Environment that has the key material that protects the conveyance channel.
- A trusted environment protects the conveyance channel's key material, which may depend on other Attesting Environments with equivalent strength protections.
As illustrated in [RATS-UCCS], an entity that receives unprotected Evidence via a trusted conveyance channel always takes on the job of vouching for the Evidence's authenticity and freshness. If protected Evidence is generated, the Attester's Attesting Environments take on that responsibility. When unprotected Evidence is processed by a Verifier, Relying Parties have to trust that the Verifier can handle Evidence in a way that preserves its authenticity and freshness. 😬 Generating and conveying unprotected Evidence always creates significant risk, so the benefits have to be carefully weighed against the potential drawbacks.
Want the security strength deets? See Section 12 for discussion on security strength. 🧚
7.5. Endorser, Reference Value Provider, and Verifier Owner
In some scenarios, the Endorser, Reference Value Provider, and Verifier Owner may need to trust the Verifier before handing over the Endorsement, Reference Values, or appraisal policy to it. 🫶 This can be done in a similar way to how a Relying Party might establish trust in a Verifier.
As discussed in Section 7.3, authentication or attestation in both directions might be needed. Typically, one side's identity or Evidence in this case has to be considered safe to share with an untrusted entity in order to bootstrap the sequence. It's giving chicken-and-egg energy, ngl. See Section 11 for more discussion. 🌈
8. Conceptual Messages 💜
Figure 1 shows the flow of conceptual messages between the various roles. This section gives extra elaboration and implementation considerations. It's the responsibility of protocol specifications to define the actual data format and semantics of any relevant conceptual messages. 📜
8.1. Evidence 🔍
Evidence is a set of Claims about the Target Environment that reveal operational status, health, configuration, or construction that has security relevance. A Verifier appraises Evidence to establish its relevance, compliance, and timeliness. Claims need to be collected in a reliable way, so a Target Environment cannot lie to the Attesting Environment about its trustworthiness properties. Evidence needs to be securely associated with the Target Environment, so the Verifier can't be tricked into accepting Claims that come from a different environment (one that may be more trustworthy). Evidence also must be protected from an active on-path attacker who may observe, change, or misdirect Evidence as it travels from the Attester to the Verifier. 🕵️♀️ The timeliness of Evidence can be captured using Claims that pinpoint the time or interval when changes in operational status, health, and so forth occur. ⏰
8.2. Endorsements 🏅
An Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device's various capabilities, such as Claims collection, signing, launching code, transitioning to other environments, storing secrets, and more. For example, if the device's signing capability is in hardware, an Endorsement might be a manufacturer certificate that signs a public key whose corresponding private key is only known inside the device's hardware. So when Evidence and such an Endorsement are used together, an appraisal procedure can be conducted based on appraisal policies that may not be specific to the device instance, but are merely specific to the manufacturer providing the Endorsement. For example, an appraisal policy might simply check that devices from a given manufacturer have information matching a set of Reference Values. An appraisal policy might also have a more complex logic for how to appraise the validity of information. 🧠
However, while an appraisal policy that treats all devices from a given manufacturer the same may be appropriate for some use cases, it would be inappropriate to use such an appraisal policy as the sole means of authorization for use cases that wish to constrain which compliant devices are considered authorized for some purpose. 🚫 For example, an enterprise using remote attestation for Network Endpoint Assessment (NEA) [RFC5209] may not wish to let every healthy laptop from the same manufacturer onto the network. Instead, it may only want to let devices that it legally owns onto the network. Thus, an Endorsement may be helpful information in authenticating information about a device, but it is not necessarily sufficient to authorize access to resources that may need device-specific information, such as a public key for the device or component or user on the device. Not every laptop gets a VIP pass, bestie. 🎟️
8.3. Reference Values 📏
Reference Values used in appraisal procedures come from a Reference Value Provider, and the Verifier then uses them to compare against Evidence. Reference Values with matching Evidence produce acceptable Claims. On top of that, an appraisal policy may play a role in determining the acceptance of Claims. ✅
8.4. Attestation Results 🎀
okay so Attestation Results are what the Relying Party looks at to decide how much it trusts a particular Attester ✨ like, how much access it lets them have to some data, or whether they get to run an operation at all. literally the vibe check that decides everything 💅
Attestation Results can carry a boolean saying the Attester is compliant or not compliant with the Verifier's appraisal policy 🙈. They can also carry a richer set of Claims about the Attester, and then the Relying Party runs its own Appraisal Policy for Attestation Results against those 🧚
The quality of the Attestation Results depends on how well the Verifier can actually evaluate the Attester 🔥. Different Attesters have a different Strength of Function [strengthoffunction], so the Attestation Results end up being qualitatively different in strength. ngl that's a whole mood 🌸
An Attestation Result that indicates non-compliance can be used by an Attester (in the Passport Model) or a Relying Party (in the Background-Check Model) to show that the Attester should not be treated as authorized and may need remediation 🩹. In some cases it can even mean the Evidence itself can't be authenticated as correct 💀
By default, the Relying Party does not believe the Attester to be compliant 🙅. Once it gets an authentic Attestation Result and the Appraisal Policy for Attestation Results is satisfied, the Attester is allowed to do the prescribed actions or get the prescribed access 🎉. The simplest appraisal policy might just give the Attester full access or control over the resources the Relying Party guards 👑. A more complex one might compare the info in the Attestation Result against expected values, or run some fancier analysis on the other info inside it 🧠
So Attestation Results can hold detailed info about an Attester, and that can include privacy sensitive stuff, as discussed in Section 11 🔒. Unlike Evidence, which is often super device- and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic info from appraising the vendor-specific info in Evidence 🦋. That keeps a Relying Party's appraisal policy simpler, maybe based on standard ways of expressing info, while still letting heterogeneous devices interoperate 🌈
Finally, Evidence is signed by the device (or indirectly by a manufacturer if Endorsements are used), whereas Attestation Results are signed by a Verifier 🖊️. So a Relying Party only needs a trust relationship with one entity, instead of a bigger set of entities, for its appraisal policy 💖
8.5. Appraisal Policies 📋
The Verifier (when appraising Evidence) or the Relying Party (when appraising Attestation Results) checks the values of matched Claims against constraints in its appraisal policy 🔍. Examples of such constraint checks include the following:
- Comparison for equality against a Reference Value.
- A check for being in a range bounded by Reference Values.
- Membership in a set of Reference Values.
- A check against values in other Claims.
Once all the appraisal policy constraints are done, the remaining Claims are accepted as input toward determining Attestation Results (when appraising Evidence) or as input to a Relying Party (when appraising Attestation Results) ✅
9. Claims Encoding Formats 🧩
Figure 8 shows a relationship where we want to add remote attestation 👀
.-------------. .------------. Evaluate
| +-------------->| | request
| Attester | Access some | Relying | against
| | resource | Party | security
'-------------' '------------' policy
Figure 8: Typical Resource AccessThe protocol between the Attester and a Relying Party can be any new or existing protocol (e.g., HTTP(S), CoAP(S), Resource-Oriented Lightweight Information Exchange (ROLIE) [RFC8322], 802.1x, OPC UA [OPCUA], etc.), depending on the use case 🌸
Typically, those protocols already have mechanisms for passing security info for authentication and authorization 🔐. Common formats include JSON Web Tokens (JWTs) [RFC7519], CWTs [RFC8392], and X.509 certificates 📜
Retrofitting already-deployed protocols with remote attestation means adding RATS conceptual messages to the existing data flows 🛠️. This has to be done in a way that does not degrade the security properties of the systems involved, and it should use the extension mechanisms the underlying protocol provides 🫶. For example, if a TLS handshake is going to be extended with remote attestation capabilities, attestation Evidence may be embedded in an ad hoc X.509 certificate extension (e.g., [TCG-DICE]) or into a new TLS Certificate Type (e.g., [TLS-CWT]) 🦋
Especially for constrained nodes, there's a desire to minimize the amount of parsing code a Relying Party needs, to keep both the footprint and the attack surface small 🤏. Sure, you could embed a CWT inside a JWT, or a JWT inside an X.509 extension, etc., but there's a desire to encode the info in a format the Relying Party already supports 💅
This motivates having a common "information model" that describes the set of remote attestation related info in an encoding-agnostic way 🧠. It allows multiple encoding formats (CWT, JWT, X.509, etc.) that all encode the same info into the Claims format the Relying Party needs ✨
Figure 9 shows that Evidence and Attestation Results might be expressed through multiple potential encoding formats, so they can be conveyed by various existing protocols 🌈. It also explains why the Verifier might be responsible for accepting Evidence that encodes Claims in one format while issuing Attestation Results that encode Claims in a different format 🔄
Evidence Attestation Results
.--------------. CWT CWT .-------------------.
| Attester-A +-----------. .---------->| Relying Party V |
'--------------' | | `-------------------'
v |
.--------------. JWT .---------+--. JWT .-------------------.
| Attester-B +-------->| +-------->| Relying Party W |
'--------------' | | `-------------------'
| |
.--------------. X.509 | | X.509 .-------------------.
| Attester-C +-------->| Verifier +-------->| Relying Party X |
'--------------' | | `-------------------'
| |
.--------------. TPM | | TPM .-------------------.
| Attester-D +-------->| +-------->| Relying Party Y |
'--------------' '---------+--' `-------------------'
^ |
.--------------. other | | other .-------------------.
| Attester-E +-----------' '---------->| Relying Party Z |
'--------------' `-------------------'
Figure 9: Multiple Attesters and Relying Parties with Different
Formats10. Freshness ⏰
A Verifier or Relying Party might need to know the point in time (i.e., the "epoch") when an Evidence or Attestation Result was produced 🕰️. This is essential for deciding whether the included Claims can be considered fresh, meaning they still reflect the latest state of the Attester 🌟. It also matters for checking that any Attestation Result was generated using the latest Appraisal Policy for Evidence, Endorsements, and Reference Values 📋
This section gives a bunch of details, but it doesn't define any protocol formats, and the interactions shown are abstract 🧚. It's meant for people creating protocols and solutions, so they understand the options for keeping things fresh 💖. How freshness gets provisioned in a protocol is an architectural decision. It affects how many round trips a protocol needs, so it has to be decided super early in the design 🚨. Different decisions can have big impacts on interoperability, which is why this section goes into enough detail that freshness choices stay compatible across interacting protocols, like the ones in Figure 9 🫶
Freshness is assessed based on the Appraisal Policy for Evidence or Attestation Results, which compares the estimated epoch against an "expiry" threshold defined locally to that policy ⏳. There's always a race condition possible, though, because the state of the Attester and the appraisal policies might change right after the Evidence or Attestation Result was generated 😭. The goal is just to narrow their recentness to something the Verifier (for Evidence) or Relying Party (for Attestation Result) is willing to accept 🎯. Some flexibility on the freshness requirement is a key part of enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable when computing them uses a big chunk of the resource budget (e.g., energy in constrained devices) 🔋
There are three common approaches for determining the epoch of Evidence or an Attestation Result 🧮
10.1. Explicit Timekeeping Using Synchronized Clocks ⌚
The first approach is to rely on synchronized, trustworthy clocks and include a signed timestamp (see [RATS-TUDA]) along with the Claims in the Evidence or Attestation Result ✅. Timestamps can also be added on a per-Claim basis, to tell apart the time the Evidence or Attestation Result was generated from the time a specific Claim was generated 🔍. The clock's trustworthiness can generally be established via Endorsements, and it typically needs additional Claims about the signer's time synchronization mechanism 🧾
However, a trustworthy clock might not be available in some use cases 🙃. For example, in many TEEs today, a clock is only available outside the TEE, so the TEE can't trust it 🚫
10.2. Implicit Timekeeping Using Nonces 🎲
The second approach puts the onus of timekeeping solely on the Verifier (for Evidence) or the Relying Party (for Attestation Results) 🫵. This might be a good fit when the Attester doesn't have a trustworthy clock, or when time synchronization is otherwise impaired 🕰️. Here, the appraising entity sends an unpredictable nonce, and the nonce is then signed and included along with the Claims in the Evidence or Attestation Result 🎀. After checking that the sent and received nonces are the same, the appraising entity knows the Claims were signed after the nonce was generated 💡. That lets it associate a "rough" epoch with the Evidence or Attestation Result 🌤️. The epoch is called rough because:
- The epoch applies to the entire Claim set instead of a more granular association, and
- The time between the creation of Claims and the collection of Claims is indistinguishable.
10.3. Implicit Timekeeping Using Epoch IDs ⏳🦋
okay so the third approach is giving epoch IDs 🦋. An "epoch ID distributor" periodically sends them to both the sender and the receiver of Evidence or Attestation Results, so everyone has the same current epoch ID 💖
Epoch IDs are not the same as nonces 🙅♀️. They can be used more than once, and they can even be used by more than one entity at the same time. They're also not timestamps, since they don't have to tell you anything about a point in time. i.e., they are not necessarily monotonically increasing integers 🔢
Like the nonce approach, this gives you a "rough" epoch without needing a trustworthy clock or time synchronization to generate or appraise the freshness of Evidence or Attestation Results ✨ Only the epoch ID distributor needs access to a clock, so it can periodically send new epoch IDs. Main character energy for that one 👑
The most recent epoch ID gets included in the Evidence or Attestation Results that get produced. The appraising entity then compares the epoch ID in what it receives against the latest epoch ID it got from the epoch ID distributor, to figure out if it's within the current epoch 🧚 An actual solution also has to deal with race conditions when moving to a new epoch 😭 Some ways to handle that:
- Using a counter signed by the epoch ID distributor as the epoch ID 🔐
- Including both the current and previous epoch IDs in messages, and/or doing checks by requiring retries in case of mismatching epoch IDs 🔁
- Buffering incoming messages that might be associated with an epoch ID that the receiver has not yet obtained 📦
More generally, to stop an appraising entity from making false negatives (like tossing out Evidence that is considered stale even when it isn't), the appraising entity should keep an "epoch window" made up of the most recently received epoch IDs 🪟 The depth of that epoch window is directly proportional to the maximum network propagation delay between the first and the last to receive the epoch ID, and it's inversely proportional to the epoch duration 📐 The appraising entity shall compare the epoch ID carried in the received Evidence or Attestation Result with the epoch IDs in its epoch window, to find a suitable match 💅
Here's the vibe check: the nonce approach usually makes the appraising entity keep state for every nonce it generated. The epoch ID approach keeps way less state 🥹 It stays independent of how many Attesters or Verifiers it expects to hear from, as long as they all use the same epoch ID distributor 🌸
10.4. Discussion 🌈
Implicit and explicit timekeeping can be combined into hybrid mechanisms 🫶 For example, if clocks exist within the Attesting Environment and are considered trustworthy (tamper-proof) but aren't synchronized, you can use a nonce-based exchange to work out the (relative) time offset between the involved peers. After that, you can do any number of timestamp-based exchanges. Galaxy brain 🧠✨
It's important to note that the actual values in Claims might have been generated long before the Claims get signed 👀 If so, it's the signer's responsibility to make sure the values are still fresh when they're signed. For example, values generated at boot time might have been saved to secure storage until network connectivity is established to the remote Verifier and a nonce is obtained 🍓
A more detailed discussion with examples appears in Appendix A 📖
For a discussion on the security of epoch IDs, see Section 12.3 🔒
11. Privacy Considerations 🙈
The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a device, as well as potentially any users of the device 😬
In many cases, the whole point of attestation procedures is to give reliable info about the type of the device and the firmware/software the device is running 💜
That info can be super interesting to lots of attackers. For example, knowing that a device is running a weak version of firmware gives an attacker a way to aim attacks better. Not me being like "oh no" 💀
In some circumstances, if an attacker can become aware of Endorsements, Reference Values, or appraisal policies, it could give them insight into defensive mitigations. It is recommended that attention be paid to the confidentiality of such information 🤫
Also, many Evidence, Attestation Results, and appraisal policies potentially contain Personally Identifying Information (PII), depending on the end-to-end use case of the remote attestation procedure. Remote attestation that includes containers and applications (like a blood pressure monitor) may further reveal details about specific systems or users 🩺
In some cases, an attacker may be able to make inferences about the contents of Evidence from the resulting effects or timing of the processing. For example, an attacker might be able to infer the value of specific Claims if it knew that only certain values were accepted by the Relying Party 👀
Conceptual messages (see Section 8) carrying sensitive or confidential information are expected to be integrity protected (i.e., either via signing or a secure channel), and they optionally might be confidentiality protected via encryption 🔐 If conceptual messages themselves don't have confidentiality protection, the underlying conveyance protocol should provide these protections.
As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted Verifiers 🫣 Some Attesters might want a stronger level of assurance of a Verifier's trustworthiness before sending Evidence to it. In that case, an Attester can first act as a Relying Party and ask for the Verifier's own Attestation Result. Then it appraises that result just like a Relying Party would appraise an Attestation Result for any other purpose 💅
Another approach to dealing with Evidence is to remove PII from the Evidence while still being able to verify that the Attester is one of a large set. This approach is often called "Direct Anonymous Attestation". See Section 6.2 of [CCC-DeepDive] and [RATS-DAA] for more discussion 🦋
12. Security Considerations 🚨
This document provides an architecture for doing remote attestation. No specific wire protocol is documented here. Without a specific proposal to compare against, it's impossible to know if the security threats listed below have been mitigated well 🤷♀️
The security considerations below should be read as being, essentially, requirements against realizations of the RATS architecture. Some threats apply to protocols, and some are against implementations (code) and physical infrastructure (such as factories). Serious stuff, bestie 😤
The fundamental purpose of the RATS architecture is to allow a Relying Party to establish a basis for trusting the Attester 🫶
12.1. Attester and Attestation Key Protection 🔑
Implementers need to pay close attention to the protection of the Attester and the manufacturing processes for provisioning attestation key material. If either of these is compromised, the intended levels of assurance for remote attestation procedures are compromised, because attackers can forge Evidence or manipulate the Attesting Environment 😱 For example, a Target Environment should not be able to tamper with the Attesting Environment that measures it, so isolating the two environments from each other in some way is key 🧱
Remote attestation applies to use cases with a range of security requirements. The protections discussed here range from low to high security. Low security may be limited to application or process isolation by the device's operating system, and high security may involve specialized hardware to defend against physical attacks on a chip 🛡️
12.1.1. On-Device Attester and Key Protection 📱
It is assumed that an Attesting Environment is sufficiently isolated from the Target Environment it collects Claims about, and that it signs the resulting Claims set with an attestation key, so the Target Environment cannot forge Evidence about itself 🙅♀️ Such an isolated environment might be provided by a process, a dedicated chip, a TEE, a virtual machine, or another secure mode of operation. The Attesting Environment must be protected from unauthorized modification to ensure it behaves correctly. Confidentiality protection of the Attesting Environment's signing key is vital, so it can't be misused to forge Evidence 🔐
In many cases, the user or owner of a device that includes the role of Attester must not be able to modify or extract keys from the Attesting Environments, to prevent creating forged Evidence. Some common examples include the user of a mobile phone or a FIDO authenticator 📲
Measures for a minimally protected system might include process or application isolation provided by a high-level operating system, plus restricted access to root or system privileges. In contrast, for really simple single-use devices that don't use a protected mode operating system (like a Bluetooth speaker), the only factual isolation might be the sturdy housing of the device 🔈
Measures for a moderately protected system could include a special restricted operating environment, such as a TEE. In this case, only security-oriented software has access to the Attester and key material 🧚
Measures for a highly protected system could include specialized hardware used to provide protection against chip decapping attacks, power supply and clock glitching, fault injection and RF, and power side channel attacks. Absolute unit behavior 🔥
12.1.2. Attestation Key Provisioning Processes 🏭
Attestation key provisioning is the process that occurs in the factory or elsewhere to establish signing key material on the device and validation key material off the device. Sometimes this procedure is referred to as "personalization" or "customization" 🎀
When generating keys off-device, in the factory or in the device, the use of a cryptographically strong sequence ([RFC4086], Section 6.2) needs consideration 💜
12.1.2.1. Off-Device Key Generation ✨
okay so one way to get key material onto a device is to generate it outside the device first and then copy it over 🔑 in that case, you need confidentiality protection for the generator AND the path the key travels over. the manufacturer needs to take care to protect that key material with measures that match how valuable it is 💅
the amount of protection this key gets can vary a lot depending on what the device is for and what the manufacturer or integrator actually does in practice 🤷♀️ and bestie, the confidentiality part is basically built on some amount of physical protection 🏰 encryption is often used to keep a key confidential while it's being moved around a factory where the attestation key is created or applied, BUT the key has to be available in unencrypted form at some point 😭 so the physical protection can range from "the key is only unencrypted inside tightly controlled secure enclaves inside the silicon" all the way to "the entire facility is considered secure because it has locked doors and limited access" 🔒
the crypto used to protect the attestation key also has its own requirements that need securing 🌀 it's giving recursion. the key material used to provision attestation keys must again have somehow been provisioned securely beforehand, which needs yet another layer of protection, and so on, and so on 🙈
so usually you'll see a mix of physical security measures and cryptographic measures working together to establish confidentiality protection 🫶
12.1.2.2. On-Device Key Generation 🌸
when key material is generated inside the device and its secret part never leaves the device, the problem gets lighter 🦋 for public-key cryptography, you don't need to keep the public key confidential, which is a relief tbh 💜 BUT the integrity of the chain of custody for the public key is still necessary, so attackers can't get a key endorsed that they control 🚫 that's the whole point of this one, periodt ✨
to summarize: attestation key provisioning must ensure that only valid attestation key material is established in Attesters 👑
12.2. Conceptual Message Protection 💌
any solution that conveys information in any conceptual message (see Section 8) must support end-to-end integrity protection and replay attack prevention. it often also needs to support additional security properties, including:
- end-to-end encryption,
- denial-of-service protection,
- authentication,
- auditing,
- fine-grained access controls, and
- logging.
Section 10 talks about how freshness can be used in this architecture to protect against replay attacks ⏰
to figure out how much security a particular appraisal policy actually gives you, it's important to understand how strong the root of trust is 🌱 for example, is it mutable software or firmware that's read-only after boot, or is it immutable hardware/ROM? big difference, no cap 💀
it's also important that the appraisal policy was obtained securely in the first place 🔐 if an attacker can configure or modify appraisal policies and Endorsements or Reference Values for a Relying Party or a Verifier, then the integrity of the whole process is compromised 😱
security protections in the RATS architecture may be applied at different layers, whether that's by a conveyance protocol or an information encoding format 🧩 this architecture expects conceptual messages to be end-to-end protected based on the role interaction context. so, for example, if an Attester produces Evidence that gets relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence 🙅♀️
the RATS architecture lets an entity function in multiple roles (Section 6) and also allows for composite devices (Section 3.3) 🎭 implementers need to evaluate their designs so that the assumed security properties of the individual components and roles still hold even without separation, and so that no emergent risk gets introduced 👀 the specifics of this evaluation depend on the implementation and the use case, so they're out of scope for this document 🙃 isolation mechanisms in software or hardware that separate Attesting Environments and Target Environments (Section 3.1) can support an implementer's evaluation and the design decisions that come out of it 🧱
12.3. Attestation Based on Epoch ID ⏳
Epoch IDs, described in Section 10.3, can be tampered with, replayed, dropped, delayed, and reordered by an attacker 😤
the attacker could be external, or they could be part of the distribution group (for example, if one of the Attester entities has been compromised) 🕵️♀️
an attacker who can tamper with epoch IDs can potentially lock all the participants in a certain epoch of their choice forever, which is basically freezing time 🧊 that's a major problem, because it destroys the ability to ascertain the freshness of Evidence and Attestation Results 😭
to mitigate this threat, the transport should be at least integrity protected and provide origin authentication 🛡️
selectively dropping epoch IDs is the same thing as pinning the victim node to a past epoch 📌 if an attacker drops epoch IDs for some entities and not others, that will typically result in a denial of service, because the Attestation Result or Evidence becomes permanently stale 🥀
delaying or reordering epoch IDs is the same as manipulating the victim's timeline whenever the attacker wants ⏪ a malicious actor (for example, a compromised router) could use that ability to mount a confusion attack 🌀 for instance, a Verifier can be tricked into accepting Evidence from a past epoch as fresh, while in the meantime the Attester has been compromised 😈
reordering and dropping attacks are mitigated if the transport provides the ability to detect reordering and drops ✅ however, the delay attack described above can't be stopped this way 💔
12.4. Trust Anchor Protection 👑
as noted in Section 7, Verifiers and Relying Parties have trust anchor stores that must be secured 🔐 [RFC6024] has more discussion of trust anchor store requirements for protecting public keys. Section 6 of [NIST-800-57-p1] is a thorough treatment of the topic, including protection of symmetric key material 📚 specifically, a trust anchor store must resist modification against unauthorized insertion, deletion, and modification 🚧 and if the trust anchor is a symmetric key, the trust anchor store must not allow unauthorized read 🙊
if certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor, which includes checking for certificate revocation 📜 for an example of how that procedure works, see Section 6 of [RFC5280] 🔍
13. IANA Considerations 🌈
this document has no IANA actions 🫧
14. References 📖
14.1. Normative References
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, https://www.rfc-editor.org/info/rfc5280.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, https://www.rfc-editor.org/info/rfc7519.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, https://www.rfc-editor.org/info/rfc8392.
14.2. Informative References 📚✨
Okay bestie, these are the informative refs, the extra reading that's not required to get the spec, but it's giving deep-dive energy 🤓💅. Every entry is copied exactly below so you can look up any of them 🔍.
[CCC-DeepDive]
Confidential Computing Consortium, "A Technical Analysis
of Confidential Computing", Version 1.3, November 2022,
<https://confidentialcomputing.io/white-papers-reports>.
[CTAP] FIDO Alliance, "Client to Authenticator Protocol (CTAP)",
February 2018, <https://fidoalliance.org/specs/fido-v2.0-
id-20180227/fido-client-to-authenticator-protocol-v2.0-id-
20180227.html>.
[NIST-800-57-p1]
Barker, E., "Recommendation for Key Management: Part 1 -
General", DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-57pt1r5.pdf>.
[OPCUA] OPC Foundation, "OPC Unified Architecture Specification,
Part 2: Security Model, Release 1.03", OPC 10000-2 ,
November 2015, <https://opcfoundation.org/developer-tools/
specifications-unified-architecture/part-2-security-
model/>.
[RATS-DAA] Birkholz, H., Newton, C., Chen, L., and D. Thaler, "Direct
Anonymous Attestation for the Remote Attestation
Procedures Architecture", Work in Progress, Internet-
Draft, draft-ietf-rats-daa-02, 7 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
daa-02>.
[RATS-PSA-TOKEN]
Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T.
Fossati, "Arm's Platform Security Architecture (PSA)
Attestation Token", Work in Progress, Internet-Draft,
draft-tschofenig-rats-psa-token-10, 6 September 2022,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
rats-psa-token-10>.
[RATS-TUDA]
Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
"Time-Based Uni-Directional Attestation", Work in
Progress, Internet-Draft, draft-birkholz-rats-tuda-07, 10
July 2022, <https://datatracker.ietf.org/doc/html/draft-
birkholz-rats-tuda-07>.
[RATS-UCCS]
Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
Work in Progress, Internet-Draft, draft-ietf-rats-uccs-04,
11 January 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-uccs-04>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<https://www.rfc-editor.org/info/rfc5209>.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, DOI 10.17487/RFC6024, October
2010, <https://www.rfc-editor.org/info/rfc6024>.
[RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource-
Oriented Lightweight Information Exchange (ROLIE)",
RFC 8322, DOI 10.17487/RFC8322, February 2018,
<https://www.rfc-editor.org/info/rfc8322>.
[strengthoffunction]
NIST, "Strength of Function",
<https://csrc.nist.gov/glossary/term/
strength_of_function>.
[TCG-DICE] Trusted Computing Group, "DICE Attestation Architecture",
Version 1.00, Revision 0.23, March 2021,
<https://trustedcomputinggroup.org/wp-content/uploads/
DICE-Attestation-Architecture-r23-final.pdf>.
[TCG-DICE-SIBDA]
Trusted Computing Group, "Symmetric Identity Based Device
Attestation", Version 1.0, Revision 0.95, January 2020,
<https://trustedcomputinggroup.org/wp-content/uploads/
TCG_DICE_SymIDAttest_v1_r0p95_pub-1.pdf>.
[TCGarch] Trusted Computing Group, "Trusted Platform Module Library,
Part 1: Architecture", November 2019,
<https://trustedcomputinggroup.org/wp-content/uploads/
TCG_TPM2_r1p59_Part1_Architecture_pub.pdf>.
[TEEP-ARCH]
Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-teep-architecture-19, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teep-
architecture-19>.
[TLS-CWT] Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens
(CWTs) in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS)", Work in Progress,
Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
tls-cwt-02>.
[WebAuthN] W3C, "Web Authentication: An API for accessing Public Key
Credentials Level 1", March 2019,
<https://www.w3.org/TR/webauthn-1/>.Appendix A. Time Considerations ⏰🦋
Okay, time to get into the timey-wimey stuff! 🕰️ Section 10 covered the issues and requirements around how fresh Evidence needs to be, and it summarised three approaches different solutions might use to handle them. This appendix gives you more details and examples so you can see how those approaches play out and get inspired to build your own solution 💖.
The table below defines a bunch of relevant events, each with an ID that the later diagrams use 📊. The timing of these events might be written in absolute clock time, like Coordinated Universal Time, or relative to some other timestamp or timeticks counter, like a clock that resets its epoch every time it powers on ⚡.
+====+============+=================================================+
| ID | Event | Explanation of event |
+====+============+=================================================+
| VG | Value | A value to appear in a Claim was created. |
| | generated | In some cases, a value may have technically |
| | | existed before an Attester became aware of |
| | | it, but the Attester might have no idea how |
| | | long it has had that value. In such a |
| | | case, the value created time is the time at |
| | | which the Claim containing the copy of the |
| | | value was created. |
+----+------------+-------------------------------------------------+
| NS | Nonce sent | A nonce not predictable to an Attester |
| | | (recentness & uniqueness) is sent to an |
| | | Attester. |
+----+------------+-------------------------------------------------+
| NR | Nonce | A nonce is relayed to an Attester by |
| | relayed | another entity. |
+----+------------+-------------------------------------------------+
| IR | Epoch ID | An epoch ID is successfully received and |
| | received | processed by an entity. |
+----+------------+-------------------------------------------------+
| EG | Evidence | An Attester creates Evidence from collected |
| | generation | Claims. |
+----+------------+-------------------------------------------------+
| ER | Evidence | A Relying Party relays Evidence to a |
| | relayed | Verifier. |
+----+------------+-------------------------------------------------+
| RG | Result | A Verifier appraises Evidence and generates |
| | generation | an Attestation Result. |
+----+------------+-------------------------------------------------+
| RR | Result | A Relying Party relays an Attestation |
| | relayed | Result to a Relying Party. |
+----+------------+-------------------------------------------------+
| RA | Result | The Relying Party appraises Attestation |
| | appraised | Results. |
+----+------------+-------------------------------------------------+
| OP | Operation | The Relying Party performs some operation |
| | performed | requested by the Attester via a resource |
| | | access protocol as depicted in Figure 8, |
| | | e.g., across a session created earlier at |
| | | time(RA). |
+----+------------+-------------------------------------------------+
| RX | Result | An Attestation Result should no longer be |
| | expiry | accepted, according to the Verifier that |
| | | generated it. |
+----+------------+-------------------------------------------------+
Table 1: Relevant Events over TimeUsing the table above, we've got a bunch of hypothetical examples of how a solution could be built 🧩. This list isn't meant to be complete ngl, it's just representative enough to show off the different timing things to think about 💅.
All times are relative to the local clocks, marked with an "_a" (Attester), "_v" (Verifier), or "_r" (Relying Party) suffix 🕐. Times with an appended Prime (') mean a second instance of the same event 🌸. How and if clocks get synchronised depends on the model, so it's totally a vibe check 🫶.
In the figures below, curly braces mean containment 🎀. For example, the notation Evidence{foo} means that 'foo' is contained in the Evidence, so it's covered by its signature. Main character signature energy 🔥✨
A.1. Example 1: Timestamp-Based Passport Model
okay so this one is the timestamp example 🕰️✨ bestie, picture a hypothetical Passport Model solution where everybody's clocks are roughly synced up. The whole trick is that the Attester, Verifier, and Relying Party all need a secure clock sync mechanism to make it work, no cap 💅. Because of that, whoever receives a conceptual message with a timestamp can just compare it straight to their own clock and timestamps. so easy, it's giving simplicity 🦋
.----------. .----------. .---------------.
| Attester | | Verifier | | Relying Party |
'----+-----' '-----+----' '-------+-------'
| | |
time(VG_a) | |
| | |
~ ~ ~
| | |
time(EG_a) | |
| | |
+------Evidence{time(EG_a)}------>| |
| | |
| time(RG_v) |
| | |
|<-----Attestation Result---------+ |
| {time(RG_v),time(RX_v)} | |
~ ~
| |
+--Attestation Result{time(RG_v),time(RX_v)}--> time(RA_r)
| |
~ ~
| |
| time(OP_r)
Figure 10: Timestamp-Based Passport Modelso the Verifier can check if the Evidence is fresh when it appraises it at time(RG_v) 🌸 it does this by checking time(RG_v) - time(EG_a) < Threshold. the Verifier's threshold has to be big enough to cover the maximum permitted clock skew between the Verifier and the Attester, otherwise it's gonna be messy 😭
if time(VG_a) is included in the Evidence along with the Claim value made at that time, AND the Verifier decides it can trust that time(VG_a) value, then the Verifier can also figure out whether the Claim value is recent by checking time(RG_v) - time(VG_a) < Threshold. the Appraisal Policy for Evidence decides what that threshold is, and again it needs to account for the maximum permitted clock skew between the Verifier and the Attester 🎀
the Attester doesn't consume the Attestation Result, but it might cache it 🧚
now the Relying Party can check if the Attestation Result is fresh when it appraises it at time(RA_r), by checking time(RA_r) - time(RG_v) < Threshold 💖 its threshold has to be large enough for the maximum permitted clock skew between the Relying Party and the Verifier. the result might then get used for a while (for example, the whole lifetime of a connection set up at time(RA_r)) ✨ BUT the Relying Party must be careful not to keep using it past the period where it's still fresh enough, bestie, this is serious 💀 so it might allow use (at time(OP_r)) as long as time(OP_r) - time(RG_v) < Threshold. and if the Attestation Result has an expiry time time(RX_v), then it could explicitly check time(OP_r) < time(RX_v) 🔥
A.2. Example 2: Nonce-Based Passport Model
Figure 11 shows a hypothetical Passport Model solution that uses nonces instead of timestamps 🌈 compared to the timestamp one, it needs an extra round trip to grab a nonce, and the Verifier and Relying Party have to track state to remember the nonce for some period of time 🙈
the big perk is that it doesn't need any clocks to be synchronized 🫶 which means the receiver of a conceptual message with a timestamp can't directly compare it to its own clock or timestamps. so we use a suffix on the IDs ("a" for Attester, "v" for Verifier, and "r" for Relying Party) to show which clock made them, since times from different clocks can't be compared. the receiver can only use the delta between two events from the sender 🧠
.----------. .----------. .---------------.
| Attester | | Verifier | | Relying Party |
'----+-----' '-----+----' '-------+-------'
| | |
time(VG_a) | |
| | |
~ ~ ~
| | |
|<--Nonce1---------------------time(NS_v) |
| | |
time(EG_a) | |
| | |
+---Evidence--------------------->| |
| {Nonce1, time(EG_a)-time(VG_a)} | |
| | |
| time(RG_v) |
| | |
|<--Attestation Result------------+ |
| {time(RX_v)-time(RG_v)} | |
~ ~
| |
|<--Nonce2-------------------------------------time(NS_r)
| |
time(RR_a) |
| |
+--[Attestation Result{time(RX_v)-time(RG_v)}, -->|time(RA_r)
| Nonce2, time(RR_a)-time(EG_a)] |
| |
~ ~
| |
| time(OP_r)
Figure 11: Nonce-Based Passport Modelin this example the Verifier can check if the Evidence is fresh at time(RG_v) by making sure time(RG_v)-time(NS_v) < Threshold 🌸
BUT (and this is a big but 😭) the Verifier can't just rely on a Nonce to decide whether a Claim value is recent, because the Claim value might have been generated way before the Verifier sent the nonce. still, if the Verifier decides the Attester can be trusted to correctly provide the delta time(EG_a)-time(VG_a), then it can figure out recency by checking time(RG_v)-time(NS_v) + time(EG_a)-time(VG_a) < Threshold 🦋
same vibe for the Relying Party: if it trusts the Verifier's Attestation Result and decides the Attester can be trusted to correctly provide time deltas, then it can check if the Attestation Result is fresh by checking time(OP_r)-time(NS_r) + time(RR_a)-time(EG_a) < Threshold 💅 the Nonce2 and time(RR_a)-time(EG_a) values can't go inside the Attestation Result, but the Attester might sign them so the Attestation Result vouches for the Attester's signing capability 🎀
the Relying Party still has to be careful not to keep using it past the period where it's valid, periodt ✨ so if the Attestation Result sends a validity lifetime in terms of time(RX_v)-time(RG_v), then the Relying Party can check time(OP_r)-time(NS_r) < time(RX_v)-time(RG_v) 👑
A.3. Example 3: Passport Model Based on Epoch ID
okay last one, and it's a fun one 🧚💜 Figure 12 shows a hypothetical Passport Model solution that uses epoch IDs instead of nonces or timestamps 🌸
the epoch ID distributor broadcasts epoch ID I, which starts a new epoch E for a protocol participant when it gets received at time(IR) 💖
the Attester makes Evidence that includes epoch ID I and sends it to the Verifier 🫶
the Verifier checks that the epoch ID I it got is "fresh" according to the definition in Section 10.3, where retries are needed if the epoch IDs don't match. then the Verifier makes an Attestation Result, and that gets sent back to the Attester ✨
after epoch ID I' gets sent out, a new epoch E' is set up once I' is received by each protocol participant 🌈 the Attester relays the Attestation Result it got during epoch E (linked to epoch ID I) to the Relying Party, using the epoch ID for the current epoch I'. if the Relying Party hasn't received I' yet, the Attestation Result gets rejected 😭 in this example, it does get received 🎉
in Figure 12, the epoch ID used to relay the Attestation Result to the Relying Party is current, but a previous epoch ID was used to make the Verifier-evaluated Evidence. this means at least one epoch transition happened, so the Attestation Results may only be as fresh as the previous epoch 💀 if the Relying Party remembers the previous epoch ID I during an epoch window (as discussed in Section 10.3) and the message arrives during that window, the Attestation Result is accepted as fresh 🙌 otherwise it's rejected as stale 🥀
.-------------.
.----------. | Epoch ID | .----------. .---------------.
| Attester | | Distributor | | Verifier | | Relying Party |
'----+-----' '------+------' '-----+----' '-------+-------'
| | | |
time(VG_a) | | |
| | | |
~ | ~ ~
| | | |
time(IR_a) <-----I--o--I------> time(IR_v) ---> time(IR_r)
| | | |
time(EG_a) | | |
| | | |
+---Evidence--------------------->| |
| {I,time(EG_a)-time(VG_a)} | |
| | | |
| | time(RG_v) |
| | | |
|<--Attestation Result------------+ |
| {I,time(RX_v)-time(RG_v)} | |
| | | |
time(IR'_a) <----I'-o--I' ----> time(IR'_v) --> time(IR'_r)
| | |
+---[Attestation Result--------------------> time(RA_r)
| {I,time(RX_v)-time(RG_v)},I'] | |
| | |
~ ~ ~
| | |
| | time(OP_r)
Figure 12: Epoch ID-Based Passport ModelA.4. Example 4: Timestamp-Based Background-Check Model 🕰️✨
okay so bestie, this one is a hypothetical Background-Check Model solution 💅 It uses timestamps, which means the Attester, Verifier, and Relying Party need roughly synchronized clocks ⏰🫶 The Attester sends Evidence to the Relying Party, and the Relying Party doesn't open it up or poke at it. It just forwards it along to the Verifier 📨
.----------. .---------------. .----------.
| Attester | | Relying Party | | Verifier |
'-------+--' '-------+-------' '----+-----'
| | |
time(VG_a) | |
| | |
~ ~ ~
| | |
time(EG_a) | |
| | |
+----Evidence------->| |
| {time(EG_a)} | |
| time(ER_r) ---Evidence{time(EG_a)}---->|
| | |
| | time(RG_v)
| | |
| time(RA_r) <---Attestation Result------+
| | {time(RX_v)} |
~ ~ ~
| | |
| time(OP_r) |
Figure 13: Timestamp-Based Background-Check Modelthe time considerations here are basically the same vibe as Example 1 🌸 go check that one out if you want the full tea 🍵
A.5. Example 5: Nonce-Based Background-Check Model 🎀
okay this one is a hypothetical Background-Check Model solution that uses nonces 🧚 which means it does not need any clocks to be synchronized 🙌 In this setup, the Verifier makes a nonce whenever the Relying Party asks for one, for when the Relying Party needs to send it to an Attester 💌
.----------. .---------------. .----------.
| Attester | | Relying Party | | Verifier |
'----+-----' '-------+-------' '----+-----'
| | |
time(VG_a) | |
| | |
~ ~ ~
| | |
| |<-------Nonce-----------time(NS_v)
| | |
|<---Nonce-----------time(NR_r) |
| | |
time(EG_a) | |
| | |
+----Evidence{Nonce}--->| |
| | |
| time(ER_r) ---Evidence{Nonce}--->|
| | |
| | time(RG_v)
| | |
| time(RA_r) <---Attestation Result--+
| | {time(RX_v)-time(RG_v)} |
~ ~ ~
| | |
| time(OP_r) | Figure 14: Nonce-Based Background-Check Modelthe Verifier can check whether the Evidence is fresh and whether a Claim value is recent, same as Example 2 ✨
However, unlike in Example 2, the Relying Party can use the Nonce to figure out whether the Attestation Result is fresh 🕵️♀️ It does that by checking that:
time(OP_r)-time(NR_r) < ThresholdHowever, the Relying Party still has to be careful and not let things keep going past the period it considers the Attestation Result to stay valid 🚨 So if the Attestation Result sends a validity lifetime in terms of time(RX_v)-time(RG_v), then the Relying Party can check:
time(OP_r)-time(ER_r) < time(RX_v)-time(RG_v)Acknowledgments 🫶
The authors would like to thank the following people for their input 💖
Joerg Borchert, Carsten Bormann, Nancy Cam-Winget, Guy Fedorkow, Jessica Fitzgerald-McKay, Thomas Fossati, Simon Frost, Andrew Guinn, Thomas Hardjano, Eliot Lear, Diego Lopez, Peter Loscocco, Laurence Lundblade, Giri Mandyam, Daniel Migault, Kathleen Moriarty, Paul Rowe, Hannes Tschofenig, Eric Voit, Monty Wiseman, David Wooten, and Liang Xia 🌈👑
Contributors 🧚
Thomas Hardjono created initial versions of the terminology section in collaboration with Ned Smith 💜 Eric Voit provided the conceptual separation between Attestation Provision Flows and Attestation Evidence Flows 🔥 Monty Wisemen was a key author of a document that was merged to create this document 🦋 Carsten Bormann provided many of the motivational building blocks with respect to the Internet Threat Model 🌸
Peter Loscocco contributed critical review feedback as part of the weekly design team meetings that added precision and depth to several sections ⭐
Authors' Addresses 📬
Henk Birkholz Fraunhofer SIT Rheinstrasse 75 64295 Darmstadt Germany Email: henk.birkholz@sit.fraunhofer.de
Dave Thaler Microsoft United States of America Email: dthaler@microsoft.com
Michael Richardson Sandelman Software Works Canada Email: mcr+ietf@sandelman.ca
Ned Smith Intel Corporation United States of America Email: ned.smith@intel.com
Wei Pan Huawei Technologies Email: william.panwei@huawei.com
📦 where this page comes from
- ietf: rfc9334 2023-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms