Internet DRAFT - draft-birkholz-rats-suit-claims

draft-birkholz-rats-suit-claims







RATS                                                         H. Birkholz
Internet-Draft                                            Fraunhofer SIT
Intended status: Standards Track                                B. Moran
Expires: 16 July 2022                                        Arm Limited
                                                         12 January 2022


 Trustworthiness Vectors for the Software Updates of Internet of Things
                         (SUIT) Workflow Model
                   draft-birkholz-rats-suit-claims-03

Abstract

   The IETF Remote Attestation Procedures (RATS) architecture defines
   Conceptual Messages as input and output of the appraisal process that
   assesses the trustworthiness of remote peers: Evidence and
   Attestation Results.  Based on the Trustworthiness Vectors defined in
   Trusted Path Routing, this document defines a core set of Claims to
   be used in Evidence and Attestation Results for the Software Update
   for the Internet of Things (SUIT) Workflow Model.  Consecutively,
   this document is in support of the Trusted Execution Environment
   Provisioning (TEEP) architecture, which defines the assessment of
   remote peers via RATS and uses SUIT for evidence generation as well
   as a remediation measure to improve trustworthiness of given remote
   peers.

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 16 July 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Birkholz & Moran          Expires 16 July 2022                  [Page 1]

Internet-Draft                   SUIT TV                    January 2022


   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
     1.1.  SUIT Workflow Model and Procedures  . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Trustworthiness Vectors . . . . . . . . . . . . . . . . . . .   4
   3.  SUIT Claims . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  System Properties Claims  . . . . . . . . . . . . . . . .   5
       3.1.1.  vendor-identifier . . . . . . . . . . . . . . . . . .   6
       3.1.2.  class-identifier  . . . . . . . . . . . . . . . . . .   6
       3.1.3.  device-identifier . . . . . . . . . . . . . . . . . .   6
       3.1.4.  image-digest  . . . . . . . . . . . . . . . . . . . .   6
       3.1.5.  image-size  . . . . . . . . . . . . . . . . . . . . .   6
       3.1.6.  version . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Interpreter Record Claims . . . . . . . . . . . . . . . .   7
       3.2.1.  record-success  . . . . . . . . . . . . . . . . . . .   7
       3.2.2.  component-index . . . . . . . . . . . . . . . . . . .   7
       3.2.3.  dependency-index  . . . . . . . . . . . . . . . . . .   7
       3.2.4.  command-index . . . . . . . . . . . . . . . . . . . .   7
       3.2.5.  nominal-parameters  . . . . . . . . . . . . . . . . .   7
     3.3.  Generic Record Conditions (TBD) . . . . . . . . . . . . .   7
   4.  List of Commands (TBD)  . . . . . . . . . . . . . . . . . . .   8
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Attestation Results are an essential output of Verifiers as defined
   in the Remote ATtestation procedureS (RATS) architecture
   [I-D.ietf-rats-architecture].  They are consumed by Relying Parties:
   the entities that intend to build future decisions on trustworthiness
   assessments of remote peers.  Attestation Results must be easily
   appraised by Relying Parties -- in contrast to the rather complex or
   domain-specific Evidence appraised by Verifiers.






Birkholz & Moran          Expires 16 July 2022                  [Page 2]

Internet-Draft                   SUIT TV                    January 2022


   In order to create Attestation Results, a Verifier must consume
   Evidence generated by a given Attester (amongst other Conceptual
   Messages, such as Endorsements and Attestation Policies).  Both
   Evidence and Attestation Results are composed of Claims.  This
   document highlights and defines a set of Claims to be used in
   Evidence and Attestation Results that are based on the SUIT Workflow
   Model [I-D.ietf-suit-manifest].  In the scope of this document, an
   Attester takes on the role of a SUIT Recipient: the system that
   receives a SUIT Manifest.

