<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-chen-rats-usecase-02">
  <!-- ***** FRONT MATTER ***** -->
  <front>
    <title abbrev="RATS Use Cases">Use Cases for RATS</title>
    <author fullname="Meiling Chen" initials="M." surname="Chen">
     <organization abbrev="China Mobile">
       China Mobile
     </organization>
     <address>
       <postal>
         <street>32, Xuanwumen West </street>
         <city>BeiJing</city>
         <region>BeiJing</region>
         <code>100053</code>
         <country>China</country>
       </postal>
       <email>
         chenmeiling@chinamobile.com
       </email>
     </address>
   </author>
   <author initials="Li." surname="Su" fullname="Li Su">
      <organization>
        China Mobile
      </organization>
      <address>
        <postal>
          <street>
            32, Xuanwumen West
          </street>
          <city>
            BeiJing
          </city>
          <code>
            100053
          </code>
          <country>
            China
          </country>
        </postal>
        <email>
          suli@chinamobile.com
        </email>
      </address>
    </author>
    <date day="26" month="January" year="2021" />
    <area>Security Area</area>
    <workgroup>RATS</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>
        This document presents three scenarios from the Internet Service Providers' perspective as an supplement use case of the RATS work group. And make some discussions of access authentication, application authentication and trusted link. The requirements of trusted link is put forward to establish a protecttive network connection, thus ensure the native network security. 
        </t>
    </abstract>
  </front>

  <middle>
    <section anchor="section_introduction" title="Introduction">
      <t>
        At present, it is necessary to complete the authentication before accessing the operator's network to obtain the service. RATS aimed at the solutions to provide interoperable way for domain-specific attestation mechanisms, within RATS relying party may not to maintain the authentication background, as an ISP what may be involved at the level of access authentication is preshared secret keys based authentication, the authentication based on PSK(Preshared secret keys) is different from identity-based authentication, such as IBC(Identity-Based Cryptograph).
      </t>
       <t>
        After access to the network, operators can also provide application layer authentication services for a variety of applications. At present, there are many application layer authentication methods, it can be divided into certificate-based and non-certificate-based certification systems, so there are the following situations. One application authenticated by certificate-based PKI system may request resource access to a server or service, but the server or service's authentication function is based on identity which is belong to non-certificate-based certification systems. These are all possible future demand scenarios, also in the context of the RATS. Due to limitation of resource, many companies are unable to operate their own certification and willing to rely on the result from operator to reduce their cost, and operator can provide authentication services. Multiple certification centers would be made due to different kinds of request from service and perspective of deployment, before obtaining a certification center's service, certification center need proof for identification, including software and hardware health information. These certification centers are based on regions then there have manage barriers, how can clients from a certification center asstest themselves' identities to another certification center. Especially now there are more virtual resources, cloud resources, one need to prove whether it has access to the resources and can protect the data. From an internal business perspective, how to integrate resources, achieve cross-domain trust and break down management barriers in order to streamline and improve flexibility will also be something rats<xref target="I-D.ietf-rats-architecture"></xref> can do.
      </t>
      <t>
        AS Communication Technology and Internet Technology are converging, especially mobile communication network have stepped into 5G era, besides 5G network slice safety needs attention, basic routing is also need to pay much more attention since damage points of routing nodes will affect the security of the whole link. In some scenarios we need to form a trusted routing link. in the internet draft draft-voit-rats-trustworthy-path-routing-00 also have mentioned this problem.
      </t>
      <t>
      	A trusted link means that every device on the link is proven to be trusted dymaticly. In the real world, a new device or a small network is need to add into the core network, newly added associated equipments are required Security and Trustworthy. After the formation of deterministic networks, three problems need to be solved: how to dynamically check the security of equipment, how to dynamically select the best route based on business requirements, how to ensure computing and security capabilities.
      </t>
    </section>
    <section anchor="section_terms" title="Terminology">
      <t>
        The readers should be familiar with the terms defined in.
      </t>
      <t>
        In addition, this document makes use of the following terms:
      </t>
      <t>
        <list style="hanging">
          <t hangText="PSK:">
           Preshared secret keys means keys are shared in advance between the authentication parties.
          </t>
          <t hangText="IBC:">
           Identity-Based Cryptograph, it is an asymmetric public key cryptosystem. 
          </t>
          <t hangText="PKI:">
           Public Key Infrastructure, an infrastructure built with a public-key mechanism.
          </t>
        </list>
      </t>
    </section>
    <section anchor="section_use_cases" title="Use Cases">
      <t>
        This section describes use cases which happens inside an ISP.
      </t>
      <section anchor="section_use_cases_access_authentication" title="Access authentication based on different method">   
          <t>
            This section considers the level of access authentication. For operators, the access of users is usually based on preshared secret keys, preset with symmetric secret keys before the release. The first access only needs to be activated, and subsequent authentication uses PSK to complete data protection which is based on Symmetric secret key system. In addition, there are other identity-based authentication methods, the access authentication based on identity is asymmetric and the identity is the public key, this approach makes it easier for the peer to obtain the public key of the other peer.
          </t>
          <t>
            In short, these are two different authentication methods. When a psk-based authentication device needs to request an identity-based service, it needs to prove its' trustworthiness to the other party and the whole process need to ensure the confidentiality of evidences and attestation results. 
          </t>
          <t>
            <figure align="center">
              <artwork><![CDATA[

             （relying party1)               (relying party2)
             +---------------+              +---------------+
             |PSK Auth_Center|              |IBC Auth_Center|
             +---------------+              +---------------+
                    |\          +------------//      |
                    |Evidence  /Attestation          |
       Attestation  |         /    Result            |
           Result  \|        /                       |
          +-------------------+       +-------------------+
         |App/SIMCard/IoTCard|         |App/SIMCard/IoTCard|
        +-------------------+           +-------------------+ 
              (attester)

         Figure 1: different access authentication methods within RATS

              ]]></artwork>
            </figure>
          </t>
          <t>
            The format and content of the evidence: TBD
          </t>
          <t>
            The format of the Attestation Result: TBD
          </t>
          <t>
            The transmission protocol for evidence or attestation result: TBD
          </t>
        </section>
        <section anchor="section_use_cases_app_authentication" title="Application authentication based on different system">
          <t>
            At the application level, due to limitation of resource, many applications need operators to provide business authentication services. At present, there are two business authentication methods: one is certification-based PKI system authentication, because the management of certificates is always a very big problem, so the other is non-certificated, such as identity-based authentication whose identity is readable.  
          </t>
          <t>
           When cross-business authentication is required, how to prove one's identity to the other will be a common problem.
          </t>
          <t>
            <figure align="left">
              <artwork><![CDATA[

           (relying party1)                            (relying party2)
  +-----------------------------------+     +-----------------------------------+
  |Application authentication platform|     |Application authentication platform|
  |     based on certificate          |-----|      based on non-certificate     |
  +-----------------------------------+     +-----------------------------------+
                    |        {Attestation}  /|                  |
                    |        {    Result } /                    |
                    |           ----------                      |
                    |         /                                 |
            +---------------+                           +---------------+
            |  application  |                           |  application  |
            +---------------+                           +---------------+
                 (attester1)                                (attester2)

  Figure 2: different application authentication methods in RATS architecture
        ]]></artwork>
            </figure>
          </t>
           <t>
            The format and content of the evidence: TBD
          </t>
            <t>
              The format of the Attestation Result: TBD
            </t>
            <t>
              The transmission protocol for evidence or attestation result: TBD
            </t>
            <t>
              Certification-based authentication process: TBD
            </t>
            <t>
              Identity-based authentication process: TBD
          </t>
        </section>
      
    <section anchor="section_use_cases_trusted_routing" title="Use case based on trusted routing">
      <t>
        5G provides security slices based on routing security, routing devices can be hijacked because of vulnerabilities, damaged equipment could be monitored, so ISP need to be able to dynamically retrieve the status of routing devices, according to the state of the devices dynamicly form a safety link, RATS needs to be used in this case. There are two scenarios for this case: a trusted link is formed within a single operator and a trusted link is formed across operators. The default prerequisite is routing devices support TPM or other relevant standard. 
      </t>
      <t>
            <figure align="left">
              <artwork><![CDATA[
              +---------------------------------+
              |                                 |
              |  Trusted Identification System  |
              |                                 |
              +-------- -------^--+-------------+
                               |  |
                               |  |
                               |  |
           Device Conditions   |  | Latest trusted status
            (evidence)or       |  |
            (Appraisal results)|  |
                               |  |
+-----------------+            |  |          +------------------+
|                 |            |  |          |                  |
| Routing Device  +------------+  +---------->   Orchestrator   |
|                 |                          |                  |
+-----------------+                          +--------+---------+
                                                      |
                                                      v
                                            Form a routing path
  Figure 3: a trusted link is formed within an ISP in RATS
        ]]></artwork>
            </figure>
          </t>
           <t>
            <figure align="left">
              <artwork><![CDATA[
         ISP A                                         ISP B
+-------------------+                          +--------------------+
|                   |      Appraisal results   |                    |
|  Trusted Path     +-------------------------^+    Trusted Path    |
|                   <--------------------------+                    |
+-------------------+ cross-domain trusted link+--------------------+

  Figure 4: a trusted link is formed between ISPs in RATS
        ]]></artwork>
            </figure>
          </t>
    </section>

    </section>
    <section title="Requirements of trusted link">
    	<t>
    	From the operator's point of view, a more secure link capability will be more competitive for external service. Therefore, Operators attach great importance to the innate security of links, the links innate security highly relied on each networking device that is the routing equipment.
    </t>
    	<section title="New equipment into the network">
    		<t>
    			How to add a new device to the network without the consideration of trustworthiness? new routing devices go through four steps before they are actually added to the network, step 1: manually configure the IP address; step 2: discovery device by broadcast protocol; step 3: Verify the identity of the device; step 4: Device Manager issues routing configuration policies. After completing these four steps, the route neighbor is formed.
    		</t>
    		<t>
            <figure align="left">
              <artwork><![CDATA[
           +------------+
   +-------+Orchestrator+---------+
   |       +----+--+----+         |
   |            |  ^              |
   |       step2|  |step3         |
   |       step4|  |              |
   |            v  |              |
+--+-+         ++--++          +--+-+
| RT |         | RT |step1     | RT |
+----+         +----+          +----+
                NEW
Figure 5-1: a new router added to network
        ]]></artwork>
            </figure>
          </t>
          <t>
    			How to add a new device to the network with the consideration of devices' trustworthiness? A trusted link has been formed by default, when a new equipment apply to join the network, new router should provide evidences to the verifier, the orchestrator play the role of verifier, and feed back the attestation result back to the new router, it depends on the implementation. Provision of evidence and trustworthiness assessment actually happens in the Step3 which described in the figure above. After complete the trustworthiness assessment, the orchestrator forms routing policies based on the trustworthiness and issues them, the trusted link establishment is complete.
    		</t>
    		<t>
            <figure align="left">
              <artwork><![CDATA[
       +------------------------------------+
       |                                    |
       | +------------+                     |
 Step3 | |            |       Result +----+ |
       | |Ochestrator +<-------------> RT | |
       | +-----+------+  evidence    +----+ |
       |       |                       NEW  |
       +------------------------------------+
               |
+--------------+--------------------------+
|  +----+         +----+          +----+  |
|  | RT +---------+ RT +----------+ RT |  |
|  +----+   1     +----+     2    +----+  |
+-----------------------------------------+
            Trusted link

Figure 5-2: a new router added to network
        ]]></artwork>
            </figure>
          </t>
    	</section>

    	<section title="Device status updating">
    		<t>
    			How to maintain the freshness of trusted links for the network is always under threat of attack when need to form a trusted link to provide to the user for transmission. The Ochestrator can collect routing information in real time or periodically, including device information, log information, fault information, and trusty measure vendors. Then Ochestrator forms a path link based on users' trustworthiness requirements while the whole network has fault convergence.
    		</t>
    		<t>
            <figure align="left">
              <artwork><![CDATA[
            +-----------+
            |Ochestrator|
            +-+--+---+--+
              ^  ^   ^
              |  |   |
   +----------+  |   +-----------+
   |          evidence           |
   |             |               |
+--+-+         +-+--+          +-+--+
| RT +---------+ RT +----------+ RT |
+----+   1     +----+     2    +----+

             Trusted link

Figure 6: a new router added to network
        ]]></artwork>
            </figure>
          </t>
    	</section>
    </section>
    <section title="Security Considerations">
      <t>
        TBD
      </t>
    </section>
    <section title="IANA Considerations">
      <t>
        This document does not require any action from IANA.
      </t>
    </section>
    <section title="Acknowledgement">
      <t>
        TBD
      </t>
    </section>
  </middle>
  <!-- ***** BACK MATTER ***** -->
  <back>
    
    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-rats-architecture'?>
      
    </references>
    <!-- Appendix -->
  </back>
</rfc>