wdiff draft-birkholz-rats-architecture-01.txt draft-birkholz-rats-architecture-02.txt

Network Working Group H. Birkholz
Internet-Draft Fraunhofer SIT
Intended status: Standards Track M. Wiseman
Expires: September 13, 2019 March 15, 2020 GE Global Research
H. Tschofenig
ARM Ltd.
N. Smith
Intel
March
September 12, 2019

Architecture and Reference Terminology for

Remote Attestation Procedures
draft-birkholz-rats-architecture-01 Architecture
draft-birkholz-rats-architecture-02

Abstract

The Remote ATtestation ProcedureS procedureS (RATS) architecture facilitates the
attestation
interoperability of device characteristics that, in general, are based on
specific trustworthiness qualities intrinsic to a device or service.
It includes trusted computing functionality provided attestation mechanisms by device
hardware defining a set of
participant roles and software interactions that allows reveal information about the
trustworthiness qualities to attributes of an attester's computing environment.
By making trustworthiness attributes explicit, they can be
asserted evaluated
dynamically and verified as part of, or pre-requisite to, the device's
normal operation. The RATS architecture maps corresponding
attestation functions and capabilities to specific RATS Roles. The
goal is to enable within an appropriate conveyance of evidence about device
trustworthiness via network protocols. RATS Roles provide the
endpoint operational context for where risk mitigation
depends on having a more complete understanding the various interaction semantics of the attestation lifecycle. The RATS architecture provides the
building block concepts, semantics, syntax and framework for
interoperable attestation while remaining hardware-agnostic. This
flexibility is intended possible
vulnerabilities germane to address a significant variety of use-cases
and scenarios involving interoperable attestation. Example usages
include, but are not limited to: financial transactions, voting
machines, critical safety systems, network equipment health, or
trustworthy end-user device management. Existing industry
attestation efforts may be helpful toward informing RATS
architecture. Such as: Remote Integrity VERification (RIVER), the
creation of Entity Attestation Tokens (EAT), software integrity
Measurement And ATtestation (MAAT) attester's environment.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 13, 2019. March 15, 2020.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2
1.1. What is Remote Attestation . . . . . . . . . . . . . . . 4
1.2. The purpose of RATS Architecture and Terminology . . . in a Nutshell . 4
1.3. Requirements notation . . . . . . . . . . . . . . . . . . 4 3
2. RATS Architecture . . . . . . . . . . . . . . . . . . . . . . 4
3. Architectural Components . . . . . . . . . . . . . . . . . . 5
3.1. RATS Roles . . . . . . . . . . . . . . . . . . . . . . . 5
4. RATS Actors . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. RATS Duties . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Attester Duties . . . . . . . . . . . . . . . . . . . 8
4.1.2. Verifier Duties . . . . . . . . . Terminology . . . . . . . . . . 8
4.1.3. Claimant Duties . . . . . . . . . . . . . . . . 3
2.1. Requirements Notation . . . 8
4.1.4. Relying Party Duties . . . . . . . . . . . . . . . . 8
4.1.5. RATS Interactions . 4
3. Conceptual Overview . . . . . . . . . . . . . . . . . 9
5. Application of RATS . . . . 4
3.1. Computing Environments . . . . . . . . . . . . . . . . . 10
5.1. Trust and 5
3.2. Trustworthiness . . . . . . . . . . . . . . . . 11
5.2. Claims and Evidence . . . . . . . . . . . . . . . . . . . 12
5.3. 6
3.3. RATS Information Flows . . . . . Workflow . . . . . . . . . . . . 12
6. Exemplary Composition of Roles . . . . . . . . . . . . . . . 13
6.1. Conveyance of Trusted Claim Sets Validated by Signature . 13
6.2. Conveyance of Attestation Evidence Appraised by a
Verifier . . . . . . . . . . . . . . . . . . . . . . . . 14
7. The Scope of 6
3.4. Interoperability between RATS . . . . . . . . . . . . . . . . . . . . . . 14
7.1. The Lying Endpoint Problem . . . . . . . . . . . . . . . 15
7.1.1. How the 7
4. RATS Architecture Addresses the Lying
Endpoint Problem . . . . . . . . . . . . . . . . . . 16
8. RATS Terminology . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Computing Context . . . . . . . . . . . . . 7
4.1. Goals . . . . . . . 18
8.1.1. Characteristics of a Computing Context . . . . . . . 19
8.1.2. Computing Context Semantic Relationships . . . . . . 19
8.1.3. Computing Context Identity . . . . . . . . . . . . . 21
8.2. Remote 7
4.2. Attestation Concepts . . . . . . Principles . . . . . . . . . 21
8.3. Core RATS Terminology . . . . . . . . . . . . . . . . . . 22
8.4. RATS Information Model Terminology . . . . . . . . . . . 22
8.5. 8
4.3. RATS Work-Flow Terminology . . . . . . . . . . . . Roles and Messages . . . 23
8.6. RATS Reference Use Cases . . . . . . . . . . . . . . 8
4.3.1. Roles . . 24
8.6.1. Use Case A . . . . . . . . . . . . . . . . . . . . . 24
8.6.2. Use Case B . 9
4.3.2. Role Messages . . . . . . . . . . . . . . . . . . . . 24
8.7. 10
4.4. RATS Reference Terminology . . . . . . . . . . . . . . . 24
8.8. Interpretations of RFC4949 Terminology for Attestation . 26
8.9. Building Block Vocabulary (Not in RFC4949) . . . . Principals . . . 28
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28
10. 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 29
13. 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 29
13.2. 12
6.2. Informative References . . . . . . . . . . . . . . . . . 29
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 13

1. Introduction

The long-standing Internet Threat Model [RFC3552] focuses on threats
to the communication channel, as pioneered by Dolev and Yao
[DOLEV-YAO] in 1983. However, threats to the endpoint [RFC5209] and
system components [RFC4949] of transited communication gear (i.e.
hosts) are increasingly relevant for assessing the trustworthiness
properties of a communication channel. Beyond the collection and
conveyance of security posture [RFC5209] about an endpoint (host),
remote attestation provides believable trustworthiness claims
("Evidence") about an endpoint (host). In general, this document
provides normative guidance how to use, create or adopt network
protocols that facilitate remote attestation
procedures. The RATS.

1.1. RATS Architecture anticipates broad deployment
contexts that range from IoT to Cloud and Edge ecosystems. in a Nutshell

The
foundation of the RATS architecture is provides a basis to assess the specification trustworthiness
of RATS
Roles that can be chained via RATS Interactions and - as a result -
may be composed into use-case specific Remote Attestation Procedures.
RATS Actors establish an ecosystem neutral context where RATS Roles endpoints by other parties:

o In remote attestation workflows, trustworthiness Claims are hosted and where
accompanied by a variety of Remote Attestation Procedure
interactions are defined independent proof of specific conveyance protocols veracity. Typically, this proof is a
cryptographic expression such as a digital signature or message formats.
digest. Trustworthiness Claims with proof is what makes
attestation Evidence believable.

o A corresponding attestation provisioning workflow uses
trustworthiness Claims to convey believable Endorsements and
Known-Good-Values used by a Verifier to appraise Evidence.

In summary, the goal of the RATS Architecture architecture, specific content items are identified (and
described in more detail below):

o Evidence is provable Claims about a specific Computing Environment
made by an Attester.

o Known-Good-Values are reference Claims used to enable interoperable interaction between appraise Evidence.

