Network Working Group W. Beck Internet-Draft Deutsche Telekom Expires: April 16, 2012 October 14, 2011 Real-Time Web Communication Simplified Interconnection draft-beck-rtcweb-alt-ic-00 Abstract The Real-Time Communication Web (RTCWEB) approach uses browser-based scripts to minimize the number of network protocols between server and browser that need standardization. With traditional interconnection concepts, the success of this effort is limited as different RTCWEB applications still need to interoperate. This document proposes an alternative interconnection model where caller and callee always use the same RTCWEB client and server and avoid any interworking this way. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 16, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Beck Expires April 16, 2012 [Page 1] Internet-Draft RTCWEB Simplified Interconnection October 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Beck Expires April 16, 2012 [Page 2] Internet-Draft RTCWEB Simplified Interconnection October 2011 1. Problem Statement +-------------+ +--------------+ | | e.g. SIP | | | Web App A +------------------+ Web App B | | | | | | | | | +------+------+ +------+-------+ / Codec + Params \ / <-----------------------> \ / \ / \ / \ Browser + Media Browser + RTCWEB UA A <---------------------> RTCWEB UA B User A User B Figure 1 Figure 1 shows the original RTCWEB model for interconnecting users of web application A and web application B. Not only the server applications A and B have to agree on a common protocol, but to some degree also the browser-based RTCWEB clients. This model requires that the signaling between RTCWEB server and client can be matched to the intra-server protocol. Codec parameters and other information that is only relevant to the clients must be exchanged between them. The Session Initiation Protocol (SIP, [RFC3261]) and the Session Description Protocol (SDP, [RFC4566]) have traditionally been used to perform those functions. Both protocols suffer from the complexity that is the result of the combined number of requirements of all possible use cases. Re-using one or both of these protocols in RTCWEB clients offers little advantage over classical SIP clients. The key benefit of RTCWEB is the possibility to tailor the client- server protocol to the actual use case. The software has only to support those parameters and protocol states that are required in a particular application. However, much of this advantage is lost when two different RTCWEB applications have to interoperate. The applications may have a different audiences and may have only a small subset of common functionalities. An example is the call from an RTCWEB application designed for mobile users to an RTCWEB application designed for high quality conferencing. The two applications will have very different requirements regarding the codec choice and call Beck Expires April 16, 2012 [Page 3] Internet-Draft RTCWEB Simplified Interconnection October 2011 control features. The perceived requirement to have interoperable RTCWEB applications is rooted in the traditional way of interconnecting networks. In traditional phone networks, the 'application providers' were also owners of the physical links that connected them. The architecture shown in Figure 1 was a technological necessity. The associated trust relationships were a welcome side effect as other ways of authentication and authorization were not feasible. o The originating side (Web App A) authenticates and authorizes the user to make call. It trusts Web App B to forward the call to the correct user. o The terminating side (Web App B, the application receiving a call) only authorizes the originating side as a whole, not its individual users. It trusts Web App A to authenticate the calling user. o It is possible to have 'transit' entities between the originating and terminating side. The involved parties form a chain of trust. Even with standardized protocols, this models often requires detailed agreements between interconnection partners to even out implementation differences. Beck Expires April 16, 2012 [Page 4] Internet-Draft RTCWEB Simplified Interconnection October 2011 2. Third Party Authentication +-------------+ +--------------+ | | | | | Identity +- - - - - - - - - + Web App B | | Provider | 3rd | (relying | | \ Party Auth. | party) | +-------------+\ Protocol +-+----+-------+ \ / \ \ / \ \ / \ \ / \ \ / \ \ Browser + Browser + RTCWEB UA B RTCWEB UA B User A | User B | | | +----Media--------+ Figure 2 Figure 2 shows an alternative interconnection model: o User A and user B use the same RTCWEB application and browser- based client (B). RTCWEB makes this very easy as user A can run the client instantly. As Web App B handles the call on its own, it does not need to interoperate with Web App A for call control. o User A presents some 3rd party identity assertion to RTCWEB application B. RTCWEB application B can check this assertion either by asking the 3rd party, or by checking its cryptographic signature. Based on the issuer of the authentication assertion, application B can grant or restrict its functionality to user A. The key idea is to separate the trust relationship from call signaling. Only the media stream between the two browsers needs to be standardized. With this model the terminating side is always in charge of the whole call. The originating side takes only the role of an identity provider. The following sections give an overview over some existing third party authentication methods that can be used with RTCWEB. Beck Expires April 16, 2012 [Page 5] Internet-Draft RTCWEB Simplified Interconnection October 2011 3. Client-Side Certificates The generation of client certificates in the browser has been standardized with HTML 5. o When a user signs up to the RTCWEB service, the server will generate a client certificate and install it in the browser. To do this, it uses an HTML form containing a element. The browser will then generate a public key and send it to the server. The server will sign it and offer the resulting certificate back to the user for download. o When a user makes a call, the called party's RTCWEB service will check the client certificate. If it trusts the issuer of the certificate, the user can make the call. The main drawback of using client certificates is the poor user interface in current browsers. There have been attempts to improve this by implementing TLS in Javascript and to store certificates using a widely used proprietary browser plugin. This solution is not a suitable base for standardization. With client certificates, the originating side has no control over the call at all. It does not even know that a call took place and can only distribute a certificate revocation list to restrict a user's actions. To avoid the cost associated with properly authenticated client certificates, the WebID initiative has come up with a new way to verify them: the browser sends a client certificate as part of a https session setup. The certificate contains a URL that can be used for verification. The URL points to a resource which contains a public key. If this public key is identical to the one received in the client certificate, the web application can be sure of its authenticity. This way the user does not require an expensive certificate issued by a universally acknowledged authority. The web application can choose to reject request carrying certificates issued by institutions it does not trust. Example from the user's perspective: 1. Alice (https://atlanta.com/rtcweb/alice) wants to call Bob at https://biloxi.com/users/bob. She points her browser to Bob's URL. 2. Alice's browser opens a certificate selection box: 'The site has requested that you identify yourself with a certificate'. She Beck Expires April 16, 2012 [Page 6] Internet-Draft RTCWEB Simplified Interconnection October 2011 selects the one she wants to use for this call. 3. Alice's browser loads the RTCWEB client from biloxi.com and connects her to Bob. Beck Expires April 16, 2012 [Page 7] Internet-Draft RTCWEB Simplified Interconnection October 2011 4. OAuth With OAuth an application can ask a user for access to a protected resource owned by the user. The OAuth roles can be mapped to RTCWEB interconnection roles: o The terminating RTCWEB application is the OAuth client. o The originating RTCWEB application provides the authorization and resource servers. o The calling user is the resource owner. o The authorization scope is the URL of the called user. o The protected resource is information about the actions the caller's provider has granted to the calling user. To protect the caller's privacy, this could be restricted to a simple yes or no as a response to an access attempt carrying a specific authorization scope parameter. When using OAuth, the calling user has to confirm the the access of the called RTCWEB provider to her own RTCWEB provider. OAuth gives the originating RTCWEB application some control over its users' actions. Example from the user's perspective: 1. Alice has logged into her RTCWEB application at atlanta.com. 2. Alice (https://atlanta.com/rtcweb/alice) wants to call Bob at https://biloxi.com/users/bob. She points her browser to Bob's URL. 3. biloxi.com redirects her to an OAuth dialog at atlanta.com, which recognizes her as logged in, eg by checking an HTTP cookie. It shows a dialog: 'biloxi.com wants to make a call to https://biloxi.com/users/bob for you, Alice. Allow / Don't Allow' 4. Alice allows the call and gets redirected back again. Her browser loads the RTCWEB client from biloxi.com and connects her to Bob. Beck Expires April 16, 2012 [Page 8] Internet-Draft RTCWEB Simplified Interconnection October 2011 5. OpenID OpenID [OpenID] is an HTTP-based single sign-on system where a request to a relying party web site carries an authentication assertion which can be checked with an OpenID provider. If a request does not contain an authentication assertion, the relying party redirects the browser to the user's OpenID provider and adds a callback URL. Upon successful authentication, the identity provider uses the callback URL to redirect the user's browser back to the relying party. In an RTCWEB scenario, the originating side would be the OpenID provider and the terminating side would be the relying party. The originating side has no straightforward way to actually authorize a request. The openid.realm parameter and the return_to URL are the only hints about the nature of the service for which the authentication is intended. Example from the user's perspective: 1. Alice (https://atlanta.com/rtcweb/alice) wants to call Bob at https://biloxi.com/users/bob. She points her browser to Bob's URL. 2. biloxi.com asks for her OpenID login; Alice enters it and her browser gets redirected to atlanta.com. 3. atlanta.com asks Alice for her password. 4. Alice enters her password. Her browser gets redirected back to biloxi.com and connects her with Bob. Beck Expires April 16, 2012 [Page 9] Internet-Draft RTCWEB Simplified Interconnection October 2011 6. Security Considerations This document proposes to re-use existing third party authentication and authorization standards for RTCWEB. Their security is discussed in the respective standards documents. [TBD] Beck Expires April 16, 2012 [Page 10] Internet-Draft RTCWEB Simplified Interconnection October 2011 7. References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [I-D.ietf-oauth-v2] Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 2.0 Authorization Protocol", draft-ietf-oauth-v2-22 (work in progress), September 2011. [OpenID] Openid.net, "OpenID Authentication 2.0 - Final", December 2007, . Beck Expires April 16, 2012 [Page 11] Internet-Draft RTCWEB Simplified Interconnection October 2011 Author's Address Wolfgang Beck Deutsche Telekom AG Heinrich Hertz Strasse 3-7 Darmstadt Germany Email: beckw@telekom.de Beck Expires April 16, 2012 [Page 12]