1.1.  SUIT Workflow Model and Procedures

   This document focuses on Evidence and Attestation Results that can be
   generated based on the output of SUIT Procedures.  The SUIT Workflow
   Model allows for two types of SUIT Procedures generating Reports on
   the Attester as defined in the SUIT Manifest specification
   [I-D.ietf-suit-manifest]:

   Update Procedures:  A procedure that updates a device by fetching
      dependencies, software images, and installing them.

      An Update Procedure creates a Report about mutable software
      components that are installed or updated on hardware components.

   Boot Procedures:  A procedure that boots a device by checking
      dependencies and images, loading images, and invoking one or more
      image.

      A Boot Procedure creates a Report on measured boot events (e.g.
      during Secure Boot).

   The Records contained in each type of Report can be used as Claims in
   Evidence generation on the Attester for Remote Attestation Procedures
   as described in this document.  Analogously, a corresponding Verifier
   appraising that Evidence can generate Attestation Results using the
   Claims defined in this document.

   Both types of SUIT Procedures pass several stages (e.g. dependency-
   checking is one stage).  The type and sequence of stages are defined
   by the Command Sequences included in a SUIT Manifest.  For each stage
   in which a Command from the Command Sequence is executed a Record is
   created.  All Records of a SUIT procedure contain binary results
   limited to "fail" or "pass".  The aggregated sequence of all Records
   is composed into a Report.







Birkholz & Moran          Expires 16 July 2022                  [Page 3]

Internet-Draft                   SUIT TV                    January 2022


   This document specifies new Claims derived from Command Sequence
   Reports and relates them to Claims defined in Attestation Results for
   Secure Interactions [I-D.ietf-rats-ar4si] -- if applicable to the
   operational state of installed and updated software.

   The Claims defined in this document are in support of the Trusted
   Execution Environment Provisioning (TEEP) architecture.  During TEEP,
   the current operational state of an Attester is assessed via RATS.
   If the corresponding Attestation Results -- as covered in this
   document -- indicate insufficient Trustworthiness Tiers in a
   Trustworthiness Vector with respect to installed software, the SUIT
   Workflow Model is used for remediation.

1.2.  Terminology

   This document uses the terms and concepts defined in
   [I-D.ietf-rats-architecture], [I-D.ietf-suit-manifest], and
   [I-D.ietf-teep-architecture].

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

2.  Trustworthiness Vectors

   While there are usage scenarios where Attestation Results can be
   binary decisions, more often than not the assessment of
   trustworthiness is represented by a more fine-grained spectrum or
   based on multiple factors.  These shades of Attestation Results are
   captured by the definition of Trustworthiness Vectors in Attestation
   Results for Secure Interaction [I-D.ietf-rats-ar4si].
   Trustworthiness Vectors are sets of Trustworthiness Claims
   representing appraisal outputs produced by a Verifier (Attestation
   Results).  Each of these Trustworthiness Claims has a Trustworthiness
   Tier ranging from Affirmed to None.

   An Attester processing SUIT Manifests can manages three types of
   information about it's Target Environments:

   *  installed manifests including initial state (e.g. factory
      default),

   *  hardware component identifiers that represent identifiable targets
      of updates, and





Birkholz & Moran          Expires 16 July 2022                  [Page 4]

Internet-Draft                   SUIT TV                    January 2022


   *  SUIT Interpreter results (e.g. test-failed) generated during
      updates.

   Every SUIT Manifest maps to a certain intended state of a device.
   Every intended device composition of software components associated
   with hardware components can therefore be expressed based on a SUIT
   Manifest.  The current operational state of a device can be
   represented in the same form, including the initial state.

   As a result, the Claims defined in this document are bundled by the
   scope of the information represented in SUIT Manifests, i.e.,
   dedicated blobs of software that are the payload of a SUIT Manifest.
   All Claims associated with an identifiable SUIT Manifest MUST always
   be bundled together in a Claims set that is limited to the Claims
   defined in this document.