o Endorsements are reference Claims about the RATS Roles. Hence, environment protecting
the RATS Architecture is designed Attesters capabilities to enable interoperability via
well-defined semantics of create believable Evidence (e.g. the information model (attestation
assertions/claims), associated with RATS Roles following a conveyance
model (RATS Interactions) that may be used to compose domain-specific
remote
type of protection for an attestation solutions.

1.1. What is Remote Attestation

Unfortunately, key). It answers the term Attestation itself
question "why Evidence is an overloaded term. In
consequence, the term Remote believable".

o Attestation covers a spectrum of
meanings. The common denominator encompasses Results are the output from the creation,
conveyance, and appraisal of evidence pertaining to Evidence,
Known-Good-Values and Endorsements.

Attestation Results are the
trustworthiness characteristics output of the creator RATS. Assessment of
Attestation Results can be multi-faceted, but is out-of-scope for the evidence. In
essence,
RATS architecture. If appropriate Endorsements about the Attester
are used available, Known-Good-Values about the Attester are available,
and if the Attester is capable of creating believable Evidence - then
the Verifier is able to create Attestation Results that enable the assessment
Relying Parties to establish a level of confidence in the
trustworthiness of the Attester.

2. Terminology

Conveyance: a communication partner.

1.2. The purpose of mechanism for transferring RATS Architecture Evidence,
Endorsements, Known-Good-Values or Attestation Results.

Entity: a user, organization, device or computing environment.

Principal: an Entity that implements RATS Roles and Terminology

To consolidate the utilization of existing creates provable
Claims or Attestation Results (see [ABLP] and emerging network
protocols [Lampson2007]).

Trustworthiness: an expectation about a computing environment that
it will behave in the a way that is intended and nothing more.

Computing Environment: a computing context consisting of RATS, this document provides system
components.

Attesting Computing Environment: a detailed
definition Computing Environment capabile of Attestation Terminology that enables interoperability
between different types pf RATS. Specifically, this document
illustrates
monitoring and remediates the impedance mismatch of terms related to
Remote Attestation Procedures used in different domains today. As an
additional contribution, new terms defined by this document provide attesting a
common basis target Computing Environment.

Attested Computing Environment: a target Computing Environment that simplifies future work on RATS in the IETF
is monitored and
beyond.

1.3. attested by an Attesting Computing Environment.

2.1. Requirements notation Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

2. RATS Architecture

One of the goals of the RATS Architecture

3. Conceptual Overview

In network protocol exchanges, it is to provide the building
blocks - the roles defined by the RATS Architecture - to enable often the
composition of service-chains/hierarchies and work-flows case that can
create and appraise evidence about one entity
(a Relying Party) requires an assessment of the trustworthiness of devices and
services.

The RATS Architecture is based on the use-cases defined in
[I-D.richardson-rats-usecases].

The RATS architecture specifies:

o The building blocks to create remote attestation procedures
applicable Actors, Roles, Duties, and Interactions,

o Mandatory and optional trust relationships between its Roles, that
may assume a Root-of-Trust context,

o The interaction between Roles that reside on separate Actors and
interact via network protocols,

o Protocol/message framing that allows for well-defined and opaque
payloads,

o The means to prove, preserve and convey trust properties, such as
identity, varacity, freshness,
remote entity (an Attester or provenance, and

o Primitives necessary for the construction of interoperable
attestation payloads.

3. Architectural Components

The basic architectural specifc system components defined in this document are:

o RATS Roles

o RATS Actors

o RATS Duties

o RATS Interactions

The following sub-section define and elaborate on these terms:

3.1. RATS Roles

A Role [RFC4949]
thereof). Remote ATtestation procedureS (RATS) enable Relying
Parties to establish a level of confidence in the context trustworthiness of usage scenarios for
remote attestation
procedures is providing a service to other Roles. Roles are building
blocks that can be providers and consumers of information. In system components through the
RATS architecture, devices or services can take on RATS roles. They
are composites creation of internal functions (RATS Duties) attestation evidence
by remote system components and external
functions (RATS Interactions) that facilitate a required (sometimes
optional) task in a remote attestation procedure.

The base set processing chain of RATS roles is:

Claimant: architectural
constituents towards the relying party.

The producer of corresponding trustworthiness assertions pertaining to
an Attester; that attributes processed may or not have a root-of-trust for measurement.

It is not guaranteed that be
just a Verifier Role can appraise the output finite set of a Claimant via reference values (in contrast to values. Additionally, the output system
characteristics of remote components themselves have an Attester).

Examples impact on the
veracity of Claimant assertions include: * The trustworthiness attributes included in Evidence.
Attester environments can vary widely ranging from those highly
resistant to attacks to those having little or no resistance to
attacks. Configuration options, if set poorly, can result in a
highly resistant environment being operationally less resistant.
Computing Environments are often malleable being constructed from re-
programmable hardware, firmware
and firmware, software components of and updatable memory. When
a trustworthy environment changes, the Attester. * The manufactuer of
Attester components. * The Attester's current configuration. *
The Attester's current location - e.g. GPS coordinates. * The
method by which binding of an attester question has to be asked
whether the change transitioned the environment from a trustworthy
state to an RTR. * untrustworthy state. The
identifier(s) available for identifying and authenticating the
Attester - e.g. Universal Entity ID (UEID).

Typically, claimant role are taken on by RATS Actors that supply
chain entities (SCE). Various assertions (often represented as
Claims or Trusted Claims Sets, e.g. [I-D.mandyam-eat] or
[I-D.tschofenig-rats-psa-token]).

Attester: The producer of attestation evidence that has architecture provides a root of
trust
framework for reporting (RTR) and implements anticipating when a conveyance protocol,
authenticates using an attestation credential, consumes assertions
about itself and presents it relevant change with respect to a consumer of evidence (e.g. a
relying party or
trustworthiness attribute occurs, what changed and how relevant it
is. A remote attestation framework also creates a verifier). Every output of context for
enabling an attester can be
appraised via reference values.

Authentication Checker: The consumer of signed assertions such as
trusted claim sets or attestation evidence that assesses the appropriate response by applications, system software and
protocol endpoints when changes to trustworthiness or other trust relationships of attributes do
occur.

3.1. Computing Environments

In the information
consumed via trusted third parties or external trust authorities,
such as RATS context, a privacy certificate authority. In certain environments,
an Authentication Checker can assess Claim is a system's specific trustworthiness
via external trust anchors, implicitly.

Verifier: The consumer of attestation evidence attribute
that has pertains to a root particular Computing Environment of
trust for verification (RTV), implements conveyance protocols,
appraises attestation evidence against reference values or
policies, and makes verification results available to relying
parties.

Relying Party: an Attester.
The consumer and assessor set of verifier or
Authentication Checker results for possible Claims is expected to follow the purpose of improved risk
management, operational efficiency, security, privacy (natural or
legal person) or safety. The verifier and/or authentication
checker roles possible
computing environments that support attestation. In other words,
identical (i.e. same type, model, versions, components and the relying party role may be tightly
integrated.

4. RATS Actors

RATS Actors may be any entity, such as an user, organization,
execution environment, device or service provider,
composition) Attesting Computing Environments can create different
Claim values that takes on
(implements) one still compose valid Evidence due to different
computing contexts. Exemplary Claims include flight vectors or more RATS Roles and performs RATS Duties and/or
RATS Interactions. RATS Interactions occur between RATS Actors. The
methods whereby RATS Actors are identified, discovered, and
connectivity established
learned configuration.

Likely, there are out-of-scope for this architecture. In
contrast, if multiple RATS Roles reside on a single RATS Actor, the
definition set of RATS Interactions Claims that is out-of-scope of the RATS
architecture, widely applicable across
most, if no network protocols not all environments. Conversely, there are required.

