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

Versions: 00 01

RATS Working Group                                               E. Voit
Internet-Draft                                                     Cisco
Intended status: Standards Track                       February 27, 2020
Expires: August 30, 2020


             Trusted Path Routing using Remote Attestation
                draft-voit-rats-trusted-path-routing-00

Abstract

   There are end-users who believe encryption technologies like IPSec
   alone are insufficient to protect the confidentiality of their highly
   sensitive traffic flows.  This specification describes two
   alternatives for protecting these sensitive flows as they transit a
   network.  In both alternatives, protection is accomplished by
   forwarding sensitive flows across network devices currently appraised
   as trustworthy.

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 August 30, 2020.

Copyright Notice

   Copyright (c) 2020 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



Voit                     Expires August 30, 2020                [Page 1]


Internet-Draft                 trust-path                  February 2020


   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
     2.1.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements Notation . . . . . . . . . . . . . . . . . .   4
   3.  Centralized Trusted Path Routing  . . . . . . . . . . . . . .   4
   4.  Distributed Trusted Path Routing  . . . . . . . . . . . . . .   6
     4.1.  Trusted Topology  . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Passport with Composite Evidence  . . . . . . . . . . . .   7
   5.  Attestation Event Stream  . . . . . . . . . . . . . . . . . .  10
     5.1.  Subscribing to the stream . . . . . . . . . . . . . . . .  10
     5.2.  YANG notifications placed on the Event Stream . . . . . .  11
       5.2.1.  tpm-extend  . . . . . . . . . . . . . . . . . . . . .  11
       5.2.2.  tpm12-attestation . . . . . . . . . . . . . . . . . .  11
       5.2.3.  tpm20-attestation . . . . . . . . . . . . . . . . . .  13
     5.3.  Pre-filtering the Event Stream  . . . . . . . . . . . . .  13
     5.4.  Replaying previous PCR Extend events. . . . . . . . . . .  14
     5.5.  Configuring the Attestation Event Stream  . . . . . . . .  14
   6.  YANG Module . . . . . . . . . . . . . . . . . . . . . . . . .  16
   7.  Passport Protocol Bindings  . . . . . . . . . . . . . . . . .  22
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  26
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  27
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  27
   Appendix C.  Open Questions . . . . . . . . . . . . . . . . . . .  27
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  27

1.  Introduction

   There are end-users who believe encryption technologies like IPSec
   alone are insufficient to protect the confidentiality of their highly
   sensitive traffic flows.  These customers want their highly sensitive
   flows to be transported over only network devices recently verified
   as trustworthy.

   With the inclusion of cryptoprocessor hardware into network devices,
   it is now possible for network providers to identify those network
   devices which have potentially exploitable or even exploited
   vulnerabilities.  Using this knowledge, it then becomes possible to
   redirect sensitive flows around these potentially compromised
   devices.




Voit                     Expires August 30, 2020                [Page 2]


Internet-Draft                 trust-path                  February 2020


   This specification describes two architectural alternatives for
   exchanging traffic with end-user customer identified "sensitive
   subnets".  Traffic going to and from these subnets will transit a
   path where the IP layer and above are only interpretable by those
   network devices recently evaluated as trustworthy.  These two
   architectural alternatives are:

   1.  Centralized Trusted Path Routing - For sensitive subnets, trusted
       end-to-end paths are pre-assigned through a network provider
       domain.  Along these paths, attestation evidence of potentially
       transited components has been assessed.  Each path is guaranteed
       to only include devices meeting the needs of a formally defined
       trustworthiness level.

   2.  Distributed Trusted Path Routing - Through the exchange of
       attestation evidence between peering network devices, a trusted
       topology is established and maintained.  Only devices meeting the
       needs of a formally defined trustworthiness level are included as
       members of this topology.  Traffic exchanged with sensitive
       subnets is forwarded into this topology.

   Beyond the definition of these two architectural alternatives,
   incremental technology enhancements needed for each are also
   specified within this document.  The specification works under the
   assumptions that cryptoprocessors capable of supporting [TPM1.2] or
   [TPM2.0] interface specifications are available on each network
   device, and the device supports the concepts of remote attestation
   laid out in [RATS-Device].

2.  Terminology

2.1.  Terms

   The following terms are imported from [I-D.ietf-rats-architecture]:
   Attester, Composite Evidence, Evidence, Passport, Relying Party, and
   Verifier.

   The following terms at imported from [RFC8639]: Event Stream.

   Newly defined terms for this document:

   o  Attested Device: a device where a Verifier's most recent appraisal
      of attestation evidence has successfully met the criteria for a
      specific Trustworthiness Level.  Attested Devices cannot be
      appraised as unverified or compromised.






Voit                     Expires August 30, 2020                [Page 3]


Internet-Draft                 trust-path                  February 2020


   o  Sensitive Subnet: an IP address range where IP packets to or from
      that range must only have their IP headers and encapsulated
      payloads accessible/visible only by Attested Devices.

   o  Transparently-Transited Device: a network device within an IGP
      domain where any packets passed into that IGP domain are
      completely opaque at Layer 3 and above.

   o  Trusted Topology: A topology which includes only Attested Devices
      and Transparently-Transited Devices.

   o  Trustworthiness Level: a specific grade of trust earned by a
      device.  The grade for a device is assigned by a Verifier during
      the appraisal process and can be returned within Attestation
      Results.  Example levels include boot-verified, unverified and
      compromised.  (Note: significant discussion will be needed to
      agree on definitions of these levels.)

