<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-rein-remote-attestation-nfv-use-cases-01"
     ipr="trust200902">
  <front>
    <title abbrev="Remote Attestation NFV Use Cases">The Remote Attestation
    NFV Use Cases</title>

    <author fullname="Andre Rein" initials="A." surname="Rein">
      <organization>Huawei</organization>

      <address>
        <email>Andre.Rein@huawei.com</email>
      </address>
    </author>

    <author fullname="Liang Xia" initials="L." surname="Xia">
      <organization>Huawei</organization>

      <address>
        <email>frank.xialiang@huawei.com</email>
      </address>
    </author>

    <date day="04" month="September" year="2018"/>

    <abstract>
      <t>This document proposes the use cases on an architectural level in
      terms of Remote Attestation for virtualized environments, especially in
      the context of Network Function Virtualization (NFV).</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <section title="Stakeholders">
        <t>Stakeholders play a major role in NFV and there is a strict
        hierarchical separation between the stakeholders in terms of
        responsibility, accessibility and visibility within the the NFV
        architecture. Although these issues are also relevant for other
        virtualized environments, for example in private or hybrid clouds,
        they are most apparent in NFV, especially in multi vendor
        deployments.</t>

        <t>The stakeholders in NFV are:<list style="symbols">
            <t>Cloud Service Provider (CSP): The CSP provides the platform,
            i.e. the hardware and core services, acting as the Virtual Machine
            Manager (VMM) or hypervisor for the provisioning of Virtual
            Machines (VM). With regard to this document, the CSP is not
            responsible for the provisioning itself. The CSP only provides the
            platform w.r.t. to CSP NFV Infrastructure (CSP:NFVI) role. The
            actual provisioning of specific VMs is carried out by the CSP
            Management and Orchestration (CSP:MANO) role, whereas both roles
            may be represented by the same or different organizations. This
            contribution, however, is not concerned with the internal
            operations and procedures of the CSP:MANO and therefore does
            address CSP:MANO neither as a role nor as a functional
            component.</t>

            <t>Cloud Service Customer (CSC): The CSC is the actual user of the
            VMM and requests the provisioning of specific VMs that eventually
            provide some service. The CSC is also in full control in terms of
            which specific VM is actually launched and thus not constrained in
            this regard.</t>

            <t>Cloud Service User (CSU): The CSU is an external entity that
            uses the CSC's provided services. The CSU only has access to
            public API's provided by the offered service and has neither any
            responsibilities nor obligations within the NFV internals.</t>
          </list></t>
      </section>

      <section title="Major Issue">
        <t>The most significant issue related to remote attestation is that
        the stakeholders may be constrained with regards to the information
        available to them. This means that in a strict model that involves a
        multi-vendor NFV deployment, access to certain information may only be
        available to one particular stakeholder. For instance, the CSP may
        only have direct access to the collected platform information and not
        to the information of provisioned VMs. Similarly, the CSC may be
        limited to the information collected on the provisioned VMs and does
        not have access to the information of the platform. This issue can be
        resolved by generally allowing the access to the information to all
        interested entities, w.r.t. a relaxed model, or allowing the access
        based on the enforcement of access permission policies.</t>

        <t>More severe is the information necessary to carry out an appraisal
        of the measured information, that is the information about the
        expected configuration of the specific entity.</t>

        <t>In principle there are two concerns, either this appraisal
        information should not be made available to a different entity (a
        stakeholder from a different organization) or the other entity does
        not want to carry out the appraisal by itself for any system not under
        its control. This means, even under the consideration that the
        collected information is shared between multiple stakeholders, the
        information necessary for carrying out the appraisal may not be
        available for different reasons.</t>

        <t>To simplify the terminology, this contribution distinguishes
        between Remote Attestation Information Providers (RAIP) and Remote
        Attestation Information Consumers (RAIC). In particular:<list
            style="symbols">
            <t>CSP is limited to acting only as a RAIP for all authorized
            entities</t>

            <t>CSC is limited to acting as a RAIP for all authorized entities
            and is a specific RAIC of CSP</t>

            <t>RATP is limited to acting as a RAIP for all authorized entities
            and is a specific RAIC of CSP and CSC</t>
          </list></t>

        <t>Furthermore a new term, the Level of Assurance (LoA) is introduced.
        The LoA is defined as an hierarchical model that specifies the systems
        and components to be attested and whether an attestation is carried
        out on a local or remote basis.</t>

        <t>With regards to this document, the overall targeted LoA equivalent
        to the NFV defined LoA levels 4 and 5 that corresponds to the remote
        attestation of the VMMs and VMs including the appraisal of load and
        runtime of applications within the VM's scope.</t>
      </section>
    </section>

    <section title="Terminology">
      <section title="Key Words">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in [RFC2119].</t>
      </section>

      <section title="Definition of Terms"/>
    </section>

    <section title="Remote Attestation Use Cases">
      <t>With regard to the main issue mentioned above, there are two
      options:<list style="symbols">
          <t>Decentralized Model: Each entity carries out the remote
          attestation only for the particular system under its control. This
          is referred to as the decentralized remote attestation model and
          involved multiple remote attestation servers.</t>

          <t>Centralized Model: A new entity, referred to as a Remote
          Attestation Trusted Party (RATP), is introduced that has access to
          all information necessary to carry out a remote attestation on its
          own. This is referred to as the centralized remote attestation
          model.</t>
        </list></t>

      <t>However, the goal of the remote attestation is to convince an
      internal or external entity that a specific service (a networking
      function) has been provided by a trusted VM that was executed on a
      trusted VMM. For case (1.) this implies that the internal or external
      entity that want to know about the trustworthiness of a service must
      inherently trust the appraised results of both, the CSP and CSC. For
      case (2.) this means that the internal or external entity must only
      trust in the decision made by the RATP.</t>

      <section title="Decentralized Model Use Case">
        <t>In this case there are multiple independent remote attestation
        servers controlled and maintained by the CSP or CSC stakeholders.</t>

        <t>Assumptions:<list style="symbols">
            <t>It is assumed that the model satisfies LoA of 4 and 5</t>
          </list></t>

        <t>Pre-Conditions:<list style="symbols">
            <t>Relevant collected evidence (RA measurement information) is
            available. Access permissions policies are either defined or
            enforced, or information is available to all RAICs.</t>

            <t>Role-specific RA appraisal information is available to the
            RAIC, but limited to the systems and components directly managed
            by the corresponding stakeholder.</t>
          </list></t>

        <t>Use case description:</t>

        <t>A deployed NFV system consists of multiple RAIPs and RAICs that are
        under the control of stakeholders from different organizations. The
        RAIPs collect evidence on systems and offer this information, for the
        purpose of appraising them, to RAICs that are also under the control
        of stakeholders from the same organization.</t>

        <t>For example, any RAIP under the control of stakeholder S1 will only
        share its collected evidence with RAICs that are also under the
        control of stakeholder S1.</t>

        <t>In addition, the information necessary to carry out an appraisal of
        the collected evidences (i.e., the RA appraisal information) are
        limited; RAICs from stakeholder S1 only have access to appraisal
        information for RAIPs that are under the control of the same
        stakeholder, i.e. S1. For this reason, a RAIC can only appraise
        collected evidence from a RAIP operated by the same stakeholder.</t>

        <t>For example, there is RAIP1 (i.e. a VMM) and RAIC1 both under the
        control of CSP. RAIC1 receives the collected evidence from RAIP1,
        appraises it and makes a statement based on the appraised evidence
        (i.e. AR1).</t>

        <figure>
          <artwork>          VMM
        --------       --------     -----
