WebRTC Security Architecture
Extracted elements (31)
The browser serves as the user's Trusted Computing Base (TCB). Any security property the user wishes to enforce must ultimately be guaranteed by the browser or transitively by some property the browser verifies. If the browser is compromised, no security guarantees are possible.
The IdP proxy mechanism was designed so browsers need only know how to load the IdP's JavaScript from a deterministic well-known URI and call a generic API, without implementing any particular identity protocol. This allows a single browser to support any number of identity protocols including those that didn't exist when the browser was written.
Earlier drafts required DTLS 1.0 with TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA. At time of publication, some implementations do not support DTLS 1.2; endpoints which support only DTLS 1.2 might encounter interoperability issues with those older implementations.
All implementations MUST support DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 curve. The DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported. Implementations MUST favor cipher suites supporting Forward Secrecy and SHOULD favor AEAD over non-AEAD cipher suites.
Browser client implementations of WebRTC MUST implement ICE. Browser implementations MUST verify reachability via ICE prior to sending any non-ICE packets to a given destination. Implementations MUST NOT provide the ICE transaction ID to JavaScript during the lifetime of the transaction.
Browsers MUST NOT permit permanent screen or application sharing permissions to be installed as a response to a JS request. Browsers MUST provide a separate dialog request for screen/application sharing permissions, and MUST indicate any windows currently being shared in an unambiguous way.
Clients MUST treat HTTP and HTTPS origins as different permissions domains, because the security of the origin depends on authenticating content via HTTPS. Browsers that allow active mixed content MUST nevertheless disable WebRTC functionality in mixed content settings.
Each IdP MUST serve its initial entry page from a well-known URI constructed as: https://<authority>/.well-known/idp-proxy/<protocol>. An IdP MUST be loaded using HTTPS. The separator characters '/' and '\' MUST NOT be permitted in the protocol field. The IdP MAY redirect but MUST retain the 'https:' scheme.
Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a 'no_renegotiation' alert if offered. Endpoints MUST NOT implement TLS False Start.
Implementations MUST obtain explicit user consent prior to providing access to the camera and/or microphone. Implementations MUST refuse all permissions grants for HTTP origins, as HTTP origins cannot be securely established against network attackers.
Implementations MUST support SRTP, DTLS, DTLS-SRTP, and SCTP over DTLS. All media channels MUST be secured via SRTP and SRTCP. Media traffic MUST NOT be sent over plain (unencrypted) RTP or RTCP; implementations MUST NOT negotiate cipher suites with NULL encryption modes.
The API MUST generate a new authentication key pair for every new call by default (for unlinkability). Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin to avoid creating a super-cookie. The API MUST NOT permit JS to obtain the negotiated DTLS-SRTP keying material.
The API MUST provide a mechanism to allow JS to suppress ICE negotiation until the user decides to answer a call. The API MUST provide a mechanism for the calling application JS to indicate that only TURN candidates are to be used, and MUST also permit suppression of the related address field.
The browser MUST generate the input to the IdP assertion process and display verification results to the user in a way that cannot be imitated by the calling site. The IdP proxy on the sender's side MUST ensure it is running in the IdP's origin prior to issuing assertions.
The 'identity' attribute MUST be bound to all 'fingerprint' attributes in the session description. Implementations SHOULD only include a single 'identity' attribute in an offer or answer. If identity verification fails, the answerer MUST discard the offer or answer as malformed.
The identity provided from the IdP to the RP browser MUST be a string in the form '<user>@<domain>'. If the 'domain' portion equals the IdP proxy domain, the assertion is valid (authoritative). If not, the PeerConnection MUST reject the assertion unless the IdP domain is explicitly trusted as a third-party IdP and local policy permits it.
The RP browser MUST verify that the in-use certificate for a DTLS connection is in the set of fingerprints returned from the IdP when verifying an assertion. The 'identity' attribute MUST include all 'fingerprint' values from the session description.
The UI MUST clearly indicate when the user's camera and microphone are in use. This indication MUST NOT be suppressible by JavaScript and MUST clearly indicate how to terminate device access, providing a UI means to immediately stop camera/microphone input without JS being able to prevent it.
WebRTC implementations MUST NOT offer SDP security descriptions (RFC 4568) or select it if offered. An SRTP Master Key Identifier (MKI) MUST NOT be used. DTLS-SRTP MUST be offered for every media channel.
WebRTC implementations MUST periodically send keepalives using the consent freshness mechanism specified in RFC 7675. If a keepalive fails and no new ICE channels can be established, then the session is terminated.
When modifying a session, if the set of fingerprints changes, the sender MUST either send a new 'identity' attribute or none at all, and the receiver MUST discard all previously established identities. If fingerprints are unchanged and the same 'identity' attribute is sent, the established identity MUST be applied to existing DTLS connections.
Any identifier persisting across multiple calls is a privacy risk for anonymous calling services. Such services SHOULD instruct the browser to use separate DTLS keys for each call and use TURN throughout. Browsers SHOULD implement the privacy-preserving CNAME generation mode of RFC 7022 to prevent cross-call correlation.
ICE by default reveals the user's IP address to the peer, leaking location information. The API must provide mechanisms to suppress ICE negotiation until call answer, restrict to TURN-only candidates, and suppress the related address field. These protections assume a non-malicious calling service; users needing privacy from the calling site must use separate technologies like Tor.
The IdP proxy is JavaScript downloaded from a well-known URI at the IdP's domain and runs in an isolated security context within the browser. The PeerConnection component communicates with it via a secure message-passing channel. The proxy performs both identity assertion generation and verification, decoupling the browser from any specific identity protocol.
The SDP 'identity' attribute is a session-level attribute used to convey an endpoint's identity assertion to its peer. The identity-assertion value is base64-encoded JSON containing two keys: 'assertion' (an opaque IdP-consumed string) and 'idp' (a dictionary identifying the IdP by domain and protocol).
This document registers the 'idp-proxy' well-known URI suffix from RFC 8615. The URI is used to locate the IdP proxy JavaScript entry page for WebRTC identity provider integration.
This document registers the SDP 'identity' attribute per RFC 4566 Section 8.2.4. It is a session-level, non-charset-dependent attribute carrying an identity assertion that binds an identity to the transport-level security session. Mux Category: NORMAL.
An attacker can cross-connect offers and answers to induce multiple browsers to send media to a victim (large-scale parallel forking attack). Implementations can defend by only responding to ICE Binding Requests for a limited number of remote ufrags, which is the reason JS must not control the ufrag and password.
Because a broad range of characters are permitted in identity strings, attackers may craft identities confusable with other identities (homograph attacks). Those presenting identifiers to users should consider highlighting cases of mixed script usage per RFC 5890 Section 4.4.
If HTTPS is not used and the identity mechanism is not used, any on-path attacker can replace DTLS-SRTP fingerprints and substitute its own identity. Even with HTTPS, the signaling server can mount a MITM attack. Content JavaScript MUST NOT be allowed to access or perform computations with DTLS keys, including performing operations that would be valid for a DTLS endpoint.
The identity-assertion value is a JSON object base64-encoded per RFC 4648. The JSON contains 'idp' (with 'domain' and optional 'protocol' keys) and 'assertion' (an opaque string). The 'identity' attribute binds to all 'fingerprint' attributes in the session description. Syntax: identity-assertion-value = base64 *(SP identity-extension).