3.  SUIT Claims

   The Claim description in this document uses CDDL as the formal
   modeling language for Claims.  This approach is aligned with
   [I-D.ietf-rats-eat].  All Claims are based on information elements as
   used in the SUIT Manifest specification [I-D.ietf-suit-manifest].
   For instance, a SUIT Class ID is represented as an UUID.
   Analogously, the corresponding class-identifier Claim found below is
   based on a UUID.  SUIT Claims are differentiated in:

   *  software and hardware characteristics (System Properties), and

   *  reports about updates and their SUIT Commands (SUIT Records).

   *  success/failure reports

   Each type of Claims is always bundled in a dedicated Claim Set.
   Implementations can encode this information in various different ways
   (data models), e.g., sets, sequences, or nested structures.

   The SUIT Report is defined in [I-D.ietf-suit-report].  It is used
   verbatim in this draft.  The following subsections define the SUIT
   Report Claims for RATS.

3.1.  System Properties Claims

   System Properties Claims are composed of:

   *  Hardware Component Claims and

   *  Software Component Claims.




Birkholz & Moran          Expires 16 July 2022                  [Page 5]

Internet-Draft                   SUIT TV                    January 2022


   Correspondingly, the Claim definitions below highlight if a Claim is
   generic or hw/sw-component specific.

3.1.1.  vendor-identifier

   A RFC 4122 UUID representing the vendor of the Attester or one of its
   hardware and/or software components.

   $$system-property-claim //= (vendor-identifier =>
       (RFC4122_UUID / cbor-pen))
   cbor-pen = #6.112(bstr)

3.1.2.  class-identifier

   A RFC 4122 UUID representing the class of the Attester or one of its
   hardware and/or software components.

   $$system-property-claim //= ( class-identifier => RFC4122_UUID )

3.1.3.  device-identifier

   A RFC 4122 UUID representing the Attester.

   $$system-property-claim //= ( device-identifier => RFC4122_UUID )

3.1.4.  image-digest

   A fingerprint computed over a software component image on the
   Attester.  This Claim is always bundled with a component-identifier
   or component-index.

   $$system-property-claim //= ( image-digest => digest )

3.1.5.  image-size

   The size of a firmware image on the Attester.

   $$system-property-claim //= ( image-size => size )

3.1.6.  version

   The Version of a hardware or software component of the Attester.

   $$system-property-claim //= ( version => version-value )







Birkholz & Moran          Expires 16 July 2022                  [Page 6]

Internet-Draft                   SUIT TV                    January 2022


3.2.  Interpreter Record Claims

   This class of Claims represents the content of SUIT Records generated
   by Interpreters running on Recipients.  They are always bundled into
   Claim Sets representing SUIT Reports and are intended to be included
   in Evidence generated by an Attester.  The Interpreter Record Claims
   appraised by a Verifier can steer a corresponding a Firmware
   Appraisal procedures that consumes this Evidence.  Analogously, these
   Claims can be re-used in generated Attestation Results as
   Trustworthiness Vectors [I-D.ietf-rats-ar4si].

3.2.1.  record-success

   The result of a Command that was executed by the Interpreter on an
   Attester.

   $$interpreter-record-claim //= ( record-success => bool )

3.2.2.  component-index

   A positive integer representing an entry in a flat list of indices
   mapped to software component identifiers to be updated.

   $$system-property-claim //= ( component-index => uint )

3.2.3.  dependency-index

   A thumbprint of a software component that an update depends on.

   $$interpreter-record-claim //= ( dependency-index => digest )

3.2.4.  command-index

   A positive integer representing an entry in a SUIT_Command_Sequence
   identifying a Command encoded as a SUIT Manifest Directive or SUIT
   Manifest Condition.

   $$interpreter-record-claim //= ( command-index => uint )

3.2.5.  nominal-parameters

   A list of SUIT_Parameters associated with a specific Command that was
   executed by the Interpreter on an Attester.

   $$interpreter-record-claim //= ( actual-parameters => parameter-list )

