One document matched: draft-reddy-tram-turn-third-party-authz-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-reddy-tram-turn-third-party-authz-00"
ipr="trust200902">
<front>
<title abbrev="TURN for 3rd party Authorization ">TURN Extension for Third
Party Authorization</title>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<street></street>
<city>Bangalore</city>
<country>India</country>
</postal>
<email>praspati@cisco.com</email>
</address>
</author>
<author fullname="Ram Mohan Ravindranath" initials="R."
surname="Ravindranath">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park,</street>
<street>Kadabeesanahalli Village, Varthur Hobli,</street>
<street>Sarjapur-Marathahalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>rmohanr@cisco.com</email>
</address>
</author>
<author fullname="Justin Uberti" initials="J." surname="Uberti">
<organization>Google</organization>
<address>
<postal>
<street>747 6th Ave S</street>
<street>Kirkland, WA</street>
<code>98033</code>
<country>USA</country>
</postal>
<email>justin@uberti.name</email>
</address>
</author>
<date />
<workgroup>TRAM</workgroup>
<abstract>
<t>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 <xref
target="I-D.reddy-behave-turn-auth"></xref>.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>TURN <xref target="RFC5766"></xref> 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.</t>
<t>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 <xref
target="I-D.reddy-behave-turn-auth"></xref>, this document proposes the
use of third party authorization using OAuth for TURN.</t>
<t>To achieve third party authorization, a resource owner e.g. WebRTC
server, authorizes a TURN client to access resources on the TURN
server.</t>
<t>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.</t>
</section>
<section anchor="term" title="Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t><list style="symbols">
<t>WebRTC Server: A web server that supports WebRTC <xref
target="I-D.ietf-rtcweb-overview"></xref>.</t>
<t>Access Token: OAuth 2.0 access token.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section anchor="problem_stmt" title="Solution Overview">
<t>This specification uses token type 'Handle' (or artifact) described
in <xref target="RFC6819"></xref>. 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.</t>
<t><figure anchor="figure1" title="TURN Third Party Authorization">
<artwork><![CDATA[
+-------------------+ +--------+ +---------+
| ......... 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 ////// | |
]]></artwork>
</figure></t>
<t>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.</t>
<t>For example HTTP response from Authorization server:</t>
<figure anchor="Example" title="Example">
<preamble></preamble>
<artwork align="left"><![CDATA[
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"
}
]]></artwork>
</figure>
<t>Handle token type is selected for the following reasons:</t>
<t><list style="numbers">
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section anchor="oauth" title="Obtaining a Token Using OAuth">
<t>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.</t>
<figure anchor="oauth_webrtc_terminology_map"
title="OAuth terminology mapped to WebRTC terminology">
<preamble>The following mapping of OAuth concepts to WebRTC is used
:</preamble>
<artwork align="left"><![CDATA[
+----------------------+----------------------------+
| OAuth | WebRTC |
+======================+============================+
| Client | WebRTC client |
+----------------------+----------------------------+
| Resource owner | WebRTC server |
+----------------------+----------------------------+
| Authorization server | Authorization server |
+----------------------+----------------------------+
| Resource server | TURN Server |
+----------------------+----------------------------+
]]></artwork>
</figure>
<t>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 <xref
target="interactions"></xref>.</t>
<figure anchor="interactions" title="Interactions">
<artwork align="left"><![CDATA[
+---------------+ 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
]]></artwork>
</figure>
<t>OAuth in <xref target="RFC6749"></xref> defines four grant types.
This specification uses the OAuth grant type "Implicit" explained in
section 1.3.2 of <xref target="RFC6749"></xref> where the WebRTC client
is issued an access token directly. The scope of the access token
explained in section 3.3 of <xref target="RFC6749"></xref> MUST be
TURN.</t>
</section>
<section anchor="Request" title="Forming a Request">
<t>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 <xref
target="RFC5389"></xref>, 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.</t>
</section>
<section anchor="Response" title="TURN Server validating Request">
<t>The TURN server, on receiving a request, performs checks listed in
section 10.2.2 of <xref target="RFC5389"></xref> in addition to the
following steps to verify that the access token is valid:</t>
<t><list style="symbols">
<t>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 <xref
target="I-D.richer-oauth-introspection"></xref>.</t>
<t>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).</t>
<t>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.</t>
</list></t>
<t>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.</t>
</section>
<section title="STUN Attributes">
<t>The following new STUN attributes are introduced by this
specification to accomplish third party authorization.</t>
<section anchor="attribute" title="THIRD-PARTY-AUTHORIZATION">
<t>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 <xref
target="RFC3986"></xref>.</t>
</section>
<section anchor="token" title="ACCESS-TOKEN">
<t>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 <xref
target="RFC5389"></xref>), 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.</t>
<t>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.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>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.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>IANA is requested to add the following attributes to the <xref
target="iana-stun">STUN attribute registry</xref>, <list style="symbols">
<t>THIRD-PARTY-AUTHORIZATION</t>
<t>ACCESS-TOKEN</t>
</list></t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>Authors would like to thank Dan Wing, Pal Martinsen for comments and
review.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include="reference.RFC.6749"?>
<?rfc include="reference.RFC.3986"?>
<reference anchor="iana-stun"
target="http://www.iana.org/assignments/stun-parameters/stun-pa rameters.xml">
<front>
<title>IANA: STUN Attributes</title>
<author fullname="IANA" surname="IANA">
<organization></organization>
</author>
<date month="April" year="2011" />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-rtcweb-overview'?>
<?rfc include='reference.I-D.reddy-behave-turn-auth'?>
<?rfc include='reference.I-D.richer-oauth-introspection'?>
<?rfc include="reference.RFC.5766"?>
<?rfc include="reference.RFC.6819"?>
<!---->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:39:41 |