TRAM T. Reddy Internet-Draft P. Patil Intended status: Standards Track R. Ravindranath Expires: July 31, 2014 Cisco J. Uberti Google January 27, 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 July 31, 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 July 31, 2014 [Page 1] Internet-Draft TURN for 3rd party Authorization January 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 . . . . . . . . . . . . . . . . . . . . . . 9 7.3. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . . . 9 7.4. KEY-ID . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.5. MAC-ALGORITHM . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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. Reddy, et al. Expires July 31, 2014 [Page 2] Internet-Draft TURN for 3rd party Authorization January 2014 To achieve third party authorization, a resource owner eg WebRTC setver, authorizes a TURN client to access resources on the TURN server. Using OAuth, a client obtains an ephemeral token from an authorization server eg 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 server. 3. Solution Overview This specification uses the token type 'Assertion' (aka self- contained token) described in [RFC6819] 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 authorization server for token validation, thus reducing latency. 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 as JSON, along with other OAuth Parameters like token type, mac_key, mac_algorithm, kid, token lifetime etc. The client is oblivious to the content of the token. The token is securely 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 July 31, 2014 [Page 3] Internet-Draft TURN for 3rd party Authorization January 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, TIMESTAMP, KEY-ID, MAC-ALGORITHM | | | | | | | | | | | Allocate success response | | | |<------------------------------------------| | | | TURN Messages | | | | ////// integrity protected ////// | | | | ////// integrity protected ////// | | | | ////// integrity protected ////// | | Figure 1: TURN Third Party Authorization For example HTTP response from Authorization server: Reddy, et al. Expires July 31, 2014 [Page 4] Internet-Draft TURN for 3rd party Authorization January 2014 HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token": "eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDK0hTMjU2In0. pwaFh7yJPivLjjPkzC-GeAyHuy7AinGcS51AZ7TXnwkC80Ow1aW47kcT_UV54ubo nONbeArwOVuR7shveXnwPmucwrk_3OCcHrCbE1HR-Jfme2mF_WR3zUMcwqmU0RlH kwx9txo_sKRasjlXc8RYP-evLCmT1XRXKjtY5l44Gnh0A84hGvVfMxMfCWXh38hi", "token_type":"mac", "expires_in":1800, "refresh_token":"8xLOxBtZp8", "kid":"22BIjxU93h/IgwEb4zCRu5WF37s=", "mac_key":"adijq39jdlaska9asud", "mac_algorithm":"hmac-sha1-160" } Figure 2: Example 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 signalling the TURN client that the TURN server supports third party authorization. Reddy, et al. Expires July 31, 2014 [Page 5] Internet-Draft TURN for 3rd party Authorization January 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), key-id and mac_algorithm OAuth parameters from the authorization server as specified in [I-D.ietf-oauth-v2-http-mac]. 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. Both of these two key distribution steps are described in more detail in Section 4 of [I-D.ietf-oauth-v2-http-mac]. 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 July 31, 2014 [Page 6] Internet-Draft TURN for 3rd party Authorization January 2014 +---------------+ | +<******+ +------------->| Authorization | * | | Server | * | +----------|(WebRTC Server)| * AS-RS Key | | | | * (4) (1) | | +---------------+ * Access | | (2) * Token | | Access Token * Request | | + * | | Session Key * | | * | V V +-------+---+ +-+----=-----+ | | (3) | | | | TURN Request + Access | | | WebRTC | Token | TURN | | Client |---------------------->| Server | | (Alice) | | | | | | | +-----------+ +------------+ User : Alice ****: Out-of-Band Long-Term Key Establishment 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, timestamp, lifetime, kid and mac_algorithm values in ACCESS-TOKEN, TIMESTAMP, LIFETIME, KEY-ID and MAC-ALGORITHM STUN attributes. The TURN client includes a MESSAGE-INTEGRITY attribute as the last attribute in the message over the contents of the TURN message using the mac_key and mac_algorithm. MESSAGE-INTEGRITY attribute is calculated using the other rules specified in section 15.4 of [RFC5389]. Reddy, et al. Expires July 31, 2014 [Page 7] Internet-Draft TURN for 3rd party Authorization January 2014 The TURN client MUST not include the USERNAME attribute in the request. This differs from the long-term credential mechanism described in [RFC5389]. 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 mac_key is transported to the TURN server using the mechanism explained in section 4.2 of [I-D.ietf-oauth-v2-http-mac]. o The TURN server uses the mac_key and mac_algorithm to compute the value for the message integrity and if the resulting value does not match the contents of the MESSAGE-INTEGRITY attribute then reject the request with an error response 401 (Unauthorized). o The TURN server verifies that no replay took place by comparing the value in the TIMESTAMP attribute with the local time. The timestamp verification procedure is described in Section 6.1 of [I-D.ietf-oauth-v2-http-mac]. 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 and mac_algorithm. o The TURN server does not check for the presence of USERNAME. A TURN response is discarded by the client if the value computed for message integrity using mac_key and mac_algorithm 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 has no value part and thus the attribute length field is 0. Reddy, et al. Expires July 31, 2014 [Page 8] Internet-Draft TURN for 3rd party Authorization January 2014 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 513 bytes. 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. 7.3. TIMESTAMP 64-bit unsigned integer field containing a timestamp. The value indicates the time since January 1, 1970, 00:00 UTC, by using a fixed point format. In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/64K fractions of a second (Native format - Unix). 7.4. KEY-ID key id is an identifier generated by the resource server. This value selects the appropriate keying material for decryption. This keying material is a symmetric or an asymmetric long-term key established between the resource server and the authorization server, as shown in Figure 4 as AS-RS key. The establishment of this long-term key is outside the scope of this specification and discussed in Appendix A.2.3 of [I-D.ietf-oauth-v2-http-mac]. 7.5. MAC-ALGORITHM Indicates the MAC algorithm. The MAC Algorithm ID field contains an IKEv2 Transform ID of Transform Type 3 [RFC4306]. All TURN implementations MUST support AUTH_HMAC_SHA1_160 (7) [RFC4595]. 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. Other security considerations are discussed in [I-D.ietf-oauth-v2-http-mac]. Reddy, et al. Expires July 31, 2014 [Page 9] Internet-Draft TURN for 3rd party Authorization January 2014 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 o TIMESTAMP o KEY-ID o MAC-ALGORITHM 10. Acknowledgements Authors would like to thank Dan Wing, Pal Martinsen for comments and review. 11. References 11.1. Normative References [I-D.ietf-oauth-v2-http-mac] Richer, J., Mills, W., Tschofenig, H., and P. Hunt, "OAuth 2.0 Message Authentication Code (MAC) Tokens", draft-ietf- oauth-v2-http-mac-05 (work in progress), January 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, July 2006. [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 July 31, 2014 [Page 10] Internet-Draft TURN for 3rd party Authorization January 2014 [iana-stun] IANA, , "IANA: STUN Attributes", April 2011, . 11.2. Informative References [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Brower- based Applications", draft-ietf-rtcweb-overview-09 (work in progress), February 2014. [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. [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 July 31, 2014 [Page 11] Internet-Draft TURN for 3rd party Authorization January 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 July 31, 2014 [Page 12]