2.2.  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
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Centralized Trusted Path Routing

   With this architectural alternative, a controller-based Verifier
   ensures communications with Sensitive Subnets traveses a Trusted
   Topology within the controller's IGP domain.  To do this, the
   Verifier continuously acquires Evidence about each potentially
   transited device.  This access is done via the context established
   within [RATS-Device].  The controller then appraises all available
   Evidence and decides on a Trustworthiness Level for each device.
   Using the set of all appraisals, the controller identifies end-to-end
   path(s) which avoid any devices with an insufficient Trustworthiness
   Level.  Finally, the controller provisions Sensitive Subnets to use
   just these end-to-end paths.

   Evidence passed to the Verifier which are used to establish a
   device's Trustworthiness Level will include but is not limited to:

   o  An Attester's security measurements being extended into [TPM1.2]
      or [TPM2.0] compliant Platform Configuration Registers (PCR).

   o  An Attester's current PCR measurements.




Voit                     Expires August 30, 2020                [Page 4]


Internet-Draft                 trust-path                  February 2020


   It is the consideration of all Evidence which allows the
   establishment and maintenance of a Trustworthiness Level.  Note that
   it is outside the scope of this specification to include algorithms
   for determining a Trustworthiness Level.

   The prerequisites for this solution are:

   1.  Customer designated Sensitive Subnet ranges and their demanded
       Trustworthiness Levels have been identified and associated with
       external interfaces to/from the edge of an IGP domain.

   2.  A Verifier which can continuously acquire Evidence and appraise
       the Trustworthiness Levels of all network devices within the IGP
       domain.

   3.  A Verifier which continuously optimizes a set of network paths/
       tunnels.  These paths must traverse only Attested Devices or
       Transparently-Transited Devices while on their way to an egress
       interface for an IGP Domain.

   4.  A Verifier which can provision and maintain the set of Sensitive
       Subnets associated with specific network paths/tunnels.

   Figure 1 provides a network diagram of where these four sit within a
   network topology.

       .----------------------------------.         .---------.
       |   Verifier + Relying Party  (3)  |<-----(2)|Edge     |
       '----------------------------------'<-----.  |Router   |
         (4)         ^        ^         ^        |  |(Attest (1).
          |         (2)       |         |        |  | =Fail)  | |
          |     .-------.     |         |       (2) '---------' |
          V     |Hacked |    (2)       (2)    .--------.        |
    .--------.  |Router | .-------. .-------. | Edge   |    Sensitive
    | Edge   |  |(Attest| |Router | |Switch | | Router |    Subnet
    | Router |  | =Fail)| |(Attest| |(Attest| | (Attest|        |
    |        |  '-------' |  =OK) | |  =OK) | |   =OK) |        |
   (1)   path==================================>      (1)-------'
    |        <==================================path   |
    '--------'            '-------' '-------' '--------'

                Figure 1: Centralized Trusted Path Routing

   The feature functionality describing how to achieve (1), (3), and (4)
   are outside the scope of this specification.  The reasoning is that
   each of these can be accomplished via existing standard-based or
   standards-track technologies.  For example, in step (4), it is
   possible for a Verifier to provision each ingress device with the set



Voit                     Expires August 30, 2020                [Page 5]


Internet-Draft                 trust-path                  February 2020


   of Sensitive Subnets for which traffic would be placed into a
   specific [I-D.ietf-idr-segment-routing-te-policy] tunnel.

   The new requirements which need to be supported for this
   specification come from prerequisite (2).  To accomplish prerequisite
   (2), it is necessary for each network device to stream changes in
   Evidence to a Verifier.  This can be accomplished by the Verifier
   establishing an [RFC8639] subscription to the <attestation> Event
   Stream described in Section 5 below within this document.

   With this new <attestation> Event Stream, a Verifier can consume and
   continuously determine the Trustworthiness Level of various network
   devices within the IGP domain.  Maintaining this information allows
   the Controller to calculate an appropriate network path (3).

4.  Distributed Trusted Path Routing

4.1.  Trusted Topology

   With this architectural alternative, Composite Evidence is assembled
   into a passport [I-D.ietf-rats-architecture] by the Attester network
   device.  Upon receiving this passport as part of link layer
   authentication credentials, a peer Relying Party decides if this
   Attester is trustworthy enough to be an Attested Device.  It also
   appraises its Trustworthiness Level.  If found trustworthy, the
   relevant link is included into any Trusted Topologies capable of
   supporting that Trustworthiness Level.

   When enough links have been included, a Trusted Topology will now
   exist for a specified Trustworthiness Level.  And traffic exchanged
   with Sensitive Subnets can be forwarded into that Trusted Topology
   from all edges of an IGP domain.

                 .--------.             .---------.
                 | Hacked |             | Edge    |
    .---------.  | Router |             | Router  |
    | Router  |  |        |             |         |
    |         |  |   trust>-------------<no_trust |
    | no_trust>--<trust   | .--------.  |         |----Sensitive
    |         |  '--------' |   trust>==<trust    |    Subnet
    |    trust>=============<trust   |  |         |
    '---------'             |        |  '---------'
                            | Router |
                            '--------'

           Figure 2: Distributed Trusted Path Topology Assembly





Voit                     Expires August 30, 2020                [Page 6]


Internet-Draft                 trust-path                  February 2020


