+---------------+
                        |               +<******+
         +------------->| Authorization |       *
         |              | Server        |       *    
         |   +----------|(WebRTC Server)|       *  AS-RS,  
         |   |          |               |       *  AUTH keys    
(2)      |   |           +---------------+      *   (1)
Access   |   |  (3)                             *
Token    |   | Access Token                     *
Request  |   |    +                             *
         |   | Session Key                      *
         |   |                                  *
         |   V                                  V
     +-------+---+                       +-+----=-----+
     |           |         (4)           |            |
     |           | TURN Request + Access |            |
     | WebRTC    | Token                 | TURN       |
     | Client    |---------------------->| Server     |
     | (Alice)   | Allocate Response     |            |
     |           |<----------------------|            |
     +-----------+                       +------------+
                                                  
User : Alice
****: Out-of-Band Long-Term Key Establishment

Figure 5: 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.

4.1. Key Establishment

The TURN and authorization servers establish symmetric key (AS-RS key) for confidentiality and authentication key (AUTH key) for integrity, using an out of band mechanism. The Token is encrypted using Advanced Encryption Standard (AES) in Cipher Block Chaining (CBC) mode, using the AS-RS key for confidentiality.The default AS-RS key size is 128 bits, and all implementations MUST support this key size. Implementations MAY also support key sizes of 192 bits and 256 bits. Symmetric keys MUST be chosen to ensure that the size of encrypted token is not large. Usage of asymmetric keys will result in large encrypted tokens which may not fit into a single STUN message. The integrity of the token is calculated with the AUTH key and using HMAC-SHA-256-128 algorithm. AUTH key length MUST be 256-bit (section 2.6 of [RFC4868]). Authorization server MUST also also signal a unique key identifier (kid) to the TURN server which will be used to select the appropriate keying material for decryption.

The TURN and Authorization servers MUST establish the symmetric key over an authenticated secure channel. For example, the two servers could choose to use Dynamic Symmetric Key Provisioning Protocol [RFC6063] or simply use HTTP for this exchange. The following example describes HTTP interactions that could be used to obtain the symmetric key.

4.1.1. HTTP interactions

To retrieve a new set of symmetric keys, the TURN server makes an HTTP GET request to the Authorization server, specifying TURN as the service to allocate the symmetric keys for, and optionally specifying the domain name/IP Address of the TURN server. The response is returned with content-type "application/json", and consists of a JSON object containing the symmetric key.

Request
-------

service - specifies the desired service (turn)
domain - an optional domain to be associated with the key

example: GET /?service=turn&domain=turn.example.com


Response
--------

ckey - symmetric key (AS-RS key)
akey - authentication key (AUTH key)
ttl - the duration for which the key is valid, in seconds.

example:
    {
     "ckey" : "ESIzRFVmd4iZABEiM0RVZgKn6WjLaTC1",
     "akey" : "FXAghRMVTzkBGNaaN496523WIISKerLi",
     "ttl" : 86400,
     "kid" :"22BIjxU93h/IgwEb"
    }

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 for computing the message integrity.

6. STUN Attributes

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

6.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 optional 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]. The THIRD-PARTY-AUTHORIZATION attribute is a comprehension-optional attribute (see Section 15 from [RFC5389]).

The TURN server may have tie-up with multiple authorization servers so the client MUST provide the TURN server domain name or IP address to the authorization server so that it can select the appropriate keying material to generate the self-contained token.

6.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 if path MTU is unknown then STUN messages over IPv4 would need to be less than 548 bytes (Section 7.1 of [RFC5389]), access token length needs to be restricted to fit within the maximum STUN message size. Note that the self-contained token is opaque to the client and it MUST NOT examine the ticket. The ACCESS-TOKEN attribute is a comprehension-optional attribute (see Section 15 from [RFC5389]).

The token is structured as follows:

      struct {
          ushort key_length;
          opaque mac_key[key_length];
          opaque timestamp[8];
          long   lifetime;
          opaque mac[16];
      } token;