idnits 2.17.1 draft-chen-rats-usecase-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2020) is 1318 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-05 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS M. Chen 3 Internet-Draft Li. Su 4 Intended status: Informational China Mobile 5 Expires: March 14, 2021 September 10, 2020 7 Use Cases for RATS 8 draft-chen-rats-usecase-01 10 Abstract 12 This document presents two three scenarios from the Internet Service 13 Providers' perspective as an supplement use case of the RATS work 14 group. And make some discussions of access authentication, 15 application authentication and trusted link. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 14, 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Access authentication based on different method . . . . . 3 55 3.2. Application authentication based on different system . . 4 56 3.3. Use case based on trusted routing . . . . . . . . . . . . 5 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 60 7. Informative References . . . . . . . . . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 At present, it is necessary to complete the authentication before 66 accessing the operator's network to obtain the service. RATS aimed 67 at the solutions to provide interoperable way for domain-specific 68 attestation mechanisms, within RATS relying party may not to maintain 69 the authentication background, as an ISP what may be involved at the 70 level of access authentication is preshared secret keys based 71 authentication, the authentication based on PSK(Preshared secret 72 keys) is different from identity-based authentication, such as 73 IBC(Identity-Based Cryptograph). 75 After access to the network, operators can also provide application 76 layer authentication services for a variety of applications. At 77 present, there are many application layer authentication methods, it 78 can be divided into certificate-based and non-certificate-based 79 certification systems, so there are the following situations. One 80 application authenticated by certificate-based PKI system may request 81 resource access to a server or service, but the server or service's 82 authentication function is based on identity which is belong to non- 83 certificate-based certification systems. These are all possible 84 future demand scenarios, also in the context of the RATS. Due to 85 limitation of resource, many companies are unable to operate their 86 own certification and willing to rely on the result from operator to 87 reduce their cost, and operator can provide authentication services. 88 Multiple certification centers would be made due to different kinds 89 of request from service and perspective of deployment, before 90 obtaining a certification center's service, certification center need 91 proof for identification, including software and hardware health 92 information. These certification centers are based on regions then 93 there have manage barriers, how can clients from a certification 94 center asstest themselves' identities to another certification 95 center. Especially now there are more virtual resources, cloud 96 resources, one need to prove whether it has access to the resources 97 and can protect the data. From an internal business perspective, how 98 to integrate resources, achieve cross-domain trust and break down 99 management barriers in order to streamline and improve flexibility 100 will also be something rats[I-D.ietf-rats-architecture] can do. 102 AS Communication Technology and Internet Technology are converging, 103 especially mobile communication network have stepped into 5G era, 104 besides 5G network slice safety needs attention, basic routing is 105 also need to pay much more attention since damage points of routing 106 nodes will affect the security of the whole link. In some scenarios 107 we need to form a trusted routing link. in the internet draft draft- 108 voit-rats-trustworthy-path-routing-00 also have mentioned this 109 problem. 111 2. Terminology 113 The readers should be familiar with the terms defined in. 115 In addition, this document makes use of the following terms: 117 PSK: Preshared secret keys means keys are shared in advance between 118 the authentication parties. 120 IBC: Identity-Based Cryptograph, it is an asymmetric public key 121 cryptosystem. 123 PKI: Public Key Infrastructure, an infrastructure built with a 124 public-key mechanism. 126 3. Use Cases 128 This section describes use cases which happens inside an ISP. 130 3.1. Access authentication based on different method 132 This section considers the level of access authentication. For 133 operators, the access of users is usually based on preshared secret 134 keys, preset with symmetric secret keys before the release. The 135 first access only needs to be activated, and subsequent 136 authentication uses PSK to complete data protection which is based on 137 Symmetric secret key system. In addition, there are other identity- 138 based authentication methods, the access authentication based on 139 identity is asymmetric and the identity is the public key, this 140 approach makes it easier for the peer to obtain the public key of the 141 other peer. 143 In short, these are two different authentication methods. When a 144 psk-based authentication device needs to request an identity-based 145 service, it needs to prove its' trustworthiness to the other party 146 and the whole process need to ensure the confidentiality of evidences 147 and attestation results. 149 （relying party1) (relying party2) 150 +---------------+ +---------------+ 151 |PSK Auth_Center| |IBC Auth_Center| 152 +---------------+ +---------------+ 153 |\ +------------// | 154 |Evidence /Attestation | 155 Attestation | / Result | 156 Result \| / | 157 +-------------------+ +-------------------+ 158 |App/SIMCard/IoTCard| |App/SIMCard/IoTCard| 159 +-------------------+ +-------------------+ 160 (attester) 162 Figure 1: different access authentication methods within RATS 164 The format and content of the evidence: TBD 166 The format of the Attestation Result: TBD 168 The transmission protocol for evidence or attestation result: TBD 170 3.2. Application authentication based on different system 172 At the application level, due to limitation of resource, many 173 applications need operators to provide business authentication 174 services. At present, there are two business authentication methods: 175 one is certification-based PKI system authentication, because the 176 management of certificates is always a very big problem, so the other 177 is non-certificated, such as identity-based authentication whose 178 identity is readable. 180 When cross-business authentication is required, how to prove one's 181 identity to the other will be a common problem. 183 (relying party1) (relying party2) 184 +-----------------------------------+ +-----------------------------------+ 185 |Application authentication platform| |Application authentication platform| 186 | based on certificate |-----| based on non-certificate | 187 +-----------------------------------+ +-----------------------------------+ 188 | {Attestation} /| | 189 | { Result } / | 190 | ---------- | 191 | / | 192 +---------------+ +---------------+ 193 | application | | application | 194 +---------------+ +---------------+ 195 (attester1) (attester2) 197 Figure 2: different application authentication methods in RATS architecture 199 The format and content of the evidence: TBD 201 The format of the Attestation Result: TBD 203 The transmission protocol for evidence or attestation result: TBD 205 Certification-based authentication process: TBD 207 Identity-based authentication process: TBD 209 3.3. Use case based on trusted routing 211 5G provides security slices based on routing security, routing 212 devices can be hijacked because of vulnerabilities, damaged equipment 213 could be monitored, so ISP need to be able to dynamically retrieve 214 the status of routing devices, according to the state of the devices 215 form a safety link, RATS needs to be used in this case. There are 216 two scenarios for this case: a trusted link is formed within a single 217 operator and a trusted link is formed across operators. The default 218 prerequisite is routing devices support TPM or other relevant 219 standard. 221 +---------------------------------+ 222 | | 223 | Trusted Identification System | 224 | | 225 +-------- -------^--+-------------+ 226 | | 227 | | 228 | | 229 Device Conditions | | Latest trusted status 230 (evidence)or | | 231 (Appraisal results)| | 232 | | 233 +-----------------+ | | +------------------+ 234 | | | | | | 235 | Routing Device +------------+ +----------> Orchestrator | 236 | | | | 237 +-----------------+ +--------+---------+ 238 | 239 v 240 Form a routing path 242 Figure 3: a trusted link is formed within an ISP in RATS 244 ISP A ISP B 245 +-------------------+ +--------------------+ 246 | | Appraisal results | | 247 | Trusted Path +-------------------------^+ Trusted Path | 248 | <--------------------------+ | 249 +-------------------+ cross-domain trusted link+--------------------+ 251 Figure 4: a trusted link is formed between ISPs in RATS 253 4. Security Considerations 255 TBD 257 5. IANA Considerations 259 This document does not require any action from IANA. 261 6. Acknowledgement 263 TBD 265 7. Informative References 267 [I-D.ietf-rats-architecture] 268 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 269 W. Pan, "Remote Attestation Procedures Architecture", 270 draft-ietf-rats-architecture-05 (work in progress), July 271 2020. 273 Authors' Addresses 275 Meiling Chen 276 China Mobile 277 32, Xuanwumen West 278 BeiJing, BeiJing 100053 279 China 281 Email: 282 chenmeiling@chinamobile.com 284 Li Su 285 China Mobile 287 32, Xuanwumen West 289 BeiJing 291 100053 293 China 295 Email: 296 suli@chinamobile.com