RATS Working Group H. Birkholz
Internet-Draft Fraunhofer SIT
Intended status: Standards Track M. Wiseman
Expires: May 7, 2020 GE Global Research
H. Tschofenig
ARM Ltd.
N. Smith
Intel
M. Richardson
Sandelman Software Works
November 04, 2019
Remote Attestation Procedures Architecture
draft-birkholz-rats-architecture-03
Abstract
An entity (a relying party) requires a source of truth and evidence
about a remote peer to assess the peer's trustworthiness. The
evidence is typically a believable set of claims about its host,
software or hardware platform. This document describes an
architecture for such remote attestation procedures (RATS).
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 May 7, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Birkholz, et al. Expires May 7, 2020 [Page 1]
Internet-Draft RATS Arch & Terms November 2019
(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
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Opportunities . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Overview of Document . . . . . . . . . . . . . . . . . . 4
1.4. RATS in a Nutshell . . . . . . . . . . . . . . . . . . . 5
1.5. Remote Attestation Workflow . . . . . . . . . . . . . . . 5
1.6. Message Flows . . . . . . . . . . . . . . . . . . . . . . 7
1.6.1. Passport Model . . . . . . . . . . . . . . . . . . . 7
1.6.2. Background Check . . . . . . . . . . . . . . . . . . 8
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Reference use cases . . . . . . . . . . . . . . . . . . . . . 10
3.1. Device Capabilities/Firmware Attestation . . . . . . . . 11
3.2. IETF TEEP WG Use-Case . . . . . . . . . . . . . . . . . . 11
3.3. Safety Critical Systems . . . . . . . . . . . . . . . . . 12
3.4. Virtualized Multi-Tenant Hosts . . . . . . . . . . . . . 12
3.5. Cryptographic Key Attestation . . . . . . . . . . . . . . 13
3.6. Geographic Evidence . . . . . . . . . . . . . . . . . . . 13
3.7. Device Provenance Attestation . . . . . . . . . . . . . . 14
4. Conceptual Overview . . . . . . . . . . . . . . . . . . . . . 14
4.1. Two Types of Environments . . . . . . . . . . . . . . . . 15
4.2. Evidence Creation Prerequisites . . . . . . . . . . . . . 16
4.3. Trustworthiness . . . . . . . . . . . . . . . . . . . . . 17
4.4. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 17
4.5. Interoperability between RATS . . . . . . . . . . . . . . 18
5. RATS Architecture . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Attestation Principles . . . . . . . . . . . . . . . . . 18
5.3. Attestation Workflow . . . . . . . . . . . . . . . . . . 19
5.3.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3.2. Role Messages . . . . . . . . . . . . . . . . . . . . 20
5.4. Principals (Entities?) - Containers for the Roles . . . . 22
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
Birkholz, et al. Expires May 7, 2020 [Page 2]
Internet-Draft RATS Arch & Terms November 2019
1. Introduction
Remote Attestation provides a way for an entity (the Relying Party)
to determine the health and provenance of an endpoint/host (the
Attester). Knowledge of the health of the endpoint allows for a
determination of trustworthiness of the endpoint.
1.1. Motivation
The IETF has long spent it's time focusing on threats to the
communication channel (see [RFC3552] and [DOLEV-YAO]), assuming that
endpoints could be trusted and were under the observation of trusted,
well-trained professionals. This assumption has not been true since
the days of the campus mini-computer. For some time after the
desktop PC became ubiquitous, the threat to the endpoints has been
dealt with as an internal matter, with generally poor results.
Enterprises have done some deployment of Network Endpoint Assessment
([RFC5209]) to assess the security posture about an endpoint, but it
has not been ubiquitous.
The movement towards personal mobile devices ("smartphones") and the
continuing threat from unmanaged residential desktops has resulted in
a renewed interest in standardizing internet-scale endpoint remote
attestation. Additionally, the rise of the Internet of Things (IoT)
has made this issue even more critical: some skeptics have even
renamed it to the Internet of Threats [iothreats] :-) IoT devices
have poor or non-existent user interfaces, as such as there are not
even good ways to assess the health of the devices manually: a need
to determine the health via remote attestation is now critical.
In addition to the health of the device, knowledge of its provenance
helps to determine the level of trust, and prevents attacks to the
supply chain.
1.2. Opportunities
The Trusted Platform Module (TPM) is now a commonly available
peripheral on many commodity compute platforms, both servers and
desktops. Smartphones commonly have either an actual TPM, or have
the ability to emulate one in software running in a Trusted Execution
Environment [I-D.ietf-teep-architecture]. There are now few barriers
to creating a standards-based system for remote attestation
procedures.
A number of niche solutions have emerged that provide for use-case
specific remote attestation, but none have the generality needed to
be used across the Internet.
Birkholz, et al. Expires May 7, 2020 [Page 3]
Internet-Draft RATS Arch & Terms November 2019
1.3. Overview of Document
The architecture described in this document (along with the
accompanying solution and reference documents) enables the use of
common formats for communicating Claims about an Attester to a
Relying Party. [FIXME Attester? Flows? To what end?]
Existing transports were not designed to carry attestation Claims.
It is therefore necessary to design serializations of Claims that fit
into a variety of transports, for instance: X.509 certificates, TLS
negotiations, YANG modules or EtherNet/IP. There are also new,
greenfield uses for remote attestation. Transport and serialization
of these can be done without retrofitting. This is (will be)
described in [INSERT reference to adopted document on transport].
While it is not anticipated that the existing niche solutions
described in the use cases section Section 3 will exchange claims
directly, the use of a common format enables common code. As some of
the code needs to be in intentionally hard to modify trusted modules,
the use of a common formats and transfer protocols significantly
reduces the cost of adoption to all parties. This commonality also
significantly reduces the incidence of critical bugs.
In some environments the collection of Evidence by the Attester to be
provided to the Verifier is part of an existing protocol: this
document does not change that, rather embraces those legacy
mechanisms as part of the specification. This is an evolutionary
path forward, not revolutionary. Yet in other greenfield
environments, there is a desire to have a standard for Evidence as
well as for Attestation Results, and this architecture outlines how
that is done.
This introduction gives an overview of the message flows and roles
involved. Following this, is a terminology section that is
referenced normatively by other documents and is a key part of this
document. There is then a section on use cases and how they leverage
the roles and workflows described.
In this document, terms defined within this document are consistently
Capitalized [work in progress. please raise issues, if there are
Blatant inconsistencies].
Current verticals that use remote attestation include:
o The Trusted Computing Group "Network Device Attestation Workflow"
[I-D.fedorkow-rats-network-device-attestation]
o Android Keystore [keystore]
Birkholz, et al. Expires May 7, 2020 [Page 4]
Internet-Draft RATS Arch & Terms November 2019
o Fast Identity Online (FIDO) Alliance attestation [fido]
o A number of Intel SGX niche systems based upon OTRP.
1.4. RATS in a Nutshell
1. Remote Attestation message flows typically convey Claims that
contain the trustworthiness properties associated with an
Attested Environment (Evidence).
2. A corresponding provisioning message flows conveys Reference
trustworthiness claims that can be compared with attestation
Evidence. Reference Values typically consist of firmware or
software digests and details about what makes the attesting
module a trusted source of Evidence.
3. Relying Parties are performing tasks such as managing a resource,
controlling access, and/or managing risk. Attestation Results
helps Relying Parties determine levels of trust.
1.5. Remote Attestation Workflow
The logical information flow is from Attester to Verifier to Relying
Party. There are variations presented below on how this integrates
into actual protocols.
Birkholz, et al. Expires May 7, 2020 [Page 5]
Internet-Draft RATS Arch & Terms November 2019
************
* Asserter *
************
|
|
|Known-Good-Values
|Endorsements
|
v
.---------------.
| Verifier |
.--------->| |----------.
| | | |
| '---------------' |
| |
|Evidence |Attestation Results
| |(Claims)
| |
| v
.---------------. .---------------.
| Attester | | Relying Party |
| | | |
| | | |
'---------------' '---------------'
Figure 1: RATS Workflow
In the architecture shown above, specific content items (payload
conveyed in message flows) are identified:
o Evidence is as set of believable Claims about distinguishable
Environments made by an Attester.
o Known-Good-Values are reference Claims used to appraise Evidence
by an Verifier.
o Endorsements are reference Claims about the type of protection
that enables an Attester to create believable Evidence.
Endorsements enable trust relationships towards system components
or environments Evidence cannot be created for by an Attester.
o Attestation Results are the output from the appraisal of Evidence,
Known-Good-Values and Endorsements and are consumed by Relying
Parties.
Attestation Results are the output of RATS.
Birkholz, et al. Expires May 7, 2020 [Page 6]
Internet-Draft RATS Arch & Terms November 2019
Assessment of Attestation Results is be multi-faceted and out-of-
scope for the architecture.
If appropriate Endorsements about the Attester are 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 Relying Parties to
establish a level of confidence in the trustworthiness of the
Attester.
The Asserter role and the format for Known-Good-Values and
Endorsements are not subject to standardization at this time. The
current verticals already include provisions for encoding and/or
distributing these objects.
1.6. Message Flows
Two distinct flows have been identified for passage of Evidence and
production of Attestation Results. It is possible that there are
additional situations which are not captured by these two flows.
1.6.1. Passport Model
In the Passport Model message flow the Attester provides it's
Evidence directly to the Verifier. The Verifier will evaluate the
Evidence and then sign an Attestation Result. This Attestation
Result is returned to the Attester, and it is up to the Attester to
communicate the Attestation Result (potentially including the
Evidence, if disclosable) to the Relying Party.
Birkholz, et al. Expires May 7, 2020 [Page 7]
Internet-Draft RATS Arch & Terms November 2019
************
* Asserter *
************
|Known-Good-Values
|Endorsements
|
v
.---------------.
| Verifier |
| |
| |
'------------|--'
^ |
| |Attestation Results
Evidence | |(Claims)
| |
| |
| v
.---|-----------. .---------------.
| Attester | | Relying Party |
| ----------------------> |
| | Attestation Results | |
'---------------' (Claims) '---------------'
Figure 2: RATS Passport Flow
This flow is named in this way because of the resemblance of how
Nations issue Passports to their citizens. The nature of the
Evidence that an individual needs to provide to it's local authority
is specific to the country involved. The citizen retains control of
the resulting document and presents it to other entities when it
needs to assert a citizenship or identity claim.
1.6.2. Background Check
In the Background-Check message flow the Attester provides it's
Evidence to the Relying Party. The Relying Party sends this evidence
to a Verifier of its choice. The Verifier will evaluate the Evidence
and then sign an Attestation Result. This Attestation Result is
returned to the Relying Party, which processes it directly.
Birkholz, et al. Expires May 7, 2020 [Page 8]
Internet-Draft RATS Arch & Terms November 2019
************
* Asserter *
************
|Known-Good-Values
|Endorsements
|
v
.---------------.
| Verifier |
| |
| |
'--^---------|--'
| |
| |Attestation Results
Evidence | |(Claims)
| |
| v
.---------------. .--|------------.
| Attester | Evidence | Relying Party |
| ----------------------> |
| | | |
'---------------' '---------------'
Figure 3: RATS Background Check Flow
This flow is named in this way because of the resemblance of how
employers and volunteer organizations perform background checks.
When a prospective employee provides claims about education or
previous experience, the employer will contact the respective
institutions or former employers to validate the claim. Volunteer
organizations often perform police background checks on volunteers in
order to determine the volunteer's trustworthiness.
2. Terminology
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.
Appraisal: A Verifier process that compares Evidence to Reference
values while taking into account Endorsements and produces
Attestation Results.
Asserter: See Section 5.3.1.2.
Attester: See Section 5.3.1.1.
Birkholz, et al. Expires May 7, 2020 [Page 9]
Internet-Draft RATS Arch & Terms November 2019
Attested Environment: A target environment that is observed or
controlled by an Attesting Environment.
Attesting Environment: An environment capable of making
trustworthiness Claims about an Attested Environment.
Background-Check Message Flow: An attestation workflow where the
Attester provides Evidence to a Relying Party, who consults one or
more Verifiers who supply Attestation Results to the Relying
Party. See Section 1.6.2.
Claim: A statement about the construction, composition, validation
or behavior of an Entity that affects trustworthiness. Evidence,
Reference Values and Attestation Results are expressions that
consists of one or more Claims.
Conveyance: The process of transferring Evidence, Reference Values
and Attestation Results between Entities participating in
attestation workflow.
Entity: A device, component (see System Component [RFC4949]), or
environment that implements one or more Roles.
Evidence: See Section 5.3.2.1.
Passport Message Flow: An attestation workflow where the Attester
provides Evidence to a Verifier who returns Attestation Results
that are then forwarded to one or more Relying Parties. See
Section 1.6.1.
Reference Values: See Section 5.3.2.2. Also referred to as Known-
Good-Values.
Relying Party: See Section 5.3.1.4.
Attestation Results: See Section 5.3.2.3.
Role: A function or process in an attestation workflow, typically
described by: Attester, Verifier, Relying Party and Asserter.
Verifier: See Section 5.3.1.3.
3. Reference use cases
This section provides an overview of a number of distinct use cases
that benefit from a standardized claim format. In addition to
outlining the user, the specific message flow is identified from
among the flows detailed in Section 1.6.
Birkholz, et al. Expires May 7, 2020 [Page 10]
Internet-Draft RATS Arch & Terms November 2019
3.1. Device Capabilities/Firmware Attestation
This is a large category of claims that includes a number of
subcategories, not detailed here.
Use case name: Device Identity
Who will use it: Network Operators, larger enterprises
Attester: varies
Message Flow: sometimes passport and sometimes background check
Relying Party: varies
Description: Network operators want a trustworth report of identity
and version of information of the hardware and software on the
machines attached to their network. The process starts with some
kind of Root of Trust that provides device identity and protected
storage for measurements. The mechanism performs a series of
measurements, and expresses this with an attestation as to the
hardware and firmware/software which is running.
This is a general description for which there are many specific use
cases, including [I-D.fedorkow-rats-network-device-attestation]
section 1.2, "Software Inventory"
3.2. IETF TEEP WG Use-Case
Use case name: TAM validation
Who will use it: The TAM server
Message Flow: background check
Attester: Trusted Execution Environment (TEE)
Relying Party: end-application
Description: The "Trusted Application Manager (TAM)" server wants to
verify the state of a TEE, or applications in the TEE, of a
device. The TEE attests to the TAM, which can then decide whether
to install sensitive data in the TEE, or whether the TEE is out of
compliance and the TAM needs to install updated code in the TEE to
bring it back into compliance with the TAM's policy.
Birkholz, et al. Expires May 7, 2020 [Page 11]
Internet-Draft RATS Arch & Terms November 2019
3.3. Safety Critical Systems
Use case name: Safety Critical Systems
Who will use it: Power plants and other systems that need to assert
their current state, but which can not accept any inputs from the
outside. The corollary system is a black-box (such as in an
aircraft), which needs to log the state of a system, but which can
never initiate a handshake.
Message Flow: background check
Attester: web services and other sources of status/sensor
information
Relying Party: open
Claims used as Evidence: the beginning and ending time as endorsed
by a Time Stamp Authority, represented by a time stamp token. The
real time clock of the system itself. A Root of Trust for time;
the TPM has a relative time from startup.
Description: These requirements motivate the creation of the Time-
Base Unidirectional Attestation (TUDA) [I-D.birkholz-rats-tuda],
the output of TUDA is typically a secure audit log, where
freshness is determined by synchronization to a trusted source of
external time.
The freshness is preserved in the Evidence by the use of a Time
Stamp Authority (TSA) which provides Time Stamp Tokens (TST).
3.4. Virtualized Multi-Tenant Hosts
Use case name: Multi-Tenant Hosts
Who will use it: Virtual machine systems
Message Flow: passport
Attester: virtual machine hypervisor
Relying Party: network operators
Description: The host system will do verification as per Section 3.1
The tenant virtual machines will do verification as per
Section 3.1.
Birkholz, et al. Expires May 7, 2020 [Page 12]
Internet-Draft RATS Arch & Terms November 2019
The network operator wants to know if the system _as a whole_ is
free of malware, but the network operator is not allowed to know
who the tenants are.
This is contrasted to the Chassis + Line Cards case (To Be
Defined: TBD).
Multiple Line Cards, but a small attestation system on the main
card can combine things together. This is a kind of proxy.
3.5. Cryptographic Key Attestation
Cryptographic Attestion includes subcategories such as Device Type
Attestation (the FIDO use case), and Key storage Attestation (the
Android Keystore use case), and End-User Authorization.
Use case name: Key Attestation
Who will use it: network authentication systems
Message Flow: passport
Attester: device platform
Relying Party: internet peers
Description: The relying party wants to know how secure a private
key that identifies an entity is. Unlike the network attestation,
the relying party is not part of the network infrastructure, nor
do they necessarily have a business relationship (such as
ownership) over the end device.
The Device Type Attestation is provided by a Firmware TPM
performing the Verifier function, creating Attestation Results
that indicate a particular model/type of device. In TCG terms,
this is called Implicit Attestation, in this case the Attested
Environment is the (smartphone) Rich Execution Environment (REE)
([I-D.ietf-teep-architecture] section 2), and the Attesting
Environment is within the TEE.
3.6. Geographic Evidence
Use case name: Location Evidence
Who will use it: geo-fenced systems
Message Flow: passport (probably)
Birkholz, et al. Expires May 7, 2020 [Page 13]
Internet-Draft RATS Arch & Terms November 2019
Attester: secure GPS system(s)
Relying Party: internet peers
Description: The relying party wants to know the physical location
(on the planet earth, using a geodetic system) of the device.
This may be provided directly by a GPS/GLONASS/BeiDou/Galileo
module that is incorporated into a TPM. This may also be provided
by collecting other proximity messages from other device that the
relying party can form a trust relationship with.
3.7. Device Provenance Attestation
Use case name: RIV - Device Provenance
Who will use it: Industrial IoT devices
Message Flow: passport
Attester: network management station
Relying Party: a network entity
Description: A newly manufactured device needs to be onboarded into
a network where many if not all device management duties are
performed by the network owner. The device owner wants to verify
the device originated from a legitimate vendor. A cryptographic
device identity such as an IEEE802.1AR is embedded during
manufacturing and a certificate identifying the device is
delivered to the owner onboarding agent. The device authenticates
using its 802.1AR IDevID to prove it originated from the expected
vendor.
The device chain of custody from the original device manufacturer to
the new owner may also be verified as part of device provenance
attestation. The chain of custody history may be collected by a
cloud service or similar capability that the supply chain and owner
agree to use.
[I-D.fedorkow-rats-network-device-attestation] section 1.2 refers to
this as "Provable Device Identity", and section 2.3 details the
parties.
4. Conceptual Overview
In network protocol exchanges, it is often the case that one entity
(a Relying Party) requires an assessment of the trustworthiness of a
remote entity (an Attester or specific system components [RFC4949]
Birkholz, et al. Expires May 7, 2020 [Page 14]
Internet-Draft RATS Arch & Terms November 2019
thereof). Remote ATtestation procedureS (RATS) enable Relying
Parties to establish a level of confidence in the trustworthiness of
Attesters through the
o Creation,
o Conveyance, and
o Appraisal
of attestation Evidence.
Qualities of Evidence: Evidence is composed of Claims about
trustworthiness (the set of Claims is unbounded). The system
characteristics of Attesters - the Environments they are composed-
of, and their continuous development - have an impact on the
veracity of trustworthiness Claims included in valid Evidence.
Valid Evidence about the intactness of an Attester must be
impossible to create by an untrustworthy or compromised
Environment of an Attester.
Qualities of Environments: The resilience of Environments that are
part of an Attester 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.
When a trustworthy Environment changes, it is possible that it
transitions from being trustworthy to being untrustworthy.
An untrustworthy or compromised Environment must never be able to
create valid Evidence expressing the intactness of an Attester.
The architecture provides a framework for anticipating when a
relevant change with respect to a trustworthiness attribute occurs,
what exactly changed and how relevant it is. The architecture also
creates a context for enabling an appropriate response by
applications, system software and protocol endpoints when changes to
trustworthiness attributes do occur.
Detailed protocol specifications for message flows are defined in
separate documents.
4.1. Two Types of Environments
An Attester produces Evidence about its own integrity, which means
"it measures itself". To disambiguate this recursive or circular
Birkholz, et al. Expires May 7, 2020 [Page 15]
Internet-Draft RATS Arch & Terms November 2019
looking relationships, two types of Environments inside an Attester
are distinguished:
The attest-ED Environments and the attest-ING Environments.
Attested Environments are measured. They provide the raw values and
the information to be represented in Claims and ultimately expressed
as Evidence.
Attesting Environments conduct the measuring. They collect the
Claims, format them appropriately, and typically use key material and
cryptographic functions, such as signing or cipher algorithms, to
create Evidence.
Attesting Environments use system components that have to be trusted.
As a result, Evidence includes Claims about the Attested and the
Attesting Environments. Claims about the Attested Environments are
appraised using Reference Values and Claims about the Attesting
Environments are appraised using Endorsements. It is not mandated
that both Environments have to be separate, but it is highly
encouraged. Examples of separated Environments that can be used as
Attesting Environments include: Trusted Execution Environments (TEE),
embedded Secure Elements (eSE), or Hardware Security Modules (HSM).
In summary, the majority of the creation of evidence can take place
in an Attested Environments. Exemplary duties include the collection
and formatting of Claim values, or the trigger for creating Evidence.
A trusted sub-set of the creation of evidence can take place in an
Attesting Environment, that provide special protection with respect
to key material, identity documents, or primitive functions to create
the Evidence itself.
4.2. Evidence Creation Prerequisites
One or more Environments that are part of an Attester must be able to
conduct the following duties in order to create Evidence:
o monitoring trustworthiness attributes of other Environments,
o collecting trustworthiness attributes and create Claims about
them,
o serialize Claims using interoperable representations,
o provide integrity protection for the sets of Claims, and
o add appropriate attestation provenance attributes about the sets
of Claims.
Birkholz, et al. Expires May 7, 2020 [Page 16]
Internet-Draft RATS Arch & Terms November 2019
4.3. Trustworthiness
The trustworthiness of an Attester and therefore the believability of
the Evidence it creates relies on the protection methods in place to
shield and restrict the use of key material and the duties conducted
by the Attesting Environment. In order to assess trustworthiness
effectively, it is mandatory to understand the trustworthiness
properties of the environments of an Attester. The corresponding
appraisal of Evidence that leads to such an assessment of
trustworthiness is the duty of a Verifier.
Trusting the assessment of a Verifier might com frome trusting the
Verifier's key material (direct trust), or trusting an Entity that
the Verifier is associated with via a certification path (indirect
trust).
The trustworthiness of corresponding Attestation Results also relies
on trust towards manufacturers and those manufacturer's hardware in
order to assess the integrity and resilience of that manufacturer's
devices.
A stronger level of security comes when information can be vouched
for by hardware or by (unchangeable) firmware, especially if such
hardware is physically resistant to hardware tampering. The
component that is implicitly trusted is often referred to as a Root
of Trust.
4.4. Workflow
The basic function of RATS is creation, conveyance and appraisal of
attestation Evidence. An Attester creates attestation Evidence that
are conveyed to a Verifier for appraisal. The appraisals compare
Evidence with expected Known-Good-Values obtained from Asserters
(e.g. Principals that are Supply Chain Entities). There can be
multiple forms of appraisal (e.g., software integrity verification,
device composition and configuration verification, device identity
and provenance verification). Attestation Results are the output of
appraisals. Attestation Results are signed and conveyed to Relying
Parties. Attestation Results provide the basis by which the Relying
Party may determine a level of confidence to place in the application
data or operations that follow.
The architecture defines attestation Roles: Attester, Verifier,
Asserter and Relying Party. Roles exchange messages, but their
structure is not defined in this document. The detailed definition
of the messages is in an appropriate document, such as
[I-D.ietf-rats-eat] or other protocols to be defined. Roles can be
combined in various ways into Principals, depending upon the needs of
Birkholz, et al. Expires May 7, 2020 [Page 17]
Internet-Draft RATS Arch & Terms November 2019
the use case. Information Model representations are realized as data
structure and conveyance protocol specifications.
4.5. Interoperability between RATS
The RATS architecture anticipates use of information modeling
techniques that describe computing structures - their components/
computational elements and corresponding capabilities - so that
verification operations may rely on the information model as an
interoperable way to navigate the structural complexity.
5. RATS Architecture
5.1. Goals
RATS architecture has the following goals:
o Enable semantic interoperability of attestation semantics through
information models about computing environments and
trustworthiness.
o Enable data structure interoperability related to claims, endpoint
composition / structure, and end-to-end integrity and
confidentiality protection mechanisms.
o Enable programmatic assessment of trustworthiness. (Note:
Mechanisms that manage risk, justify a level of confidence, or
determine a consequence of an attestation result are out of
scope).
o Provide the building blocks, including Roles and Principals that
enable the composition of service-chains/hierarchies and workflows
that can create and appraise evidence about the trustworthiness of
devices and services.
o Use-case driven architecture and design (see
[I-D.richardson-rats-usecases] and Section 3)
o Terminology conventions that are consistently applied across RATS
specifications.
o Reinforce trusted computing principles that include attestation.
5.2. Attestation Principles
Specifications developed by the RATS working group apply the
following principles:
Birkholz, et al. Expires May 7, 2020 [Page 18]
Internet-Draft RATS Arch & Terms November 2019
o Freshness - replay of previously asserted Claims about an Attested
Environment can be detected.
o Identity - the Attesting Environment is identifiable (non-
anonymous).
o Context - the Attested Environment is well-defined (unambiguous).
o Provenance - the origin of Claims with respect to the Attested and
Attesting Environments are known.
o Validity - the expected lifetime of Claims about an Attested
Environment is known.
o Veracity - the believability (level of confidence) of Claims is
based on verifiable proofs.
5.3. Attestation Workflow
Attestation workflow helps a Relying Party make better decisions by
providing insight about the trustworthiness of endpoints
participating in a distributed system. The workflow consists
primarily of four roles; Relying Party, Verifier, Attester and
Asserter. Attestation messages contain information useful for
appraising the trustworthiness of an Attester endpoint and informing
the Relying Party of the appraisal result.
This section details the primary roles of an attestation workflow and
the messages they exchange.
5.3.1. Roles
An endpoint system (a.k.a., Entity) may implement one or more
attestation Roles to accommodate a variety of possible message flows.
Exemplary message flows are described in Section 1.6.1 and
Section 1.6.2. Role messages are secured by the Entity that
generated it. Entities possess credentials (e.g., cryptographic
keys) that authenticate, integrity protect and optionally
confidentiality protect attestation messages.
5.3.1.1. Attester
The Attester consists of both an Attesting Environment and an
Attested Environment. In some implementations these environments may
be combined. Other implementations may have multiples of Attesting
and Attested environments. Although endpoint environments can be
complex, and that complexity is security relevant, the basic function
Birkholz, et al. Expires May 7, 2020 [Page 19]
Internet-Draft RATS Arch & Terms November 2019
of an Attester is to create Evidence that captures operational
conditions affecting trustworthiness.
5.3.1.2. Asserter
The Asserter role is out of scope. The mechanism by which an
Asserter communicates Known-Good-Values to a Verifier is also not
subject to standardization. Users of the RATS architecture are
assumed to have pre-existing mechanisms.
5.3.1.3. Verifier
The Verifier workflow function accepts Evidence from an Attester and
accepts Reference Values from one or more Asserters. Reference
values may be supplied a priori, cached or used to created policies.
The Verifier performs an appraisal by matching Claims found in
Evidence with Claims found in Reference Values and policies. If an
attested Claim value differs from an expected Claim value, the
Verifier flags this as a change possibly impacting trust level.
Endorsements may not have corresponding Claims in Evidence (because
of their intrinsic nature). Consequently, the Verifier need only
authenticate the endpoint and verify the Endorsements match the
endpoint identity.
The result of appraisals and Endorsements, informed by owner
policies, produces a new set of Claims that a Relying Party is suited
to consume.
5.3.1.4. Relying Party
A Role in an attestation workflow that accepts Attestation Results
from a Verifier that may be used by the Relying Party to inform
application specific decision making. How Attestation Results are
used to inform decision making is out-of-scope for this architecture.
5.3.2. Role Messages
5.3.2.1. Evidence
Claims that are formatted and protected by an Attester.
Evidence SHOULD satisfy Verifier expectations for freshness,
identity, context, provenance, validity, and veracity.
Birkholz, et al. Expires May 7, 2020 [Page 20]
Internet-Draft RATS Arch & Terms November 2019
5.3.2.2. Reference Values
Reference-values are Claims that a manufacturer, vendor or other
supply chain entity makes that affects the trustworthiness of an
Attester endpoint.
Claims may be persistent properties of the endpoint due to the
physical nature of how it was manufactured or may reflect the
processes that were followed as part of moving the endpoint through a
supply-chain; e.g., validation or compliance testing. This class of
Reference-values is known as Endorsements.
Another class of Reference-values identifies the firmware and
software that could be installed in the endpoint after its
manufacture. A digest of the the firmware or software can be an
effective identifier for keeping track of the images produced by
vendors and installed on an endpoint. This class of Reference-value
is referred to as Known-Good-Value (KGV).
Known-Good-Values: Claims about the Attested Environment.
Typically, Known-Good-Value (KGV) Claims are message digests of
firmware, software or configuration data supplied by various
vendors. If an Attesting Environment implements cryptography,
they include Claims about key material.
Like Claims, Known-Good-Values SHOULD satisfy a Verifier's
expectations for freshness, identity, context, provenance,
validity, relevance and veracity. Known-Good-Values are reference
Claims that are - like Evidence - well formatted and protected
(e.g. signed).
Endorsements: Claims about immutable and implicit characteristics of
the Attesting Environment. Typically, endorsement Claims are
created by manufacturing or supply chain entities.
Endorsements are intended to increase the level of confidence with
respect to Evidence created by an Attester.
5.3.2.3. Attestation Results
Statements about the output of an appraisal of Evidence that are
created, formatted and protected by a Verifier.
Attestation Results provide the basis for a Relying Party to
establish a level of confidence in the trustworthiness of an
Attester. Attestation Results SHOULD satisfy Relying Party
expectations for freshness, identity, context, provenance, validity,
relevance and veracity.
Birkholz, et al. Expires May 7, 2020 [Page 21]
Internet-Draft RATS Arch & Terms November 2019
5.4. Principals (Entities?) - Containers for the Roles
[The authors are unhappy with the term Principal, and have been
looking for something else. JOSE/JWT uses the term Principal]
Principals are Containers for the Roles.
Principals are users, organizations, devices and computing
environments (e.g., devices, platforms, services, peripherals).
Principals may implement one or more Roles. Massage flows occurring
within the same Principal are out-of-scope.
The methods whereby Principals may be identified, discovered,
authenticated, connected and trusted, though important, are out-of-
scope.
Principal operations that apply resiliency, scaling, load balancing
or replication are generally believed to be out-of-scope.
+------------------+ +------------------+
| Principal 1 | | Principal 2 |
| +------------+ | | +------------+ |
| | | | | | | |
| | Role A |<-|---|->| Role D | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| +-----+------+ | | +-----+------+ |
| | | | | | | |
| | Role B |<-|---|->| Role E | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
+------------------+ +------------------+
Figure 4: Principals-Role Composition
Principals have the following properties:
o Multiplicity - Multiple instances of Principals that possess the
same Roles can exist.
o Composition - Principals possessing different Roles can be
combined into a singleton Principal possessing the union of Roles.
Message flows between combined Principals is uninteresting.
Birkholz, et al. Expires May 7, 2020 [Page 22]
Internet-Draft RATS Arch & Terms November 2019
o Decomposition - A singleton Principal possessing multiple Roles
can be divided into multiple Principals.
6. Privacy Considerations
The conveyance of Evidence and the resulting Attestation Results
reveal a great deal of information about the internal state of a
device. In many cases the whole point of the Attestation process is
to provided reliable evidence about the type of the device and the
firmware that the device is running. This information is
particularly interesting to many attackers: knowing that a device is
running a weak version of a the firmware provides a way to aim
attacks better.
Just knowing the existence of a device is itself a disclosure.
Conveyance protocols must detail what kinds of information is
disclosed, and to whom it is exposed.
7. Security Considerations
Evidence, Verifiable Assertions and Attestation Results SHOULD use
formats that support end-to-end integrity protection and MAY support
end-to-end confidentiality protection.
Replay attacks are a concern that protocol implementations MUST deal
with. This is typically done via a Nonce Claim, but the details
belong to the protocol.
All other attacks involving RATS structures are not explicitly
addressed by the architecture.
Additional security protections MAY be required of conveyance
mechanisms. For example, additional means of authentication,
confidentiality, integrity, replay, denial of service and privacy
protection of RATS payloads and Principals may be needed.
8. Acknowledgements
Dave Thaler created the concepts of "Passport" and "Background
Check".
9. References
Birkholz, et al. Expires May 7, 2020 [Page 23]
Internet-Draft RATS Arch & Terms November 2019
9.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>.
9.2. Informative References
[ABLP] Abadi, M., Burrows, M., Lampson, B., and 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.
[fido] FIDO Alliance, ., "FIDO Specification Overview", 2019,
<https://fidoalliance.org/specifications/>.
[I-D.birkholz-rats-tuda]
Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
"Time-Based Uni-Directional Attestation", draft-birkholz-
rats-tuda-01 (work in progress), September 2019.
[I-D.fedorkow-rats-network-device-attestation]
Fedorkow, G. and J. Fitzgerald-McKay, "Network Device
Attestation Workflow", draft-fedorkow-rats-network-device-
attestation-00 (work in progress), July 2019.
[I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Ballesteros, M., and J.
O'Donoghue, "The Entity Attestation Token (EAT)", draft-
ietf-rats-eat-01 (work in progress), July 2019.
[I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D.
Liu, "Trusted Execution Environment Provisioning (TEEP)
Architecture", draft-ietf-teep-architecture-03 (work in
progress), July 2019.
Birkholz, et al. Expires May 7, 2020 [Page 24]
Internet-Draft RATS Arch & Terms November 2019
[I-D.richardson-rats-usecases]
Richardson, M., Wallace, C., and W. Pan, "Use cases for
Remote Attestation common encodings", draft-richardson-
rats-usecases-05 (work in progress), October 2019.
[iothreats]
GDN, ., "The Internet of Things or the Internet of
threats?", 2016, <https://gcn.com/articles/2016/05/03/
internet-of-threats.aspx>.
[keystore]
Google, ., "Android Keystore System", 2019,
<https://developer.android.com/training/articles/
keystore>.
[Lampson2007]
Lampson, B., "Practical Principles for Computer Security",
IOSPress Proceedings of Software System Reliability and
Security, page 151-195, DOI 10.1.1.63.5360, 2007.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security 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>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<https://www.rfc-editor.org/info/rfc5209>.
Authors' Addresses
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
Darmstadt 64295
Germany
Email: henk.birkholz@sit.fraunhofer.de
Birkholz, et al. Expires May 7, 2020 [Page 25]
Internet-Draft RATS Arch & Terms November 2019
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
Michael Richardson
Sandelman Software Works
Canada
Email: mcr+ietf@sandelman.ca
Birkholz, et al. Expires May 7, 2020 [Page 26]