TURN Extension for Third Party Authorization
draft-reddy-tram-turn-third-party-authz-00

TRAM                                                            T. Reddy
Internet-Draft                                                  P. Patil
Intended status: Standards Track                         R. Ravindranath
Expires: August 18, 2014                                           Cisco
                                                               J. Uberti
                                                                  Google
                                                       February 14, 2014

              TURN Extension for Third Party Authorization
               draft-reddy-tram-turn-third-party-authz-00

Abstract

   This document proposes the use of OAuth to obtain and validate
   ephemeral tokens that can be used for TURN authentication.  The usage
   of ephemeral tokens ensure that access to a TURN server can be
   controlled even if the tokens are compromised, as is the case in
   WebRTC where TURN credentials must be specified in Javascript.  It
   also addresses the need for stronger authentication described in
   [I-D.reddy-behave-turn-auth].

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 August 18, 2014.

Copyright Notice

   Copyright (c) 2014 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

Reddy, et al.            Expires August 18, 2014                [Page 1]
Internet-Draft      TURN for 3rd party Authorization       February 2014

   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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Obtaining a Token Using OAuth . . . . . . . . . . . . . . . .   5
   5.  Forming a Request . . . . . . . . . . . . . . . . . . . . . .   7
   6.  TURN Server validating Request  . . . . . . . . . . . . . . .   8
   7.  STUN Attributes . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  THIRD-PARTY-AUTHORIZATION . . . . . . . . . . . . . . . .   8
     7.2.  ACCESS-TOKEN  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   TURN [RFC5766] is a protocol that is often used to improve the
   connectivity of P2P applications.  By providing a cloud-based relay
   service, TURN ensures that a connection can be established even when
   one or both sides is incapable of a direct P2P connection.  However,
   as a relay service, it imposes a nontrivial cost on the service
   provider.  Therefore, access to a TURN service is almost always
   access-controlled.

   TURN provides a mechanism to control access via "long-term" username/
   password credentials that are provided as part of the TURN protocol.
   It is expected that these credentials will be kept secret; if the
   credentials are discovered, the TURN server could be used by
   unauthorized users or applications.  However, in web applications,
   ensuring this secrecy is typically impossible.  To address this
   problem and the ones described in [I-D.reddy-behave-turn-auth], this
   document proposes the use of third party authorization using OAuth
   for TURN.

   To achieve third party authorization, a resource owner e.g. WebRTC
   server, authorizes a TURN client to access resources on the TURN
   server.

Reddy, et al.            Expires August 18, 2014                [Page 2]
Internet-Draft      TURN for 3rd party Authorization       February 2014

   Using OAuth, a client obtains an ephemeral token from an
   authorization server e.g. WebRTC server, and the token is presented
   to the TURN server instead of the traditional mechanism of presenting
   username/password credentials.  The TURN server validates the
   authenticity of the token and provides required services.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   o  WebRTC Server: A web server that supports WebRTC
      [I-D.ietf-rtcweb-overview].

   o  Access Token: OAuth 2.0 access token.

   o  mac_key: The session key generated by the authorization server.
      Note that the lifetime of the session key is equal to the lifetime
      of the access token.

   o  kid: The name of the key (key id), which is an identifier
      generated by the resource owner.  It is RECOMMENDED that the
      authorization server generates this key id by computing a hash
      over the access token, for example using SHA-1, and to encode it
      in a base64 format.

3.  Solution Overview

   This specification uses token type 'Handle' (or artifact) described
   in [RFC6819].  A handle token is a reference to some internal data
   structure within the OAuth authorization server; the internal data
   structure contains the attributes of the token such as mac_key,
   lifetime of the access token etc.  The exact mechanism used by a
   client to obtain a token from the OAuth authorization server is
   outside the scope of this document.  For example, a client could make
   an HTTP request to an authorization server to obtain a token that can
   be used to avail TURN services.  The TURN token is returned in JSON,
   along with other OAuth Parameters like token type, mac_key, kid,
   token lifetime etc.  The client is oblivious to the content of the
   token.  The token is embedded within a TURN request sent to the TURN
   server.  Once the TURN server has determined the token is valid, TURN
   services are offered for a determined period of time.