4.2.  Passport with Composite Evidence

   Critical to the establishment and maintenance of a Trusted Topology
   is the passport.  Within the passport, Composite Evidence is
   continuously exchanged between peering network devices over a link
   layer protocol.  This Section 4.2 provides a protocol independent
   process for passport generation and evaluation.  Section 7 later in
   the document binds the passport to specific link layer protocols,
   YANG models, and authentication methods.

   The composite nature of the passport exposes multiple dimensions of
   an attesting router's security posture to a network peer.
   Specifically, using capabilities defined as part of either the TCG
   [TPM1.2] or [TPM2.0] specifications, the following can be established
   about the Attester:

   o  its hardware-based identity,

   o  the last Verifier appraisal of its Trustworthiness Level,

   o  the amount of time which has passed since the Attester has been at
      a Trustworthiness Level, and

   o  if the PCRs haven't changed, the Attester's current
      Trustworthiness Level

   With this information, the Relying Party peer can make nuanced
   decisions.  For example, when the Attester's legitimate hardware
   identity credentials can be verified, it might choose to accept link
   layer connections and forward generic Internet traffic.
   Additionally, if the Attester's Trustworthiness Level is acceptable,
   and it hasn't been too long since the Trustworthiness Level was
   examined by a Verifier, the Relying Party can include that link in a
   Trusted Topology.

   As the process described above repeats across the set of links within
   the IGP domain, Trusted Topologies can be extended and maintained.
   Traffic to and from Sensitive Subnets is then identified at the edges
   of the IGP domain and passed into this Trusted Topology.

   The prerequisites for this solution to work are:

   o  Customer designated Sensitive Subnets and their requested
      Trustworthiness Levels have been identified and associated with
      external interfaces to/from the edge of an IGP domain.






Voit                     Expires August 30, 2020                [Page 7]


Internet-Draft                 trust-path                  February 2020


   o  A FlexAlgo [I-D.ietf-lsr-flex-algo] topology exists in an IGP
      domain for the forwarding of customer traffic.  This Topology will
      carry traffic of a Trustworthiness Level.

   o  Verifiers A and B are able to verify [TPM1.2] or [TPM2.0]
      signatures of an Attester.

   o  Verifier A can establish the Trustworthiness Level of an Attester
      and return a signed result to that Attester.

   o  An Attester can assemble a passport of Composite Evidence for
      Verifier B.

   o  Verifier B trusts the Attestation Results and can verify
      signatures made by Verifier A.

   o  Within an IGP domain, a Relying Party is able to use affinity to
      include/exclude links as part of the FlexAlgo Topology based on
      this appraisal.

   o  Traffic to/from a Sensitive Subnet can be passed into the FlexAlgo
      topology.

       .--------------.
       |  Verifier A  |
       '--------------'
           ^     (2)
           |     Verifier A signed Trustworthiness Level
      Evidence    |
          (1)     V
        .-------------.                           .---------------.
        | Attester    |                           | Relying Party |
        |  (Router)   |<------------------nonce(3)|               |
        |  .-----.    |                           | (Verifier B   |
        |  | TPM |    |(4)-Passport containing--->|   / Router)   |
        |  '-----'    |    Composite Evidence     |      (5)      |
        '-------------'                           '---------------'

    Figure 3: Distributed Trusted Path Passport Generation and Delivery

   In Figure 3 above, Evidence from a TPM1.2 or TPM2.0 is generated and
   signed by that TPM.  This Evidence is appraised by Verifier A, and
   the Attester is given a Trustworthiness Level which is signed and
   returned as Attestation Results to the Attester.  Later, when a
   request comes in from a Relying Party, the Attester assembles and
   returns three independently signed elements of Evidence.  These three
   comprise the Composite Evidence which when taken together allow




Voit                     Expires August 30, 2020                [Page 8]


Internet-Draft                 trust-path                  February 2020


   Verifier B to appraise the current Trustworthiness Level of the
   Attester.

   More details on the mechanisms used in the construction and
   verification of the passport match to the numbered steps of Figure 3:

   1.  An Attester sends signed TPM PCR measurements to Verifier A at
       time(x).

   2.  Verifier A appraises (1), then signs and returns back to that
       Attester:

       1.  a Trustworthiness Level, and

       2.  the signature of (1).

   3.  A nonce known to the Relying Party is received by the Attester at
       time(y).

   4.  The Attester generates and sends a passport.  The encapsulated
       Composite Evidence includes:

       1.  (1)

       2.  (2)

       3.  New signed, verifiably fresh PCR measurements at time(y),
           which incorporates the nonce from (3).

   5.  On receipt of (4), the Relying Party makes its determination of
       how the Composite Evidence will impact forwarding topology.  The
       decision process is:

       1.  Verify that (4.3) includes the nonce from (3).

       2.  Verify the TPM signature within (4.2) matches the signature
           of (4.1).

       3.  Validate the signatures of (4.1), (4.2), (4.3).

       4.  Failure of (5.1), (5.2), or (5.3) means the link should be
           assigned a <compromised> Trustworthiness Level, and
           additionally jump to step (5.8).

       5.  If selected PCR values of (1) match (4.3), then Relying Party
           can accept (2.1).





Voit                     Expires August 30, 2020                [Page 9]


Internet-Draft                 trust-path                  February 2020


       6.  When the PCR values are different, and not much time has
           passed between time(x) and time(y), the Relying Party can
           either accept any previous Trustworthiness Level, or attempt
           to acquire a new passport.  In many cases, it should only be
           a few seconds before a new Attestation Results should be
           delivered to an Attester via (2).

       7.  When the PCR values are different, but there is a large time
           gap between time(x) and time(y), the Link should be assigned
           an <unverified> Trustworthiness Level.

       8.  Based on the link's Trustworthiness Level, add or remove it
           from the appropriate FlexAlgo topology.