CSP:    |RAIP 1|  ---&gt; |RAIC 1| --&gt; |AR1|
        --------       --------     -----
</artwork>
        </figure>

        <t>Similarly, there is RAIP2 (i.e. a VM instantiated on top of CSP's
        VMM) and RAIC2 both under the control of CSC. RAIC2 receives the
        collected evidence from RAIP2, appraises it and makes a statement
        based on the appraised evidence (i.e. AR2).</t>

        <figure>
          <artwork>           VM
        --------       --------     -----
CSC:    |RAIP 2|  ---&gt; |RAIC 2| --&gt; |AR2|
        --------       --------     -----
</artwork>
        </figure>

        <t>Under the consideration of the requirements defined by LoA 4 and 5
        a single RAIC does not have the capability to satisfy these
        requirements. More specifically this means that at least CSP's and
        CSC's RAICs must work together to be compliant to LoA 4 and 5
        requirements. As a result, RAICs may share appraisal results with
        other RAICs or other external entities. This sharing may be
        constrained by access permission policies. For instance an external
        entity may request AR1 from RAIC1 and AR2 from RAIC2 and derive AR12
        under the assumption it trusts the individual appraised results from
        either RAIC.</t>

        <figure>
          <artwork>--------       --------    -----   
|RAIP 1|  ---&gt; |RAIC 1| --&gt;|AR1|--|
--------       --------    -----  |     -----------------     ------
                                  |---&gt; |external entity|----&gt;|AR12|