Reddy, et al.            Expires August 18, 2014                [Page 3]
Internet-Draft      TURN for 3rd party Authorization       February 2014

   +-------------------+                         +--------+  +---------+
   | .........  TURN   |                         |  TURN  |  |  WebRTC |
   | .WebRTC .  Client |                         |        |  |         |
   | .Client .         |                         | Server |  |  Server |
   | .........         |                         |        |  |         |
   +-------------------+                         +--------+  +---------+
     |       |           Allocate request                |         |
     |       |------------------------------------------>|         |
     |       |                                           |         |
     |       |         Allocate error response           |         |
     |       |<------------------------------------------|         |
     |       |         THIRD-PARTY-AUTHORIZATION         |         |
     |       |                                           |         |
     |       |                                           |         |
     |       |      HTTP Request for token               |         |
     |------------------------------------------------------------>|
     |       |      HTTP Response with token parameters  |         |
     |<------------------------------------------------------------|
     |OAuth  |                                           |         |
      Attributes                                         |         |
     |-----> |                                           |         |
     |       |    Allocate request ACCESS-TOKEN          |         |
     |       |------------------------------------------>|         |
     |       |                                           |         |
     |       |         Allocate success response         |         |
     |       |<------------------------------------------|         |
     |       |             TURN Messages                 |         |
     |       |      ////// integrity protected //////    |         |
     |       |      ////// integrity protected //////    |         |
     |       |      ////// integrity protected //////    |         |

                 Figure 1: TURN Third Party Authorization

   Note : An implementation may choose to contact the WebRTC server to
   obtain a token even before it makes an allocate request, if it knows
   the server details before hand.  For example, once a client has
   learnt that a TURN server supports Third Party authorization from a
   WebRTC server, the client can obtain the token before making
   subsequent allocate requests.

   For example HTTP response from Authorization server:

Reddy, et al.            Expires August 18, 2014                [Page 4]
Internet-Draft      TURN for 3rd party Authorization       February 2014

        HTTP/1.1 200 OK
        Content-Type: application/json
        Cache-Control: no-store

        {
          "access_token":
      "eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDK0hTMjU2In0.
      kwx9txo_sKRasjlXc8RYP-evLCmT1XRXKjtY5l44Gnh0A84hGvVfMxMfCWXh38hi",
          "token_type":"mac",
          "expires_in":1800,
          "refresh_token":"8xLOxBtZp8",
          "kid":"22BIjxU93h/IgwEb4zCRu5WF37s=",
          "mac_key":"adijq39jdlaska9asud"
        }

                             Figure 2: Example

   Handle token type is selected for the following reasons:

   1.  The Authorization server can inform the TURN server to revoke the
       access token after the call is terminated.  This mechanism
       ensures that even if the TURN client does not delete existing
       allocations, the TURN server based on the revocation notification
       from the Authorization server can close the allocations.

   2.  Another approach, not discussed in this document, is a self-
       contained token where all the information necessary to
       authenticate the validity of the token is contained within the
       token itself.  This approach has the benefit of avoiding a
       protocol between the TURN server and the OAuth authentication
       server for token validation, thus reducing latency.  However,
       this approach has the drawback of needing a large TURN packet to
       accommodate the token.

4.  Obtaining a Token Using OAuth

   A TURN client should know the authentication capability of the TURN
   server before deciding to use third party authorization with it.  A
   TURN client initially makes a request without any authorization.  If
   the TURN server supports or mandates third party authorization, it
   will return an error message indicating support for third party
   authorization.  The TURN server includes an ERROR-CODE attribute with
   a value of 401 (Unauthorized), a nonce value in a NONCE attribute and
   a SOFTWARE attribute that gives information about the TURN server's
   software.  The TURN servers also includes additional STUN attribute
   THIRD-PARTY-AUTHORIZATION signaling the TURN client that the TURN
   server supports third party authorization.