5.  Attestation Event Stream

   The <attestation> Event Stream is an [RFC8639] complaint Event Stream
   which is defined within this section and within the YANG Module of
   Section 6.  The Event Stream contains YANG notifications which carry
   Evidence which assists a Verifier in appraising the Trustworthiness
   Level of an Attester.  Data Nodes allow the configuration of this
   Event Stream's contents on a particular Attester.

   This <attestation> Event Stream may only be exposed on Attesters
   capable of signing cryptoprocessor PCRs using a private key
   unavailable elsewhere within the Attester.  There is not a
   requirement that the underlying cryptoprocessor of the Attester has
   undergone TCG certification.

5.1.  Subscribing to the stream

   To establish the subscription in a way which results in provably
   fresh Evidence, randomness must be provided to the Attester.  This is
   done by an augmentation of the RFC8639 <establish-subscription> RPC:

     augment /sn:establish-subscription/sn:input:
       +---w nonce-value?   binary

   As part of the response to the <establish-subscription>, a YANG
   notification defined in this document is retuned.  This notification
   MUST incorporate the randomness provided by the <nonce-value>.  By
   including this YANG notification in the response, critical
   measurements are delivered in a way which provides protection against
   replay attacks.  Additionally, the Verifier has immediate access to
   current measurements.






Voit                     Expires August 30, 2020               [Page 10]


Internet-Draft                 trust-path                  February 2020


  augment /sn:establish-subscription/sn:output:
    +--ro latest-attestation
       +--(instance of <tpm12-attestation> or <tpm20-attestation> notification)

5.2.  YANG notifications placed on the Event Stream

5.2.1.  tpm-extend

   This notification is generated every time a PCR is extended within a
   cryptoprocessor.  The notification contains a list of the one or more
   strings which have extended a PCR.

   +--n tpm-extend
       +--ro tpm_name               string
       +--ro tpm-physical-index?    int32 {ietfhw:entity-mib}?
       +--ro pcr-index-changed      uint8
       +--ro extended-with*         binary

   All notifications since boot MUST be retained, and replayable.

5.2.2.  tpm12-attestation

   This notification contains an instance of a TPM1.2 style signed
   cryptoprocessor measurement.  It is supplemented by Attester
   information which is not signed.  This notification is generated and
   emitted from an Attester every time at least one PCR identified
   within the <pcr-list> has changed from the previous
   <tpm12-attestation> notification:























Voit                     Expires August 30, 2020               [Page 11]


Internet-Draft                 trust-path                  February 2020


       +---n tpm12-attestation
          +--ro tpm_name?                    string
          +--ro up-time?                     uint32
          +--ro node-name?                   string
          +--ro node-physical-index?         int32 {ietfhw:entity-mib}?
          +--ro fixed?                       binary
          +--ro external-data?               binary
          +--ro signature-size?              uint32
          +--ro signature?                   binary
          +--ro (tpm12-quote)
             +--:(tpm12-quote1)
             |  +--ro version* []
             |  |  +--ro major?      uint8
             |  |  +--ro minor?      uint8
             |  |  +--ro revMajor?   uint8
             |  |  +--ro revMinor?   uint8
             |  +--ro digest-value?          binary
             |  +--ro TPM_PCR_COMPOSITE* []
             |     +--ro pcr-indices*       uint8
             |     +--ro value-size?        uint32
             |     +--ro tpm12-pcr-value*   binary
             +--:(tpm12-quote2)
                +--ro tag?                   uint8
                +--ro pcr-indices*           uint8
                +--ro locality-at-release?   uint8
                +--ro digest-at-release?     binary

   The vast majority of the YANG objects above are defined within
   [RATS-YANG].  As a result, these objects are not redefined in this
   draft.  The objects which are new include:

   o  pcr-index-changed* - this is a list of a PCRs which have new
      values since the last <tpm12-attestation> notification.

   o  pcr-index-attested* - this is a list of all the PCRs contained in
      the <tpms-attest-result>.

   Only the most recent <tpm12-attestation> is replayable.  All others
   are discarded from the Event Stream history.

   Note that this notification alone does not fully handle replay attack
   protection for Centralized Trusted Path Routing.  As a result, a
   Verifier MUST periodically receive a nonce based TPM1.2 style quote
   response.  This can be done in several ways including via the <tpm12-
   challenge-response-attestation> RPC specified in [RATS-YANG].  This
   periodic query allows a synching on the freshness of the results.
   Such a periodic synching is not required for the Distributed Trusted




Voit                     Expires August 30, 2020               [Page 12]


Internet-Draft                 trust-path                  February 2020


   Path Routing architecture as the nonce based quote at time(y) proves
   the freshness of every passport.

5.2.3.  tpm20-attestation

   This notification contains an instance of TPM2 style signed
   cryptoprocessor measurements.  It is supplemented by Attester
   information which is not signed.  This notification is generated at
   two points in time:

   o  every time at least one PCR has changed from a previous
      tpm20-attestation.

   o  after a locally configurable minimum heartbeat period since a
      previous tpm20-attestation was sent.  This heartbeat is
      identifiable as the <pcr-index-changed> will be missing from the
      notification.  As a result, there is no need to match it to one or
      more <tpm-extend> notifications.

   Only the most recent <tpm20-attestation> is replayable.  All others
   are discarded from the Event Stream history.

   Note that [RATS-YANG] does not yet include the full set of [TPM2.0]
   objects.  As soon as [RATS-YANG] is updated with the necessary
   information, a new version of this draft will include a tree diagram
   which identifies those objects within this notification.