--------       --------    -----  |     -----------------     ------
|RAIP 2|  ---&gt; |RAIC 2| --&gt;|AR2|--|
--------       --------    -----
</artwork>
        </figure>

        <t>However, the appraisal result generated from any other system but a
        RAIC (e.g. derived by an arbitrary external entity) is not trusted by
        any other entity (e.g. CSP, CSC or CSU). This mean that in this case
        AR12 only has any semantic meaning for the system (i.e. external
        entity) who derived it.</t>

        <t>Alternatively, RAIC2 may use AR1 as an additional input to RAIP2's
        collected evidence input and derive AR12 accordingly. This is also
        under the consideration that RAIC2 implicitly trusts the statement
        made by RAIC1.</t>

        <figure>
          <artwork>          VMM
        --------       --------     -----
CSP:    |RAIP 1|  ---&gt; |RAIC 1| --&gt; |AR1|
        --------       --------     -----
                                      |
                           ,----------'
                           |
           VM              v
        --------       --------     ------
CSC:    |RAIP 2|  ---&gt; |RAIC 2| --&gt; |AR12|
        --------       --------     ------
</artwork>
        </figure>

        <t>In this case, AR12 is derived from CSC's RAIC and therefore other
        systems do trust this statement because it came from an authorized
        entity within the system.</t>

        <t>See the summary table as below:</t>

        <figure>
          <artwork>+-------------+------------+-------------+-----------+------------+
|             |    CSP     |    CSC      |    CSU    |   External |
|             |            |             |           |   Entity   |
+=============+============+=============+===========+============+
| Provides    |  anyone    |   anyone    | -         | -          |
| RA          | authorized | authorized  |           |            |
| measurement |            |             |           |            |
| information |            |             |           |            |
|             |            |             |           |            |
+-------------+------------+-------------+-----------+------------+
| Has RA      | Only CSP   | Only CSC    | -         | -          |
| appraisal   |            |             |           |            |
| information |            |             |           |            |
|             |            |             |           |            |
+-------------+------------+-------------+-----------+------------+
| Provides    |  anyone    |  anyone     | -         | -          |
| RA          | authorized | authorized  |           |            |
| appraisal   |            |             |           |            |
| results     |            |             |           |            |
|             |            |             |           |            |
+-------------+------------+-------------+-----------+------------+
| Has         | From CSP   | From CSC    | From CSC  | From CSC   |
| access to   | and, if    | and, if     | or CSP    | or CSP     |
| RA          | eligible,  | eligible,   | (if       | (if        |
| Appraisal   | CSC        | CSP         | eligible) | eligible)  |
| Results     |            |             |           |            |
|             |            |             |           |            |
+-------------+------------+-------------+-----------+------------+ </artwork>
        </figure>
      </section>

      <section title="Centralized Model (in a Single Trust Domain) Use Case">
        <t>In this case there are multiple independent remote attestation
        servers controlled and maintained by the CSP or CSC stakeholders.</t>

        <t>Assumptions:<list style="symbols">
            <t>It is assumed that the model satisfies LoA of 4 and 5</t>
          </list></t>

        <t>Pre-Conditions:<list style="symbols">
            <t>Relevant collected evidence (RA measurement information) is
            available to RATP without any restriction.</t>

            <t>Role-specific RA appraisal information is available to RATP
            without any restriction.</t>
          </list></t>

        <t>Use case description:</t>

        <t>A deployed NFV system consists of multiple RAIPs and RAICs that are
        under the control of stakeholders from different organizations and, in
        addition one RATP that is implicitly trusted by the other entities in
        the system. The RAIPs collect evidence on systems and offer this
        information, for the purpose of appraising them, to RAICs that are
        also under the control of stakeholders from the same organization or
        to RATP.</t>

        <t>For example, any RAIP under the control of stakeholder S1 will only
        share its collected evidence with RAICs that are also under the
        control of stakeholder S1 and RATP.</t>

        <t>In addition, the information necessary to carry out an appraisal of
        the collected evidences (i.e., the RA appraisal information) are
        limited; RAICs from stakeholder S1 only have access to appraisal
        information for RAIPs that are under the control of the same
        stakeholder, i.e. S1.</t>

        <t>In contrast to this, RATP has access to all appraisal information
        of any system under evaluation from all stakeholders, i.e. CSP and
        CSC.</t>

        <t>Similar to use-case 1, a RAIC can only appraise collected evidence
        from a RAIP operated by the same stakeholder, whereas RATP can
        appraise collected evidence from all stakeholders.</t>

        <t>For example, there is RAIP1 (i.e. a VMM) under the control of CSP
        and RATP. RATP receives the collected evidence from RAIP1, appraises
        it and makes a statement based on the appraised evidence (i.e.
        AR1).</t>

        <figure>
          <artwork>          VMM
        --------       ------     -----