+------------------+ +------------------+
| Actor 1 | | Actor 2 |
| +------------+ | | +------------+ |
| | | | | | | |
| | Role 1 |<-|---|->| Role 2 | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| +-----+------+ | | +-----+------+ |
| | | | | | | |
| | Role 2 |<-|---|->| Role 3 | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
+------------------+ +------------------+

Figure 1: RATS Actor-Role Interactions

RATS Actors have the following properties: * Multiplicity - Multiple
instances of RATS Actors Claims that possess are
unique to specific environments. Consequently, the same RATS Roles can exist.
* Decomposability - A singleton RATS Actor possessing multiple RATS
Roles architecture
incorporates extensible mechanisms for representing Claims.

Computing Environments can be separated into complex structurally. In general,
every Attester consists of multiple RATS Actors. RATS Interactions
may occur between them. * Composablility - RATS Actors possessing
different RATS Roles components (e.g. memory, CPU,
storage, networking, firmware, software). Components are
computational elements that can be combined into linked and composed to form
computational pipelines, arrays and networks (e.g. a singleton RATS Actor
possessing the union of RATS Roles. RATS Interactions between
combined RATS Actors ceases.

Interactions between RATS Roles belonging BIOS, a
bootloader, or a trusted execution environment).

An Attester includes at least one Computing Environment that is able
to the same RATS Actor are
generally believed create attestation Evidence (the Attesting Computing Environment)
about other Computing Environments (the Attested Computing
Environments). Not every computational element of an Attester is
expected to be uninteresting. Actor operations that apply
resiliency, scaling, load balancing or replication are generally
believed to a Computing Environment capable of remote attestation.
Analogously, remote attestation capable Computing Environments may
not be uninteresting.

4.1. RATS Duties

A RATS Role can take on one ore more duties. RATS Duties are role-
internal functions capable of attesting to (creating evidence about) every
computational element that do not require interaction interacts with other RATS
Roles. In general, and RATS Duties are typically associated the Computing Environment.
A Computing Environment with a
RATS Role. The list presented in this document is exhaustive. Also,
there an attestation capability can only be usage scenario where RATS Duties are associated with
other RATS Roles than illustrated below:

4.1.1. Attester Duties

o Acquisition or collection of assertions
endorsed by an external entity and cannot create believable evidence
about itself

o Provide or create proof that an assertion is bound to by its own.

A Computing Environment with the Attester

o Create Evidence from assertion bundles via roots-of-trust

4.1.2. Verifier Duties

o Acquisition and storage capability of assertion semantics remote attestation:

o Acquisition is separate from other Attested Computing Environments (about
which attestation evidence is created), and storage of appraisal policies

o Verification is enabling the role of an Attester Identity (attestation provenance)

o Comparing assertions or evidence in the RATS architecture.

A Computing Environment with reference values according
to appraisal policies

o Validate authentication information based on public keys,
signatures, secrets that are shielded, or secrets that are access
restricted via protection profiles

4.1.3. Claimant Duties

o Hardens the device or service that implements capability of remote attestation and
taking on the Attester role

o Provisions device identities and/or key material accessible to the of an Attester role

o Evaluates trustworthiness during manufacturing, supply chain and
onboarding has the following duties in order
to create Evidence:

o Produces monitoring trustworthiness assertions applicable to the Attestor
role attributes of other Computing
Environments,

o Embeds collecting trustworthiness assertions attributes and create Claims about the Attester role in the
device or service during manufacturing, supply chain or onboarding

4.1.4. Relying Party Duties
them,

o Evaluate assertions/evidence locally as far as possible

o Compare trust policies to attestation-results based on assertions
or evidence serialize Claims using interoperable representations,

o Enforce policies or create input provide integrity protection for risk engines

4.1.5. RATS Interactions the sets of Claims, and

o add appropriate attestation provenance attributes about the sets
of Claims.

3.2. Trustworthiness

The flow trustworthiness of information between RATS Roles located on RATS Actors
compose individual remote attestation procedures. The RATS
Architecture provides capabilities is also a set of standard interactions between
consideration for the RATS
Roles defined in this document in order architecture. It should be possible to enable this composability.
In this section, common interactions between roles are specified.
This list of interactions is not exhaustive, but provides
understand the basis
to create various standard RATS.

Every RATS Interaction specified below is based on trustworthiness properties of the information remote attestation
capability for any set of claims of a remote attestation flow between two RATS Roles defined above. Every RATS Interaction is
conducted via an Interconnect between corresponding RATS Roles that
RATS Actors take on. If more than one
verification operations. The RATS Role resides on architecture anticipates recursive
trustworthiness properties and the same
RATS Actor, a network protocol might not be required. If RATS Roles
are collapsed into need for termination. Ultimately,
a singular RATS Actor in this way, the method portion of
conveying information a computing environment's trustworthiness is out-of-scope of established
via non-automated means. For example, design reviews, manufacturing
process audits and physical security. For this document. If network
protocols are used to convey corresponding information between reason, trustworthy
RATS
Roles (collapsed depend on a singular RATS Actor or not), the definitions trustworthy manufacturing and requirements defined in this document apply.

In essence, an Interconnect is an abstract "distance-less" channel
between supply chain practices.

3.3. RATS Actors that can range from General Purpose Input Output
(GPIO) interfaces to the Internet.

Attester/Verifier: Workflow

The most basic RATS interaction is between the
creator of evidence (Attester) and its complementary remote
attestation service (Verifier). In order to convey evidence (or
assertions that are not accompanied by a proof function of their validity)
this RATS Interaction is required.

Attester/Relying-Party: A Relying Party typically requires external
help to either validate authentication information or to appraise
evidence presented by an Attester. In most cases, a Relying Party
requires a corresponding Verifier to process the assertions/
evidence received. In consequence, (a subset of) the information
received by an Attester must be relayed securely to a Verifier.

Relying-Party/Verifier: Typically, trusted assertions or evidence
are conveyed from an Attester to a Relying Party. In an open
ecosystem, such as the Internet, the creation, conveyance and appraisal of the evidence
presented by an
attestation Evidence. An Attester provided in order to assess its
trustworthiness requires a remote creates attestation service. Hence,
either the RATS roles of Verifier and Relying Party Evidence that
are collapsed
and compose a single RATS Actor, or - if they reside on separate
RATS Actors - a Relying Party requires appropriate configuration
or a discovery/join/rendezvous service conveyed to initiate a RATS
Interaction Verifier for appraisal. The appraisals compare
Evidence with an appropriate and trusted Verifier.

Attestation information originating expected Known-Good-Values called obtained from an Attester
Asserters (e.g. Prinicipals that is
relayed via a Relying Party must be protected from replay or relay
attacks, accordingly. In a closed ecosystem, trustworthiness with
respect to the Attester are Supply Chain Entities). There
can be achieved via a simply query to the
Verifier. In an open ecosystem, the information conveyed in this
interaction can include integrity measurements multiple forms of every
distinguishable appraisal (e.g., software component that has been executed since
its last boot cycle.

In the scope of RATS, this interaction encompasses integrity
verification, device composition and configuration verification,
device identity and provenance verification). Attestation Results
are the largest
variety output of information conveyed.

Claimant/Verifier: The intended operational state an Attester is
intended to be in, is defined by the supply chain entities that
manufacture appraisals. Attestation Results are signed and maintain the Attestor. In order to appraise
trusted assertions or evidence
conveyed by the Attester, every
distinguishable system component the Attester is composed of can to Relying Parties. Attestation Results provide trusted assertions or evidence about its trustworthiness.
A corresponding verifier that is tasked with assessing the
trustworthiness of basis
by which the Attester potentially requires Relying Party may determine a multitude
of sources level of reference values according confidence to policies and
place in the
information provided. As Relying Parties often have to discover
an appropriate application data or operations that follow.

