[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-birkholz-attestation-terminology) 00 01 02 03

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/