5.3.  Pre-filtering the Event Stream

   It is possible for a receive just those PCR changes of interest from
   an Attester.  To accomplish this, a RFC8639 <establish-subscription>
   RPC is made against the <attestation> Event Stream.  To limit the set
   of notifications, a <stream-filter> as per RFC8639, Section 2.2 can
   be set to select the following:

   o  each <tpm-extend> containing a <pcr-index-changed> of a desired
      PCR

   o  each <tpm12-attestation> containing a <pcr-index-changed> of a
      desired PCR

   o  each <tpm20-attestation> containing a <pcr-index-changed> of a
      desired PCR








Voit                     Expires August 30, 2020               [Page 13]


Internet-Draft                 trust-path                  February 2020


5.4.  Replaying previous PCR Extend events.

   To verify the value of a PCR, a Verifier must either know that the
   value is a known good value [KGV] or be able to reconstruct the hash
   value by viewing all the PCR-Extends since the Attester rebooted.
   Wherever a hash reconstruction might be needed, the <attestation>
   Event Stream MUST support the RFC8639 <replay> feature.  Through the
   <replay> feature, it is possible for a Verifier to retrieve and
   sequentially hash all of the PCR extending events since an Attester
   booted.  And thus, the Verifier has access to all the evidence needed
   to verify a PCR's current value.

5.5.  Configuring the Attestation Event Stream

   Figure 4 is tree diagram which exposes the configurable elements of
   the <attestation> Event Stream.  This allows an Attester to select
   what information should be available on the stream.  A fetch
   operation also allows an external device such as a Verifier to
   understand the current configuration of stream.

   The majority of the YANG objects below are defined via reference from
   [RATS-YANG].





























Voit                     Expires August 30, 2020               [Page 14]


Internet-Draft                 trust-path                  February 2020


     +--rw tpm12-stream
     |  +--rw tpm12-stream-config* [tpm_name]
     |  |  +--rw tpm_name                string
     |  |  +--rw pcr-indices*            uint8
     |  |  +--rw (key-identifier)?
     |  |     +--:(public-key)
     |  |     |  +--rw pub-key-id?       binary
     |  |     +--:(TSS_UUID)
     |  |        +--rw TSS_UUID-value
     |  |           +--rw ulTimeLow?       uint32
     |  |           +--rw usTimeMid?       uint16
     |  |           +--rw usTimeHigh?      uint16
     |  |           +--rw bClockSeqHigh?   uint8
     |  |           +--rw bClockSeqLow?    uint8
     |  |           +--rw rgbNode*         uint8
     |  +--rw TPM_SIG_SCHEME-value    uint8
     +--rw tpm20-stream
        +--rw tpm20-stream-config* [tpm_name]
        |  +--rw tpm_name            string
        |  +--rw pcr-list* [pcr-index]
        |  |  +--rw pcr-index                     uint8
        |  |  +--rw (algo-registry-type)
        |  |     +--:(tcg)
        |  |     |  +--rw tcg-hash-algo-id?       uint16
        |  |     +--:(ietf)
        |  |        +--rw ietf-ni-hash-algo-id?   uint8
        |  +--rw (key-identifier)?
        |     +--:(public-key)
        |     |  +--rw pub-key-id?   binary
        |     +--:(uuid)
        |        +--rw uuid-value?   binary
        +--rw (signature-identifier-type)
        |  +--:(TPM_ALG_ID)
        |  |  +--rw TPM_ALG_ID-value?       uint16
        |  +--:(COSE_Algorithm)
        |     +--rw COSE_Algorithm-value?   int32
        +--rw tpm2-heartbeat?               uint8

               Figure 4: Configuring the Attestation Stream

   There is one object which is new with this model however.
   <tpm2-heartbeat> defines the maximum amount of time which should pass
   before a subscriber to the event stream should get a
   <tpm20-attestation> notification from devices which contain a TPM2.

   If there is no configuration of any <tpm-name> information within
   this model, all subscriptions should be rejected with an [RFC8639]
   reason of <stream-unavailable>.



Voit                     Expires August 30, 2020               [Page 15]


Internet-Draft                 trust-path                  February 2020


6.  YANG Module

   This YANG module imports modules from [RATS-YANG] and [RFC8639].  It
   is also work-in-progress.

<CODE BEGINS> ietf-rats-attestation-stream@2020-02-24.yang
module ietf-rats-attestation-stream {
  yang-version 1.1;
  namespace
     "urn:ietf:params:xml:ns:yang:ietf-rats-attestation-stream";
  prefix ats;