RATS architecture defines attestation Roles (i.e., Attester,
Verifier, a Verifier has to obtain Asserter and potentially
store appropriate reference values in order to asses assertions or
evidence about trustworthiness.

Claimant/Attester: To enable RATS, trustworthy assertions have to be
embedded in an Attester by its manufactorer. In some cases this
involves Relying Party), the messages they exchange,
their structure and the various types of roots of trust. In other cases shielded
pre-master secrets legal ways in combination with key derivation functions
(KDF) provide this binding of trusted information to an Attester.
A supply chain entity can embed additional trusted assertions to
an Attester. These assertion can also which Roles may be used to assert the
trustworthiness on behalf of a separate
hosted, combined and divided (see Principals below). RATS Actor or they can
originate from messages
are defined by an external entity (e.g. a security certification
authority).

5. Application of RATS

Attester information model that defines Claims, environment
and protocol semantics. Information Model representations are typically composite devices (in the case
realized as data structure and conveyance protocol binding
specifications.

3.4. Interoperability between RATS

The RATS architecture anticipates use of atomically
integrated devices information modeling
techniques that would result in a composite device with one
component) or services. Services are software components describe computing environment structures - e.g. a
daemon, a virtual network function (vnf) or a network security
function (nsf) their
components/computational elements and corresponding capabilities - so
that can reside verification operations may rely on one or more Attester and are not
necessarily bound the information model as an
interoperable way to a specific set of hardware devices.

Relevant decision-factors that influence navigate the composition of RATS
Roles on RATS Actors, which result in specific work-flows are
(amongst others):

o which RATS Role (or correspondingly, which structural complexity.

4. RATS Actore that is
taking on specific Architecture

4.1. Goals

RATS roles) is triggering a Remote Attestation
Procedure

o which entities are involved in a Remote Attestation Procedure
(e.g. architecture has the Attester itself, trusted third parties, specific trust
anchors, or other sources of assertions) following goals:

o the capabilities Enable semantic interoperability of the protocols used (e.g. challenge-response
based, RESTful, or uni-directional) attestation semantics through
information models about computing environments and
trustworthiness.

o the security requirements Enable data structure interoperability related to claims, endpoint
composition / structure, and security capabilities end-to-end integrity and
confidentiality protection mechanisms.

o Enable programmatic assessment of systems in trustworthiness. (Note:
Mechanisms that manage risk, justify a domain level of application confidence, or
determine a consequence of an attestation result are out of
scope).

o Provide the risks and corresponding threats that are intended to be
mitigated

5.1. Trust building blocks, including Roles and Trustworthiness

[RFC4949] provides definitions Principals that highlight the difference between
a "trusted system" and a "trustworthy system". The following
definitions exclude
enable the explicit specialization composition of concepts service-chains/hierarchies and workflows
that are
"environmental disruption" as well as "human user can create and operator
errors".

A trusted system in appraise evidence about the context trustworthiness of RATS "operates as expected,
according to design
devices and policy, doing what is required services.

o Use-case driven architecture and not doing
other things" [RFC4949]. A trustworthy system is a system "that not
only is trusted, but also warrants that trust because the system's
behavior can be validated design (RATS use cases are
summarized in some convincing way, such as through
formal analysis or code review" [RFC4949].

The goal of RATS is to convey information about system component
characteristics, such as integrity or authenticity, [I-D.richardson-rats-usecases]).

o Terminology conventions that can be
appraised in a convincing way. are consistently applied across RATS require trust relationships with third parties that qualify
assertions about, for example, origin of data, the manufacturer or
the capabilities of a system, or the origination of attestation
evidence (attestation provenance). Without
specifications.

o Reinforce trusted authorities (e.g.
a certificate authority) it is virtually impossible to assess the
level of assurance (or resulting level of confidence,
correspondingly) of information produced computing principles that include attestation.

4.2. Attestation Principles

Specifications developed by RATS. Trusting a system
does not make it trustworthy. Assessing trustworthiness requires the
conveyance of evidence that a system is a trustworthy system, which
has to originate from RATS working group apply the system itself and has to
following principles:

o Freshness - replay of previously asserted Claims about an Attested
Computing Environment can be convincing. If detected.

o Identity - the convincing information Attesting Computing Environment is not originating from the system itself,
it comprises trusted claim sets and not evidence. In essence, identifiable
(non-anonymous).

o Context - the
attestation provenance of attestation evidence Attested Computing Environment is well-defined
(unambiguous).

o Provenance - the system that
intends origin of Claims with respect to present its trustworthiness in a believable manner.

The essential basis for trust in the information created via RATS are
roots of trust.

Roots of trust Attested and
Attesting Computing Environments are defined by known.

o Validity - the NIST special publication 800-164
draft as "security primitives composed of hardware, firmware and/or
software that provide a set of trusted, security-critical functions.
They must always behave in an expected manner because their
misbehavior cannot be detected. As such, RoTs need to be secured by
their design. Hardware RoTs are preferred over software RoTs due to
their immutability, smaller attack surface, and more reliable
behavior."

If the root lifetime of trust involved Claims about an Attested
Computing Environment is a root of trust for measurement
(RTM), known.

o Relevance - the producer of information takes on Claims associated with the role of a asserter.
An asserter can also make use of a root of trust for integrity (RTI)
in order Attested Computing
Environment pertain to increase trustworthiness metrics.

o Veracity - the level believability (level of assurance in the assertions
produced. If the root confidence) of trust involved Claims is a root of trust for
reporting (RTR), the producer of information takes
based on the role of an
attester.

5.2. Claims verifiable proofs.

4.3. RATS Roles and Evidence Messages

The RATS asserter role produces measurements about the system's
characteristics in the form of signed (sometimes un-signed) claim
sets in order to convey information. A secret signing key is
required for this procedure, which is typically stored in a shielded
location that can be trusted, for example, via a root of trust for
storage (RTS).

The Roles (roles) are performed by RATS attester role produces signed attestation evidence in order
to convey information. Principals.

The secret key required for this procedure is
stored in a shielded location that only allows access to that key, if
a specific operational state of RATS Architecture provides the system is met. The trust with
respect building blocks to this origination is based on a root of trust for
reporting.

5.3. compose various
RATS Information Flows

There are six roles defined in the by leveraging existing and new protocols. It defines
architecture for composing RATS architecture. iFigure 2 roles with principals and models
their interactions.

Figure Figure 1 provides a simplified an overview of the relationships between
RATS Roles defined above,
illustrating a general Interconnect in and the center that facilitates
all RATS Interactions.

+------------+ +------------------+ messages they exchange.

+----------------+ +-----------------+
| | Known-Good-Values | |
| Attester | +->| Asserter(s) |-------------------->| Verifier |
| | Endorsements /-->| |
+----------------+ | +-----------------+
|
+------------+ | +------------------+
^
| |
| | +----------------+
|
+---->| |<-+ |Attestation
| Interconnect |Results
|
+---->| |<-+ | +----------------+
|
v |
+------------+
| +------------------+ v
+----------------+ | +-----------------+
| | Evidence | | | Claimant
| +->| Attester |-----------------/ | Relying Party |
| | | |
+------------+ +------------------+
+----------------+ +-----------------+

Figure 2: Overall Relationships of Roles in the 1: RATS Architecture

6. Exemplary Composition of Roles

In order to provide an intuitive understanding how the roles used in

4.3.1. Roles

RATS can be composed into work-flows, this document provides a few
example work-flows. Boxes in the following examples that include
more than one role are systems that take on more than one role.

