Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers
Extracted elements (15)
No generic URI parameters were added to TURN URIs in order to prevent compatibility issues, as discussed at IETF 72 in Dublin.
The <password> component is excluded from TURN URIs because it is deprecated in RFC 3986. The <username> and <auth> components are also excluded because they do not guide the RFC 5928 resolution mechanism.
The suffix "s" on the "turns" scheme was retained rather than moving the secure option to a URI parameter (e.g., ";proto=tls") in order to preserve symmetry with the STUN URI scheme, which also uses a "stuns" variant rather than a parameter.
TURN URIs are defined as opaque (non-hierarchical) URIs, following the advice of RFC 4395 Section 2.2, because the TURN URI does not describe a hierarchical structure.
The "turn" and "turns" URI schemes are designed to provision the four components (secure flag, host, port, transport) required by the RFC 5928 TURN Resolution Mechanism without modification. Applications using these URIs must pass the components directly to that algorithm.
Developers MUST NOT use a generic hierarchical URI parser to parse a "turn" or "turns" URI. Although <host> and <port> are defined in RFC 3986 as components of generic hierarchical URIs, the "turn" and "turns" schemes are opaque, not hierarchical.
The "turns" URI scheme MUST be used when TURN is run over TLS-over-TCP (or, in the future, DTLS-over-UDP). The "turn" scheme MUST be used otherwise. The <secure> flag is set to false for "turn" and true for "turns" when passed to the RFC 5928 algorithm.
If the <port> component is absent, the default port is 3478 for both UDP and TCP transports. The default port for TURN over TLS is 5349. When present, the port denotes where the TURN server awaits connection requests.
The <secure> component derived from the URI scheme name (false for "turn", true for "turns") is one of the four components — along with host, port, and transport — passed to the RFC 5928 TURN Resolution Mechanism to produce a list of IP address, port, and transport tuples.
The TURN URI scheme syntax is defined as: turnURI = scheme ":" host [ ":" port ] [ "?transport=" transport ], where scheme is "turn" or "turns" and transport is "udp", "tcp", or an extension token. The <host>, <port>, and <transport> components are passed without modification to the RFC 5928 resolution algorithm.
The "turn" URI scheme is registered with IANA as a permanent URI scheme (per RFC 4395). It is intended for applications identifying a TURN server for NAT traversal. The IESG is the change controller.
The "turns" URI scheme is registered with IANA as a permanent URI scheme (per RFC 4395). It is intended for applications identifying a TURN server for NAT traversal over a secure (TLS) connection. The IESG is the change controller.
A TURN client MUST ensure that the username, password, "turns" URI, and any other security-relevant parameters are received with equivalent security before using the "turns" URI. Receiving those parameters over a TLS session with commensurate ciphersuites can provide appropriate security.
Although a "turns" URI does not itself carry credentials, in WebRTC environments username and password will typically be provisioned remotely at the same time as the URI. If those credentials are received in the clear, using a "turns" URI provides little or no security benefit.
Security considerations for the TURN resolution mechanism, including normative authentication procedures for TLS clients, are defined in Section 5 of RFC 5928. The "turn" and "turns" URI schemes do not introduce specific security issues beyond those in RFC 3986.