  import ietf-subscribed-notifications {
    prefix sn;
    reference
      "RFC 8639: Subscription to YANG Notifications";
  }
  import ietf-tpm-remote-attestation {
    prefix yang-brat;
    reference
      "draft-ietf-rats-yang-tpm-charra-00";
  }
  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991: Common YANG Data Types";
  }

  organization "IETF";
  contact
    "WG Web:   <http://tools.ietf.org/wg/rats/>
     WG List:  <mailto:rats@ietf.org>

     Editor:   Eric Voit
               <mailto:evoit@cisco.com>";

  description
    "This module contains conceptual YANG specifications for
    subscribing to attestation streams being generated from TPM chips.

    Copyright (c) 2020 IETF Trust and the persons identified as authors
    of the code.  All rights reserved.

    Redistribution and use in source and binary forms, with or without
    modification, is permitted pursuant to, and subject to the license
    terms contained in, the Simplified BSD License set forth in Section
    4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
    (https://trustee.ietf.org/license-info).



Voit                     Expires August 30, 2020               [Page 16]


Internet-Draft                 trust-path                  February 2020


    This version of this YANG module is part of RFC XXXX; see the RFC
    itself for full legal notices.";

  revision 2020-02-24 {
    description
      "Initial version.";
    reference
      "draft-voit-rats-trusted-path-routing";
  }

  /*
   * FEATURES
   */

  feature passport {
    description
      "This feature indicates that an Attester supports passports.";
  }

  /*
   * IDENTITIES
   */

  identity trustworthiness-level {
    if-feature "passport";
    description
      "Base identity for a verifier assessed trustworthiness level.";
  }

  identity compromised {
    base trustworthiness-level;
    description
      "A Verifier has appraised an Attester as compromised.";
  }

  identity unverified {
    base trustworthiness-level;
    description
      "There is no recent Verifier appraisal of an Attester.";
  }

  identity boot-verified {
    base trustworthiness-level;
    description
      "A Verifier has appraised an Attester as Boot Integrity Verified.";
  }





Voit                     Expires August 30, 2020               [Page 17]


Internet-Draft                 trust-path                  February 2020


  /*
   * Groupings
   */

  grouping tpm-name {
    description
      "Name of a TPM.";
    leaf tpm_name {
      type string;
      description
        "Name of the TPM or All";
    }
  }

  grouping tpm12-attestation {
    description
      "Contains an instance of TPM1.2 style signed cryptoprocessor
      measurements.  It is supplemented by unsigned Attester information.
      The vast majority of the YANG objects in the YANG tree are defined
      within [RATS-YANG].";
    uses tpm-name;
    uses yang-brat:node-uptime;
    uses yang-brat:compute-node;
    uses yang-brat:tpm12-quote-info-common;
    choice tpm12-quote {
      mandatory true;
      description
        "Either a tpm12-quote-info or tpm12-quote-info2, depending
        on whether TPM_Quote or TPM_Quote2 was used
        (cf. input field add-verson).";
      case tpm12-quote1 {
        description
          "BIOS/UEFI event logs";
        uses yang-brat:tpm12-quote-info;
        uses yang-brat:tpm12-pcr-composite;
      }
      case tpm12-quote2 {
        description
          "BIOS/UEFI event logs";
        uses yang-brat:tpm12-quote-info2;
      }
    }
  }


  /*
   * RPCs
   */



Voit                     Expires August 30, 2020               [Page 18]


Internet-Draft                 trust-path                  February 2020


  augment "/sn:establish-subscription/sn:input" {
    description
      "This augmentation adds a nonce to as a subscription parameters
       that apply specifically to datastore updates to RPC input.";
    leaf nonce-value {
      type binary;
      description
        "This nonce should be generated via a registered
        cryptographic-strength algorithm. In consequence, the length
        of the nonce depends on the hash algorithm used. The algorithm
        used in this case is independent from the hash algorithm used to
        create the hash-value in the response of the attestor.";
      reference
        "draft-ietf-rats-yang-tpm-charra";
    }
  }

  augment "/sn:establish-subscription/sn:output" {
    description
      "This augmentation allows a subscriber/verifier to understand the
      state of the Attester at time of subscription.";
    container latest-attestation {
      description
         "provides the current PCR values of a TPM.";
      uses tpm12-attestation;

    /* Awaiting WG progress on draft-ietf-rats-yang-tpm-charra
       before completing for TPM2.0 style.  */

    }
  }

  /*
   * NOTIFICATIONS
   */

  notification tpm-extend {
    description
      "This notification indicates that a PCR has extended within a TPM 1.x
      or 2.0 cryptoprocessor.  Within a small number of seconds, it should be
      followed with a tpm12-attestation or tpm20-attestation.";
    uses yang-brat:tpm-name;
    leaf pcr-index-changed {
      type uint8;
      mandatory true;
      description
        "The number of the PCR extended.";
    }



Voit                     Expires August 30, 2020               [Page 19]


Internet-Draft                 trust-path                  February 2020


    leaf-list extended-with {
      type binary;
      ordered-by user;
      description
        "Includes the one or more elements extending the PCR. The sequence of
        elements represented in list must match the sequence entered into the
        TPM.";
    }
  }

  notification tpm12-attestation {
    description
      "Contains an instance of TPM1.2 style signed cryptoprocessor
      measurements.  It is supplemented by unsigned Attester information.
      The vast majority of the YANG objects in the YANG tree are defined
      within [RATS-YANG].";
    uses tpm12-attestation;
  }

  /* Awaiting WG progress on draft-ietf-rats-yang-tpm-charra before completing
  notification tpm20-attestation {
    description
      "We still need to define the majority of the YANG objects in
      within [RATS-YANG].  Redefining them here would just result in lots of
      unnecessary churn.";
  }
  */

  /*
   * DATA NODES
   */

  container attestation-config {
    description
      "This allows an Attester to determine which TPMs and PCRs are evaluated
        and included within the Attestation Stream.";
    container tpm12-stream {
      description
        "Configuration elements for a TPM1.2 event stream.  This includes
        all of the TPM1.2s which are available on an Attester.";
      list tpm12-stream-config {
        key tpm_name;
        description
          "Allows the stream to be configured for the inclusion of TPM1.2
          quotes and evidence.";
        uses tpm-name;
        uses yang-brat:tpm12-pcr-selection;
        uses yang-brat:tpm12-attestation-key-identifier;



Voit                     Expires August 30, 2020               [Page 20]


Internet-Draft                 trust-path                  February 2020


      }
      uses yang-brat:tpm12-signature-scheme;
    }
    container tpm20-stream {
      description
        "Configuration elements for a TPM2.0 event stream.  This includes
        all of the TPM2.0s which are available on an Attester.";
      list tpm20-stream-config {
        key tpm_name;
        description
          "Allows the stream to be configured for the inclusion of TPM2.0
          quotes and evidence.";
        uses tpm-name;
        list pcr-list {
          description
            "For each PCR in this list an individual list of banks
            (hash-algo) can be requested.";
          key pcr-index;
          leaf pcr-index {
             type uint8;
             description
               "The number of the PCR. At the moment this is limited 32";
          }
          uses yang-brat:hash-algo;
        }
        uses yang-brat:tpm20-attestation-key-identifier;
      }
      uses yang-brat:tpm20-signature-scheme;
      leaf tpm2-heartbeat {
        type uint8;
        description
          "Number of seconds before the Attestation stream should send a new
          Notification which with a fresh quote.  This allows confirmation
          that the PCR values haven't changed since the last
          tpm20-attestation.";
      }
    }
  }
  container attestation-results {
    if-feature "passport";
    description
      "Latest Verifier appraisal of an Attester.";
    leaf-list trustworthiness-level {
      type identityref {
        base trustworthiness-level;
      }
      min-elements 1;
      description



Voit                     Expires August 30, 2020               [Page 21]


Internet-Draft                 trust-path                  February 2020


        "One or more Trustworthiness Levels assigned.";
    }
    leaf timestamp {
      type yang:date-and-time;
      mandatory true;
      description
        "The timestamp of the Verifier's appraisal.";
    }
    leaf tpmt-signature {
      type binary;
      description
        "Must match a recent tpmt-signature sent in a notification to
        a Verifier.  This allows correlation of the Attestation Results to
        a recent PCR change.";
    }
    leaf verifier-signature {
      type binary;
      description
        "Signature of the Verifier across all the current objects in the
        attestation-results container.";
    }
    leaf verifier-signature-key-name {
      type binary;
      description
        "Name of the key the Verifier used to sign the results.";
    }
  }
}
<CODE ENDS>