6.1. Conveyance of Trusted Claim Sets Validated by Signature

If there is a trust relationship between a trusted third party that
can assert that signed claims created by a claimant guarantee a
trustworthy origination of claim, the work-flow depicted in Figure 3
can facilitate a trust-based implicit remote attestation procedure.
The information conveyed are signed claim sets that roles are trusted via
an authoritative third party. In this work-flow claim emission is
triggered by the claimant. Variations based on requests emitted by
the relying party can be easily facilitated by the same set of roles.

+-----------+
+------------+ +----------------+ | |
| | | | | Relying |
| Claimant |->| Interconnect |--->| Party |
| | | | | |
+------------+ +----------------+ +-----------+

Figure 3: Conveyance of Trusted Claim Sets Validated by Signature

6.2. Conveyance of Attestation Evidence Appraised implemented by a Verifier

If there is trust in the root of trust for reporting based on the
assertions of a trusted third party, the work-flow depicted in
Figure 4 can facilitate an evidence-based explicit remote attestation
procedure. The information conveyed is signed attestation evidence principals that is created by the trusted verifier. In this work-flow claims do
not necessarily have possess cryptographic
keys used to be signed protect and the work-flow is triggered by
the attestor that aggregates claims from a root of trust of
measurement. Variations based on requests emitted by the verifier
can be easily facilitated by the same set of roles.

+------------------+ +----------------------+
| | | +----------------+ |
| +------------+ | +----------------+ | | | |
| | | | | | | | | |
| | Attester |--+->| Interconnect |--+->| Verifier | |
| | | | | | | | | |
| +------------+ | +----------------+ | +----------------+ |
| ^ | | | |
| | | | v |
| | | | +-----------+ |
| +-----+------+ | | | | |
| | | | | | Relying | |
| | Claimant | | | | Party | |
| | | | | | | |
| +------------+ | | +-----------+ |
| | | |
+------------------+ +----------------------+

Figure 4: Conveyance of authenticate Claims or Results.

Attester: An Attestation Function that creates Evidence Appraised by
collecting, formatting and protecting (e.g., signing) Claims. It
presents Evidence to a Verifier

7. The Scope of RATS

During its evolution, the term Remote Attestation has been used in
multiple contexts and multiple scopes and in consequence accumulated
various connotations with slightly different semantic meaning.

Correspondingly, Remote using a conveyance mechanism or
protocol.

Verifier: An Attestation Procedures (RATS) are employed in
various usage scenarios and different environments.

In order to better understand and grasp the intent and meaning of
specific RATS in the scope of the security area - including the
requirements Function that are addressed by them - this document provides an
overview of existing work, its background, and common terminology.
As the contribution, accepts Evidence from that state-of-the-art a set of terms that
provides a stable basis for future work on RATS in the IETF is
derived.

In essence, a prerequisite for providing an adequate set of terms and
definitions for the RATS architecute is a general understanding and
Attester using a
common definitions of "what" RATS can accomplish "how" RATS can to be
used.

Please note that this section is still missing various references conveyance mechanism or protocol. It also
accepts Known-Good-Values and
is considered "under construction". The majority of definitions is
still only originating Endorsments from IETF work. Future iterations will pull
in more complementary definitions from other SDO (e.g. Global
Platform, TCG, etc.) and an Asserter using a general structure template
conveyance mechanism or protocol. It verifies the protection
mechanisms, parses and appraises Evidence according to highlight
semantic relationships good-known
valid (or known-invalid) Claims and capable of resolving potential
discrepancies will be introduced. A section of context awareness
will provide further insight on how Endorsments. It produces
Attestation procedures are vital
to ongoing work in the IETF (e.g. I2NSF & tokbind). The definitions
in the section about RATS Results that are still self-describing in this version.
Additional explanatory text will be added to provide more context formatted and
coherence.

7.1. The Lying Endpoint Problem

A very prominent goal of RATS is protected (e.g.,
signed). It presents Attestation Results to address the "lying endpoint
problem". The lying endpoint problem is characterized as a condition
of Relying Party using
a Computing Context where the information or behavior embedded,
created, relayed, stored, conveyance mechanism or emitted by protocol.

Asserter: An Attestation Function that generates reference Claims
about both the Attesting Computing Context is not
"correct" according to expectations of Environment and the authorized system
designers, operators Attested
Computing Environment. The manufacturing and users. There can be multiple reasons why
these expectations development
processes are incorrect, either from malicious Activity,
unanticipated conditions or accidental means. The observed behavior,
nevertheless, appears to be a compromised Computing Context.

Attempts to "scrub" the data or "proxy" control elements implies the
existence of a more fundamental trusted endpoint that is operating
correctly. Therefore, Remote Attestation - the technology designed presumed to detect and mitigate the "lying endpoint problem" - must be trusted
to behave correctly independent of trustworthy processes. In other controls.

Consequently, a "lying endpoint" cannot also be a "trusted system".

Remote Attestation procedures are intended to enable
words the consumer of
information emitted Asserter is presumed, by a Computing Context Verifier, to assess the validity and
integrity of the information transferred. produce valid
Claims. The approach is based, for
example, on the assumption that if attestation evidence can be
provided in order to prove the integrity of every software instance
installed involved in the activity of creating the emitted
information in question, the emitted information can be considered function collects, formats and protects (e.g. signs)
valid Claims known as Endorsements and integer.

In contrast, such Evidence has to be impossible Known-Good-Values. It
presents provable Claims to create if the
software instances used in a Computing Context are compromised.
Attestation activities that are intended to create this Evidence
therefore also provide guarantees about the validity of the Evidence
they can create.

7.1.1. How the RATS Architecture Addresses the Lying Endpoint Problem

RATS imply the involvement of at least two players (roles) who seek
to overcome the lying endpoint problem. The Verifier wishes to
consume application data supplied by using a Computing Context. But before
application data is consumed, the Verifier obtains Attestation
Evidence about the Computing Context to assess likelihood of poisoned
data due to endpoint compromise conveyance
mechanism or failure. Remote protocol.

Relying Party: An Attestation
argues Function that a systems's integrity characteristics should not be
believed until rationale for believability is presented to the
relying party seeking to interact with the system.

An Interconnect defines an untrusted channel between subject and
object wherein the rationale for believability is securely exchanged.
The type of interconnect technology could vary widely, ranging accepts Attestation
Results from
GPIO pins, to a PC peripheral IO bus, to the Internet, to a direct
physical connection, to Verifier using a wireless radio-receiver association, conveyance mechanism or to
a world wide mesh of peers. In other words, virtually every kind
communication path could be used as the "Interconnect" in RATS. In
fact, a single party could take on all roles at the same time (e.g.
Self Encrypting Devices). protocol.
It assesses Attestation evidence can be thought of as the topics Results protections, parses and assesses
Attestation Results according to an assessent context (Note:
definition of the exchange
that assessment context is created the operational primitives of a root out-of-scope).

4.3.2. Role Messages

Claims: Statements about trustworthiness characteristics of trust for
reporting. Evidence may be structured in an interoperable format
called claims that may include references to the claimants which are
asserting the claims. RATS aims to define "interoperable Remote
Attestation" such that evidence can be created and consumed by
different ecosystem systems and can be securely exchanged by a broad
set of network protocols.

8. RATS Terminology

This document relies on terminology found in [RFC4949]. This
document presumes the reader is familiar with the following terms.

o Cryptography

o Entity (System entity)

o Identity

o Object

o Principal

o Proof-of-possession protocol

o Security environment (Environment)

o Security perimeter

o Subject

o Subsystem

o System

o Target-of-Evaluation (TOE)