Reddy, et al.            Expires August 18, 2014                [Page 5]
Internet-Draft      TURN for 3rd party Authorization       February 2014

   The following mapping of OAuth concepts to WebRTC is used :

                 +----------------------+----------------------------+
                 |         OAuth        |            WebRTC          |
                 +======================+============================+
                 | Client               | WebRTC client              |
                 +----------------------+----------------------------+
                 | Resource owner       | WebRTC server              |
                 +----------------------+----------------------------+
                 | Authorization server | Authorization server       |
                 +----------------------+----------------------------+
                 | Resource server      | TURN Server                |
                 +----------------------+----------------------------+

         Figure 3: OAuth terminology mapped to WebRTC terminology

   Using the OAuth 2.0 authorization framework, a WebRTC client (third-
   party application) obtains limited access to a TURN (resource server)
   on behalf of the WebRTC server (resource owner or authorization
   server).  The WebRTC client requests access to resources controlled
   by the resource owner (WebRTC server) and hosted by the resource
   server (TURN server).  The WebRTC client obtains access token,
   lifetime, session key (in the mac_key parameter) and key id (kid).
   The TURN client conveys the access token and other OAuth parameters
   learnt from the authorization server to the resource server (TURN
   server).  The TURN obtains the session key via the access token.  The
   TURN server validates the token, computes the message integrity of
   the request and takes appropriate action i.e permits the TURN client
   to create allocations.  This is shown in an abstract way in Figure 4.

Reddy, et al.            Expires August 18, 2014                [Page 6]
Internet-Draft      TURN for 3rd party Authorization       February 2014

                           +---------------+   Token metadata
                           |               +       (4)
            +------------->| Authorization |------------+
            |              | Server        |            |
            |   +----------|(WebRTC Server)|<------+    |
            |   |          |               |       |    |
   (1)      |   |           +--------------+       |    |
   Access   |   |  (2)                             |    |
   Token    |   | Access Token                     |    |
   Request  |   |    +                 Get Token   |    |
            |   | Session Key            (3)       |    |
            |   |                                  |    |
            |   V                                  |    V
        +-------+---+                       +-+----=-----+
        |           |         (5)           |            |
        |           | TURN Request + Access |            |
        | WebRTC    | Token                 | TURN       |
        | Client    |---------------------->| Server     |
        | (Alice)   |                       |            |
        |           |                       |            |
        +-----------+                       +------------+

   User : Alice

                          Figure 4: Interactions

   OAuth in [RFC6749] defines four grant types.  This specification uses
   the OAuth grant type "Implicit" explained in section 1.3.2 of
   [RFC6749] where the WebRTC client is issued an access token directly.
   The scope of the access token explained in section 3.3 of [RFC6749]
   MUST be TURN.

5.  Forming a Request

   When a TURN server responds that third party authorization is
   required, a TURN client re-attempts the request, this time including
   access token and kid values in ACCESS-TOKEN and USERNAME STUN
   attributes.  The TURN client includes a MESSAGE-INTEGRITY attribute
   as the last attribute in the message over the contents of the TURN
   message.  MESSAGE-INTEGRITY attribute is calculated using the long-
   term credentials mechanism specified in section 10.2 of [RFC5389],
   using the "kid" value from the returned JSON for its USERNAME
   attribute, and the "mac_key" value for the password input to the
   MESSAGE-INTEGRITY hash.

Reddy, et al.            Expires August 18, 2014                [Page 7]
Internet-Draft      TURN for 3rd party Authorization       February 2014

6.  TURN Server validating Request

   The TURN server, on receiving a request, performs checks listed in
   section 10.2.2 of [RFC5389] in addition to the following steps to
   verify that the access token is valid:

   o  The TURN server communicates with the authorization server to
      validate the token and fetches the metadata mac_key, lifetime etc
      associated with the token.  The communication mechanism between
      Resource server and Authorization server is discussed in
      [I-D.richer-oauth-introspection].

   o  The TURN server uses the mac_key to compute the value for the
      message integrity and if the resulting value does not match the
      contents of the MESSAGE-INTEGRITY attribute then it rejects the
      request with an error response 401 (Unauthorized).

   o  If all the checks pass, the TURN server continues to process the
      request.  Any response generated by the server MUST include the
      MESSAGE-INTEGRITY attribute, computed using the mac_key.

   A TURN response is discarded by the client if the value computed for
   message integrity using mac_key does not match the contents of the
   MESSAGE-INTEGRITY attribute.

