Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization
Extracted elements (30)
Long-term STUN username/password credentials cannot be kept secret in WebRTC JavaScript web applications, enabling unauthorized use if discovered. OAuth 2.0 ephemeral tokens limit the damage window even if a token is compromised.
Symmetric cryptography must be used for token encryption so that the encrypted token remains small enough to fit within a single STUN message. Asymmetric cryptography would produce tokens too large for STUN.
The AEAD associated data is bound to the STUN server name so that a client cannot reuse the same token to gain access to other STUN servers in the same administrative domain that share the same long-term symmetric key with an authorization server.
The 'Assertion' (self-contained) token type is used so that all information needed to validate the token is contained within the token itself. This avoids a protocol round-trip between the STUN server and the authorization server, reducing latency.
The OAuth 2.0 Implicit grant type is used so that the client is issued an access token directly by the authorization server. The string 'stun' is defined as the OAuth scope parameter for these tokens.
If a STUN client does not support or is not capable of performing third-party authorization (e.g., it cannot comprehend the THIRD-PARTY-AUTHORIZATION comprehension-optional attribute), it defaults to first-party authentication as defined in RFC 5389.
A key_length of 160 bits MUST be supported for the mac_key field within the token's encrypted_block, enabling use with HMAC-SHA-1 for STUN message integrity and supporting the hash agility plan in RFC 5389 Section 16.3.
A STUN server and authorization server implementation MUST support A256GCM as the authenticated encryption algorithm for the long-term symmetric key used to encrypt the self-contained token.
A STUN server and authorization server implementation SHOULD support REST-based key establishment (Section 4.1.1) even when manual provisioning is used, because manual configuration requires reconfiguration to rotate keys.
Any response generated by the STUN server MUST include the MESSAGE-INTEGRITY attribute computed using the mac_key extracted from the decrypted access token.
If a client comprehends the THIRD-PARTY-AUTHORIZATION attribute, it MUST ensure that third-party authorization takes precedence over first-party authentication as described in RFC 5389 Section 10.
If MESSAGE-INTEGRITY is absent from the server response, or if the value computed using mac_key does not match the MESSAGE-INTEGRITY attribute, the response MUST be discarded by the client.
Symmetric cryptography MUST be chosen to encrypt the self-contained token to ensure the token size is not large enough to exceed a single STUN message.
The AEAD associated data (A) MUST be the STUN server name, binding the token to a specific server and preventing its reuse against other STUN servers sharing the same long-term key.
The client MUST NOT examine the self-contained access token; its content is opaque to the client.
The STUN server and authorization server MUST establish the long-term symmetric key K over an authenticated secure channel.
The token's lifetime value MUST be greater than or equal to the OAuth 'expires_in' parameter (RFC 6749 Section 4.2.2); otherwise the resource server could revoke the token while the client still assumes it is valid and does not refresh.
The TURN client MUST include the ACCESS-TOKEN attribute only in Allocate and Refresh requests. The lifetime returned by the TURN server in Allocate and Refresh responses MUST be less than or equal to the remaining lifetime of the token.
When a TURN access token expires, the client MUST obtain a new token and MUST use it to refresh existing allocations, not only for new allocations, so only one token per TURN server need be maintained.
When HTTP interactions are used for long-term key establishment, HTTPS MUST be used for data confidentiality and TLS based on a client certificate MUST be used for mutual authentication between the STUN server and the authorization server.
The ACCESS-TOKEN STUN attribute is a comprehension-required attribute carrying the self-contained encrypted OAuth access token. The kid value identifying the keying material is placed in the USERNAME STUN attribute alongside the ACCESS-TOKEN.
The THIRD-PARTY-AUTHORIZATION STUN attribute is a comprehension-optional attribute sent by the STUN server in a 401 error response. Its value contains the STUN server name, which the client must supply to the authorization server to select the appropriate keying material for token generation.
IANA allocated the comprehension-optional codepoint 0x802E for the THIRD-PARTY-AUTHORIZATION STUN attribute defined in Section 6.1 of this document.
IANA allocated the comprehension-required codepoint 0x001B for the ACCESS-TOKEN STUN attribute defined in Section 6.2 of this document.
This document registers the 'stun-key' well-known URI suffix in the IANA Well-Known URIs registry (RFC 5785), used by STUN servers to retrieve long-term symmetric keys from the authorization server via REST over HTTPS.
All interaction between the STUN client and the authorization server requires TLS with a ciphersuite offering confidentiality protection, per RFC 7525 guidance. The session key MUST NOT be transmitted in clear, as doing so completely destroys the security benefits of the scheme.
An attacker may remove the THIRD-PARTY-AUTHORIZATION attribute from a 401 error response, forcing the client to fall back to weaker first-party authentication. This downgrade attack is mitigated by using TLS or DTLS as the STUN transport protocol.
Replay attacks using a captured ACCESS-TOKEN are mitigated by frequent nonce rotation (per RFC 5389 Section 10.2) and by server-side timestamp validation: a token is accepted only if lifetime + Delta > abs(RDnew - TS), with a recommended Delta of 5 seconds.
STUN third-party authorization flow: (1) client sends unauthenticated request; (2) server responds 401 Unauthorized with THIRD-PARTY-AUTHORIZATION and NONCE; (3) client fetches OAuth token from authorization server; (4) client retries with ACCESS-TOKEN (kid in USERNAME) and MESSAGE-INTEGRITY; (5) server validates token, timestamp, and integrity — success or 401.
The self-contained token format: nonce_length (uint16), nonce (opaque), then an encrypted_block containing key_length (uint16), mac_key (opaque), timestamp (uint64 fixed-point: 48-bit seconds since Unix epoch + 16-bit 1/64000-second fractions), and lifetime (uint32, seconds). All fields are in network byte order; the encrypted_block is base64-encoded for signaling to the client.