o Trusted
Attested Computing Base (TCB)

o Trusted Platform Module (TPM)

o Trusted (Trustworthy) system

o Verification

Terminology defined by this document is preceded by a dollar sign ($)
to distinguish it from terms defined elsewhere and as Environment.

The veracity of a way to
disambiguate term definition from explanatory text.

Terms defined by this document that are subsequently used by this
document are distinguished Claim is determined by capitalizing the first letter reputation of the
term (e.g. Term or First_word Second_word).

8.1. Computing Context

This section introduces the term Computing Context in order to
specialize
entity making the notions of environment Claim. (Note: Reputation may involve
identifying, authenticating and endpoint to terminology
that has relevance to trusted computing. Attestation is a discipline
of trusted computing.

A Computing Context could refer tracking transactions associated
with an entity. RATS may be used to a large variety of endpoints.
Examples include establish entity reputation,
but are not limited to: the compartmentalization of
physical resources, the separation of software instances with
different dependencies in dedicated containers, and the nesting of
virtual components via hardware-based and software-based solutions.
The number of approaches exclusively. Other reputation mechanisms are out-of-
scope).

Evidence: Claims that are formatted and techniques to construct protected by an endpoint
continuously changes with new innovation. Hence, it isn't a goal of
this document to define remote attestation Attester.

Evidence SHOULD satisfy Verifier expectations for a fixed set of
endpoints. Rather, it attempts to define endpoints conceptually freshness,
identity, context, provenance, validity, relevance and
rely on veracity.

Known-Good-Values: Claims management as a way to clarify about the details and
specific attributes of conceptual endpoints. Attested Computing Contexts may be recursive in nature in that it could be
composed of a system that is itself a composite of subsystems. In
consequence, a system may be composed of other systems that may be
further composed Environment.
Typically, KGV Claims are message digests of one firmware, software or more
configuration data supplied by various vendors. If an Attesting
Computing Contexts capable of taking
on the RATS roles. The scope and application of these roles can
range from:

o Continuous mutual Attestation procedures of every subsystem inside Environment implements cryptography, they include Claims
about key material.

Like Claims, Known-Good-Values SHOULD satisfy a composite device, to

o Sporadic Remote Attestation of unknown parties via heterogeneous
Interconnects.

Analogously, the increasing number of features Verifier's
expectations for freshness, identity, context, provenance,
validity, relevance and functions that
constitute components of a device start to blur the lines that veracity. Known-Good-Values are
required to categorize each solution and approach precisely. To
address this increasingly challenging categorization, the term
Computing Context defines the characteristics of the (sub)systems
that can take on the role of an Attester and/or the role of a
Verifier. This approach is intended to provide a stable basis of
definitions for future solutions that continuous to remain viable
long-term.

$ Computing Context : An umbrella term reference
Claims that combines the scope of
the definitions of endpoint [ref NEA], device [ref 1ar], and thing
[ref t2trg], including hardware-based are - like Evidence - well formatted and software-based sub-
contexts that constitute independent, isolated protected
(e.g. signed).

Endorsements: Claims about immutable and distinguishable
slices implicit characteristics of a
the Attesting Computing Context Environment. Typically, endorsement
Claims are created by compartmentalization
mechanisms, such as Trusted Execution Environments (TEE), Hardware
Security Modules (HSM) manufacturing or Virtual Network Function (VNF) contexts.

8.1.1. Characteristics of a Computing Context

While the semantic relationships highlighted above constitute the
fundamental basis to provide a define Computing Context, the
following list of object characteristics is supply chain entities.

Endorsements are intended to improve the
application of the term and provide a better understanding of its
meaning:

$ Computing Context Characteristics: A representation of increase the
identity, composition, configuration and state level of a Computing
Context.

Computing context characteristics provide the following: * An
independent environment in regard to executing and running
software, * An isolated control plane state (by potentially
interacting with other Computing Contexts), * A dedicated
management interface by which control plane behavior can be
effected, * Unique identification towards reliable disambiguation
within a given scope.

Computing context characteristics do not necessarily include a
network interface confidence with associated network addresses (as required by
the definition of an endpoint) - although it is very likely
respect to have
(access to) one.

[Issue: This conclusion could be incorrect] In contrast, a container
[ref docker, find a more general term here] context is not a
distinguishable isolated slice of an information system and therefore
is not Evidence created by an independent Computing Context. [more feedback on this
statement is required as Attester.

Attestation Results: Statements about the capabilities output of docker-like functions
evolve continuously]

Examples include: a smart phone, a nested virtual machine, a
virtualized firewall function running distributed on a cluster an appraisal of
physical and virtual nodes, or a trust-zone.

8.1.2. Computing Context Semantic Relationships

Computing Contexts may relate to other Computing Contexts
Evidence that are
decomposable in a variety of ways.

o Singleton,

o Tuples (e.g. 2-tuple, n-tuple),
o Nested,

o Clustered (homogeneous),

o Grouped (heterogenous).

The scope of Computing Context encompasses a broad spectrum of
systems including, but not limited to:

o An information system,

o An object,

o A composition of objects,

o A system component,

o A system sub-component,

o A composition of system sub-components,

o A system entity,

o A composition of system entities.

A Computing Context may be realized in a variety of ways including,
but not limited to:

o A process, thread or task as defined by an operating system,

o A privileged operating system task, interrupt handler or event
handler,

o A virtual machine,

o A virtual machine monitor,

o A processor mode (e.g. system management mode),

o A co-processor,

o A peripheral device,

o A secure element,

o A trusted execution environment,

o A controller, sensor, actutor, switch, router or gateway,
o An FPGA,

o An ASIC,

o A memory resource,

o A storage resource.

Analogously, a computing sub-context is a decomposition of a
Computing Context; a subsystem is a decomposition of a system; a sub-
component is a decomposition of a component; created, formatted and protected by a peer node is a
decomposition of a node cluster.

A formal semantic relationship is therefore expressed using an
information model that captures interactions, relationships, bindings
and interfaces among systems, subsystems, system components, system
entities or objects.

[Issue: A tangible relationship to an information model is required
here] An information model that richly captures Computing Context
semantics is therefore believed to be relevant if not fundamental to
Remote Attestation.

8.1.3. Computing Context Identity

The identity of a Computing Context implies there is a binding
operation between an identifier and the Computing Context.

$ Computing Context Identity: Computing Context Identity provides Verifier.

Attestation Results provide the basis for associating attestation Evidence about a particular
Computing Context Relying Party to create believable knowledge about attestation
provenance.

Confidence in the identity assurance level [NIST SP-800-63-3] or the
assurance levels for identity authentication [RFC4949] is
establsh a property level of the identifier uniqueness properties and binding operation
veracity. Such properties impact confidence in the trustworthiness of associated
attestation Evidence.

8.2. Remote Attestation Concepts an
Attester. Attestation Evidence created by Results SHOULD satisfy Relying Party
expectations for freshness, identity, context, provenance,
validity, relevance and veracity.

4.4. RATS is a form of telemetry about a Principals

RATS Principals are entities, users, organizations, devices and
computing environment that enables better security risk management
through disclosure of security properties of the environment.
Attestation environments (e.g., devices, platforms, services,
peripherals).

RATS Principals may be performed locally (within the same computing
environment) implement one or remotely (between different computing environments).
The exchange of attestation evidence can be formalized to include
well-defined protocol, message syntax and semantics.

8.3. Core more RATS Terminology

$ Attestation: The creation of evidence by the Attester based on
measurements or other claimant output.

A form of telemetry involving the delivery of Claims describing
various security properties of a Computing Context by an Attester,
such that the Claims can be used as Evidence toward convincing a
Verifier regarding trustworthiness of the Computing Context.