7.  STUN Attributes

   The following new STUN attributes are introduced by this
   specification to accomplish third party authorization.

7.1.  THIRD-PARTY-AUTHORIZATION

   This attribute is used by the TURN server to inform the client that
   it supports third party authorization.  This attribute is used by the
   TURN server to inform the client that it supports third party
   authorization.  This attribute value be a URL that the client should
   contact, to obtain a token for third party authorization.  The format
   for the URL will be as described in [RFC3986].

7.2.  ACCESS-TOKEN

   The access token is issued by the authorization server.  OAuth does
   not impose any limitation on the length of the access token but since
   STUN messages cannot exceed 548 bytes (Section 7.1 of [RFC5389]),
   access token length needs to be restricted to fit within the maximum
   STUN message size.  The value of ACCESS-TOKEN is a variable-length
   value.  Its length MUST be less than 256 bytes and SHOULD be less
   than 64 bytes.

Reddy, et al.            Expires August 18, 2014                [Page 8]
Internet-Draft      TURN for 3rd party Authorization       February 2014

   Since the access token is valid for a period of time the resource
   server MUST cache it so that it does not need to be provided in every
   request from the client.  The ACCESS-TOKEN MUST only be included in
   the first request from the client to the server but MUST NOT be
   included in a subsequent request/response.

8.  Security Considerations

   When OAuth is used the interaction between the client and the
   authorization server requires Transport Layer Security (TLS) with a
   ciphersuite offering confidentiality protection.  The session key
   MUST NOT be transmitted in clear since this would completely destroy
   the security benefits of the proposed scheme.  The TURN server can
   also maintain a cache of used kid as an effective countermeasure
   against replay attacks.

9.  IANA Considerations

   IANA is requested to add the following attributes to the STUN
   attribute registry [iana-stun],

   o  THIRD-PARTY-AUTHORIZATION

   o  ACCESS-TOKEN

10.  Acknowledgements

   Authors would like to thank Dan Wing, Pal Martinsen for comments and
   review.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
              6749, October 2012.

Reddy, et al.            Expires August 18, 2014                [Page 9]
Internet-Draft      TURN for 3rd party Authorization       February 2014

   [iana-stun]
              IANA, , "IANA: STUN Attributes", April 2011,
              <http://www.iana.org/assignments/stun-parameters/stun-pa
              rameters.xml>.

11.2.  Informative References

   [I-D.ietf-rtcweb-overview]
              Alvestrand, H., "Overview: Real Time Protocols for Brower-
              based Applications", draft-ietf-rtcweb-overview-08 (work
              in progress), September 2013.

   [I-D.reddy-behave-turn-auth]
              Reddy, T., R, R., Perumal, M., and A. Yegin, "Problems
              with STUN Authentication for TURN", draft-reddy-behave-
              turn-auth-04 (work in progress), September 2013.

   [I-D.richer-oauth-introspection]
              Richer, J., "OAuth Token Introspection", draft-richer-
              oauth-introspection-04 (work in progress), May 2013.

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

   [RFC6819]  Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0
              Threat Model and Security Considerations", RFC 6819,
              January 2013.

Authors' Addresses

   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com

   Prashanth Patil
   Cisco Systems, Inc.
   Bangalore
   India

   Email: praspati@cisco.com

Reddy, et al.            Expires August 18, 2014               [Page 10]
Internet-Draft      TURN for 3rd party Authorization       February 2014

   Ram Mohan Ravindranath
   Cisco Systems, Inc.
   Cessna Business Park,
   Kadabeesanahalli Village, Varthur Hobli,
   Sarjapur-Marathahalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: rmohanr@cisco.com

   Justin Uberti
   Google
   747 6th Ave S
   Kirkland, WA
   98033
   USA

   Email: justin@uberti.name

Reddy, et al.            Expires August 18, 2014               [Page 11]