CSP:    |RAIP 1|  ---&gt; |RATP| --&gt; |AR1|
        --------       ------     -----
</artwork>
        </figure>

        <t>Similarly, there is RAIP2 (i.e. a VM instantiated on top of CSP's
        VMM) under the control of CSC and RATP. RAIC2 receives the collected
        evidence from RAIP2, appraises it and makes a statement based on the
        appraised evidence (i.e. AR2).</t>

        <figure>
          <artwork>           VM
        --------       ------     -----
CSC:    |RAIP 2|  ---&gt; |RATP| --&gt; |AR2|
        --------       ------     -----
</artwork>
        </figure>

        <t>Under the consideration of the requirements defined by LoA 4 and 5,
        RATP satisfies these requirements under the assumption that it
        received the correlated collected evidences from both VMM and VM. RATP
        may share its appraisal results with any other entity, however, access
        permissions policies may constrain access to the information. For
        instance, considering access permissions allow it, an external entity
        may request AR12 from RATP.</t>

        <figure>
          <artwork>--------          
|RAIP 1|  -,  
--------   |   ------      ------    -----------------
            -&gt; |RATP| ---&gt; |AR12| -&gt; |external entity|
--------   |   ------      ------    -----------------
|RAIP 2|  -'  
--------       
</artwork>
        </figure>

        <t>Important to note in this case is that the appraisal result
        provided by RATP is ultimately trusted by all participating systems
        from any stakeholder and all external entities the request this
        appraisal result.</t>

        <t>See the summary table as below:</t>

        <figure>
          <artwork>+-------------+-----------+-----------+-----------+-----------+-----------+
|             |   CSP     |    CSC    |    CSU    |    RATP   | External  |
|             |           |           |           |           | System    |
+=============+===========+===========+===========+===========+===========+
| Provides    | To RATP   | To RATP   | -         | -         |           |
| RA          | or CSP    | or CSC    |           |           |           |
| measurement |           |           |           |           |           |
| information |           |           |           |           |           |
+-------------+-----------+-----------+-----------+-----------+-----------+
| Has RA      | Only CSP  | Only CSC  | -         | CSP and   |           |
| appraisal   |           |           |           | CSC       |           |
| information |           |           |           |           |           |
+-------------+-----------+-----------+-----------+-----------+-----------+
| Provides RA | -         | -         | -         | For CSP,  |           |
| appraisal   |           |           |           | CSC, CSU, |           |
| results     |           |           |           | External  |           |
|             |           |           |           | system    |           |
|             |           |           |           | (access   |           |
|             |           |           |           | restricti |           |
|             |           |           |           | ons       |           |
|             |           |           |           | may be    |           |
|             |           |           |           | defined)  |           |
+-------------+-----------+-----------+-----------+-----------+-----------+
| Has access  | From RATP | From RATP | From RATP | From RATP | From RATP |
| to RA       |           |           |           |           |           |
| Appraisal   | (if       | (if       | (if       | (if       | (if       |
| results     | eligible) | eligible) | eligible) | eligible) | eligible) |
|             |           |           |           |           |           |
|             |           |           |           |           |           |
+-------------+-----------+-----------+-----------+-----------+-----------+</artwork>
        </figure>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>To be added.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t/>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
    </references>
  </back>
</rfc>