$ Conveyance: The transfer of Evidence from the Attester to Roles. Role
interactions occurring within the
Verifier.

$ Verification: same RATS Principal are out-of-
scope.

The appraisal of Evidence by the Verifier who
evaluates it against a reference policy. See also RFC4949 [1].

$ Remote Attestation: A procedure involving Attestation, Conveyance
and Verification.

8.4. methods whereby RATS Information Model Terminology

Evidence conveyed to a Verifier by an Attester is structured to
facilitate syntactic and semantic interoperability. An information
model defines the tag namespaces used to create tag-value pairs
containing discrete bits of Evidence.

$ Evidence: A set of Measurements, quality metrics, quality
procedures or assurance criteria about an Computing Context's
behavioral, operational and intrinsic characteristics.

$ Claim: Structured Evidence asserted about a Computing Context. It
contains metadata that informs regarding the type, class,
representation and semantics of Evidence information. A Claim is
represented as a name-value pair consisting of a Claim Name Principals may be identified, discovered,
authenticated, connected and a
Claim Value [RFC7519]. In the context of SACM, a Claim is also
specialized as an attribute-value pair trusted, though important, are out-of-
scope.

Principal operations that is intended to be
related to a statement [I-D.ietf-sacm-terminology].

$ Attestable Claim: Structured Evidence including one apply resiliency, scaling, load balancing
or more Claims
that replication are asserted by a Claimant (Note: an Attester role doubles as
a Claimant role). An Attestable Claim has the following
structure:

1. A Claim or Claims.

2. A Claimant identity.

3. Proof of Claimant identity.

4. Proof the Claimant intended generally believed to make these Claims.

Note: Proofs of Claims assertions may be separated from the Claim
itself. For example, a secure transport over which Claims are
conveyed where Claimant's signing key integrity protects the
transport payload could be used as proof of Claim assertion.
Alternatively, each Claim could be separately signed by a Claimant.

$ Attested (Asserted) Claim: An Attestable Claim where the proof
elements are populated.

$ Evidence (Claims) Creation: Instantiation of Attested Claims by a
Claimant.

$ Evidence (Claims) Collection: Assembling of Attested Claims by an
Attester for the purpose of Conveyance.

$ Verified (Valid) Claim: An Attested Claim where the proof elements
have been verified by a Verifier according to a policy that
identifies trusted Claimants and/or trusted Evidence values.

8.5. out-of-scope.

+------------------+ +------------------+
| Principal 1 | | Principal 2 |
| +------------+ | | +------------+ |
| | | | | | | |
| | Role 1 |<-|---|->| Role 2 | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| +-----+------+ | | +-----+------+ |
| | | | | | | |
| | Role 2 |<-|---|->| Role 3 | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
+------------------+ +------------------+

Figure 2: RATS Work-Flow Terminology

This section introduces terms and definitions that are required to
illustrate the scope and the granularity of Principals-Role Composition

RATS workflows in the
domain of security automation. Terms defined in Principals have the following
sections will be based on this workflow-related definitions.

In general, RATS are composed properties:

o Multiplicity - Multiple instances of iterative activities RATS Principals that can be
conducted in intervals. It is neither a generic set of actions nor
simply a task, because possess
the actual actions to be conducted by same RATS Roles can
vary significantly depending on the protocols employed and types of
Computing Contexts involved.

$ Activity: A sequence of actions conducted by Computing Contexts
that compose a Remote Attestation procedure. The actual
composition of actions can vary, depending on the characteristics
of the Computing Context they are conducted by/in and the
protocols used to utilize an Interconnect. A single Activity
provides only a minimal amount of semantic context, e.g.defined by
the Activity's requirements imposed upon the Computing Context, or
via the set of actions it is composed of. Example: The Conveyance
of cryptographic Evidence or the appraisal of Evidence via
imperative guidance.

$ Task: A unit of work to be done or undertaken.

In the scope of RATS, a task is a procedure to be conducted.
Example: A Verifier exist.

o Composition - RATS Principals possessing different RATS Roles can
be tasked with the appraisal of Evidence
originating from a specific type of Computing Contexts providing
appropriate identities.

$ Action: The accomplishment of a thing usually over a period of
time, in stages, or with the possibility of repetition.

In the scope of RATS, an action is the execution of an operation
or function in the scope of an Activity conducted by combined into a Computing
Context. A single action provides no semantic context by itself,
although it can limit potential semantic contexts of singleton RATS to a
specific scope. Example: Signing an existing public key via a
specific openssl library, transmitting data, or receiving data are
actions.

$ Procedure: A series of actions that are done in a certain way or
order.

In Principal possessing the scope of RATS, a procedure is a composition of activities
(sequences of actions) that is intended to create a well specified
result with a well established semantic context. Example: The
activities union
of Attestation, Conveyance and Verification compose a
Remote Attestation procedure.

8.6. RATS Reference Use Cases

A "lying endpoint" Roles. RATS Interactions between combined RATS Principals
is not trustworthy.

This document provides NNN prominent examples of use cases
Attestation procedures are intended to address:

o Verification of the source integrity of a Computing Context via
data integrity proofing of installed software instances that are
executed, and uninteresting.

o Verification of the identity proofing of a Computing Context.

8.6.1. Use Case Decomposition - A

8.6.2. Use Case B

8.7. singleton RATS Reference Terminology

$ Attestable Computing Context: A Computing Context where a Claimant
is able to create Claims, an Attester is able to Attest those
Claims and a Verifier is able to verify the Claims.

$ Attestation Identity: An identity that refers to an Attester.

$ Attestation Identity Credential: A credential used to authenticate
an Attestation Identity.

$ Attestation Identity Key (AIK): An Attestation Identity Credential
in the form of an asymmetric cryptographic key where the AIK
private key is protected by a Computing Context with protection
properties that are stronger than the Computing Context about
which the AIK attests. A root-of-trust Computing Context normally
protects AIK private keys.

$ Claimant Identity: An identity that refers to an Claimant.

$ Claimant Identity Credential: A credential used to authenticate a
Claimant Identity.

$ Measurements / Integrity Measurements: Metrics of Computing
Context characteristics (i.e. composition, configuration and
state) that affect the confidence in the trustworthiness of a
Computing Context. Digests of integrity Measurements Principal possessing multiple
RATS Roles can be
stored in shielded locations (e.g. a PCR of a TPM).

$ Reference Integrity Measurements: Signed Measurements about a
Computing Context's characteristics that are provided by a vendor
or manufacturer divided into multiple RATS Principals.

RATS Interactions may occur between them.

5. Security Considerations

RATS Evidence, Verifiable Assertions and are intended to be used as declarative
guidannce [I-D.ietf-sacm-terminology] (e.g. a signed CoSWID).

$ Root-of-trust: The Computing Context Results SHOULD use formats
that protects the following
where no other Computing Context is expected to provide its
Attestation Evidence: + Attestation Evidence. + AIKs. + Code
used during the collection and reporting of Attestation Evidence.

$ Root-of-trust-for-measurement (RTM): A trusted Computing Context
where a Claimant creates support end-to-end integrity Measurements protection and other Evidence
about MAY support end-to-
end confidentiality protection. Replay attack prevention MAY be
supported if a Computing Context where no other Computing Context Nonce Claim is
expected to provide its Attestation Evidence.

$ Root-of-trust-for-reporting (RTR): A trusted Computing Context
where an Attester stages reporting of included. Nonce Claims where no other
Computing Context is expected to provide its Attestation Evidence.

