idnits 2.17.1 draft-cheng-rtcweb-teleauth-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 103 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 9 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 114, but not defined == Unused Reference: 'I-D.ietf-rtcweb-use-cases-and-requirements' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-security-arch' is defined on line 308, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-13 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-07 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RTCWeb Working Group Z. Cheng 2 Internet Draft M. Qi 3 J. Zhu 4 Intended status: Informational China Mobile 5 Expires:August 8, 2014 Feb. 8, 2014 7 Security Authentication of WebRTC Communication Service 8 for Telephony Terminal 9 draft-cheng-rtcweb-teleauth-00 11 Abstract 12 The WebRTC use-cases and related requirements are defined in 13 [draft-ietf-rtcweb-use-cases-and-requirements] that contains browser to 14 browser use-cases and browser-GW/server use-cases (e.g., telephony 15 terminal). In the use-case of telephony terminal, it is necessary for 16 telephony terminal to be able to attest his identity to the telephony 17 operator. Unlike the current authentication specified in 18 [draft-ietf-rtcweb-security] such as PKI based authentication and web 19 based peer authentication WebRTC communication is directly controlled 20 by the telephony operator, which poses new authentication methods, 21 including re-using existence authentication mechanism of telephony 22 operator and authentication by using web credentials. This document 23 presents the security authentication of WebRTC communication for 24 telephony terminal. 26 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on August 8, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 52 Relating to IETF Documents (http://trustee.ietf.org/license-info) 53 in effect on the date of publication of this document. Please 54 review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Table of Contents 59 1. Introduction .....................................................2 60 2. Conventions used in this document ................................3 61 2.1. Definitions.....................................................3 62 3. Problem Statement ................................................4 63 4. Requirement ......................................................6 64 5. Telephony Terminal Authentication Solution .......................6 65 5.1. Introduction ...................................................6 66 5.2. authentication solution for scenario 1..........................7 67 5.3. authentication solution for scenario 2..........................7 68 6. Security Considerations ..........................................9 69 7. IANA Considerations .............................................10 70 8. Conclusions .....................................................11 71 9. References ......................................................11 72 9.1. Normative References ..........................................11 73 9.2. Informative References ........................................11 75 1. Introduction 76 The WebRTC use-cases and related requirements are defined in 77 [draft-ietf-rtcweb-use-cases-and requirements] that contains a use-case 78 titled telephony terminal. As shown in Figure 1, a mobile telephony 79 operator allows its customers to use a web browser to access their 80 services, so that WebRTC service is provided by the telephony operator 81 but not the web server. Therefore, the current authentication solutions 82 (i.e., PKI based authentication and web based peer authentication) are 83 only adaptive for service facilitated by web server, new authentication 84 solutions due to a new exploited entity as operator server should be 85 defined for the use case of telephony terminal, all telephony terminals 86 can be authenticated to access WebRTC communication service provided by 87 the telephony operator. 89 This document presents the security authentication of WebRTC 90 communication for telephony terminal. 92 +---------------------------------------------------------------------+ 93 | | 94 | HTTP +------------+ | 95 | +-------------| Web Server | | 96 | | +------------+ | 97 | | | 98 | | | 99 | | | 100 | V | 101 | +------------+ Signal +------------+ | 102 | | Telephony |<--------------------------->| Operator | | 103 | | Terminal | Media | Server | | 104 | +------------+ +------------+ | 105 | | 106 +---------------------------------------------------------------------+ 107 Figure 1. WebRTC system for telephony terminal 109 2. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC-2119 [RFC2119]. 115 In this document, these words will appear with that interpretation 116 only when in ALL CAPS. Lower case uses of these words are not to be 117 interpreted as carrying RFC-2119 significance. 119 2.1. Definitions 120 Terminal: the terminal with browser that is equipped with a WebRTC JS 121 application capable of interconnection with the operator server. 123 WebRTC application: The WebRTC application is downloaded from the Web 124 server within the operator network or a third party network and provides 125 access to the communications service from the telephony operator. 127 Web server: The Web Server is the initial point to contact in the Web 128 that controls access WebRTC communications service for the terminal. 130 Operator server: The operator server is the point to verify any possible 131 authentications of terminals and provide the specific WebRTC communication 132 service for terminals. 134 3. Problem Statement 135 3.1 use cases 137 Nowadays, in current WebRTC use-cases (i.e., browser-to-browser use-cases), 138 the terminals with WebRTC enable browsers visit some Web server which 139 operates a calling service. The current authentication solution either 140 uses PKI-style certificate or Web-based identity (e.g., Brower ID) to 141 authenticate the terminals. In fact, not only the Web server but also the 142 telephony operator can provide a calling service for their terminals. 144 As depicted in [draft-ietf-rtcweb-use-cases-and-requirements], there exists 145 a specific use-case as follows: 146 Telephony terminal: A mobile telephony operator allows its customers to use 147 a web browser to access their services. After a simple log in the user can 148 place and receive calls in the same way as when using a normal mobile 149 phone. When a call is received or placed, the identity is shown in the same 150 manner as when a mobile phone is used. 151 The use-case of Telephony terminal supports two different solutions that 152 differ in authentication methods and ownership of the web server (i.e., 153 operator or the third party). The two solutions are depicted as follows: 155 Solution 1: The user has a subscription with an identity belongs to the 156 telephony operator and uses an authentication method (e.g. SIP digest) to 157 validate itself with the operator server. 159 Solution 2: The user has a subscription with an operator identity but 160 uses a web identity and authentication scheme to authenticate with the 161 Web server. The Web server assigns the user an operator credential in 162 terms of the user's web credential for making authentication with the 163 operator server. As aforementioned, the existing authentication solutions 164 are no longer appropriate in the use-case of telephony terminals. When a 165 telephony terminal requests for a calling service, it should prove its 166 identity belongs to the telephony operator in advance, so that the 167 operator permits it to access WebRTC service. 169 3.2 Current solutions analysis 171 In the browser-to-browser use-cases, each browser which attempt to 172 communicate with exposes standardized JavaScript calling APIs 173 (implemented as browser built-ins) which are used by the Web server 174 to set up a call. The Web server also serves as the signaling channel 175 to transport control messages between the browsers and service JS sets 176 up some media. 178 In such use-cases, the conventional solution to providing communications 179 identity usually uses third party identity system (e.g., PKI) to 180 authenticate the browsers. 181 Furthermore, a new solution using Web-based identity technologies (e.g., 182 BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID, 183 WebFinger) has recently been developed to provide lightweight (from the 184 user's perspective) third-party Web-based peer authentication. It uses 185 systems of this type to authenticate WebRTC calls, linking them to 186 existing third identity (e.g., Facebook adjacencies). Specifically, the 187 third-party identity system is used to bind the user's identity to 188 cryptographic keying material which is then used to authenticate the 189 browsers. 191 3.3 problem statement 193 1. The current solution has the following problems:For PKI-based solution 194 (i.e., PKI-style certificate), it needs to use certificate which is preset 195 between the user and the server. But the certificate management is too 196 cumbersome, including certificate application, issuance, updating, and 197 dispose, it needs to setup the complicated certificate management module. 199 When AKA procedures using certificate need to check the validity of 200 certificate, it costs extra complexity. However, for telephony user, it 201 owns pre-shared key with operator rather than certificate. Therefore, PKI 202 usage doesn't fit for telephony users. 204 2. For Web-based solution (i.e., Web-based peer authentication), it is 205 suitable for browser-to-browser use-cases, since the browser is able to 206 directly identify the other calling browser by connecting a Web-based 207 (i.e., HTTP/HTTPS) identity provider without trusting the Web server 208 which they are logged in. That means it is a general principle that the 209 party which is being authenticated is NOT the signaling site (i.e., Web 210 server) but rather the user with his browser. Refers to 211 [draft-ietf-rtcweb-security-arch] However, it is necessary for operator 212 server to authenticate its users with their browsers in the telephony 213 terminal use-case. Therefore, Web-based solution can't address this 214 requirements. 216 4. Requirement 218 In order to provide the secure WebRTC communication service from the 219 telephony operator to its users/terminals, it is need to design new 220 security authentication solutions for terminals to prove their 221 identities through WebRTC methods in the use-case of telephony terminal. 223 5. Telephony Terminal Authentication Solution 225 5.1. Introduction 227 The security authentication of the use-case so-called Telephony terminal 228 is the adaptive mechanism for the involved entities such as operator 229 server, web server and the terminal to make authentication for WebRTC 230 communication service. 232 There are two solutions for the authentication mechanisms: 233 Solution 1: The user has a subscription with an identity belongs to the 234 telephony operator and uses an authentication method (e.g. SIP digest) to 235 validate itself with the operator server. 236 Solution 2: The user has a subscription with an operator identity but 237 uses a web identity and authentication scheme to authenticate with the 238 Web server. The Web server assigns the user a operator credential in 239 terms of the user's web credential for making authentication with the 240 operator server. 242 5.2. authentication solution 1 244 1. By using a WebRTC-enabled browser, the terminal accesses a URI to the 245 Web server facilitating an HTTPS connection. The TLS connection 246 provides one-way authentication of the server based on the server 247 certificate. The browser downloads and initializes the WebRTC 248 application from the Web server. 249 2. The WebRTC application opens a WSS connection to the operator server 250 using standard cross-origin resource sharing procedures to ensure that 251 the application originated from a Web server authorized to access this 252 operator server. 253 3. The WebRTC application launches a registration transaction with the 254 operator server by sending a REGISTER request via the WSS connection. 255 The REGISTER request includes authentication parameters 256 as needed for proper registration. This request is translated 257 in the operator core network as it is processed by the operator server. 258 This process leverage user credentials in HSS. 260 5.3. authentication solution 2 262 1. By using a WebRTC-enabled browser, the terminal accesses a URI to the 263 Web server facilitating an HTTPS connection. The TLS connection 264 provides one-way authentication of the server based on the server 265 certificate. The browser downloads and initializes the WebRTC 266 application from the Web server. 267 2. The Web server authenticates the terminal using a common web 268 authentication procedure, determines the identity registered with the 269 operator and assigned it to the terminal, issues a security token to 270 the terminal and returns the identity as claims within the security 271 token to the terminal's WebRTC application. 272 3. The WebRTC application opens a WSS connection to the operator server 273 using CORS procedures to ensure that the WebRTC application originated 274 from a Web server authorized to access the operator server. 275 4. The WebRTC application sends a REGISTER request to the operator server 276 via the WSS connection. The request includes the user identity 277 extracted from the claims in the security token and the security token 278 received from the Web server. 279 5. The operator server validates the contents of the security token and 280 confirms that the identity being registered is authorized by the 281 security token. 282 6. The operator returns an OK response to the terminal to announce that 283 authenticates terminal successfully. 285 6. Security Considerations 286 This memo considers the security authentication for providing WebRTC 287 service in use case of telephony terminal. So it would not introduce 288 any additional security problems. 290 7. IANA Considerations 291 There are no IANA considerations associated to this memo. 293 8. Conclusions 295 This memo describes the problem raised by conventional authentication 296 solutions for the use-case of telephony terminal. After that, the 297 telephony terminal authentication requirement is raised and related 298 security authentication solutions are proposed. 300 9. References 301 9.1. Normative References 302 9.2. Informative References 303 [I-D.ietf-rtcweb-use-cases-and-requirements] 304 C. Holmberg, et al., "Web Real-Time Communication Use-cases and 305 Requirements", draft-ietf-rtcweb-use-cases-and-requirements-13 306 (work in progress), February 2014 308 [I-D.ietf-rtcweb-security-arch] 309 E. Rescorla, "WebRTC Security Architecture", draft-ietf-rtcweb- 310 security-arch-07 (work in progress), July 2013 312 Authors' Addresses 313 Ziyao Cheng 314 China Mobile 315 Unit 2, 32 Xuanwumenxi Ave, 316 Xicheng District, 317 Beijing 100053, China 318 Email: chengziyao@chinamobile.com 319 Minpeng Qi 320 China Mobile 321 Unit 2, 32 Xuanwumenxi Ave, 322 Xicheng District, 323 Beijing 100053, China 324 Email: qiminpeng@chinamobile.com 326 Judy Zhu 327 China Mobile 328 Unit 2, 32 Xuanwumenxi Ave, 329 Xicheng District, 330 Beijing 100053, China 331 Email: Zhuhongru@chinamobile.com