RATS Endorsements
draft-dthaler-rats-endorsements-01

RATS Working Group                                             D. Thaler
Internet-Draft                                                 Microsoft
Intended status: Informational                               17 May 2023
Expires: 18 November 2023

                           RATS Endorsements
                   draft-dthaler-rats-endorsements-01

Abstract

   In the IETF Remote Attestation Procedures (RATS) architecture, a
   Verifier accepts Evidence and, using Appraisal Policy typically with
   additional input from Endorsements and Reference Values, generates
   Attestation Results in a format needed by a Relying Party.  This
   document explains the purpose and role of Endorsements and discusses
   some considerations in the choice of message format for Endorsements.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Remote ATtestation
   ProcedureS Working Group mailing list (rats@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/rats/.

   Source for this draft and an issue tracker can be found at
   https://github.com/dthaler/rats-endorsements.

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 18 November 2023.

Thaler                  Expires 18 November 2023                [Page 1]
Internet-Draft              RATS Endorsements                   May 2023

Copyright Notice

   Copyright (c) 2023 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 (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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Current State vs Reference States . . . . . . . . . . . . . .   3
     2.1.  RATS Conceptual Messages  . . . . . . . . . . . . . . . .   4
   3.  Endorsement Format Considerations . . . . . . . . . . . . . .   5
     3.1.  Security Considerations . . . . . . . . . . . . . . . . .   5
     3.2.  Scalability Considerations  . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Section 3 in the RATS Architecture [RFC9334] gives an overview of the
   roles and conceptual messages in the IETF Remote Attestation
   Architecture.  As discussed in that document, a Verifier accepts
   Evidence and Endorsements, and appraises them using Appraisal Policy
   for Evidence, typically against a set of Reference Values.

   Various formats exist, including standard and vendor-specific
   formats, for the conceptual messages shown.  Indeed, one of the
   purposes of a Verifer as depicted in Figure 9 of [RFC9334] is to be
   able to accept Evidence in a variety of formats and generate
   Attestation Results in the format needed by a Relying Party.

Thaler                  Expires 18 November 2023                [Page 2]
Internet-Draft              RATS Endorsements                   May 2023

2.  Current State vs Reference States

   Appraisal policies (Appraisal Policy for Evidence, and Appraisal
   Policy for Attestation Results) involve comparing the current state
   of an attester against desired or undesired states, in order to
   determine how trustworthy the attester is for its purposes.  Thus, a
   Verifier needs to receive messages with information about current
   state, and information about desired/undesired states, and an
   appraisal policy that controls how the two are compared.

   Current state is a group of claims about the actual state of the
   attester at a given point in time.  Generally speaking, each claim
   has a name (or other ID) and a singleton value, being the value of
   that specific attester at a given point in time.  Some claims may
   inherently have multiple values, such as a list of files in a given
   location on the device, but for our purposes we will treat such a
   list as a single unit, meaning one attester at one point in time.

   Each attester in general has multiple components (e.g., hardware,
   firmware, Operating System, etc.), each with their own set of claims
   (sometimes called a "claimset"), where the current state of the
   attester is a group of such claimsets, for all the key components of
   the attester that are essential to determining trustworthiness.

   Reference state is a group of claims about the desired or undesired
   state of the attester.  Typically, each claim has a name (or other
   ID) and a set of potential values, being the current values that are
   allowed/disallowed when determining whether to trust the attester.
   In general there may be more gradation than simply "allowed or
   disallowed" so each value might include some more complex level of
   gradation in some implementations.

   That is, where current state has a single value per claim per
   component applying to one device at one point in time, reference
   state has a set of values per claim per component.  The appraisal
   policy then specifies how to match the current value against the set
   of reference values.

   Some examples of such matching include:

   *  The current value must be in the set of allowed reference values.

   *  The current value must not be in the set of disallowed reference
      values.

   *  The current value must be in a range where two reference values
      are the min and max.

Thaler                  Expires 18 November 2023                [Page 3]
Internet-Draft              RATS Endorsements                   May 2023

2.1.  RATS Conceptual Messages

   RATS conceptual messages in [RFC9334] fall into the above categories
   as follows:

   *  Current state: Evidence, Endorsements, Attestation Results

   *  Reference state: Reference Values

   *  Appraisal policy: Appraisal Policy for Evidence, Appraisal Policy
      for Attestation Results

   The figure below shows an example of verifier input for a layered
   attester as discussed in [RFC9334].

               / .-------------.   Appraisal    .-----------------.  \
              |  |Current state|    Policy      | Reference state |  |
              |  |  (layer N)  |                |    (layer N)    |  | R
              |  '-------------'       |        '-----------------'  | e
              |                        |                             | f
              |  .-------------.       |        .-----------------.  | e
     Evidence |  |Current state|       |        | Reference state |  | r
              |  |  (layer 2)  |       |        |    (layer 2)    |  | e
              |  '-------------'       |        '-----------------'  | n
              |                        v                             | c
              |  .-------------.  <==========>  .-----------------.  | e
              |  |Current state|   Comparison   | Reference state |  |
              |  |  (layer 1)  |     Rules      |    (layer 1)    |  | V
              \  '-------------'                '-----------------'  | a
                                                                     | l
              /  .-------------.                .-----------------.  | u
  Endorsement |  |Current state|                | Reference state |  | e
              |  |  (layer 0)  |                |    (layer 0)    |  | s
              \  '-------------'                '-----------------'  /

                     Figure 1: Example Verifier Input

   While the above example only shows one layer within Endorsements as
   the typical case, there could be multiple layers within it, such as a
   chip added to a hardware board potentially from a different vendor.

   A Trust Anchor Store is a special case of state above, where the
   Reference State would be the set of trust anchors accepted (or
   rejected) by the Verifier, and the Current State would be a trust
   anchor used to sign Evidence or Endorsements.

Thaler                  Expires 18 November 2023                [Page 4]
Internet-Draft              RATS Endorsements                   May 2023

   In layered attestation using DICE [TCG-DICE] for example, the current
   state of each layer is signed by a key held by the next lower layer.
   Thus in the example diagram above, the layer 2 current state (e.g.,
   OS state) is signed by a layer 1 key (e.g., a signing key used by the
   firmware), the layer 1 current state (e.g., firmware state) is signed
   by a layer 0 key (e.g., a hardware key stored in ROM), and the layer
   0 current state (hardware specs and key ID) is signed by a layer 0
   key (e.g., a vendor key) which is matched against the Verifier's
   trust anchor store, which is part of the layer 0 reference state
   depicted above.

3.  Endorsement Format Considerations

   This section discusses considerations around formats for
   Endorsements.

3.1.  Security Considerations

   In many scenarios, a Verifiers can also support a variety of
   different formats, and while code size may not be a huge concern,
   simplicity and correctness of code is essential to security.
   "Complexity is the enemy of security" is a popular security mantra
   and hence to increase security, any decrease in complexity helps.  As
   such, using the same format for both Evidence and Endorsements can
   reduce complexity and hence increase security.

3.2.  Scalability Considerations

   We currently assume that Reference Value Providers and Endorsers
   typically provide the same information to a potentially large number
   of clients (Verifiers, or potentially to other entities for later
   relay to a Verifier), and are generally on devices that are not
   constrained nodes, and hence additional scalability, including code
   size, is not a significant concern.

Thaler                  Expires 18 November 2023                [Page 5]
Internet-Draft              RATS Endorsements                   May 2023

   The scenario where scalability in terms of code size is strongest,
   however, is when a Verifier is embedded into a constrained node.  For
   example, when a constrained node is a Relying Party for most
   purposes, but still needs a way to establish trust in the Verifier it
   will use.  In such a case, the Relying Party may have a constrained
   Verifier embedded in it that is only capable of appraising Evidence
   provided by its desired Verifier.  Thus, the Relying Party uses its
   embedded Verifier for purposes of appraising its desired Verifier
   which it treats as only an Attester, and once verified, then uses it
   for verification of all other attesters.  In this scenario, the
   embedded Verifier may have code and data size constraints, and a very
   simple (by comparison) appraisal policy and desired state (e.g., a
   required trust anchor that Evidence must be signed with and little
   else).

   Using the same message format for Evidence, Endorsements, and (later)
   Attestation Results received from the later Verifier, can provide a
   code size savings due to having only a single parser in this limited
   case.

4.  IANA Considerations

   This document does not require any actions by IANA.

5.  References

5.1.  Normative References

   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote ATtestation procedureS (RATS)
              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
              2023, <https://www.rfc-editor.org/rfc/rfc9334>.

5.2.  Informative References

   [TCG-DICE] Trusted Computing Group, "DICE Certificate Profiles",
              n.d., <https://trustedcomputinggroup.org/wp-
              content/uploads/DICE-Certificate-Profiles-
              r01_3june2020-1.pdf>.

Author's Address

   Dave Thaler
   Microsoft
   United States of America
   Email: dthaler@microsoft.com

Thaler                  Expires 18 November 2023                [Page 6]