3.3.  Generic Record Conditions (TBD)




Birkholz & Moran          Expires 16 July 2022                  [Page 7]

Internet-Draft                   SUIT TV                    January 2022


   *  test-failed

   *  unsupported-command

   *  unsupported-parameter

   *  unsupported-component-id

   *  payload-unavailable

   *  dependency-unavailable

   *  critical-application-failure

   *  watchdog-timeout

4.  List of Commands (TBD)

   *  Check Vendor Identifier

   *  Check Class Identifier

   *  Verify Image

   *  Set Component Index

   *  Override Parameters

   *  Set Dependency Index

   *  Set Parameters

   *  Process Dependency

   *  Run

   *  Fetch

   *  Use Before

   *  Check Component Offset

   *  Check Device Identifier

   *  Check Image Not Match

   *  Check Minimum Battery




Birkholz & Moran          Expires 16 July 2022                  [Page 8]

Internet-Draft                   SUIT TV                    January 2022


   *  Check Update Authorized

   *  Check Version

   *  Abort

   *  Try Each

   *  Copy

   *  Swap

   *  Wait For Event

   *  Run Sequence

   *  Run with Arguments

5.  References

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

5.2.  Informative References

   [I-D.ietf-rats-ar4si]
              Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
              Scarlata, "Attestation Results for Secure Interactions",
              Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
              01, 2 December 2021, <https://www.ietf.org/archive/id/
              draft-ietf-rats-ar4si-01.txt>.

   [I-D.ietf-rats-architecture]
              Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote Attestation Procedures Architecture", Work
              in Progress, Internet-Draft, draft-ietf-rats-architecture-
              14, 9 December 2021, <https://www.ietf.org/archive/id/
              draft-ietf-rats-architecture-14.txt>.





Birkholz & Moran          Expires 16 July 2022                  [Page 9]

Internet-Draft                   SUIT TV                    January 2022


   [I-D.ietf-rats-eat]
              Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity
              Attestation Token (EAT)", Work in Progress, Internet-
              Draft, draft-ietf-rats-eat-11, 24 October 2021,
              <https://www.ietf.org/archive/id/draft-ietf-rats-eat-
              11.txt>.

   [I-D.ietf-sacm-coswid]
              Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
              Waltermire, "Concise Software Identification Tags", Work
              in Progress, Internet-Draft, draft-ietf-sacm-coswid-19, 20
              October 2021, <https://www.ietf.org/archive/id/draft-ietf-
              sacm-coswid-19.txt>.

   [I-D.ietf-suit-manifest]
              Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,
              "A Concise Binary Object Representation (CBOR)-based
              Serialization Format for the Software Updates for Internet
              of Things (SUIT) Manifest", Work in Progress, Internet-
              Draft, draft-ietf-suit-manifest-16, 25 October 2021,
              <https://www.ietf.org/archive/id/draft-ietf-suit-manifest-
              16.txt>.

   [I-D.ietf-suit-report]
              Moran, B., "Secure Reporting of Update Status", Work in
              Progress, Internet-Draft, draft-ietf-suit-report-00, 12
              July 2021, <https://www.ietf.org/archive/id/draft-ietf-
              suit-report-00.txt>.

   [I-D.ietf-teep-architecture]
              Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
              "Trusted Execution Environment Provisioning (TEEP)
              Architecture", Work in Progress, Internet-Draft, draft-
              ietf-teep-architecture-15, 12 July 2021,
              <https://www.ietf.org/archive/id/draft-ietf-teep-
              architecture-15.txt>.

Authors' Addresses

   Henk Birkholz
   Fraunhofer SIT

   Email: henk.birkholz@sit.fraunhofer.de


   Brendan Moran
   Arm Limited




Birkholz & Moran          Expires 16 July 2022                 [Page 10]

Internet-Draft                   SUIT TV                    January 2022


   Email: Brendan.Moran@arm.com


















































Birkholz & Moran          Expires 16 July 2022                 [Page 11]