$ Root-of-trust-for-storage (RTS): A trusted Computing Context where
a Claimaint or Attester stores Claims, Evidence, credentials or
policies associated with Attestation where no often piggy-
back other Computing
Context is expected to provide its Attestation Evidence.

$ Trustworthy Computing Context: A Computing Context that guarantees
trustworthy behavior and/or composition (with respect to certain
declarative guidance and a scope of confidence). A trustworthy
Computing Context is a trustworthy system.

<NMS: is this necessary?> Trustworthy Statement: Evidence conveyed
by a Computing Context that is not necessarily trustworthy.
[update with tamper related terms]

8.8. Interpretations of RFC4949 Terminology for Attestation

Assurance: An attribute of an information system that provides
grounds for having confidence that the system operates such that
the system's security policy is enforced [RFC4949] (see Trusted
System below).

In common criteria, assurance is the basis for the metric level of
assurance, which represents the "confidence that a system's
principal security features are reliably implemented".

The NIST Handbook [get ref from 4949] notes that the levels of
assurance defined in Common Criteria represent "a degree of
confidence, not a true measure of how secure the system actually
is. This distinction is necessary because it is extremely
difficult-and in many cases, virtually impossible-to know exactly
how secure a system is."

Historically, assurance was well-defined in the Orange Book
[http://csrc.nist.gov/publications/history/dod85.pdf] as
"guaranteeing or providing confidence that the security policy has
been implemented correctly and can convey attestation semantics that the protection-relevant
elements of the system do, indeed, accurately mediate and enforce
the intent of that policy. By extension, assurance must include a
guarantee that the trusted portion of the system works only as
intended."

Confidence: The definition are
of correctness integrity in [RFC4949]
notes that "source integrity refers to confidence in data values".
Hence, confidence in an Attestation procedure is referring essence to RATS, e.g. the
degree of trustworthiness of an Attestation Activity that produces
Evidence (Attester), of an Conveyance Activity that transfers
Evidence (interconnect), and of a Verification Activity that
appraises Evidence (Verifier), in respect to correctness
integrity.

Correctness: The property last four bytes of a system that is guaranteed as the
result of formal Verification activities.

Correctness integrity: The property that the information represented challenge nonce
could be replaced by data is accurate and consistent.

Data Integrity: (a) The property that data has not been changed,
destroyed, or lost in an unauthorized or accidental manner. (See:
data integrity service. Compare: correctness integrity, source
integrity.)

(b) The property that information has not been modified or
destroyed in an unauthorized manner.

Entity: A principal, Subject, relying party or stake holder in an
Attestation ecosystem.

Identity: The set of attributes that distinguishes a principal.

Identifier: The set of attributes that distinguishes an object.

Identity Proofing: A vetting process that verifies the information
used to establish the identity of a system entity.

(Information) System: An organized assembly of computing and
communication resources and procedures - i.e., equipment and
services, together with their supporting infrastructure,
facilities, and personnel - that create, collect, record, process,
store, transport, retrieve, display, disseminate, control, or
dispose of information to accomplish a specified set of functions.

Object: A system component that contains or receives information.

Source Integrity: The property that data is trustworthy (i.e.,
worthy of reliance or trust), based on the trustworthiness IPv4 address-value of its
sources and the trustworthiness of any procedures used for
handling data in the system.

Subject: A Computing Context acting Attester in accordance with the interests
of a principal.

Subsystem: A collection of related system components that together
perform a system function or deliver a system service.

System Component: An instance of a system resource that (a) forms a
physical or logical part of the system, (b) has specified
functions and interfaces, and (c) is extant (e.g., by policies or
specifications) outside of its
response.

All other parts of the system. (See:
subsystem.)
An identifiable and self-contained part of a $Target-of-
Evaluation.

Token: A data structure suitable for containing Claims.

Trusted (Trustworthy) System: A system that operates as expected,
according to design and policy, doing what is required - despite
environmental disruption, human user and operator errors, and attacks by hostile parties - and involving RATS structures are not doing other things.

Verification: (a) The process of examining information to establish
the truth explicitly
addressed by RATS architecture. Additional security protections MAY
be required of a claimed fact or value.

(b) The process conveyance mechanisms. For example, additional means
of comparing two levels authentication, confidentiality, integrity, replay, denial of system specification
for proper correspondence, such as comparing a security model with
a top-level specification, a top-level specification with source
code, or source code with object code.

8.9. Building Block Vocabulary (Not in RFC4949)

[working title, pulled from various sources, vital]

Attribute: TBD

Characteristic: TBD

Context: TBD

Endpoint: TBD

Environment: TBD

Manifest: TBD

Telemetry: An automated communications process by which data,
readings, Measurements and Evidence are collected at remote points
service and transmitted to receiving equipment for monitoring privacy protection of RATS payloads and
analysis. Derived from the Greek roots tele = remote, and metron
= measure.

9. IANA considerations

This document will include requests to IANA:

o first item

o second item

10. Security Considerations

There are always some.

11. Acknowledgements

Maybe.

12. Change Log

No changes yet.

13. Principals may be
needed.

6. References

13.1.

6.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

13.2.

6.2. Informative References

[I-D.ietf-sacm-terminology]
Birkholz, H., Lu, J., Strassner, J., Cam-Winget, N., and
A. Montville, "Security Automation and Continuous
Monitoring (SACM) Terminology", draft-ietf-sacm-
terminology-16 (work in progress), December 2018.

[I-D.mandyam-eat]
Mandyam, G., Lundblade, L., Lundblade, L., Ballesteros,

[ABLP] Abadi, M., Burrows, M., Lampson, B., and J. O'Donoghue, "The Entity Attestation Token
(EAT)", draft-mandyam-eat-01 (work in progress), November
2018. G. Plotkin, "A
Calculus for Access Control in Distributed Systems",
Springer Annual International Cryptology Conference,
page 1-23, DOI 10.1.1.36.691, 1991.

[DOLEV-YAO]
Dolev, D. and A. Yao, "On the security of public key
protocols", IEEE Transactions on Information Theory Vol.
29, pp. 198-208, DOI 10.1109/tit.1983.1056650, March 1983.

[I-D.richardson-rats-usecases]
Richardson, M., Wallace, C., and W. Pan, "Use cases for
Remote Attestation common encodings", draft-richardson-rats-usecases-00 draft-richardson-
rats-usecases-04 (work in progress), March July 2019.

[I-D.tschofenig-rats-psa-token]
Tschofenig, H., Frost, S., Brossard, M.,

[Lampson2007]
Lampson, B., "Practical Principles for Computer Security",
IOSPress Proceedings of Software System Reliability and A. Shaw,
"Arm's Platform
Security, page 151-195, DOI 10.1.1.63.5360, 2007.

[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Architecture (PSA) Attestation
Token", draft-tschofenig-rats-psa-token-00 (work in
progress), March 2019. Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.

[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>.

[RFC7519] Jones,

[RFC5209] Sangster, P., Khosravi, H., Mani, M., Bradley, J., Narayan, K., and N. Sakimura, "JSON Web Token
(JWT)", J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 7519, 5209, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.

13.3. URIs

[1] https://tools.ietf.org/html/rfc4949 10.17487/RFC5209, June 2008,
<https://www.rfc-editor.org/info/rfc5209>.

Authors' Addresses

Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
Darmstadt 64295
Germany

Email: henk.birkholz@sit.fraunhofer.de

Monty Wiseman
GE Global Research
USA

Email: monty.wiseman@ge.com
Hannes Tschofenig
ARM Ltd.
110 Fulbourn Rd
Cambridge CB1 9NJ
UK

Email: hannes.tschofenig@gmx.net

Ned Smith
Intel Corporation
USA

Email: ned.smith@intel.com