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

Versions: 00 01 draft-birkholz-rats-reference-interaction-model

TBD                                                          H. Birkholz
Internet-Draft                                            Fraunhofer SIT
Intended status: Informational                                  M. Eckel
Expires: July 6, 2019                                             Huawei
                                                        January 02, 2019


    Reference Interaction Model for Challenge-Response-based Remote
                              Attestation
            draft-birkholz-reference-ra-interaction-model-01

Abstract

   This document defines an interaction model for a basic remote
   attestation procedure.  Additionally, the required information
   elements are illustrated.

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 July 6, 2019.

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



Birkholz & Eckel          Expires July 6, 2019                  [Page 1]


Internet-Draft                    RAIM                      January 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements notation . . . . . . . . . . . . . . . . . .   2
   2.  Disambiguation  . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Component Roles . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Prerequisites . . . . . . . . . . . . . . . . . . . . . . . .   3
   6.  Remote Attestation Interaction Model  . . . . . . . . . . . .   4
     6.1.  Information Elements  . . . . . . . . . . . . . . . . . .   4
   7.  Interaction Model . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Further Context . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Confidentiality . . . . . . . . . . . . . . . . . . . . .   7
     8.2.  Mutual Authentication . . . . . . . . . . . . . . . . . .   7
     8.3.  Hardware-Enforcement/Support  . . . . . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   11. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     12.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Remote attestation procedures (RATS) are a combination of activities,
   in which a Verifier creates assertions about claims of integrity and
   about the characteristics of other system entities by the appraisal
   of corresponding signed claim sets (evidence).  In this document, a
   reference interaction model for a generic challenge-response-based
   remote attestation procedure is provided.  The minimum set of
   components, roles and information elements that have to be conveyed
   between Verifier and Attester are defined as a standard reference to
   derive more complex RATS from.

1.1.  Requirements notation

   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 RFC
   2119, BCP 14 [RFC2119].

2.  Disambiguation

   The term "Remote Attestation" is a common expression and often
   associated with certain properties.  The term "Remote" in this
   context does not necessarily refer to a remote system entity in the
   scope of network topologies or the Internet.  It rather refers to a



Birkholz & Eckel          Expires July 6, 2019                  [Page 2]


Internet-Draft                    RAIM                      January 2019


   decoupled system or different computing context, which also could be
   present locally as components of a composite device.  Examples
   include: a Trusted Execution Environment (TEE), Baseboard Management
   Controllers (BMCs), as well as other physical or logical protected/
   isolated execution environments.

3.  Scope

   This document focuses on a generic interaction model between
   Verifiers and Attesters.  Complementary processes, functions and
   activities that are required for a complete semantic binding of RATS
   are not in scope.  Examples include: identity establishment, key
   enrollment, and revocation.  Furthermore, any processes and
   activities that go beyond carrying out the remote attestation process
   are out of scope.  For instance, using the result or claim of a
   remote attestation that is emitted by the Verifier, such as
   triggering remediation actions and recovery processes, as well as the
   remediation actions and recovery processes themselves, are out of
   scope.

4.  Component Roles

   The Reference Interaction Model for Challenge-Response-based Remote
   Attestation is based on the standard roles defined in
   [I-D.birkholz-rats-architecture]:

   Attester:  The role that designates the subject of the remote
      attestation.  A system entity that is the provider of evidence
      takes on the role of an Attester.

   Verifier:  The role that designates the system entity and that is the
      appraiser of evidence provided by the Attester.  A system entity
      that is the consumer of evidence takes on the role of a Verifier.

5.  Prerequisites

   Identity:  An Attester must have a unique Identity in such a way that
      a Verifier can uniquely identify an Attester.  This Identity MUST
      be part of the signed claim set (attestation evidence) that the
      Attester conveys to the Verifier.

   Shared Secret:  A Shared Secret between the Verifier and the
      Attester.  This secret MUST be established between the two
      entities before a remote attestation procedure can take place.
      How this Shared Secret is established is out of scope for this
      reference model.