7.  Passport Protocol Bindings

   This section provides details of how Composite Evidence described in
   Section 4.2 interacts with link layer protocols like [MACSEC] or
   [IEEE-802.1X], YANG subscriptions [RFC8639], and [RFC3748] methods.
   Additional linkages to the YANG module defined in Section 6 are
   described.














Voit                     Expires August 30, 2020               [Page 22]


Internet-Draft                 trust-path                  February 2020


    .--------------.
    |  Verifier A  |
    '--------------'
        ^     (2)
        |     Verifier A signed Attestation Results @time(x) (
    evidence(  |  Trustworthiness Level,
    TpmQuote   |  signature from TpmQuote@time(x) )
    @time(x))  |
       (1)     V
     .-------------.                           .---------------.
     |  Attester   |<------nonce @time(y)---(3)|  Verifier B   |
     |    .-----.  |                           |       /       |
     |    | Tpm |  |(4)-composite evidence ( ->| Relying Party |
     |    '-----'  |      TpmQuote@time(y),    |     (5)       |
     '-------------'      TpmQuote@time(x),    '---------------'
                          Verifier A signed Attestation Results @time(x) )

                 Figure 5: Details of Passport Generation

   Figure 5 above expands upon the previously described Figure 3.  The
   numbering in both figures is the same.

   Step (1)

   Verifier A subscribes to an Attester's <attestation> Event Stream on
   via [RFC8639].  Within the <establish-subscription> RPC, a nonce is
   delivered as per Section 5.1.  This nonce then is included into TPM
   quotes requests driven for the Attester's cryptoprocessor.  The
   result of the TPM quote is appended to the <establish-subscription>
   response.  Following this delivery of a provably current TPM state,
   all the historical evidence needed to validate specific PCRs within
   this quote are delivered on the <attestation> Event Stream via the
   <replay> feature.  Any changes to PCRs results in new notifications
   as described in Section 5.2.  These are continuously streamed to
   Verifier A.

   Step (2)

   Whenever a PCR changes, Verifier A evaluates the totality of the
   Evidence received.  This Evidence may include information not
   provided on the <attestation> Event Stream.  Verifier A then decides
   the Trustworthiness Level of the Attester.  Subsequently it sends
   back a signed Attestation Result which includes the Trustworthiness
   Level and the signature sent as part of (1) from the Attester.  It is
   this signature which allows the Trustworthiness Level to be later
   provably associated with a recent TPM Quote.





Voit                     Expires August 30, 2020               [Page 23]


