idnits 2.17.1 draft-beck-rtcweb-alt-ic-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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2011) is 4578 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 305, but not defined == Unused Reference: 'I-D.ietf-oauth-v2' is defined on line 317, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-22 -- Possible downref: Non-RFC (?) normative reference: ref. 'OpenID' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Beck 3 Internet-Draft Deutsche Telekom 4 Expires: April 16, 2012 October 14, 2011 6 Real-Time Web Communication Simplified Interconnection 7 draft-beck-rtcweb-alt-ic-00 9 Abstract 11 The Real-Time Communication Web (RTCWEB) approach uses browser-based 12 scripts to minimize the number of network protocols between server 13 and browser that need standardization. With traditional 14 interconnection concepts, the success of this effort is limited as 15 different RTCWEB applications still need to interoperate. This 16 document proposes an alternative interconnection model where caller 17 and callee always use the same RTCWEB client and server and avoid any 18 interworking this way. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 16, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Problem Statement 54 +-------------+ +--------------+ 55 | | e.g. SIP | | 56 | Web App A +------------------+ Web App B | 57 | | | | 58 | | | | 59 +------+------+ +------+-------+ 60 / Codec + Params \ 61 / <-----------------------> \ 62 / \ 63 / \ 64 / \ 65 Browser + Media Browser + 66 RTCWEB UA A <---------------------> RTCWEB UA B 67 User A User B 69 Figure 1 71 Figure 1 shows the original RTCWEB model for interconnecting users of 72 web application A and web application B. Not only the server 73 applications A and B have to agree on a common protocol, but to some 74 degree also the browser-based RTCWEB clients. 76 This model requires that the signaling between RTCWEB server and 77 client can be matched to the intra-server protocol. Codec parameters 78 and other information that is only relevant to the clients must be 79 exchanged between them. 81 The Session Initiation Protocol (SIP, [RFC3261]) and the Session 82 Description Protocol (SDP, [RFC4566]) have traditionally been used to 83 perform those functions. Both protocols suffer from the complexity 84 that is the result of the combined number of requirements of all 85 possible use cases. Re-using one or both of these protocols in 86 RTCWEB clients offers little advantage over classical SIP clients. 88 The key benefit of RTCWEB is the possibility to tailor the client- 89 server protocol to the actual use case. The software has only to 90 support those parameters and protocol states that are required in a 91 particular application. However, much of this advantage is lost when 92 two different RTCWEB applications have to interoperate. The 93 applications may have a different audiences and may have only a small 94 subset of common functionalities. An example is the call from an 95 RTCWEB application designed for mobile users to an RTCWEB application 96 designed for high quality conferencing. The two applications will 97 have very different requirements regarding the codec choice and call 98 control features. 100 The perceived requirement to have interoperable RTCWEB applications 101 is rooted in the traditional way of interconnecting networks. 103 In traditional phone networks, the 'application providers' were also 104 owners of the physical links that connected them. The architecture 105 shown in Figure 1 was a technological necessity. The associated 106 trust relationships were a welcome side effect as other ways of 107 authentication and authorization were not feasible. 109 o The originating side (Web App A) authenticates and authorizes the 110 user to make call. It trusts Web App B to forward the call to the 111 correct user. 113 o The terminating side (Web App B, the application receiving a call) 114 only authorizes the originating side as a whole, not its 115 individual users. It trusts Web App A to authenticate the calling 116 user. 118 o It is possible to have 'transit' entities between the originating 119 and terminating side. The involved parties form a chain of trust. 121 Even with standardized protocols, this models often requires detailed 122 agreements between interconnection partners to even out 123 implementation differences. 125 2. Third Party Authentication 127 +-------------+ +--------------+ 128 | | | | 129 | Identity +- - - - - - - - - + Web App B | 130 | Provider | 3rd | (relying | 131 | \ Party Auth. | party) | 132 +-------------+\ Protocol +-+----+-------+ 133 \ / \ 134 \ / \ 135 \ / \ 136 \ / \ 137 \ / \ 138 \ Browser + Browser + 139 RTCWEB UA B RTCWEB UA B 140 User A | User B | 141 | | 142 +----Media--------+ 144 Figure 2 146 Figure 2 shows an alternative interconnection model: 148 o User A and user B use the same RTCWEB application and browser- 149 based client (B). RTCWEB makes this very easy as user A can run 150 the client instantly. As Web App B handles the call on its own, 151 it does not need to interoperate with Web App A for call control. 153 o User A presents some 3rd party identity assertion to RTCWEB 154 application B. RTCWEB application B can check this assertion 155 either by asking the 3rd party, or by checking its cryptographic 156 signature. Based on the issuer of the authentication assertion, 157 application B can grant or restrict its functionality to user A. 159 The key idea is to separate the trust relationship from call 160 signaling. Only the media stream between the two browsers needs to 161 be standardized. 163 With this model the terminating side is always in charge of the whole 164 call. The originating side takes only the role of an identity 165 provider. 167 The following sections give an overview over some existing third 168 party authentication methods that can be used with RTCWEB. 170 3. Client-Side Certificates 172 The generation of client certificates in the browser has been 173 standardized with HTML 5. 175 o When a user signs up to the RTCWEB service, the server will 176 generate a client certificate and install it in the browser. To 177 do this, it uses an HTML form containing a element. The 178 browser will then generate a public key and send it to the server. 179 The server will sign it and offer the resulting certificate back 180 to the user for download. 182 o When a user makes a call, the called party's RTCWEB service will 183 check the client certificate. If it trusts the issuer of the 184 certificate, the user can make the call. 186 The main drawback of using client certificates is the poor user 187 interface in current browsers. There have been attempts to improve 188 this by implementing TLS in Javascript and to store certificates 189 using a widely used proprietary browser plugin. This solution is not 190 a suitable base for standardization. 192 With client certificates, the originating side has no control over 193 the call at all. It does not even know that a call took place and 194 can only distribute a certificate revocation list to restrict a 195 user's actions. 197 To avoid the cost associated with properly authenticated client 198 certificates, the WebID initiative has come up with a new way to 199 verify them: the browser sends a client certificate as part of a 200 https session setup. The certificate contains a URL that can be used 201 for verification. The URL points to a resource which contains a 202 public key. If this public key is identical to the one received in 203 the client certificate, the web application can be sure of its 204 authenticity. This way the user does not require an expensive 205 certificate issued by a universally acknowledged authority. 207 The web application can choose to reject request carrying 208 certificates issued by institutions it does not trust. 210 Example from the user's perspective: 212 1. Alice (https://atlanta.com/rtcweb/alice) wants to call Bob at 213 https://biloxi.com/users/bob. She points her browser to Bob's 214 URL. 216 2. Alice's browser opens a certificate selection box: 'The site has 217 requested that you identify yourself with a certificate'. She 218 selects the one she wants to use for this call. 220 3. Alice's browser loads the RTCWEB client from biloxi.com and 221 connects her to Bob. 223 4. OAuth 225 With OAuth an application can ask a user for access to a protected 226 resource owned by the user. The OAuth roles can be mapped to RTCWEB 227 interconnection roles: 229 o The terminating RTCWEB application is the OAuth client. 231 o The originating RTCWEB application provides the authorization and 232 resource servers. 234 o The calling user is the resource owner. 236 o The authorization scope is the URL of the called user. 238 o The protected resource is information about the actions the 239 caller's provider has granted to the calling user. To protect the 240 caller's privacy, this could be restricted to a simple yes or no 241 as a response to an access attempt carrying a specific 242 authorization scope parameter. 244 When using OAuth, the calling user has to confirm the the access of 245 the called RTCWEB provider to her own RTCWEB provider. 247 OAuth gives the originating RTCWEB application some control over its 248 users' actions. 250 Example from the user's perspective: 252 1. Alice has logged into her RTCWEB application at atlanta.com. 254 2. Alice (https://atlanta.com/rtcweb/alice) wants to call Bob at 255 https://biloxi.com/users/bob. She points her browser to Bob's 256 URL. 258 3. biloxi.com redirects her to an OAuth dialog at atlanta.com, which 259 recognizes her as logged in, eg by checking an HTTP cookie. It 260 shows a dialog: 'biloxi.com wants to make a call to 261 https://biloxi.com/users/bob for you, Alice. Allow / Don't 262 Allow' 264 4. Alice allows the call and gets redirected back again. Her 265 browser loads the RTCWEB client from biloxi.com and connects her 266 to Bob. 268 5. OpenID 270 OpenID [OpenID] is an HTTP-based single sign-on system where a 271 request to a relying party web site carries an authentication 272 assertion which can be checked with an OpenID provider. If a request 273 does not contain an authentication assertion, the relying party 274 redirects the browser to the user's OpenID provider and adds a 275 callback URL. Upon successful authentication, the identity provider 276 uses the callback URL to redirect the user's browser back to the 277 relying party. 279 In an RTCWEB scenario, the originating side would be the OpenID 280 provider and the terminating side would be the relying party. 282 The originating side has no straightforward way to actually authorize 283 a request. The openid.realm parameter and the return_to URL are the 284 only hints about the nature of the service for which the 285 authentication is intended. 287 Example from the user's perspective: 289 1. Alice (https://atlanta.com/rtcweb/alice) wants to call Bob at 290 https://biloxi.com/users/bob. She points her browser to Bob's 291 URL. 293 2. biloxi.com asks for her OpenID login; Alice enters it and her 294 browser gets redirected to atlanta.com. 296 3. atlanta.com asks Alice for her password. 298 4. Alice enters her password. Her browser gets redirected back to 299 biloxi.com and connects her with Bob. 301 6. Security Considerations 303 This document proposes to re-use existing third party authentication 304 and authorization standards for RTCWEB. Their security is discussed 305 in the respective standards documents. [TBD] 307 7. References 309 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 310 A., Peterson, J., Sparks, R., Handley, M., and E. 311 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 312 June 2002. 314 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 315 Description Protocol", RFC 4566, July 2006. 317 [I-D.ietf-oauth-v2] 318 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 319 2.0 Authorization Protocol", draft-ietf-oauth-v2-22 (work 320 in progress), September 2011. 322 [OpenID] Openid.net, "OpenID Authentication 2.0 - Final", 323 December 2007, 324 . 326 Author's Address 328 Wolfgang Beck 329 Deutsche Telekom AG 330 Heinrich Hertz Strasse 3-7 331 Darmstadt 332 Germany 334 Email: beckw@telekom.de