idnits 2.17.1 draft-chen-rats-usecase-00.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 (March 7, 2020) is 1505 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-02 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: September 8, 2020 March 7, 2020 7 Use Cases for RATS 8 draft-chen-rats-usecase-00 10 Abstract 12 This document presents two demand scenarios from the Internet Service 13 Providers' perspective as an supplement use case of the RATS work 14 group. And make some discussions from the two dimensions of access 15 authentication and application authentication. 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 September 8, 2020. 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 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 59 7. Informative References . . . . . . . . . . . . . . . . . . . 5 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 At present, it is necessary to complete the authentication before 65 accessing the operator's network to obtain the service. RATS aimed 66 at the solutions to provide interoperable way for domain-specific 67 attestation mechanisms, within RATS relying party may not to maintain 68 the authentication background, as an ISP what may be involved at the 69 level of access authentication is preshared secret keys based 70 authentication, the authentication based on PSK(Preshared secret 71 keys) is different from identity-based authentication, such as 72 IBC(Identity-Based Cryptograph). 74 After access to the network, operators can also provide application 75 layer authentication services for a variety of applications. At 76 present, there are many application layer authentication methods, it 77 can be divided into certificate-based and non-certificate-based 78 certification systems, so there are the following situations. One 79 application authenticated by certificate-based PKI system may request 80 resource access to a server or service, but the server or service's 81 authentication function is based on identity which is belong to non- 82 certificate-based certification systems. These are all possible 83 future demand scenarios, also in the context of the RATS. Due to 84 limitation of resource, many companies are unable to operate their 85 own certification and willing to rely on the result from operator to 86 reduce their cost, and operator can provide authentication services. 87 Multiple certification centers would be made due to different kinds 88 of request from service and perspective of deployment, before 89 obtaining a certification center's service, certification center need 90 proof for identification, including software and hardware health 91 information. These certification centers are based on regions then 92 there have manage barriers, how can clients from a certification 93 center asstest themselves' identities to another certification 94 center. Especially now there are more virtual resources, cloud 95 resources, one need to prove whether it has access to the resources 96 and can protect the data. From an internal business perspective, how 97 to integrate resources, achieve cross-domain trust and break down 98 management barriers in order to streamline and improve flexibility 99 will also be something rats[I-D.ietf-rats-architecture] can do. 101 2. Terminology 103 The readers should be familiar with the terms defined in. 105 In addition, this document makes use of the following terms: 107 PSK: Preshared secret keys means keys are shared in advance between 108 the authentication parties. 110 IBC: Identity-Based Cryptograph, it is an asymmetric public key 111 cryptosystem. 113 PKI: Public Key Infrastructure, an infrastructure built with a 114 public-key mechanism. 116 3. Use Cases 118 This section describes use cases which happens inside an ISP. 120 3.1. Access authentication based on different method 122 This section considers the level of access authentication. For 123 operators, the access of users is usually based on preshared secret 124 keys, preset with symmetric secret keys before the release. The 125 first access only needs to be activated, and subsequent 126 authentication uses PSK to complete data protection which is based on 127 Symmetric secret key system. In addition, there are other identity- 128 based authentication methods, the access authentication based on 129 identity is asymmetric and the identity is the public key, this 130 approach makes it easier for the peer to obtain the public key of the 131 other peer. 133 In short, these are two different authentication methods. When a 134 psk-based authentication device needs to request an identity-based 135 service, it needs to prove its' trustworthiness to the other party 136 and the whole process need to ensure the confidentiality of evidences 137 and attestation results. 139 （relying party1) (relying party2) 140 +---------------+ +---------------+ 141 |PSK Auth_Center| |IBC Auth_Center| 142 +---------------+ +---------------+ 143 |\ +------------// | 144 |Evidence /Attestation | 145 Attestation | / Result | 146 Result \| / | 147 +-------------------+ +-------------------+ 148 |App/SIMCard/IoTCard| |App/SIMCard/IoTCard| 149 +-------------------+ +-------------------+ 150 (attester) 152 Figure 1: different access authentication methods within RATS 154 The format and content of the evidence: TBD 156 The format of the Attestation Result: TBD 158 The transmission protocol for evidence or attestation result: TBD 160 3.2. Application authentication based on different system 162 At the application level, due to limitation of resource, many 163 applications need operators to provide business authentication 164 services. At present, there are two business authentication methods: 165 one is certification-based PKI system authentication, because the 166 management of certificates is always a very big problem, so the other 167 is non-certificated, such as identity-based authentication whose 168 identity is readable. 170 When cross-business authentication is required, how to prove one's 171 identity to the other will be a common problem. 173 (relying party1) (relying party2) 174 +-----------------------------------+ +-----------------------------------+ 175 |Application authentication platform| |Application authentication platform| 176 | based on certificate |-----| based on non-certificate | 177 +-----------------------------------+ +-----------------------------------+ 178 | {Attestation} /| | 179 | { Result } / | 180 | ---------- | 181 | / | 182 +---------------+ +---------------+ 183 | application | | application | 184 +---------------+ +---------------+ 185 (attester1) (attester2) 187 Figure 2: different application authentication methods in RATS architecture 189 The format and content of the evidence: TBD 191 The format of the Attestation Result: TBD 193 The transmission protocol for evidence or attestation result: TBD 195 Certification-based authentication process: TBD 197 Identity-based authentication process: TBD 199 4. Security Considerations 201 TBD 203 5. IANA Considerations 205 This document does not require any action from IANA. 207 6. Acknowledgement 209 TBD 211 7. Informative References 213 [I-D.ietf-rats-architecture] 214 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 215 W. Pan, "Remote Attestation Procedures Architecture", 216 draft-ietf-rats-architecture-02 (work in progress), March 217 2020. 219 Authors' Addresses 221 Meiling Chen 222 China Mobile 223 32, Xuanwumen West 224 BeiJing, BeiJing 100053 225 China 227 Email: 228 chenmeiling@chinamobile.com 230 Li Su 231 China Mobile 233 32, Xuanwumen West 235 BeiJing 237 100053 239 China 241 Email: 242 suli@chinamobile.com