draft-ietf-rats-architecture-07.txt   draft-ietf-rats-architecture-08.txt 
RATS Working Group H. Birkholz RATS Working Group H. Birkholz
Internet-Draft Fraunhofer SIT Internet-Draft Fraunhofer SIT
Intended status: Informational D. Thaler Intended status: Informational D. Thaler
Expires: 19 April 2021 Microsoft Expires: 11 June 2021 Microsoft
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
N. Smith N. Smith
Intel Intel
W. Pan W. Pan
Huawei Technologies Huawei Technologies
16 October 2020 8 December 2020
Remote Attestation Procedures Architecture Remote Attestation Procedures Architecture
draft-ietf-rats-architecture-07 draft-ietf-rats-architecture-08
Abstract Abstract
In network protocol exchanges, it is often the case that one entity In network protocol exchanges it is often the case that one entity
(a Relying Party) requires evidence about a remote peer to assess the requires believable evidence about the operational state of a remote
peer's trustworthiness, and a way to appraise such evidence. The peer. Such evidence is typically conveyed as claims about the peer's
evidence is typically a set of claims about its software and hardware software and hardware platform, and is subsequently appraised in
platform. This document describes an architecture for such remote order to assess the peer's trustworthiness. The process of
attestation procedures (RATS). generating and appraising this kind of evidence is known as remote
attestation. This document describes an architecture for remote
attestation procedures that generate, convey, and appraise evidence
about a peer's operational state.
Note to Readers Note to Readers
Discussion of this document takes place on the RATS Working Group Discussion of this document takes place on the RATS Working Group
mailing list (rats@ietf.org), which is archived at mailing list (rats@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/rats/ https://mailarchive.ietf.org/arch/browse/rats/
(https://mailarchive.ietf.org/arch/browse/rats/). (https://mailarchive.ietf.org/arch/browse/rats/).
Source for this draft and an issue tracker can be found at Source for this draft and an issue tracker can be found at
https://github.com/ietf-rats-wg/architecture (https://github.com/ https://github.com/ietf-rats-wg/architecture (https://github.com/
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 April 2021. This Internet-Draft will expire on 11 June 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 4
3. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 5 2.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 4
3.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 6 2.2. Confidential Machine Learning (ML) Model Protection . . . 5
3.2. Confidential Machine Learning (ML) Model Protection . . . 6 2.3. Confidential Data Retrieval . . . . . . . . . . . . . . . 5
3.3. Confidential Data Retrieval . . . . . . . . . . . . . . . 7 2.4. Critical Infrastructure Control . . . . . . . . . . . . . 6
3.4. Critical Infrastructure Control . . . . . . . . . . . . . 7 2.5. Trusted Execution Environment (TEE) Provisioning . . . . 6
3.5. Trusted Execution Environment (TEE) Provisioning . . . . 7 2.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 6
3.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 8 2.7. FIDO Biometric Authentication . . . . . . . . . . . . . . 7
3.7. FIDO Biometric Authentication . . . . . . . . . . . . . . 8 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 7
4. Architectural Overview . . . . . . . . . . . . . . . . . . . 9 3.1. Appraisal Policies . . . . . . . . . . . . . . . . . . . 9
4.1. Appraisal Policies . . . . . . . . . . . . . . . . . . . 10 3.2. Reference Values . . . . . . . . . . . . . . . . . . . . 9
4.2. Reference Values . . . . . . . . . . . . . . . . . . . . 10 3.3. Two Types of Environments of an Attester . . . . . . . . 9
4.3. Two Types of Environments of an Attester . . . . . . . . 10 3.4. Layered Attestation Environments . . . . . . . . . . . . 10
4.4. Layered Attestation Environments . . . . . . . . . . . . 11 3.5. Composite Device . . . . . . . . . . . . . . . . . . . . 12
4.5. Composite Device . . . . . . . . . . . . . . . . . . . . 13 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Topological Models . . . . . . . . . . . . . . . . . . . . . 16 5. Topological Models . . . . . . . . . . . . . . . . . . . . . 16
5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 16 5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 17
5.2. Background-Check Model . . . . . . . . . . . . . . . . . 17 5.2. Background-Check Model . . . . . . . . . . . . . . . . . 18
5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 18 5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 19
6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 19 6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 20
7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Attester . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Attester . . . . . . . . . . . . . . . . . . . . . . . . 22
7.3. Relying Party Owner . . . . . . . . . . . . . . . . . . . 21 7.3. Relying Party Owner . . . . . . . . . . . . . . . . . . . 22
7.4. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 21 7.4. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 22
7.5. Endorser, Reference Value Provider, and Verifier Owner . 23 7.5. Endorser, Reference Value Provider, and Verifier Owner . 24
8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 23 8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 24
8.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 24 8.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 25
8.3. Attestation Results . . . . . . . . . . . . . . . . . . . 24 8.3. Attestation Results . . . . . . . . . . . . . . . . . . . 25
9. Claims Encoding Formats . . . . . . . . . . . . . . . . . . . 25 9. Claims Encoding Formats . . . . . . . . . . . . . . . . . . . 26
10. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30
12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12.1. Attester and Attestation Key Protection . . . . . . . . 30 12.1. Attester and Attestation Key Protection . . . . . . . . 31
12.1.1. On-Device Attester and Key Protection . . . . . . . 30 12.1.1. On-Device Attester and Key Protection . . . . . . . 31
12.1.2. Attestation Key Provisioning Processes . . . . . . . 31 12.1.2. Attestation Key Provisioning Processes . . . . . . . 32
12.2. Integrity Protection . . . . . . . . . . . . . . . . . . 31 12.2. Integrity Protection . . . . . . . . . . . . . . . . . . 32
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
15. Notable Contributions . . . . . . . . . . . . . . . . . . . . 33 15. Notable Contributions . . . . . . . . . . . . . . . . . . . . 34
16. Appendix A: Time Considerations . . . . . . . . . . . . . . . 33 16. Appendix A: Time Considerations . . . . . . . . . . . . . . . 34
16.1. Example 1: Timestamp-based Passport Model Example . . . 34 16.1. Example 1: Timestamp-based Passport Model Example . . . 35
16.2. Example 2: Nonce-based Passport Model Example . . . . . 36 16.2. Example 2: Nonce-based Passport Model Example . . . . . 37
16.3. Example 3: Handle-based Passport Model Example . . . . . 37 16.3. Example 3: Handle-based Passport Model Example . . . . . 38
16.4. Example 4: Timestamp-based Background-Check Model 16.4. Example 4: Timestamp-based Background-Check Model
Example . . . . . . . . . . . . . . . . . . . . . . . . 39 Example . . . . . . . . . . . . . . . . . . . . . . . . 40
16.5. Example 5: Nonce-based Background-Check Model Example . 39 16.5. Example 5: Nonce-based Background-Check Model Example . 41
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
17.1. Normative References . . . . . . . . . . . . . . . . . . 40 17.1. Normative References . . . . . . . . . . . . . . . . . . 42
17.2. Informative References . . . . . . . . . . . . . . . . . 40 17.2. Informative References . . . . . . . . . . . . . . . . . 42
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
In Remote Attestation Procedures (RATS), one peer (the "Attester") In Remote Attestation Procedures (RATS), one peer (the "Attester")
produces believable information about itself - Evidence - to enable a produces believable information about itself - Evidence - to enable a
remote peer (the "Relying Party") to decide whether to consider that remote peer (the "Relying Party") to decide whether to consider that
Attester a trustworthy peer or not. RATS are facilitated by an Attester a trustworthy peer or not. RATS are facilitated by an
additional vital party, the Verifier. additional vital party, the Verifier.
The Verifier appraises Evidence via appraisal policies and creates The Verifier appraises Evidence via appraisal policies and creates
the Attestation Results to support Relying Parties in their decision the Attestation Results to support Relying Parties in their decision
process. This documents defines a flexible architecture consisting process. This document defines a flexible architecture consisting of
of attestation roles and their interactions via conceptual messages. attestation roles and their interactions via conceptual messages.
Additionally, this document defines a universal set of terms that can Additionally, this document defines a universal set of terms that can
be mapped to various existing and emerging Remote Attestation be mapped to various existing and emerging Remote Attestation
Procedures. Common topological models and the data flows associated Procedures. Common topological models and the data flows associated
with them, such as the "Passport Model" and the "Background-Check with them, such as the "Passport Model" and the "Background-Check
Model" are illustrated. The purpose is to define useful terminology Model" are illustrated. The purpose is to define useful terminology
for attestation and enable readers to map their solution architecture for attestation and enable readers to map their solution architecture
to the canonical attestation architecture provided here. Having a to the canonical attestation architecture provided here. Having a
common terminology that provides well-understood meanings for common common terminology that provides well-understood meanings for common
themes such as roles, device composition, topological models, and themes such as roles, device composition, topological models, and
appraisal is vital for semantic interoperability across solutions and appraisal is vital for semantic interoperability across solutions and
platforms involving multiple vendors and providers. platforms involving multiple vendors and providers.
Amongst other things, this document is about trust and Amongst other things, this document is about trust and
trustworthiness. Trust is a choice one makes about another system. trustworthiness. Trust is a choice one makes about another system.
Trustworthiness is a quality about the other system that can be used Trustworthiness is a quality about the other system that can be used
in making one's decision to trust it or not. This is subtle in making one's decision to trust it or not. This is subtle
difference and being familiar with the difference is crucial for difference and being familiar with the difference is crucial for
using this document. Additionally, the concepts of freshness and using this document. Additionally, the concepts of freshness and
trust relationships with respect to RATS are elaborated on to enable trust relationships with respect to RATS are elaborated on to enable
implementers in order to choose appropriate solutions to compose implementers to choose appropriate solutions to compose their Remote
their Remote Attestation Procedures. Attestation Procedures.
2. Terminology
This document uses the following terms.
Appraisal Policy for Evidence: A set of rules that informs how a
Verifier evaluates the validity of information about an Attester.
Compare /security policy/ in [RFC4949]
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/ in
[RFC4949]
Attestation Result: The output generated by a Verifier, typically
including information about an Attester, where the Verifier
vouches for the validity of the results
Attester: A role performed by an entity (typically a device) whose
Evidence must be appraised in order to infer the extent to which
the Attester is considered trustworthy, such as when deciding
whether it is authorized to perform some operation
Claim: A piece of asserted information, often in the form of a name/
value pair. (Compare /claim/ in [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
Endorser: An entity (typically a manufacturer) whose Endorsements
help Verifiers appraise the authenticity of Evidence
Evidence: A set of information about an Attester that is to be
appraised by a Verifier. Evidence may include configuration data,
measurements, telemetry, or inferences.
Reference Value Provider: An entity (typically a manufacturer) whose
Reference Values help Verifiers appraise the authenticity of
Evidence.
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 referred to in other documents as
known-good values, golden measurements, or nominal values,
although those terms typically assume comparison for equality,
whereas here Reference Values might be more general and be used in
any sort of comparison.
Relying Party: A role performed by an entity that depends on the
validity of information about an Attester, for purposes of
reliably applying application specific actions. Compare /relying
party/ in [RFC4949]
Relying Party Owner: An entity (typically an administrator), that is
authorized to configure Appraisal Policy for Attestation Results
in a Relying Party
Verifier: A role performed by an entity that appraises the validity
of Evidence about an Attester and produces Attestation Results to
be used by a Relying Party
Verifier Owner: An entity (typically an administrator), that is
authorized to configure Appraisal Policy for Evidence in a
Verifier
3. Reference Use Cases 2. Reference Use Cases
This section covers a number of representative use cases for remote This section covers a number of representative use cases for remote
attestation, independent of specific solutions. The purpose is to attestation, independent of specific solutions. The purpose is to
provide motivation for various aspects of the architecture presented provide motivation for various aspects of the architecture presented
in this draft. Many other use cases exist, and this document does in this draft. Many other use cases exist, and this document does
not intend to have a complete list, only to have a set of use cases not intend to have a complete list, only to have a set of use cases
that collectively cover all the functionality required in the that collectively cover all the functionality required in the
architecture. architecture.
Each use case includes a description followed by a summary of the Each use case includes a description followed by a summary of the
Attester and a Relying Party roles. Attester and Relying Party roles.
3.1. Network Endpoint Assessment 2.1. Network Endpoint Assessment
Network operators want a trustworthy report that includes identity Network operators want a trustworthy report that includes identity
and version of information of the hardware and software on the and version of information of the hardware and software on the
machines attached to their network, for purposes such as inventory, machines attached to their network, for purposes such as inventory,
audit, anomaly detection, record maintenance and/or trending reports audit, anomaly detection, record maintenance and/or trending reports
(logging). The network operator may also want a policy by which full (logging). The network operator may also want a policy by which full
access is only granted to devices that meet some definition of access is only granted to devices that meet some definition of
hygiene, and so wants to get claims about such information and verify hygiene, and so wants to get claims about such information and verify
their validity. Remote attestation is desired to prevent vulnerable its validity. Remote attestation is desired to prevent vulnerable or
or compromised devices from getting access to the network and compromised devices from getting access to the network and
potentially harming others. potentially harming others.
Typically, solutions start with a specific component (called a "root Typically, solutions start with a specific component (called a "root
of trust") that provides device identity and protected storage for of trust") that provides device identity and protected storage for
measurements. The system components perform a series of measurements measurements. The system components perform a series of measurements
that may be signed by the root of trust, considered as Evidence about that may be signed by the root of trust, considered as Evidence about
the hardware, firmware, BIOS, software, etc. that is running. the hardware, firmware, BIOS, software, etc. that is running.
Attester: A device desiring access to a network Attester: A device desiring access to a network
Relying Party: A network infrastructure device such as a router, Relying Party: A network infrastructure device such as a router,
switch, or access point switch, or access point
3.2. Confidential Machine Learning (ML) Model Protection 2.2. Confidential Machine Learning (ML) Model Protection
A device manufacturer wants to protect its intellectual property. A device manufacturer wants to protect its intellectual property.
This is primarily the ML model it developed and runs in the devices This is primarily the ML model it developed and runs in the devices
purchased by its customers. The goals for the protection include purchased by its customers. The goals for the protection include
preventing attackers, potentially the customer themselves, from preventing attackers, potentially the customer themselves, from
seeing the details of the model. seeing the details of the model.
This typically works by having some protected environment in the This typically works by having some protected environment in the
device go through a remote attestation with some manufacturer service device go through a remote attestation with some manufacturer service
that can assess its trustworthiness. If remote attestation succeeds, that can assess its trustworthiness. If remote attestation succeeds,
then the manufacturer service releases either the model, or a key to then the manufacturer service releases either the model, or a key to
decrypt a model the Attester already has in encrypted form, to the decrypt a model the Attester already has in encrypted form, to the
requester. requester.
Attester: A device desiring to run an ML model Attester: A device desiring to run an ML model
Relying Party: A server or service holding ML models it desires to Relying Party: A server or service holding ML models it desires to
protect protect
3.3. Confidential Data Retrieval 2.3. Confidential Data Retrieval
This is a generalization of the ML model use case above, where the This is a generalization of the ML model use case above, where the
data can be any highly confidential data, such as health data about data can be any highly confidential data, such as health data about
customers, payroll data about employees, future business plans, etc. customers, payroll data about employees, future business plans, etc.
An assessment of system state is made against a set of policies to An assessment of system state is made against a set of policies to
evaluate the state of a system using attestations for the system evaluate the state of a system using attestations for the system
requesting data. Attestation is desired to prevent leaking data to requesting data. Attestation is desired to prevent leaking data to
compromised devices. compromised devices.
Attester: An entity desiring to retrieve confidential data Attester: An entity desiring to retrieve confidential data
Relying Party: An entity that holds confidential data for retrieval Relying Party: An entity that holds confidential data for release to
by other entities authorized entities
3.4. Critical Infrastructure Control 2.4. Critical Infrastructure Control
In this use case, potentially dangerous physical equipment (e.g., In this use case, potentially dangerous physical equipment (e.g.,
power grid, traffic control, hazardous chemical processing, etc.) is power grid, traffic control, hazardous chemical processing, etc.) is
connected to a network. The organization managing such connected to a network. The organization managing such
infrastructure needs to ensure that only authorized code and users infrastructure needs to ensure that only authorized code and users
can control such processes, and they are protected from malware or can control such processes, and they are protected from malware or
other adversaries. When a protocol operation can affect some other threats. When a protocol operation can affect some critical
critical system, the device attached to the critical equipment thus system, the device attached to the critical equipment thus wants some
wants some assurance that the requester has not been compromised. As assurance that the requester has not been compromised. As such,
such, remote attestation can be used to only accept commands from remote attestation can be used to only accept commands from
requesters that are within policy. requesters that are within policy.
Attester: A device or application wishing to control physical Attester: A device or application wishing to control physical
equipment equipment
Relying Party: A device or application connected to potentially Relying Party: A device or application connected to potentially
dangerous physical equipment (hazardous chemical processing, dangerous physical equipment (hazardous chemical processing,
traffic control, power grid, etc.) traffic control, power grid, etc.)
3.5. Trusted Execution Environment (TEE) Provisioning 2.5. Trusted Execution Environment (TEE) Provisioning
A "Trusted Application Manager (TAM)" server is responsible for A "Trusted Application Manager (TAM)" server is responsible for
managing the applications running in the TEE of a client device. To managing the applications running in the TEE of a client device. To
do this, the TAM wants to assess the state of a TEE, or of do this, the TAM wants to assess the state of a TEE, or of
applications in the TEE, of a client device. The TEE conducts a applications in the TEE, of a client device. The TEE conducts a
remote attestation procedure with the TAM, which can then decide remote attestation procedure with the TAM, which can then decide
whether the TEE is already in compliance with the TAM's latest whether the TEE is already in compliance with the TAM's latest
policy, or if the TAM needs to uninstall, update, or install approved policy, or if the TAM needs to uninstall, update, or install approved
applications in the TEE to bring it back into compliance with the applications in the TEE to bring it back into compliance with the
TAM's policy. TAM's policy.
Attester: A device with a trusted execution environment capable of Attester: A device with a trusted execution environment capable of
running trusted applications that can be updated running trusted applications that can be updated
Relying Party: A Trusted Application Manager Relying Party: A Trusted Application Manager
3.6. Hardware Watchdog 2.6. Hardware Watchdog
One significant problem is malware that holds a device hostage and There is a class of malware that holds a device hostage and does not
does not allow it to reboot to prevent updates from being applied. allow it to reboot to prevent updates from being applied. This can
This is a significant problem, because it allows a fleet of devices be a significant problem, because it allows a fleet of devices to be
to be held hostage for ransom. held hostage for ransom.
In the case, the Relying Party is the watchdog timer in the TPM/ In the case, the Relying Party is the watchdog timer in the TPM/
secure enclave itself, as described in [TCGarch] section 43.3. The secure enclave itself, as described in [TCGarch] section 43.3. The
Attestation Results are returned to the device, and provided to the Attestation Results are returned to the device, and provided to the
enclave. enclave.
If the watchdog does not receive regular, and fresh, Attestation If the watchdog does not receive regular, and fresh, Attestation
Results as to the systems' health, then it forces a reboot. Results as to the systems' health, then it forces a reboot.
Attester: The device that is desired to keep from being held hostage Attester: The device that should be protected from being held
for a long period of time hostage for a long period of time
Relying Party: A remote server that will securely grant the Attester Relying Party: A remote server that will securely grant the Attester
permission to continue operating (i.e., not reboot) for a period permission to continue operating (i.e., not reboot) for a period
of time of time
3.7. FIDO Biometric Authentication 2.7. FIDO Biometric Authentication
In the Fast IDentity Online (FIDO) protocol [WebAuthN], [CTAP], the In the Fast IDentity Online (FIDO) protocol [WebAuthN], [CTAP], the
device in the user's hand authenticates the human user, whether by device in the user's hand authenticates the human user, whether by
biometrics (such as fingerprints), or by PIN and password. FIDO biometrics (such as fingerprints), or by PIN and password. FIDO
authentication puts a large amount of trust in the device compared to authentication puts a large amount of trust in the device compared to
typical password authentication because it is the device that typical password authentication because it is the device that
verifies the biometric, PIN and password inputs from the user, not verifies the biometric, PIN and password inputs from the user, not
the server. For the Relying Party to know that the authentication is the server. For the Relying Party to know that the authentication is
trustworthy, the Relying Party needs to know that the Authenticator trustworthy, the Relying Party needs to know that the Authenticator
part of the device is trustworthy. The FIDO protocol employs remote part of the device is trustworthy. The FIDO protocol employs remote
skipping to change at page 9, line 10 skipping to change at page 7, line 42
Other biometric authentication protocols such as the Chinese IFAA Other biometric authentication protocols such as the Chinese IFAA
standard and WeChat Pay as well as Google Pay make use of attestation standard and WeChat Pay as well as Google Pay make use of attestation
in one form or another. in one form or another.
Attester: Every FIDO Authenticator contains an Attester. Attester: Every FIDO Authenticator contains an Attester.
Relying Party: Any web site, mobile application back end or service Relying Party: Any web site, mobile application back end or service
that does biometric authentication. that does biometric authentication.
4. Architectural Overview 3. Architectural Overview
Figure 1 depicts the data that flows between different roles, Figure 1 depicts the data that flows between different roles,
independent of protocol or use case. independent of protocol or use case.
************ ************* ************ ***************** ************ ************* ************ *****************
* Endorser * * Reference * * Verifier * * Relying Party * * Endorser * * Reference * * Verifier * * Relying Party *
************ * Value * * Owner * * Owner * ************ * Value * * Owner * * Owner *
| * Provider * ************ ***************** | * Provider * ************ *****************
| ************* | | | ************* | |
| | | | | | | |
skipping to change at page 10, line 6 skipping to change at page 8, line 44
The Verifier uses the Evidence, and any Endorsements from Endorsers, The Verifier uses the Evidence, and any Endorsements from Endorsers,
by applying an Appraisal Policy for Evidence to assess the by applying an Appraisal Policy for Evidence to assess the
trustworthiness of the Attester, and generates Attestation Results trustworthiness of the Attester, and generates Attestation Results
for use by Relying Parties. The Appraisal Policy for Evidence might for use by Relying Parties. The Appraisal Policy for Evidence might
be obtained from an Endorser along with the Endorsements, and/or be obtained from an Endorser along with the Endorsements, and/or
might be obtained via some other mechanism such as being configured might be obtained via some other mechanism such as being configured
in the Verifier by the Verifier Owner. in the Verifier by the Verifier Owner.
The Relying Party uses Attestation Results by applying its own The Relying Party uses Attestation Results by applying its own
pppraisal policy to make application-specific decisions such as appraisal policy to make application-specific decisions such as
authorization decisions. The Appraisal Policy for Attestation authorization decisions. The Appraisal Policy for Attestation
Results is configured in the Relying Party by the Relying Party Results is configured in the Relying Party by the Relying Party
Owner, and/or is programmed into the Relying Party. Owner, and/or is programmed into the Relying Party.
4.1. Appraisal Policies 3.1. Appraisal Policies
The Verifier, when appraising Evidence, or the Relying Party, when The Verifier, when appraising Evidence, or the Relying Party, when
appraising Attestation Results, checks the values of some claims appraising Attestation Results, checks the values of some claims
against constraints specified in its appraisal policy. Such against constraints specified in its appraisal policy. Such
constraints might involve a comparison for equality against a constraints might involve a comparison for equality against a
Reference Value, or a check for being in a range bounded by Reference Reference Value, or a check for being in a range bounded by Reference
Values, or membership in a set of Reference Values, or a check Values, or membership in a set of Reference Values, or a check
against values in other claims, or any other test. against values in other claims, or any other test.
4.2. Reference Values 3.2. Reference Values
Reference Values used in appraisal might be specified as part of the Reference Values used in appraisal come from a Reference Value
appraisal policy itself, or might be obtained from a separate source, Provider and are then used by the appraisal policy. They might be
such as an Endorsement, and then used by the appraisal policy. conveyed in any number of ways, including: * as part of the appraisal
policy itself, if the Verifier Owner either: acquires Reference
Values from a Reference Value Provider or is itself a Reference Value
Provider; * as part of an Endorsement, if the Endorser either
acquires Reference Values from a Reference Value Provider or is
itself a Reference Value Provider; or * via separate communication.
The actual data format and semantics of any Reference Values are The actual data format and semantics of any Reference Values are
specific to claims and implementations. This architecture document specific to claims and implementations. This architecture document
does not define any general purpose format for them or general means does not define any general purpose format for them or general means
for comparison. for comparison.
4.3. Two Types of Environments of an Attester 3.3. Two Types of Environments of an Attester
An Attester consists of at least one Attesting Environment and at An Attester consists of at least one Attesting Environment and at
least one Target Environment. In some implementations, the Attesting least one Target Environment. In some implementations, the Attesting
and Target Environments might be combined. Other implementations and Target Environments might be combined. Other implementations
might have multiple Attesting and Target Environments, such as in the might have multiple Attesting and Target Environments, such as in the
examples described in more detail in Section 4.4 and Section 4.5. examples described in more detail in Section 3.4 and Section 3.5.
Other examples may exist, and the examples discussed could even be Other examples may exist, and the examples discussed could even be
combined into even more complex implementations. combined into even more complex implementations.
Claims are collected from Target Environments, as shown in Figure 2. Claims are collected from Target Environments, as shown in Figure 2.
That is, Attesting Environments collect the values and the That is, Attesting Environments collect the values and the
information to be represented in Claims, by reading system registers information to be represented in Claims, by reading system registers
and variables, calling into subsystems, taking measurements on code and variables, calling into subsystems, taking measurements on code
or memory and so on of the Target Environment. Attesting or memory and so on of the Target Environment. Attesting
Environments then format the claims appropriately, and typically use Environments then format the claims appropriately, and typically use
key material and cryptographic functions, such as signing or cipher key material and cryptographic functions, such as signing or cipher
skipping to change at page 11, line 39 skipping to change at page 10, line 38
| .-------------. | | .-------------. |
| | Attesting | | | | Attesting | |
| | Environment | | | | Environment | |
| | | | | | | |
| '-------------' | | '-------------' |
| Attester | | Attester |
'------------------------------------' '------------------------------------'
Figure 2: Two Types of Environments Figure 2: Two Types of Environments
4.4. Layered Attestation Environments 3.4. Layered Attestation Environments
By definition, the Attester role creates Evidence. An Attester may By definition, the Attester role creates Evidence. An Attester may
consist of one or more nested or staged environments, adding consist of one or more nested or staged environments, adding
complexity to the architectural structure. The unifying component is complexity to the architectural structure. The unifying component is
the root of trust and the nested, staged, or chained attestation the root of trust and the nested, staged, or chained attestation
Evidence produced. The nested or chained structure includes Claims, Evidence produced. The nested or chained structure includes Claims,
collected by the Attester to aid in the assurance or believability of collected by the Attester to aid in the assurance or believability of
the attestation Evidence. the attestation Evidence.
Figure 3 depicts an example of a device that includes (A) a BIOS Figure 3 depicts an example of a device that includes (A) a BIOS
skipping to change at page 13, line 29 skipping to change at page 12, line 29
Environment. This would result in a third set of Claims in the Environment. This would result in a third set of Claims in the
Evidence pertaining to that application. Evidence pertaining to that application.
The essence of this example is a cascade of staged environments. The essence of this example is a cascade of staged environments.
Each environment has the responsibility of measuring the next Each environment has the responsibility of measuring the next
environment before the next environment is started. In general, the environment before the next environment is started. In general, the
number of layers may vary by device or implementation, and an number of layers may vary by device or implementation, and an
Attesting Environment might even have multiple Target Environments Attesting Environment might even have multiple Target Environments
that it measures, rather than only one as shown in Figure 3. that it measures, rather than only one as shown in Figure 3.
4.5. Composite Device 3.5. Composite Device
A Composite Device is an entity composed of multiple sub-entities A Composite Device is an entity composed of multiple sub-entities
such that its trustworthiness has to be determined by the appraisal such that its trustworthiness has to be determined by the appraisal
of all these sub-entities. of all these sub-entities.
Each sub-entity has at least one Attesting Environment collecting the Each sub-entity has at least one Attesting Environment collecting the
claims from at least one Target Environment, then this sub-entity claims from at least one Target Environment, then this sub-entity
generates Evidence about its trustworthiness. Therefore each sub- generates Evidence about its trustworthiness. Therefore each sub-
entity can be called an Attester. Among all the Attesters, there may entity can be called an Attester. Among all the Attesters, there may
be only some which have the ability to communicate with the Verifier be only some which have the ability to communicate with the Verifier
skipping to change at page 16, line 5 skipping to change at page 15, line 5
this inside Verifier uses Endorsements and appraisal policies this inside Verifier uses Endorsements and appraisal policies
(obtained the same way as any other Verifier) in the verification (obtained the same way as any other Verifier) in the verification
process to generate Attestation Results. The inside Verifier then process to generate Attestation Results. The inside Verifier then
conveys the Attestation Results of other Attesters, whether in the conveys the Attestation Results of other Attesters, whether in the
same conveyance protocol as the Evidence or not, to the outside same conveyance protocol as the Evidence or not, to the outside
Verifier. Verifier.
In this situation, the trust model described in Section 7 is also In this situation, the trust model described in Section 7 is also
suitable for this inside Verifier. suitable for this inside Verifier.
4. Terminology
This document uses the following terms.
4.1. Roles
Attester: A role performed by an entity (typically a device) whose
Evidence must be appraised in order to infer the extent to which
the Attester is considered trustworthy, such as when deciding
whether it is 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, for purposes of
reliably applying application specific actions. Compare /relying
party/ in [RFC4949]. Consumes: Attestation Results.
Verifier: A role performed by an entity that appraises the validity
of Evidence about an Attester and produces Attestation Results to
be used by a Relying Party. Consumes: Evidence, Reference Values,
Endorsements, Appraisal Policy for Evidence; Produces: Attestation
Results.
Relying Party Owner: An entity (typically an administrator), that is
authorized to configure Appraisal Policy for Attestation Results
in a Relying Party. Produces: Appraisal Policy for Attestation
Results.
Verifier Owner: An entity (typically an administrator), that is
authorized to configure Appraisal Policy for Evidence in a
Verifier. Produces: Appraisal Policy for Evidence.
Endorser: An entity (typically a manufacturer) whose Endorsements
help Verifiers appraise the authenticity of Evidence. Produces:
Endorsements.
Reference Value Provider: An entity (typically a manufacturer) whose
Reference Values help Verifiers appraise Evidence to determine if
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.
Compare /claim/ in [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 Used 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. Used 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. Used By: Relying Party;
Produced By: Verifier.
Appraisal Policy for Evidence: A set of rules that informs how a
Verifier evaluates the validity of information about an Attester.
Compare /security policy/ in [RFC4949]. Used 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/ in
[RFC4949]. Used 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 referred to in other documents as
known-good values, golden measurements, or nominal values,
although those terms typically assume comparison for equality,
whereas here Reference Values might be more general and be used in
any sort of comparison. Used By: Verifier; Produced By: Reference
Value Provider.
5. Topological Models 5. Topological Models
Figure 1 shows a basic model for communication between an Attester, a Figure 1 shows a basic model for communication between an Attester, a
Verifier, and a Relying Party. The Attester conveys its Evidence to Verifier, and a Relying Party. The Attester conveys its Evidence to
the Verifier for appraisal, and the Relying Party gets the the Verifier for appraisal, and the Relying Party gets the
Attestation Result from the Verifier. There are multiple other Attestation Result from the Verifier. There are multiple other
possible models. This section includes some reference models. This possible models. This section includes some reference models. This
is not intended to be a restrictive list, and other variations may is not intended to be a restrictive list, and other variations may
exist. exist.
skipping to change at page 16, line 33 skipping to change at page 17, line 23
airport immigration desk. The passport is considered sufficient airport immigration desk. The passport is considered sufficient
because it vouches for the citizenship and identity claims, and it is because it vouches for the citizenship and identity claims, and it is
issued by a trusted authority. Thus, in this immigration desk issued by a trusted authority. Thus, in this immigration desk
analogy, the passport issuing agency is a Verifier, the passport is analogy, the passport issuing agency is a Verifier, the passport is
an Attestation Result, and the immigration desk is a Relying Party. an Attestation Result, and the immigration desk is a Relying Party.
In this model, an Attester conveys Evidence to a Verifier, which In this model, an Attester conveys Evidence to a Verifier, which
compares the Evidence against its appraisal policy. The Verifier compares the Evidence against its appraisal policy. The Verifier
then gives back an Attestation Result. If the Attestation Result was then gives back an Attestation Result. If the Attestation Result was
a successful one, the Attester can then present the Attestation a successful one, the Attester can then present the Attestation
Result to a Relying Party, which then compares the Attestation Result Result (and possibly additional Claims) to a Relying Party, which
against its own appraisal policy. then compares this information against its own appraisal policy.
There are three ways in which the process may fail. First, the There are three ways in which the process may fail. First, the
Verifier may refuse to issue the Attestation Result due to some error Verifier may refuse to issue the Attestation Result due to some error
in processing, or some missing input to the Verifier. The second way in processing, or some missing input to the Verifier. The second way
in which the process may fail is when the Attestation Result is in which the process may fail is when the Attestation Result is
examined by the Relying Party, and based upon the appraisal policy, examined by the Relying Party, and based upon the appraisal policy,
the result does not pass the policy. The third way is when the the result does not pass the policy. The third way is when the
Verifier is unreachable. Verifier is unreachable.
Since the resource access protocol between the Attester and Relying Since the resource access protocol between the Attester and Relying
skipping to change at page 17, line 32 skipping to change at page 18, line 32
5.2. Background-Check Model 5.2. Background-Check Model
The background-check model is so named because of the resemblance of The background-check model is so named because of the resemblance of
how employers and volunteer organizations perform background checks. how employers and volunteer organizations perform background checks.
When a prospective employee provides claims about education or When a prospective employee provides claims about education or
previous experience, the employer will contact the respective previous experience, the employer will contact the respective
institutions or former employers to validate the claim. Volunteer institutions or former employers to validate the claim. Volunteer
organizations often perform police background checks on volunteers in organizations often perform police background checks on volunteers in
order to determine the volunteer's trustworthiness. Thus, in this order to determine the volunteer's trustworthiness. Thus, in this
analogy, a prospective volunteer is an Attester, the organization is analogy, a prospective volunteer is an Attester, the organization is
the Relying Party, and a former employer or government agency that the Relying Party, and the organization that issues a report is a
issues a report is a Verifier. Verifier.
In this model, an Attester conveys Evidence to a Relying Party, which In this model, an Attester conveys Evidence to a Relying Party, which
simply passes it on to a Verifier. The Verifier then compares the simply passes it on to a Verifier. The Verifier then compares the
Evidence against its appraisal policy, and returns an Attestation Evidence against its appraisal policy, and returns an Attestation
Result to the Relying Party. The Relying Party then compares the Result to the Relying Party. The Relying Party then compares the
Attestation Result against its own appraisal policy. Attestation Result against its own appraisal policy.
The resource access protocol between the Attester and Relying Party The resource access protocol between the Attester and Relying Party
includes Evidence rather than an Attestation Result, but that includes Evidence rather than an Attestation Result, but that
Evidence is not processed by the Relying Party. Since the Evidence Evidence is not processed by the Relying Party. Since the Evidence
skipping to change at page 24, line 39 skipping to change at page 25, line 39
that it legally owns onto the network. Thus, an Endorsement may be that it legally owns onto the network. Thus, an Endorsement may be
helpful information in authenticating information about a device, but helpful information in authenticating information about a device, but
is not necessarily sufficient to authorize access to resources which is not necessarily sufficient to authorize access to resources which
may need device-specific information such as a public key for the may need device-specific information such as a public key for the
device or component or user on the device. device or component or user on the device.
8.3. Attestation Results 8.3. Attestation Results
Attestation Results are the input used by the Relying Party to decide Attestation Results are the input used by the Relying Party to decide
the extent to which it will trust a particular Attester, and allow it the extent to which it will trust a particular Attester, and allow it
to access some data or perform some operation. Attestation Results to access some data or perform some operation.
may be a Boolean simply indicating compliance or non-compliance with
a Verifier's appraisal policy, or a rich set of Claims about the Attestation Results may be a Boolean simply indicating compliance or
Attester, against which the Relying Party applies its Appraisal non-compliance with a Verifier's appraisal policy, or a rich set of
Policy for Attestation Results. Claims about the Attester, against which the Relying Party applies
its Appraisal Policy for Attestation Results.
The quality of the Attestation Results depend upon the ability of the
Verifier to evaluate the Attester. Different Attesters have a
different _Strength of Function_ [strengthoffunction], which results
in the Attestation Results being qualitatively different in strength.
A result that indicates non-compliance can be used by an Attester (in A result that indicates non-compliance can be used by an Attester (in
the passport model) or a Relying Party (in the background-check the passport model) or a Relying Party (in the background-check
model) to indicate that the Attester should not be treated as model) to indicate that the Attester should not be treated as
authorized and may be in need of remediation. In some cases, it may authorized and may be in need of remediation. In some cases, it may
even indicate that the Evidence itself cannot be authenticated as even indicate that the Evidence itself cannot be authenticated as
being correct. being correct.
An Attestation Result that indicates compliance can be used by a An Attestation Result that indicates compliance can be used by a
Relying Party to make authorization decisions based on the Relying Relying Party to make authorization decisions based on the Relying
skipping to change at page 28, line 13 skipping to change at page 29, line 13
with the Claims in the Evidence or Attestation Result. Timestamps with the Claims in the Evidence or Attestation Result. Timestamps
can be added on a per-Claim basis, to distinguish the time of can be added on a per-Claim basis, to distinguish the time of
creation of Evidence or Attestation Result from the time that a creation of Evidence or Attestation Result from the time that a
specific Claim was generated. The clock's trustworthiness typically specific Claim was generated. The clock's trustworthiness typically
requires additional Claims about the signer's time synchronization requires additional Claims about the signer's time synchronization
mechanism. mechanism.
A second approach places the onus of timekeeping solely on the A second approach places the onus of timekeeping solely on the
Verifier (for Evidence), or the Relying Party (for Attestation Verifier (for Evidence), or the Relying Party (for Attestation
Results), and might be suitable, for example, in case the Attester Results), and might be suitable, for example, in case the Attester
does not have a reliable clock or time synchronisation is otherwise does not have a reliable clock or time synchronization is otherwise
impaired. In this approach, a non-predictable nonce is sent by the impaired. In this approach, a non-predictable nonce is sent by the
appraising entity, and the nonce is then signed and included along appraising entity, and the nonce is then signed and included along
with the Claims in the Evidence or Attestation Result. After with the Claims in the Evidence or Attestation Result. After
checking that the sent and received nonces are the same, the checking that the sent and received nonces are the same, the
appraising entity knows that the Claims were signed after the nonce appraising entity knows that the Claims were signed after the nonce
was generated. This allows associating a "rough" epoch to the was generated. This allows associating a "rough" epoch to the
Evidence or Attestation Result. In this case the epoch is said to be Evidence or Attestation Result. In this case the epoch is said to be
rough because: rough because:
* The epoch applies to the entire claim set instead of a more * The epoch applies to the entire claim set instead of a more
skipping to change at page 29, line 9 skipping to change at page 30, line 9
when they are signed. For example, values generated at boot time when they are signed. For example, values generated at boot time
might have been saved to secure storage until network connectivity is might have been saved to secure storage until network connectivity is
established to the remote Verifier and a nonce is obtained. established to the remote Verifier and a nonce is obtained.
A more detailed discussion with examples appears in Section 16. A more detailed discussion with examples appears in Section 16.
11. Privacy Considerations 11. Privacy Considerations
The conveyance of Evidence and the resulting Attestation Results The conveyance of Evidence and the resulting Attestation Results
reveal a great deal of information about the internal state of a reveal a great deal of information about the internal state of a
device as well as any users the device is associated with. In many device as well as potentially any users of the device. In many
cases, the whole point of the Attestation process is to provide cases, the whole point of the Attestation process is to provide
reliable information about the type of the device and the firmware/ reliable information about the type of the device and the firmware/
software that the device is running. This information might be software that the device is running. This information might be
particularly interesting to many attackers. For example, knowing particularly interesting to many attackers. For example, knowing
that a device is running a weak version of firmware provides a way to that a device is running a weak version of firmware provides a way to
aim attacks better. aim attacks better.
Many claims in Attestation Evidence and Attestation Results are Many claims in Attestation Evidence and Attestation Results are
potentially PII (Personally Identifying Information) depending on the potentially PII (Personally Identifying Information) depending on the
end-to-end use case of the attestation. Attestation that goes up to end-to-end use case of the attestation. Attestation that goes up to
skipping to change at page 30, line 8 skipping to change at page 31, line 8
In such cases, an Attester can first act as a Relying Party and ask In such cases, an Attester can first act as a Relying Party and ask
for the Verifier's own Attestation Result, and appraising it just as for the Verifier's own Attestation Result, and appraising it just as
a Relying Party would appraise an Attestation Result for any other a Relying Party would appraise an Attestation Result for any other
purpose. purpose.
12. Security Considerations 12. Security Considerations
12.1. Attester and Attestation Key Protection 12.1. Attester and Attestation Key Protection
Implementers need to pay close attention to the isolation and Implementers need to pay close attention to the isolation and
protection of the Attester and the factory processes for provisioning protection of the Attester and the factory processes for provisioning
the Attestation Key Material. When either of these are compromised, the Attestation key material. When either of these are compromised,
the remote attestation becomes worthless because the attacker can the remote attestation becomes worthless because the attacker can
forge Evidence. forge Evidence.
Remote attestation applies to use cases with a range of security Remote attestation applies to use cases with a range of security
requirements, so the protections discussed here range from low to requirements, so the protections discussed here range from low to
high security where low security may be only application or process high security where low security may be only application or process
isolation by the device's operating system and high security involves isolation by the device's operating system and high security involves
specialized hardware to defend against physical attacks on a chip. specialized hardware to defend against physical attacks on a chip.
12.1.1. On-Device Attester and Key Protection 12.1.1. On-Device Attester and Key Protection
skipping to change at page 34, line 36 skipping to change at page 35, line 36
Table 1 Table 1
Using the table above, a number of hypothetical examples of how a Using the table above, a number of hypothetical examples of how a
solution might be built are illustrated below. a solution might be solution might be built are illustrated below. a solution might be
built. This list is not intended to be complete, but is just built. This list is not intended to be complete, but is just
representative enough to highlight various timing considerations. representative enough to highlight various timing considerations.
All times are relative to the local clocks, indicated by an "a" All times are relative to the local clocks, indicated by an "a"
(Attester), "v" (Verifier), or "r" (Relying Party) suffix. (Attester), "v" (Verifier), or "r" (Relying Party) suffix.
Times with an appended Prime (') indicate a second instance of the
same event.
How and if clocks are synchronized depends upon the model. How and if clocks are synchronized depends upon the model.
16.1. Example 1: Timestamp-based Passport Model Example 16.1. Example 1: Timestamp-based Passport Model Example
The following example illustrates a hypothetical Passport Model The following example illustrates a hypothetical Passport Model
solution that uses timestamps and requires roughly synchronized solution that uses timestamps and requires roughly synchronized
clocks between the Attester, Verifier, and Relying Party, which clocks between the Attester, Verifier, and Relying Party, which
depends on using a secure clock synchronization mechanism. As a depends on using a secure clock synchronization mechanism. As a
result, the receiver of a conceptual message containing a timestamp result, the receiver of a conceptual message containing a timestamp
can directly compare it to its own clock and timestamps. can directly compare it to its own clock and timestamps.
skipping to change at page 35, line 34 skipping to change at page 36, line 34
| | | |
The Verifier can check whether the Evidence is fresh when appraising The Verifier can check whether the Evidence is fresh when appraising
it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold", it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold",
where the Verifier's threshold is large enough to account for the where the Verifier's threshold is large enough to account for the
maximum permitted clock skew between the Verifier and the Attester. maximum permitted clock skew between the Verifier and the Attester.
If time(VG_a) is also included in the Evidence along with the claim If time(VG_a) is also included in the Evidence along with the claim
value generated at that time, and the Verifier decides that it can value generated at that time, and the Verifier decides that it can
trust the time(VG_a) value, the Verifier can also determine whether trust the time(VG_a) value, the Verifier can also determine whether
the claim value is recent by checking "time(RG_v) - time(VG_a) < the claim value is recent by checking The threshold is decided by the
Threshold", again where the threshold is large enough to account for Appraisal Policy for Evidence, and again needs to take into account
the maximum permitted clock skew between the Verifier and the the maximum permitted clock skew between the Verifier and the
Attester. Attester."time(RG_v) - time(VG_a) < Threshold".
The Relying Party can check whether the Attestation Result is fresh The Relying Party can check whether the Attestation Result is fresh
when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v) when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v)
< Threshold", where the Relying Party's threshold is large enough to < Threshold", where the Relying Party's threshold is large enough to
account for the maximum permitted clock skew between the Relying account for the maximum permitted clock skew between the Relying
Party and the Verifier. The result might then be used for some time Party and the Verifier. The result might then be used for some time
(e.g., throughout the lifetime of a connection established at (e.g., throughout the lifetime of a connection established at
time(RA_r)). The Relying Party must be careful, however, to not time(RA_r)). The Relying Party must be careful, however, to not
allow continued use beyond the period for which it deems the allow continued use beyond the period for which it deems the
Attestation Result to remain fresh enough. Thus, it might allow use Attestation Result to remain fresh enough. Thus, it might allow use
(at time(OP_r)) as long as "time(OP_r) - time(RG_v) < Threshold". (at time(OP_r)) as long as "time(OP_r) - time(RG_v) < Threshold".
However, if the Attestation Result contains an expiry time time(RX_v) However, if the Attestation Result contains an expiry time time(RX_v)
then it could explicitly check "time(OP_r) < time(RX_v)". then it could explicitly check "time(OP_r) < time(RX_v)".
16.2. Example 2: Nonce-based Passport Model Example 16.2. Example 2: Nonce-based Passport Model Example
The following example illustrates a hypothetical Passport Model The following example illustrates a hypothetical Passport Model
solution that uses nonces and thus does not require that any clocks solution that uses nonces instead of timestamps. Compared to the
are synchronized. timestamp-based example, it requires an extra round trip to retrieve
a nonce, and requires that the Verifier and Relying Party track state
to remember the nonce for some period of time.
As a result, the receiver of a conceptual message containing a The advantage is that it does not require that any clocks are
timestamp cannot directly compare it to its own clock or timestamps. synchronized. As a result, the receiver of a conceptual message
Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for containing a timestamp cannot directly compare it to its own clock or
Relying Party) on the IDs below indicating which clock generated timestamps. Thus we use a suffix ("a" for Attester, "v" for
them, since times from different clocks cannot be compared. Only the Verifier, and "r" for Relying Party) on the IDs below indicating
delta between two events from the sender can be used by the receiver. which clock generated them, since times from different clocks cannot
be compared. Only the delta between two events from the sender can
be used by the receiver.
.----------. .----------. .---------------. .----------. .----------. .---------------.
| Attester | | Verifier | | Relying Party | | Attester | | Verifier | | Relying Party |
'----------' '----------' '---------------' '----------' '----------' '---------------'
time(VG_a) | | time(VG_a) | |
| | | | | |
~ ~ ~ ~ ~ ~
| | | | | |
|<--Nonce1---------------------time(NS_v) | |<--Nonce1---------------------time(NS_v) |
time(EG_a) | | time(EG_a) | |
|---Evidence--------------------->| | |---Evidence--------------------->| |
| {Nonce1, time(EG_a)-time(VG_a)} | | | {Nonce1, time(EG_a)-time(VG_a)} | |
| time(RG_v) | | time(RG_v) |
|<--Attestation Result------------| | |<--Attestation Result------------| |
| {time(RX_v)-time(RG_v)} | | | {time(RX_v)-time(RG_v)} | |
~ ~ ~ ~
| | | |
|<--Nonce2-------------------------------------time(NS_r) |<--Nonce2-------------------------------------time(NS_r)
time(RRa) time(RR_a) |
|---Attestation Result{time(RX_v)-time(RG_v)}->time(RA_r) |--[Attestation Result{time(RX_v)-time(RG_v)}, -->|time(RA_r)
| Nonce2, time(RR_a)-time(EG_a) | | Nonce2, time(RR_a)-time(EG_a)] |
~ ~ ~ ~
| | | |
| time(OP_r) | time(OP_r)
In this example solution, the Verifier can check whether the Evidence In this example solution, the Verifier can check whether the Evidence
is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) < is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) <
Threshold". Threshold".
The Verifier cannot, however, simply rely on a Nonce to determine The Verifier cannot, however, simply rely on a Nonce to determine
whether the value of a claim is recent, since the claim value might whether the value of a claim is recent, since the claim value might
skipping to change at page 41, line 21 skipping to change at page 42, line 49
Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
"Time-Based Uni-Directional Attestation", Work in "Time-Based Uni-Directional Attestation", Work in
Progress, Internet-Draft, draft-birkholz-rats-tuda-03, 13 Progress, Internet-Draft, draft-birkholz-rats-tuda-03, 13
July 2020, <http://www.ietf.org/internet-drafts/draft- July 2020, <http://www.ietf.org/internet-drafts/draft-
birkholz-rats-tuda-03.txt>. birkholz-rats-tuda-03.txt>.
[I-D.ietf-teep-architecture] [I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP) "Trusted Execution Environment Provisioning (TEEP)
Architecture", Work in Progress, Internet-Draft, draft- Architecture", Work in Progress, Internet-Draft, draft-
ietf-teep-architecture-12, 13 July 2020, ietf-teep-architecture-13, 2 November 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-teep- <http://www.ietf.org/internet-drafts/draft-ietf-teep-
architecture-12.txt>. architecture-13.txt>.
[OPCUA] OPC Foundation, "OPC Unified Architecture Specification, [OPCUA] OPC Foundation, "OPC Unified Architecture Specification,
Part 2: Security Model, Release 1.03", OPC 10000-2 , 25 Part 2: Security Model, Release 1.03", OPC 10000-2 , 25
November 2015, <https://opcfoundation.org/developer-tools/ November 2015, <https://opcfoundation.org/developer-tools/
specifications-unified-architecture/part-2-security- specifications-unified-architecture/part-2-security-
model/>. model/>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource- [RFC8322] Field, J., Banghart, S., and D. Waltermire, "Resource-
Oriented Lightweight Information Exchange (ROLIE)", Oriented Lightweight Information Exchange (ROLIE)",
RFC 8322, DOI 10.17487/RFC8322, February 2018, RFC 8322, DOI 10.17487/RFC8322, February 2018,
<https://www.rfc-editor.org/info/rfc8322>. <https://www.rfc-editor.org/info/rfc8322>.
[strengthoffunction]
NISC, "Strength of Function", n.d.,
<https://csrc.nist.gov/glossary/term/
strength_of_function>.
[TCGarch] Trusted Computing Group, "Trusted Platform Module Library [TCGarch] Trusted Computing Group, "Trusted Platform Module Library
- Part 1: Architecture", n.d., - Part 1: Architecture", n.d.,
<https://trustedcomputinggroup.org/wp-content/uploads/ <https://trustedcomputinggroup.org/wp-content/uploads/
TCG_TPM2_r1p62_Part1_Architecture_7july2020.pdf>. TCG_TPM2_r1p62_Part1_Architecture_7july2020.pdf>.
[WebAuthN] W3C, "Web Authentication: An API for accessing Public Key [WebAuthN] W3C, "Web Authentication: An API for accessing Public Key
Credentials", n.d., <https://www.w3.org/TR/webauthn-1/>. Credentials", n.d., <https://www.w3.org/TR/webauthn-1/>.
Contributors Contributors
 End of changes. 49 change blocks. 
192 lines changed or deleted 237 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/