Internet-Draft                 trust-path                  February 2020


   The delivery of Attestation Results back to the Attester can be done
   via a YANG operational datastore write of the following objects:

     +--rw attestation-results {passport}?
        +--rw trustworthiness-level*         identityref
        +--rw timestamp                      yang:date-and-time
        +--rw tpmt-signature?                binary
        +--rw verifier-signature?            binary
        +--rw verifier-signature-key-name?   binary

                    Figure 6: Attestation Results Tree

   Step (3)

   At time(y) a Relying Party makes a Link Layer connection request to
   an Attester via a protocol such as [MACSEC] or [IEEE-802.1X].  This
   connection request must include [RFC3748] credentials.  Specifics of
   the EAP credentials are TBD.  If there is no central distribution of
   time via [I-D.birkholz-rats-tuda] a nonce must be included to ensure
   freshness of a response.

   This step can repeat periodically independently of any subsequent
   iteration (1) and (2).  This allows for periodic reauthentication of
   the link layer in a way not bound to the updating of Verifier A's
   Attestation Results.

   Step (4)

   Upon receipt of (3), a passport is generated as per Section 4.2, and
   sent to the Relying Party.

   Step (5)

   Upon receipt of (4), the Relying Party verifies the Composite
   Evidence as per Section 4.2.  Most often, the relevant PCR values at
   time(x) will be the same as the PCR values at time(y).  In this case,
   the Relying Party can simply accept the Trustworthiness Level
   assigned by the Verifier A.  When the PCR values are different, and
   not much time has passed between time(x) and time(y), the Relying
   Party can either accept the previous Trustworthiness Level, or
   attempt another EAP request in a few seconds as new Attestation
   Results are delivered by Step (2).  When there is a large time gap
   between time(x) and time(y) and the PCR values are different, the
   Attester should be given an <unverified> Trustworthiness Level.

   Based on the link's Trustworthiness Level, the Relying Party may
   adjust the link affinity of the corresponding FlexAlgo topology.




Voit                     Expires August 30, 2020               [Page 24]


Internet-Draft                 trust-path                  February 2020


8.  Security Considerations

   Successful attacks on an IGP domain Verifier has the potential of
   affecting traffic on the Trusted Topology.

   For Distributed Trusted Path Routing, links which are part of the
   FlexAlgo are visible across the entire IGP domain.  Therefore a
   compromised device will know when it is being bypassed.

   Access control for the objects in Figure 6 should be tightly
   controlled so that it becomes difficult for the passport to become a
   denial of service vector.

9.  References

9.1.  Normative References

   [I-D.ietf-rats-architecture]
              Birkholz, H., Thaler, D., Richardson, M., and N. Smith,
              "Remote Attestation Procedures Architecture", draft-ietf-
              rats-architecture-01 (work in progress), February 2020.

   [RATS-YANG]
              "A YANG Data Model for Challenge-Response-based Remote
              Attestation Procedures using TPMs", January 2020,
              <https://tools.ietf.org/html/draft-ietf-rats-yang-tpm-
              charra-00>.

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

   [RFC8639]  Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
              E., and A. Tripathy, "Subscription to YANG Notifications",
              RFC 8639, DOI 10.17487/RFC8639, September 2019,
              <https://www.rfc-editor.org/info/rfc8639>.

   [TPM1.2]   TCG, ., "TPM 1.2 Main Specification", October 2003,
              <https://trustedcomputinggroup.org/resource/tpm-main-
              specification/>.






Voit                     Expires August 30, 2020               [Page 25]


Internet-Draft                 trust-path                  February 2020


   [TPM2.0]   TCG, ., "TPM 2.0 Library Specification", October 2003,
              <https://trustedcomputinggroup.org/resource/tpm-library-
              specification/>.

9.2.  Informative References

   [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.ietf-idr-segment-routing-te-policy]
              Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
              Rosen, E., Jain, D., and S. Lin, "Advertising Segment
              Routing Policies in BGP", draft-ietf-idr-segment-routing-
              te-policy-08 (work in progress), November 2019.

   [I-D.ietf-lsr-flex-algo]
              Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
              A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
              algo-06 (work in progress), February 2020.

   [IEEE-802.1X]
              Parsons, G., "802.1AE: MAC Security (MACsec)", January
              2020,
              <https://standards.ieee.org/standard/802_1X-2010.html>.

   [KGV]      TCG, ., "KGV", October 2003,
              <https://trustedcomputinggroup.org/wp-content/uploads/TCG-
              NetEq-Attestation-Workflow-Outline_v1r9b_pubrev.pdf>.

   [MACSEC]   Seaman, M., "802.1AE: MAC Security (MACsec)", January
              2006, <https://1.ieee802.org/security/802-1ae/>.

   [RATS-Device]
              Fedorkow, G. and J. Fitzgerald-McKay, "Network Device
              Remote Integrity Verification", n.d.,
              <https://tools.ietf.org/html/draft-fedorkow-rats-network-
              device-attestation-02>.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <https://www.rfc-editor.org/info/rfc3748>.







Voit                     Expires August 30, 2020               [Page 26]


Internet-Draft                 trust-path                  February 2020


Appendix A.  Acknowledgements

   Shwetha Bhandari, Henk Birkholz, Chennakesava Reddy Gaddam, Sujal
   Sheth, Peter Psenak, Nancy Cam Winget, Siva Sivabalan.

Appendix B.  Change Log

   [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.]

Appendix C.  Open Questions

   Functional requirements on how to handle traffic to/from Sensitive
   Subnets when no Trusted Topology exists between IGP edges.

   Deep discussions on the Trustworthiness Levels which need
   standardization.  Perhaps these could be mapped to the "Figure 2:
   Attested Objects" from [RATS-Device].

Author's Address

   Eric Voit
   Cisco Systems, Inc.

   Email: evoit@cisco.com



























Voit                     Expires August 30, 2020               [Page 27]


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