Birkholz & Eckel          Expires July 6, 2019                  [Page 3]


Internet-Draft                    RAIM                      January 2019


6.  Remote Attestation Interaction Model

   This section defines the information elements that have to be
   conveyed via a protocol, enabling the conveyance of evidence between
   Verifier and Attester, as well as the interaction model for a generic
   challenge-response scheme.

6.1.  Information Elements

   Nonce:  mandatory

      The Nonce (number used once) is a number intended to be unique and
      intended to be effectively infeasible to guess.  In this reference
      interaction model it MUST be provided by the Verifier and MUST be
      used as a proof of freshness, with respect to conveyed evidence
      ensuring that the result of an attestation activity was created
      recently (i.e. triggered by the challenge emitted by the
      Verifier).  As such, the Nonce MUST be part of the signed claim
      set that composes the attestation evidence sent by the Attester to
      the Verifier.

   Shared Secret ID:  mandatory

      An identifier that MUST be associated with the Shared Secret which
      is used to sign the attestation evidence claim set.

   Attestation Evidence:  mandatory

      The signed minimal claim set that is required to enable integrity
      proving of the corresponding characteristics of the Attester.
      Examples of claims included in attestation evidence are claims
      about sensor data, policies that are active on the system entity,
      versions of a platform's composite firmware, running software,
      routing tables, or information about a local time source.
      Attestation evidence must be cryptographically bound to the
      Verifier-provided Nonce, the Identity of the Attester, as well as
      to the Shared Secret identified by the Shared Secret ID.

   Additional Info:  optional

      An Attester MAY provide additional information or metadata that
      are relevant to the appraisal conducted by the Verifier in order
      to prove correctness of the integrity claims created by the
      Attester.  Usually, all information associated with the signed
      claim set that is available to the Attester SHOULD be conveyed.
      This additional information can be composed as complementary
      signed claim sets or can be encapsulated claim sets in the signed
      claim set that composes the evidence about integrity.  This



Birkholz & Eckel          Expires July 6, 2019                  [Page 4]


Internet-Draft                    RAIM                      January 2019


      information element is optional in order to enable a Verifier to
      request additional information.  An Attester MAY decide whether or
      not to provide that additional information or not.  In either
      case, all additional information MUST be cryptographically bound
      to the signed claim set.  An example for additional information
      that a Verifier can request from an Attester are (signed)
      Reference Integrity Measurements (RIMs).

   Identity:  mandatory

      A statement about a distinguishable Attester made by an entity
      without accompanying evidence of its validity, used as proof of
      identity.

7.  Interaction Model

   The following sequence diagram illustrates the reference remote
   attestation procedure defined by this document.

     [Attester]                                               [Verifier]
         |                                                         |
         | <---requestAttestation(nonce, secretID, claimSelection) |
         |                                                         |
         | ---+                                                    |
       +-+-+  | collectClaims(claimSelection)                      |
       |   |<-+                                                    |
       |   |--+                                                    |
       +-+-+  | claimSet                                           |
         | <--+                                                    |
         |                                                         |
         | ---+                                                    |
       +-+-+  | signClaims(claims, nonce, secretID, identity)      |
       |   |<-+                                                    |
       |   |--+                                                    |
       +-+-+  | signedEvidence                                     |
         | <--+                                                    |
         |                                                         |
         | returnResult(evidence, signature, identity)i----------> |
         |                                                         |
         |                                                    +--- |
         |     appraise(evidence, signature, identity, nonce) |  +-+-+
         |                                                    +->|   |
         |                                                    +--|   |
         |                                    appraisalResult |  +-+-+
         |                                                    +--> |
         |                                                         |





Birkholz & Eckel          Expires July 6, 2019                  [Page 5]


