|RFC 8833||ALPN for WebRTC||January 2021|
- Internet Engineering Task Force (IETF)
- Standards Track
Application-Layer Protocol Negotiation (ALPN) for WebRTC
This document specifies two Application-Layer Protocol Negotiation (ALPN) labels for use with Web Real-Time Communication (WebRTC). The "webrtc" label identifies regular WebRTC: a DTLS session that is used to establish keys for the Secure Real-time Transport Protocol (SRTP) or to establish data channels using the Stream Control Transmission Protocol (SCTP) over DTLS. The "c-webrtc" label describes the same protocol, but the peers also agree to maintain the confidentiality of the media by not sharing it with other applications.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Different WebRTC uses can be advertised and behavior can be constrained to what is appropriate to a given use. In particular, this allows for the identification of sessions that require confidentiality protection from the application that manages the signaling for the session.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following identifiers are defined for use in ALPN:¶
- The DTLS session is used to establish keys for the Secure Real-time Transport Protocol (SRTP) -- known as DTLS-SRTP -- as described in [RFC5764]. The DTLS record layer is used for WebRTC data channels [RFC8831].¶
- The DTLS session is used for confidential WebRTC, where peers agree to maintain the confidentiality of the media, as described in Section 3. The confidentiality protections ensure that media is protected from other applications, but the confidentiality protections do not extend to messages on data channels.¶
Both identifiers describe the same basic protocol: a DTLS session that is used to provide keys for an SRTP session in combination with WebRTC data channels. Either SRTP or data channels could be absent. The data channels send the Stream Control Transmission Protocol (SCTP) [RFC4960] over the DTLS record layer, which can be multiplexed with SRTP on the same UDP flow. WebRTC requires the use of Interactive Connectivity Establishment (ICE) [RFC8445] to establish UDP flow, but this is not covered by the identifier.¶
There is no functional difference between the identifiers except that an endpoint
c-webrtc makes a promise to preserve the
confidentiality of the media it receives.¶
A peer that is not aware of whether it needs to request confidentiality can use either
identifier. A peer in the client role MUST offer both identifiers if it is not aware of a
need for confidentiality. A peer in the server role SHOULD select
webrtc if it does not prefer either.¶
An endpoint that requires media confidentiality might negotiate a session with a peer that
does not support this specification. An endpoint MUST abort a session if it requires
confidentiality but does not successfully negotiate
peer that is willing to accept
webrtc SHOULD assume that a peer
that does not support this specification has negotiated
unless signaling provides other information; however, a peer MUST NOT assume that
c-webrtc has been negotiated unless explicitly negotiated.¶
Private communications in WebRTC depend on separating control (i.e., signaling) capabilities and access to media [RFC8827]. In this way, an application can establish a session that is end-to-end confidential, where the ends in question are user agents (or browsers) and not the signaling application. This allows an application to manage signaling for a session without having access to the media that is exchanged in the session.¶
Without some form of indication that is securely bound to the session, a WebRTC endpoint is unable to properly distinguish between a session that requires this confidentiality protection and one that does not. The ALPN identifier provides that signal.¶
A browser is required to enforce this confidentiality protection using isolation controls
similar to those used in content cross-origin protections
(see the "Origin" section of [HTML5]).
These protections ensure that media is protected from
applications, which are not able to read or modify the contents of a protected flow
of media. Media that is produced from a session using the
c-webrtc identifier MUST only be displayed to users.¶
The promise to apply confidentiality protections do not apply to data that is sent using data channels. Confidential data depends on having both data sources and consumers that are exclusively browser or user based. No mechanisms currently exist to take advantage of data confidentiality, though some use cases suggest that this could be useful, for example, confidential peer-to-peer file transfer. Alternative labels might be provided in the future to support these use cases.¶
This mechanism explicitly does not define a specific authentication method; a WebRTC endpoint that accepts a session with this ALPN identifier MUST respect confidentiality no matter what identity is attributed to a peer.¶
RTP middleboxes and entities that forward media or data cannot promise to maintain
confidentiality. Any entity that forwards content, or records content for later access by
entities other than the authenticated peer, MUST NOT offer or accept a session with the
Confidential communications depend on more than just an agreement from browsers.¶
This is not a digital rights management mechanism. A user is not prevented from using other mechanisms to record or forward media. This means that (for example) screen-recording devices, tape recorders, portable cameras, or a cunning arrangement of mirrors could variously be used to record or redistribute media once delivered. Similarly, if media is visible or audible (or otherwise accessible) to others in the vicinity, there are no technical measures that protect the confidentiality of that media.¶
The only guarantee provided by this mechanism and the browser that implements it is that the media was delivered to the user that was authenticated. Individual users will still need to make a judgment about how their peer intends to respect the confidentiality of any information provided.¶
On a shared computing platform like a browser, other entities with access to that platform (i.e., web applications) might be able to access information that would compromise the confidentiality of communications. Implementations MAY choose to limit concurrent access to input devices during confidential communications sessions.¶
For instance, another application that is able to access a microphone might be able to sample confidential audio that is playing through speakers. This is true even if acoustic echo cancellation, which attempts to prevent this from happening, is used. Similarly, an application with access to a video camera might be able to use reflections to obtain all or part of a confidential video stream.¶
webrtclabel identifies mixed media and data communications using SRTP and data channels:¶
c-webrtclabel identifies WebRTC with a promise to protect media confidentiality:¶
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, , <https://www.rfc-editor.org/info/rfc5764>.
- Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, , <https://www.rfc-editor.org/info/rfc6347>.
- Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, , <https://www.rfc-editor.org/info/rfc7301>.
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
- Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, , <https://www.rfc-editor.org/info/rfc8827>.
- Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, , <https://www.rfc-editor.org/info/rfc8831>.
- WHATWG, "HTML - Living Standard", Section 7.5, , <https://html.spec.whatwg.org/#origin>.
- Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, , <https://www.rfc-editor.org/info/rfc4960>.
- Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, , <https://www.rfc-editor.org/info/rfc8445>.
- Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, , <https://www.rfc-editor.org/info/rfc8825>.
- Alvestrand, H., "Transports for WebRTC", RFC 8835, DOI 10.17487/RFC8835, , <https://www.rfc-editor.org/info/rfc8835>.