[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                            W. Beck
Internet-Draft                                          Deutsche Telekom
Expires: April 16, 2012                                 October 14, 2011

         Real-Time Web Communication Simplified Interconnection


   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

   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  |
                                       |                 |

                                 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

   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 <keygen> 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

   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

   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

   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

   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.

              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

   Email: beckw@telekom.de

Beck                     Expires April 16, 2012                [Page 12]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/