Internet-Draft                    RAIM                      January 2019


   The remote attestation procedure is initiated by the Verifier,
   sending an attestation request to the Attester.  The attestation
   request consists of a Nonce, a Shared Secret ID, and an optional
   Additional Info part.  The Nonce guarantees attestation freshness.
   The Shared Secret ID selects the shared secret the Attester is
   requested to sign its response with.  The Additional Info part is
   optional in order to narrow down or increase the scope of received
   evidence, if required.  For example, the Verifier is only interested
   in particular information about the Attester, such as whether the
   device booted up in a known state, and not include information about
   all currently running software.

   The Attester, after receiving the attestation request, collects the
   corresponding integrity claims to compose the evidence the Verifier
   requested--or, in case the Verifier did not include any Additional
   Info, the Attester collects all information that can be used as
   complementary claims in the scope of the semantics of the remote
   attestation procedure.  After that, the Attester signs the Evidence
   with the Shared Secret including the Nonce and the Identity
   information, and sends the output back to the Verifier.  Important at
   this point is that the Nonce as well as the Identity information must
   be cryptographically bound to the signature, i.e. it is not required
   for them to be present in plain-text.  For instance, those
   information can be part of the signature after a one-way function
   (e.g. a hash function) was applied to them.  There is also a
   possibility to scramble the Nonce or Identity with other information
   that is known to both the Verifier and Attester.  A prominent example
   is the IP address of the Attester that usually is known by the
   Attester as well as the Verifier.  This extra information can be used
   to scramble the Nonce in order to counter a certain type of relay
   attacks.  As soon as the Verifier receives the attestation evidence
   data, it appraises the signed evidence, the Identity as well as the
   claims in the claim set.  This process is application-specific and
   can be done by e.g. comparing the claim set to known (good), expected
   reference claims, such as a Reference Integrity Measurement Manifest
   (RIMs), or evaluating it in other ways.  The final output, also
   referred to as Attestation Result, is a new claim about properties of
   the Attester, i.e. whether or not it is compliant to the policies, or
   even "trusted".

8.  Further Context

   Depending on the use cases to cover there may be additional
   requirements.







Birkholz & Eckel          Expires July 6, 2019                  [Page 6]


Internet-Draft                    RAIM                      January 2019


8.1.  Confidentiality

   Use confidential communication to exchange attestation information.
   This requirement usually is present when communication happens over
   insecure channels, such as the public Internet.  Speaking of a
   suitable communication protocol, TLS is a good candidate.  In private
   networks, such as carrier management networks, it must be evaluated
   whether or not the transport medium is considered confidential.

8.2.  Mutual Authentication

   In particular use cases mutual authentication may be desirable in
   such a way that a Verifier also needs to prove its identity to the
   Attester instead of only the Attester proving its identity to the
   Verifier.

8.3.  Hardware-Enforcement/Support

   In particular use cases hardware support can be desirable.  Depending
   on the requirements those can be secure storage of cryptographic
   keys, crypto accelerators, or protected or isolated execution
   environments.  Well-known technologies are Hardware Security Modules
   (HSM), Physical Unclonable Functions (PUFs), Shielded Secrets,
   Trusted Executions Environments (TEEs), etc.

9.  Security Considerations

   There are always some.

10.  Acknowledgements

   Very likely.

11.  Change Log

   Initial draft -00

   Changes from version 00 to version 01:

   Added details to the flow diagram

12.  References

12.1.  Normative References







Birkholz & Eckel          Expires July 6, 2019                  [Page 7]


Internet-Draft                    RAIM                      January 2019


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

12.2.  Informative References

   [I-D.birkholz-rats-architecture]
              Birkholz, H., Wiseman, M., Tschofenig, H., and N. Smith,
              "Architecture and Reference Terminology for Remote
              Attestation Procedures", draft-birkholz-rats-
              architecture-00 (work in progress), October 2018.

Authors' Addresses

   Henk Birkholz
   Fraunhofer SIT
   Rheinstrasse 75
   Darmstadt  64295
   Germany

   Email: henk.birkholz@sit.fraunhofer.de


   Michael Eckel
   Huawei Technologies
   Feldbergstrasse 78
   Darmstadt  64293
   Germany

   Email: michael.eckel@huawei.com




















Birkholz & Eckel          Expires July 6, 2019                  [Page 8]


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