Internet DRAFT - draft-thaler-rats-architecture

draft-thaler-rats-architecture







Network Working Group                                          D. Thaler
Internet-Draft                                                 Microsoft
Intended status: Informational                         November 04, 2019
Expires: May 7, 2020


                    Remote Attestation Architecture
                   draft-thaler-rats-architecture-01

Abstract

   In network protocol exchanges, it is often the case that one entity
   (a relying party) requires evidence about the remote peer (and system
   components [RFC4949] thereof), in order to assess the trustworthiness
   of the peer.  This document describes an architecture for such remote
   attestation procedures (RATS), which enable relying parties to decide
   whether to consider a remote system component trustworthy or not.

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 http://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
   (http://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




Thaler                     Expires May 7, 2020                  [Page 1]

Internet-Draft       Remote Attestation Architecture       November 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Network Endpoint Assessment . . . . . . . . . . . . . . .   4
     3.2.  Confidential Machine Learning (ML) Model Protection . . .   5
     3.3.  Confidential Data Retrieval . . . . . . . . . . . . . . .   5
     3.4.  Critical Infrastructure Control . . . . . . . . . . . . .   5
     3.5.  Trusted Execution Environment (TEE) Provisioning  . . . .   6
     3.6.  Hardware Watchdog . . . . . . . . . . . . . . . . . . . .   6
   4.  Serialization Formats . . . . . . . . . . . . . . . . . . . .   7
   5.  Architectural Models  . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Passport Model  . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Background-Check Model  . . . . . . . . . . . . . . . . .   9
       5.2.1.  Variation: Verifying Relying Party  . . . . . . . . .  10
       5.2.2.  Variation: Out-of-Band Evidence Conveyance  . . . . .  10
     5.3.  Combinations  . . . . . . . . . . . . . . . . . . . . . .  11
   6.  Trust Model . . . . . . . . . . . . . . . . . . . . . . . . .  12
   7.  Conceptual Messages . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Evidence  . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.2.  Endorsements  . . . . . . . . . . . . . . . . . . . . . .  13
     7.3.  Attestation Results . . . . . . . . . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   11. Informative References  . . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   In network protocol exchanges, it is often the case that one entity
   (a relying party) requires evidence about the remote peer (and system
   components [RFC4949] thereof), in order to assess the trustworthiness
   of the peer.  Remote attestation procedures (RATS) enable relying
   parties to establish a level of confidence in the trustworthiness of
   remote system components through the creation of attestation evidence
   by remote system components and a processing chain towards the
   relying party.  A relying party can then decide whether to consider a
   remote system component trustworthy or not.

   To improve the confidence in a system component's trustworthiness, a
   relying party may require evidence about:

   -  system component identity,



Thaler                     Expires May 7, 2020                  [Page 2]

Internet-Draft       Remote Attestation Architecture       November 2019


   -  composition of system components, including nested components,

   -  roots of trust,

   -  assertion/claim origination or provenance,

   -  manufacturing origin,

   -  system component integrity,

   -  system component configuration,

   -  operational state and measurements of steps which led to the
      operational state, or

   -  other factors that could influence trust decisions.

   This document discusses an architecture for describing solutions for
   this problem.

2.  Terminology

   This document uses the following terms:

   -  Attestation: A process by which one entity (the "Attester")
      provides evidence about its identity and health to another entity,
      which then assesses its trustworthiness.

   -  Attestation Result: The evaluation results generated by a
      Verifier, typically including information about an Attester, where
      the Verifier vouches for the validity of the results.

   -  Attester: An entity whose attributes must be evaluated in order to
      determine whether the entity is considered healthy or authorized
      to access a resource.

   -  Endorsement: A secure statement that some entity (typically a
      manufacturer) vouches for the integrity of an Attester's signing
      capability.  (Note: in some discussions the entity providing an
      Endorsement has been called an Asserter, but some believe that
      term is confusing and the term Endorser would be more correct.
      For now, this document avoids using a specific term until
      consensus is reached.)

   -  Evidence: A set of information about an Attester that is to be
      evaluated by a Verifier.





Thaler                     Expires May 7, 2020                  [Page 3]

Internet-Draft       Remote Attestation Architecture       November 2019


   -  Relying Party: An entity that depends on the validity of
      information about another entity, typically for purposes of
      authorization.  Compare /relying party/ in [RFC4949].

   -  Security policy: A set of rules that direct how a system evaluates
      the validity of information about another entity.  For example,
      the security policy might involve an equality comparison against
      known-good values (called Reference Integrity Measurements in some
      contexts), or might involve more complex logic.  Compare /security
      policy/ in [RFC4949].

   -  Verifier: An entity that evaluates the validity of information
      about an Attester.

3.  Use Cases

   This section covers a number of representative use cases for
   attestation, independent of solution.  The purpose is to provide
   motivation for various aspects of the architecture presented in this
   draft.  Many other use cases exist, and this document does not intend
   to have a complete list, only to have a set of use cases that
   collectively cover all the functionality required in the
   architecture.  The use cases are covered prior to discussion of
   architectural models in Section 5, since each use case might be
   addressed via different solutions that have different architectural
   models.

   Each use case includes a description, and a summary of what an
   Attester and a Relying Party refer to in the use case.  (Since
   solutions to a use case may greatly vary in architectural model, the
   role of a Verifier is considered part of a specific solution, not a
   solution-independent property of a use case, and so is not covered in
   this section.)

3.1.  Network Endpoint Assessment

   Network operators want a trustworthy report of identity and version
   of information of the hardware and software on the machines attached
   to their network, for purposes such as inventory, auditing, and/or
   logging.  The network operator may also want a policy by which full
   access is only granted to devices that meet some definition of
   health, and so wants to get claims about such information and verify
   their validity.  Attestation is desired to prevent vulnerable or
   compromised devices from getting access to the network and
   potentially harming others.

   Typically, solutions start with some component (called a "Root of
   Trust") that provides device identity and protected storage for



Thaler                     Expires May 7, 2020                  [Page 4]

Internet-Draft       Remote Attestation Architecture       November 2019


   measurements.  They then perform a series of measurements, and
   express this with Evidence as to the hardware and firmware/software
   that is running.

   -  Attester: A device desiring access to a network

   -  Relying Party: A network infrastructure device such as a router,
      switch, or access point.

3.2.  Confidential Machine Learning (ML) Model Protection

   A device manufacturer wants to protect its intellectual property in
   terms of the ML model it developed and that runs in the devices that
   its customers purchased, and it wants to prevent attackers,
   potentially including the customer themselves, from seeing the
   details of the model.

   This typically works by having some protected environment in the
   device attest to some manufacturer service.  If attestation succeeds.
   then the manufacturer service releases either the model, or a key to
   decrypt a model the Attester already has in encrypted form, to the
   requester.

   -  Attester: A device desiring to run an ML model to do inferencing

   -  Relying Party: A server or service holding ML models it desires to
      protect

3.3.  Confidential Data Retrieval

   This is a generalization of the ML model use case above, where the
   data can be any highly confidential data, such as health data about
   customers, payroll data about employees, future business plans, etc.
   Attestation is desired to prevent leaking data to compromised
   devices.

   -  Attester: An entity desiring to retrieve confidential data

   -  Relying Party: An entity that holds confidential data for
      retrieval by other entities

3.4.  Critical Infrastructure Control

   In this use case, potentially dangerous physical equipment (e.g.,
   power grid, traffic control, hazardous chemical processing, etc.) is
   connected to a network.  The organization managing such
   infrastructure needs to ensure that only authorized code and users
   can control such processes, and they are protected from malware or



Thaler                     Expires May 7, 2020                  [Page 5]

Internet-Draft       Remote Attestation Architecture       November 2019


   other adversaries.  When a protocol operation can affect some
   critical system, the device attached to the critical equipment thus
   wants some assurance that the requester has not been compromised.  As
   such, attestation can be used to only accept commands from requesters
   that are within policy.

   -  Attester: A device or application wishing to control physical
      equipment.

   -  Relying Party: A device or application connected to potentially
      dangerous physical equipment (hazardous chemical processing,
      traffic control, power grid, etc.

3.5.  Trusted Execution Environment (TEE) Provisioning

   A "Trusted Application Manager (TAM)" server is responsible for
   managing the applications running in the TEE of a client device.  To
   do this, the TAM wants to verify the state of a TEE, or of
   applications in the TEE, of a client device.  The TEE attests to the
   TAM, which can then decide whether the TEE is already in compliance
   with the TAM's latest policy, or if the TAM needs to uninstall,
   update, or install approved applications in the TEE to bring it back
   into compliance with the TAM's policy.

   -  Attester: A device with a trusted execution environment capable of
      running trusted applications that can be updated.

   -  Relying Party: A Trusted Application Manager.

3.6.  Hardware Watchdog

   One significant problem is malware that holds a device hostage and
   does not allow it to reboot to prevent updates to be applied.  This
   is a significant problem, because it allows a fleet of devices to be
   held hostage for ransom.

   A hardware watchdog can be implemented by forcing a reboot unless
   attestation to a remote server succeeds within a periodic interval,
   and having the reboot do remediation by bringing a device into
   compliance, including installation of patches as needed.

   -  Attester: The device that is desired to keep from being held
      hostage for a long period of time.

   -  Relying Party: A remote server that will securely grant the
      Attester permission to continue operating (i.e., not reboot) for a
      period of time.




Thaler                     Expires May 7, 2020                  [Page 6]

Internet-Draft       Remote Attestation Architecture       November 2019


4.  Serialization Formats

   The following diagram illustrates a relationship to which attestation
   is desired to be added:

   +-------------+               +-------------+
   |             |-------------->|             |
   |  Attester   |  Access some  |   Relying   | Evaluate request
   |             |    resource   |    Party    | against security policy
   +-------------+               +-------------+

                     Figure 1: Typical Resource Access

   In this diagram, the protocol between Attester and a Relying Party
   can be any new or existing protocol (e.g., HTTP(S), COAP(S), 802.1x,
   OPC UA, etc.), depending on the use case.  Such protocols typically
   already have mechanisms for passing security information for purposes
   of authentication and authorization.  Common formats include JWTs
   [RFC7519], CWTs [RFC8392], and X.509 certificates.

   In many cases, it is desirable to add attestation to existing
   protocols, enabling a higher level of assurance against malware for
   example.  To enable such integration, it is important that
   information needed for evaluating the Attester be usable with
   existing protocols that have constraints around what formats they can
   transport.  For example, OPC UA [OPCUA] (probably the most common
   protocol in industrial IoT environments) is defined to carry X.509
   certificates and so security information must be embedded into an
   X.509 certificate to be passed in the protocol.  Thus, attestation-
   related information could be natively encoded in X.509 certificate
   extensions, or could be natively encoded in some other format (e.g.,
   a CWT) which in turn is then encoded in an X.509 certificate
   extension.

   Especially for constrained nodes, however, there is a desire to
   minimize the amount of parsing code needed in a Relying Party, in
   order to both minimize footprint and to minimize the attack surface
   area.  So while it would be possible to embed a CWT inside a JWT, or
   a JWT inside an X.509 extension, etc., there is a desire to encode
   the information natively in the format that is natural for the
   Relying Party.

   This motivates having a common "information model" that describes the
   set of attestation related information in an encoding-agnostic way,
   and allowing multiple serialization formats (CWT, JWT, X.509, etc.)
   that encode the same information into the format needed by the
   Relying Party.




Thaler                     Expires May 7, 2020                  [Page 7]

Internet-Draft       Remote Attestation Architecture       November 2019


5.  Architectural Models

   There are multiple possible models for communication between an
   Attester, a Verifier, and a Relying Party.

5.1.  Passport Model

   In this model, an Attester sends Evidence to a Verifier, which
   compares the Evidence against its security policy.  The Verifier then
   gives back an Attestation Result.  If the Attestation Result was a
   successful one, the Attester can then present the Attestation Result
   to a Relying Party, which then compares the Attestation Result
   against its own security policy.

   Since the resource access protocol between the Attester and Relying
   Party includes an Attestation Result, in this model the details of
   that protocol constrain the serialization format of the Attestation
   Result.  The format of the Evidence on the other hand is only
   constrained by the Attester-Verifier attestation protocol.

       +-------------+
       |             | Compare Evidence
       |   Verifier  | against security policy
       |             |
       +-------------+
            ^    |
    Evidence|    |Attestation
            |    |  Result
            |    v
       +-------------+               +-------------+
       |             |-------------->|             | Compare Attestation
       |   Attester  |  Attestation  |   Relying   | Result against
       |             |     Result    |    Party    | security policy
       +-------------+               +-------------+

                         Figure 2: Passport Model

   The passport model is so named because it resembles the process
   typically used for passports and drivers licenses, where a person
   applies and gets a passport or license that is issued by a government
   and shows information such as the person's name and birthdate.  The
   passport or license can then be supplied to other entities to gain
   entrance to an airport boarding area, or age-restricted section of a
   bar, where the passport or license is considered sufficient because
   it vouches for that piece of information and is issued by a trusted
   authority.  Thus, in this analogy, the passport issuing agency is a
   Verifier, the passport is an Attestation Result, and the airport
   security is a Relying Party.



Thaler                     Expires May 7, 2020                  [Page 8]

Internet-Draft       Remote Attestation Architecture       November 2019


5.2.  Background-Check Model

   In this model, an Attester sends Evidence to a Relying Party, which
   simply passes it on to a Verifier.  The Verifier then compares the
   Evidence against its security policy, and returns an Attestation
   Result to the Relying Party.  The Relying Party then compares the
   Attestation Result against its own security policy.

   The resource access protocol between the Attester and Relying Party
   includes Evidence rather than an Attestation Result, but that
   Evidence is not processed by the Relying Party.  Since the Evidence
   is merely forwarded on to a trusted Verifier, any serialization
   format can be used for Evidence because the Relying Party does not
   need a parser for it.  The only requirement is that the Evidence can
   be _encapsulated in_ the format required by the resource access
   protocol between the Attester and Relying Party.

   However, like in the Passport model, an Attestation Result is still
   consumed by the Relying Party and so the serialization format of the
   Attestation Result is still important.  If the Relying Party is a
   constrained node whose purpose is to serve a given type resource
   using a standard resource access protocol, it already needs the
   parser(s) required by that existing protocol.  Hence, the ability to
   let the Relying Party obtain an Attestation Result in the same
   serialization format allows minimizing the code footprint and attack
   surface area of the Relying Party, especially if the Relying Party is
   a constrained node.

                                 +-------------+
                                 |             | Compare Evidence
                                 |   Verifier  | against security policy
                                 |             |
                                 +-------------+
                                     ^    |
                             Evidence|    |Attestation
                                     |    |  Result
                                     |    v
   +-------------+               +-------------+
   |             |-------------->|             | Compare Attestation
   |   Attester  |   Evidence    |   Relying   | Result against
   |             |               |    Party    | security policy
   +-------------+               +-------------+

                     Figure 3: Background-Check Model

   The background-check model is so named because it resembles the
   process typically used for job and loan applications, where a person
   fills out an application to get a job or a loan from a company, and



Thaler                     Expires May 7, 2020                  [Page 9]

Internet-Draft       Remote Attestation Architecture       November 2019


   the company then does a background check with some other agency that
   checks credit history, arrest records, etc. and gives back a report
   on the application that is then used to help determine whether to
   actually offer the job or loan.  Thus, in this analogy, a person
   asking for a loan is an Attester, the bank is the Relying Party, and
   a credit report agency is a Verifier.

5.2.1.  Variation: Verifying Relying Party

   One variation of the background-check model is a "Verifying Relying
   party", where the Relying Party and the Verifier on the same machine,
   and so there is no need for a protocol between the two.

5.2.2.  Variation: Out-of-Band Evidence Conveyance

   Another variation of the background-check model is shown in Figure 4,
   where the Verifier is still chosen by (and trusted by) the Relying
   Party, but the Evidence must be passed out-of-band.  For example, in
   step 1, the Attester communicates with the Relying Party, which
   refers the matter to a Verifier chosen by the Relying Party in step
   2.  Evidence is then passed to that Verifier in step 3, e.g., either
   by the Relying Party providing the Attester with information about
   the Verifier to send Evidence to, or by the Verifier querying the
   Attester directly, although the latter has the problem that it only
   works if devices allow unsolicited inbound queries, which may be a
   security problem in some contexts.

                                 +-------------+
                                 |             | Compare Evidence
                          +----->|   Verifier  | against security policy
                          |      |             |
                  Evidence|      +-------------+
                          |          ^    |
                          |          |    |Attestation
                          |3        2|    |  Result
                          |          |    v
   +-------------+        |      +-------------+
   |             |--------+      |             | Compare Attestation
   |   Attester  |-------------->|   Relying   | Result against
   |             |      1        |    Party    | security policy
   +-------------+               +-------------+

                 Figure 4: Out-of-Band Evidence Conveyance








Thaler                     Expires May 7, 2020                 [Page 10]

Internet-Draft       Remote Attestation Architecture       November 2019


5.3.  Combinations

   The choice of model is generally up to the Relying Party, and the
   same device may need to attest to different relying parties for
   different use cases (e.g., a network infrastructure device to gain
   access to the network, and then a server holding confidential data to
   get access to that data).  As such, both models may simultaneously be
   in use by the same device.

   Figure 5 shows an example of a combination where Relying Party 1 uses
   the passport model, whereas Relying Party 2 uses an extension of the
   background-check model.  Specifically, in addition to the basic
   functionality shown in Figure 3, Relying Party 2 actually provides
   the Attestation Result back to the Attester, allowing the Attester to
   use it with other Relying Parties.  This is the model that the
   Trusted Application Manager plans to support in the TEEP architecture
   [I-D.ietf-teep-architecture].

       +-------------+
       |             | Compare Evidence
       |   Verifier  | against security policy
       |             |
       +-------------+
            ^    |
    Evidence|    |Attestation
            |    |  Result
            |    v
       +-------------+
       |             | Compare
       |   Relying   | Attestation Result
       |   Party 2   | against security policy
       +-------------+
            ^    |
    Evidence|    |Attestation
            |    |  Result
            |    v
       +-------------+               +-------------+
       |             |-------------->|             | Compare Attestation
       |   Attester  |  Attestation  |   Relying   | Result against
       |             |     Result    |   Party 1   | security policy
       +-------------+               +-------------+

                       Figure 5: Example Combination








Thaler                     Expires May 7, 2020                 [Page 11]

Internet-Draft       Remote Attestation Architecture       November 2019


6.  Trust Model

   The scope of this document is scenarios for which a Relying Party
   trusts a Verifier that can evaluate the trustworthiness of
   information about an Attester.  Such trust might come by the Relying
   Party trusting the Verifier (or its public key) directly, or might
   come by trusting an entity (e.g., a Certificate Authority) that the
   Verifier has a certificate that chains up to.  The Relying Party
   might implicitly trust a Verifier (such as in the Verifying Relying
   Party combination).  Or, for a stronger level of security, the
   Relying Party might require that the Verifier itself provide
   information about itself that the Relying Party can use to evaluate
   the health of the Verifier before accepting its Attestation Results.

   In solutions following the background-check model, the Attester is
   assumed to trust the Verifier (again, whether directly or indirectly
   via a Certificate Authority that it trusts), since the Attester
   relies on an Attestation Result it obtains from the Verifier, in
   order to access resources.

   The Verifier trusts (or more specifically, the Verifier's security
   policy is written in a way that configures the Verifier to trust) a
   manufacturer, or the manufacturer's hardware, so as to be able to
   evaluate the health of that manufacturer's devices.  In solutions
   with weaker security, a Verifier might be configured to implicitly
   trust firmware or even software (e.g., a hypervisor).  That is, it
   might evaluate the health of an application component, or operating
   system component or service, under the assumption that information
   provided about it by the lower-layer hypervisor or firmware is true.
   A stronger level of security comes when information can be vouched
   for by hardware or by ROM code, 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.

7.  Conceptual Messages

7.1.  Evidence

   Today, Evidence tends to be highly device-specific, since the
   information in the evidence often includes vendor-specific
   information that is necessary to fully describe the manufacturer and
   model of the device including its security properties, the health of
   the device, and the level of confidence in the correctness of the
   information.  Evidence is typically signed by the device (whether by
   hardware, firmware, or software on the device), and evaluating it in
   isolation would require security policy to be based on device-
   specific details (e.g., a device public key).




Thaler                     Expires May 7, 2020                 [Page 12]

Internet-Draft       Remote Attestation Architecture       November 2019


7.2.  Endorsements

   An Endorsement is a secure statement that some entity (typically a
   manufacturer) vouches for the integrity of the device's signing
   capability.  For example, if the signing capability is in hardware,
   then an Endorsement might be a manufacturer certificate that signs a
   public key whose corresponding private key is only known inside the
   device's hardware.  Thus, when Evidence and such an Endorsement are
   used together, evaluating them can be done against security policy
   that may not be specific to the device instance, but merely specific
   to the manufacturer providing the Endorsement.  For example, a
   security policy might simply check that devices from a given
   manufacturer have information matching a set of known-good reference
   values, or a security policy might have a set of more complex logic
   on how to evaluate the validity of information.

   However, while a security policy that treats all devices from a given
   manufacturer the same may be appropriate for some use cases, it would
   be inappropriate to use such a security policy as the sole means of
   authorization for use cases that wish to constrain _which_ compliant
   devices are considered authorized for some purpose.  For example, an
   enterprise using attestation for Network Endpoint Assessment may not
   wish to let every healthy laptop from the same manufacturer onto the
   network, but instead only want to let devices that it legally owns
   onto the network.  Thus, an Endorsement may be helpful information in
   authenticating information about a device, but is not necessarily
   sufficient to authorize access to resources which may need device-
   specific information such as a public key for the device or component
   or user on the device.

7.3.  Attestation Results

   Attestation Results may indicate compliance or non-compliance with a
   Verifier's security policy.  A result that indicates non-compliance
   can be used by an Attester (in the passport model) or a Relying Party
   (in the background-check model) to indicate that the Attester should
   not be treated as authorized and may be in need of remediation.  In
   some cases, it may even indicate that the Evidence itself cannot be
   authenticated as being correct.

   An Attestation Result that indicates compliance can be used by a
   Relying Party to make authorization decisions based on the Relying
   Party's security policy.  The simplest such policy might be to simply
   authorize any party supplying a compliant Attestation Result signed
   by a trusted Verifier.  A more complex policy might also entail
   comparing information provided in the result against known-good
   reference values, or applying more complex logic using such
   information.



Thaler                     Expires May 7, 2020                 [Page 13]

Internet-Draft       Remote Attestation Architecture       November 2019


   Thus, Attestation Results often need to include detailed information
   about the Attester, for use by Relying Parties, much like physical
   passports and drivers licenses include personal information such as
   name and date of birth.  Unlike Evidence, which is often very device-
   and vendor-specific, Attestation Results can be vendor-neutral if the
   Verifier has a way to generate vendor-agnostic information based on
   evaluating vendor-specific information in Evidence.  This allows a
   Relying Party's security policy to be simpler, potentially based on
   standard ways of expressing the information, while still allowing
   interoperability with heterogeneous devices.

   Finally, whereas Evidence is signed by the device (or indirectly by a
   manufacturer, if Endorsements are used), Attestation Results are
   signed by a Verifier, allowing a Relying Party to only need a trust
   relationship with one entity, rather than a larger set of entities,
   for purposes of its security policy.

8.  Security Considerations

   To evaluate the security provided by a particular security policy, it
   is important to understand the strength of the Root of Trust, e.g.,
   whether it is mutable software, or firmware that is read-only after
   boot, or immutable hardware/ROM.

   It is also important that the security policy was itself obtained
   securely.  As such, if security policy in a Relying Party or Verifier
   can be configured via a network protocol, the ability to attest to
   the health of the client providing the security policy needs to be
   considered.

9.  IANA Considerations

   This document does not require any actions by IANA.

10.  Acknowledgements

   Some content in this document came from drafts by Michael Richardson,
   Henk Birkholz, and Ned Smith, and from the IETF RATS Working Group
   Charter.

11.  Informative References

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




Thaler                     Expires May 7, 2020                 [Page 14]

Internet-Draft       Remote Attestation Architecture       November 2019


   [OPCUA]    OPC Foundation, "OPC Unified Architecture Specification,
              Part 2: Security Model, Release 1.03", Global
              Platform GPD_SPE_009, November 2015,
              <https://opcfoundation.org/developer-tools/specifications-
              unified-architecture/part-2-security-model/>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/info/rfc4949>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

   [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
              "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
              May 2018, <https://www.rfc-editor.org/info/rfc8392>.

Author's Address

   Dave Thaler
   Microsoft

   EMail: dthaler@microsoft.com



























Thaler                     Expires May 7, 2020                 [Page 15]